https://pulumi.com logo
Powered by
#python
Title
l

little-river-49422

03/02/2019, 12:42 PM
I think I've read somewhere pulumi should restard pods if they depend on something and that something changes, I dont observe that behaviour
w

white-balloon-205

03/02/2019, 6:08 PM
Could you share a code snippet? In what way are you creating a dependency between your pod and something else?
l

little-river-49422

03/02/2019, 7:00 PM
there's really only one way to do it?
Copy code
flux_secret = Secret('flux-secret',
    metadata={
        "name": 'flux-ssh',
        "namespace": NAMESPACE
    },
    data={
        "identity": git_key
    },
    __opts__=ResourceOptions(provider=k8s)
)
gen_application("flux", [ 3030 ], '<http://quay.io/weaveworks/flux:1.10.1|quay.io/weaveworks/flux:1.10.1>', k8s, dependencies=[flux_secret], serviceAccount="flux-rbac-sa", volumeMounts=True, volumes=True)
and that function calls 
deployment()
and passes dependencies as is
w

white-balloon-205

03/02/2019, 7:08 PM
I think possibly 
Secret
does not get replaced when there are changes (but 
ConfigMap
does)? @creamy-potato-29402 or @gorgeous-egg-16927 would need to confirm?
pulumi should restard pods if they depend on something and that something changes
This is true specifically when some resource gets replaced - causing another resource to observe a change from the old to the new and redeploy. I know 
ConfigMap
is defined such that it will replace on changes to it's data - but I'm unsure exactly which other resources and properties this applies to - or whether that is documented currently in API docs. Alex and Levi should be able to help on this.
l

little-river-49422

03/02/2019, 7:22 PM
i think it gets updated, not replaced
configmap gets replaced, i think
i dont remember, let me check
yeah, it gets recreated
w

white-balloon-205

03/02/2019, 7:28 PM
Ahh - good. The problem is actually somewhere else - you are using 
depends_on
to depend on the other resource, but that does not force any change when the Secret gets replaced. If you used the Secret as an input to one of the properties of the 
Deployment
then you would cause the 
Deployment
to have to re-depoy. More simply - how does your 
Deployment
actually depend on this 
Secret
? You must be passing it (or referring to it by name in a string) somehow from the 
Deployment
? You need to make that explicit to get the benefits of Pulumi doing the updates for you. 
depends_on
itself will not do this (as there is no change you are asking to make to the Deployment). https://github.com/pulumi/pulumi/issues/838 will partly help here - but I think what you really want is to make the dependence from some actual part of the 
Deployment
more explicitly tied to this 
Secret
.
l

little-river-49422

03/02/2019, 7:31 PM
not sure I understand? why depends_on exists if it doesnt help with that?
only for ordering?
w

white-balloon-205

03/02/2019, 7:34 PM
depends_on
indicates that there is an ordering reationship. If A depends_on B it means "A cannot be successfully created until B is created" and "A cannot be deleted before B is deleted". In terms of what actually triggers an Update to be performed on your target cloud (Kubernetes) - you have to make an actual change to the desired state you want. It sounds like you are not changing the desired state. The normal way this works in examples like https://github.com/pulumi/examples/tree/master/kubernetes-ts-configmap-rollout is that the desired state of the 
Deployment
actually changes - because it points at a new 
ConfigMap
(because the ConfigMap got replaced with a new configmap with a different name).
l

little-river-49422

03/02/2019, 7:36 PM
well, i dont really want to change the names of resources
names are fine, content changes
this implies I need to take the value and hash it into a name or something
for the name to change when the value changes
w

white-balloon-205

03/02/2019, 7:38 PM
No - if you do what's in that example you do not need to do any hashing.
The name change will happen automatically as part of the replacement part we discussed earlier. If you haven't yet tried that example - definitely worth trying it and seeing what changes happen during the change to the ConfigMap value. The way this all works is indeed a little different than the normal Kubernetes approach of "change the data then find the dependent pods and kick them". Instead, in Pulumi it is "crete a new configmap with the new data, update the pods to point to the new configmap which will force them to update, and then remove the old configmap". These are different, and the latter isn't necessarily what you always want. But it's the way in which your original question about "'ve read somewhere pulumi should restard pods if they depend on something and that something changes" is realized in Pulumi. @creamy-potato-29402 will definitely be the best to go any deeper here if needed.
l

little-river-49422

03/02/2019, 7:43 PM
ok, so if I pass configmap\secret name as a string that is being constructed from the resource output using apply that will trigger the redeployment when I change the actual configmap\secret contents? but why? name stays the same. I dont really understand
w

white-balloon-205

03/02/2019, 7:43 PM
The name of the ConfigMap will not stay the same. Suggest trying out the example to see this.
👍 1
c

creamy-potato-29402

03/04/2019, 6:50 AM
The name of the 
ConfigMap
or 
Secret
will definitely change if you modify the 
.data
field, unless you specify 
.metadata.name
If you do not specify it, we will do the following: 1. Create a new 
ConfigMap
, with a new name, with the new data. 2. Modify the 
Deployment
to point at the new 
ConfigMap
, which (because it changes the 
PodTemplate
) will trigger a rollout 3. Wait for the rollout to succeed. 4. Only once rollout succeeds, delete the old version of the 
ConfigMap
.
The way Kubernetes does this is: when you update 
ConfigMap
, it will transparently update the data, and then any 
Pod
that references it will eventually, and silently, sync that data without doing any rollout, or really signaling the app generally. This means that if you update the 
ConfigMap
, then the `Pod`s get rescheduled, you might not know of config errors until many hours later, and at that point, 
Deployment
can’t roll back because the old 
ConfigMap
data is not around anymore.
So, we make all of this explicit. In 
preview
, we will tell you what changes, what is being replaced, and what is being rolled out.
If you want the old behavior for some reason, just specify 
.metadata.name
in the 
ConfigMap
and presto, it’s like it was.
Powered by