little-river-49422
03/02/2019, 12:42 PMwhite-balloon-205
little-river-49422
03/02/2019, 7:00 PMflux_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)
deployment()
and passes dependencies as iswhite-balloon-205
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 changesThis 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.little-river-49422
03/02/2019, 7:22 PMwhite-balloon-205
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
.little-river-49422
03/02/2019, 7:31 PMwhite-balloon-205
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).little-river-49422
03/02/2019, 7:36 PMwhite-balloon-205
little-river-49422
03/02/2019, 7:43 PMwhite-balloon-205
creamy-potato-29402
03/04/2019, 6:50 AMConfigMap
or Secret
will definitely change if you modify the .data
field, unless you specify .metadata.name
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
.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.preview
, we will tell you what changes, what is being replaced, and what is being rolled out..metadata.name
in the ConfigMap
and presto, it’s like it was.