gorgeous-country-43026
06/30/2021, 1:44 PMpulumi up
fails for me because Pulumi insists it has to replace all Kubernetes namespaces but when it tries to do that it fails since it apparently tries to create a new namespace with equal name first (since I have forced explicit names for a good reason) and that naturally won't work. Digged into the diff and it shows this
[provider: urn:pulumi:dev::my-project::pulumi:providers:kubernetes::k8s-provider::efaab349-6f4f-42ff-a607-ee6ab55cbb61 => urn:pulumi:dev::my-project::pulumi:providers:kubernetes::default_3_1_2::7b6466de-7864-49f9-8c33-0ece6217519a]
Which makes absolutely no sense to me. That is the only thing it is trying to change. This is 100% Pulumi internal stuff, apparently for some reason the provider has changed?pulumi refresh
doesn't seem to helpbillowy-army-68599
06/30/2021, 1:49 PMgorgeous-country-43026
06/30/2021, 1:49 PMbillowy-army-68599
06/30/2021, 1:50 PMgorgeous-country-43026
06/30/2021, 1:50 PMrandom.RandomUuid
in a typescript namespace where it is being referred in one of the namespaces relatedk8s-provider
to default_3_1_2
whatever that isbillowy-army-68599
06/30/2021, 1:54 PMgorgeous-country-43026
06/30/2021, 1:54 PM{ providers: myK8sProvider }
somewherek8sProvider
which would match, although in kebab-casebillowy-army-68599
06/30/2021, 2:00 PMgorgeous-country-43026
06/30/2021, 2:01 PMbillowy-army-68599
06/30/2021, 2:04 PMgorgeous-country-43026
06/30/2021, 2:05 PMconst grafanaIni = oauth.grafanaClientSecret.result.apply(secret => {
return `
[azure]
managed_identity_enabled = true
[security]
disable_gravatar = true
[auth]
oauth_auto_login = true
disable_login_form = true
signout_redirect_url = https://${GRAFANA_DOMAIN}
[auth.generic_oauth]
name = Keycloak
enabled = true
allow_sign_up = false
client_id = grafana
client_secret = ${secret}
scopes = user:email
empty_scopes = false
email_attribute_name = email:primary
`
});
const grafanaIni = "";
all the provider changes go awayoauth.grafanaClientSecret
is new random.RandomUuid("grafana-client-secret");
billowy-army-68599
06/30/2021, 2:48 PMgorgeous-country-43026
06/30/2021, 2:49 PMk8s.Provider
that the code was referring to was still null
. This lead the opts object to be effectively { provider: null }
which Pulumi considers to be "you have not set this, I'll just use the ~/.kube/config
value". Which in this case pointed to that exact same Kubernetes cluster since I was actively operating with it. This caused Pulumi to create the default Provider which had a different name, thus the default_3_2_1
we saw in the state.
The one thing that I can think of that would save from this issue would be a configuration parameter somewhere which would enforce the user to always to set the provider and if he fails to do this then it would be an error. The more I think of this then the less it makes sense that it is even legal to not provide the provider since that makes the code non-idempotent. End result can be very different based on external configurations not controlled by Pulumi in any way. To me it would make sense Pulumi would always require an explicit provider and one would have to set that up first.
I know this change would be backwards incompatible but it just might be worth it via deprecation warning. You may disagree and that's fine, but I think this kind of situation where one can corrupt the remote state just by placing one innocent import into wrong place is not exactly great.billowy-army-68599
07/01/2021, 8:56 AMgorgeous-country-43026
07/01/2021, 9:25 AMbillowy-army-68599
07/01/2021, 9:32 AMgorgeous-country-43026
07/01/2021, 9:34 AM