https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
w
You can use 
import: <id>
to import the resource, and can make changes (like changing 
minReplicas
from 2 to 1) after the import succeeds as long as they do not cause the resources to be replaced (which would change the 
id
). I believe that meets the needs of this scenario - both for standing up new stacks and for updating them later?
c
I’m not sure it does though. Do you not need to remove import after it imports?
I could have sworn you did.
Which is the problem I am referring to. In this scenario, import should never be removed because it needs to import on any new stack
w
You only have to remove 
import
if the resource is going to be replaced (hence changing its 
id
).
c
Ooh. I thought I saw that it has to be removed somewhere.
I’m trying it out right now
Having problems importing it as it keeps telling me there are differences, even when I use the exact yaml right from the cluster.
inputs to import do not match the existing resource; importing this resource will fail
Because it thinks there is a diff with the spec and metadata.labels.
So something is wrong here unless this is by design, in which case, we go back to the problem of if I create a new stack, I need to temporarily modify my code to allow it to import
w
What diff does it show you? If you fix that diff in the source, do things work?
c
Yes, if I remove the labels and the spec it works.
I’m gonna see if it wants to make a change now with me not having defined those labels
and the spec
If so, the importing logic is broken from a user perspective
Ok, so on up, it does not try to make any changes. I’m performing a refresh right now
Ok, so the way importing works is very weird. I would have expected it to show a diff because the resource in k8s does not match what is in pulumi
If I add back the spec, section, pulumi thinks that it is all new
Even though the resource actually has that spec
So something is really broken here
So there are 2 issues: 1) When running a refresh/up, it should notice there is a difference between what is in the inputs and what is in the cluster. 2) When doing the import, it should not complain that there is a mismatch, because there isn’t. Instead, it’s requiring the exclusion of the spec and the labels in order for it to import. This is the initial cause of the issue here.
I’m thinking the cause of this is that in order to make the developer experience better, pulumi’s import was designed with requiring a minimal amount of definition for the resource. Unfortunately, this is a problem when you want to have a resource remain with 
import: ...
so that if a new stack is created, it will import it.
s
Hi @cool-egg-852, I stumbled upon this thread in search for an import problem solution. Do I got your problem right that you’re managing a Kubernetes resource 
R
in 
stack A
. Then you’re creating a new 
stack B
and want to import 
R
into that, as well. Right? If so, then you’re managing the same resource 
R
in two different stacks. Then a change of 
R
in one stack, say 
stack A
, interferes with the same 
R
in 
stack B
. Why do you want that? Wouldn’t be a 
StackReference
the correct thing you want here? (https://www.pulumi.com/docs/intro/concepts/organizing-stacks-projects/#inter-stack-dependencies)
c
@stocky-island-3676 Hi. No, that isn’t the scenario. The scenario is that there’s 
stack A
which contains the GKE cluster with the 
istio
addon enabled. In order to make istio highly available, I needed to be able to change the 
minReplicas
. Because we wanted to do everything in IaC, we had to import the resource. But when we go to create 
stack B
, we didn’t want to have to manipulate the code again by adding the 
import
option, and again anytime we add a new stack. In the end we ended up not using the 
istio
addon because it’s not ready for production, nor do I feel that it will be anytime soon, even if they make it 
GA
because Google doesn’t seem to know what they are doing.
s
I see. So, in this case, I would say you would have better used the 
.get()
method on the HPA resource. That way the resource is dynamically referenced (even if it would have worked out with the 
import:
here, as well, when you simply have a different K8s provider per stack). Did the 
minReplicas
value stay with what you’ve set? Or was it maybe automatically set back soon afterwards?
2 Views
Open in Slack
PreviousNext
Powered by