cool-egg-85208/14/2019, 4:53 AM
to import the resource, and can make changes (like changing
from 2 to 1) after the import succeeds as long as they do not cause the resources to be replaced (which would change the
). I believe that meets the needs of this scenario - both for standing up new stacks and for updating them later?
cool-egg-85208/14/2019, 2:27 PM
if the resource is going to be replaced (hence changing its
cool-egg-85208/14/2019, 2:45 PM
inputs to import do not match the existing resource; importing this resource will fail
cool-egg-85208/14/2019, 3:30 PM
so that if a new stack is created, it will import it.
stocky-island-367610/07/2019, 10:36 AM
. Then you’re creating a new
and want to import
into that, as well. Right? If so, then you’re managing the same resource
in two different stacks. Then a change of
in one stack, say
, interferes with the same
. Why do you want that? Wouldn’t be a
the correct thing you want here? (https://www.pulumi.com/docs/intro/concepts/organizing-stacks-projects/#inter-stack-dependencies)
cool-egg-85210/07/2019, 10:49 AM
which contains the GKE cluster with the
addon enabled. In order to make istio highly available, I needed to be able to change the
. Because we wanted to do everything in IaC, we had to import the resource. But when we go to create
, we didn’t want to have to manipulate the code again by adding the
option, and again anytime we add a new stack. In the end we ended up not using the
addon because it’s not ready for production, nor do I feel that it will be anytime soon, even if they make it
because Google doesn’t seem to know what they are doing.
stocky-island-367610/07/2019, 10:59 AM
method on the HPA resource. That way the resource is dynamically referenced (even if it would have worked out with the
here, as well, when you simply have a different K8s provider per stack). Did the
value stay with what you’ve set? Or was it maybe automatically set back soon afterwards?