Hi @ihcsim @siggy

In my view, the point of --from-manifests is to allow air-gapped upgrades. As per comment linkerd/linkerd2#3559 (comment), my install was done via linkerd install > linkerd-install.yaml, the yaml saved to a git repo and argocd deploying the yaml.

Each cluster has a separate linkerd-install.yaml, containing it's specific config.

I've previously been able to do linkerd upgrade --from-manifests ./install-prod.yaml > ./install-prod.yaml and commit the new manifest without the upgrade process touching the cluster. This avoids accidentally pulling in a dev/staging config from the cluster and saving it in the prod manifest, depending on where the kube context happens to be pointing

kubectl -n linkerd get \
  secret/linkerd-identity-issuer \
  configmap/linkerd-config \
  -oyaml > linkerd-manifests.yaml

defeats the purpose of --from-manifests, in my view

@jon-walton Understood. We have a fix for it in linkerd/linkerd2#3569, which is very close to getting merged. The reason why the docs mentioned kubectl -n linkerd get secret/linkerd-identity-issuer configmap/linkerd-config -oyaml > linkerd-manifests.yaml is because those are the resources that upgrade pulls from the cluster. But yes, we will definitely continue to support the linkerd upgrade --from-manifests ./install-prod.yaml > ./install-prod.yaml use case.

Meanwhile, are you blocked by this? As you mentioned in slack, the APIService kind is the problematic one.