Upgrading installs fails on final step

[merenbach]

Steps to reproduce:

1. Set up a new argocd installation (I'm using Minikube).
2. Build the project (make, although make cli may be sufficient).
3. Run ./dist/argocd install
4. Run ./dist/argocd install --upgrade

Expected output does not include the final line:

$ ./dist/argocd install --upgrade
Namespace 'argocd' up-to-date
CustomResourceDefinition 'applications.argoproj.io' up-to-date
ServiceAccount 'application-controller' up-to-date
Role 'application-controller-role' up-to-date
RoleBinding 'application-controller-role-binding' up-to-date
Deployment 'application-controller' up-to-date
ServiceAccount 'argocd-server' up-to-date
Role 'argocd-server-role' up-to-date
RoleBinding 'argocd-server-role-binding' up-to-date
Deployment 'argocd-server' up-to-date
Service 'argocd-server' up-to-date
Deployment 'argocd-repo-server' up-to-date
FATA[0000] Service "argocd-repo-server" is invalid: [metadata.resourceVersion: Invalid value: "": must be specified for an update, spec.clusterIP: Invalid value: "": field is immutable]

This may be related to https://github.com/kubernetes/kubernetes/issues/11237. It's possible that this could be addressed with a tweak to how we invoke K8s.

[merenbach]

I'm having trouble reproducing now. This may have gotten fixed, perhaps from updates to the underlying software. Suggesting closing as cannot-reproduce. @alexmt or @jessesuen any chance we can verify whether this is reproducible locally?

[jessesuen]

I think this is fixed now after moving to the bundled manifests as part of installer.

The error "spec.clusterIP: Invalid value: "": field is immutable", only happens if you attempt to change a immutable field like LoadBalancer -> ClusterIP.

I suspect we might have been hard-wiring "ClusterIP" in our services in our previous installer. So if a user manually changed the type to LoadBalancer, we would have hit the error during the next upgrade.

Currently we do not hard-wire the service type, so we will no longer detect a difference in the YAMLs and subsequently do not consider the installation as needing an "upgrade"