https://pulumi.com logo
Join Slack
Powered by
Does a replacement of one resource automatically c...
# general
m
Does a replacement of one resource automatically cause a replacement of anything dependent on it? I have a StatefulSet, that depends on the 
configMap.metadata.name
of a ConfigMap. Changing the 
data
of the ConfigMap is causing both resources to be replaced.
w
Does a replacement of one resource automatically cause a replacement of anything dependent on it?
No - a replace resource only triggers replacements of other resources that depend on it if the property that carried the dependency indicates that it requires replacement when there are changes. In what way does your 
StatefulSet
depend on 
configMap.metadata.name
? I would have expected that your 
StatefulSet
would update in-place with the new configmap contents.
m
Probably unecessarily. I was using the 
metadata.name
output from the ConfigMap as input to the StatefulSet with no real reason to. I think the solution is to just break that dependency
Now what I wish I could figure out how to do is cause the 
spec
of the StatefulSet to change in response to the ConfigMap update. The ConfigMap supplies an entrypoint script, and I would like the StatefulSet to update when it changes.
I think I may have thought of a trick to do that. I am trying to add a dummy env var to my deployment, something like:
Copy code
{
                name: 'ENTRYPOINT_SHA',
                value: configMap.data.apply(data => data['entrypoint.sh'].apply(entrypoint => sha1hash(entrypoint))),
              }
Just trying to get the pulumi parts exactly correct
Seems like there's some typing weirdness going on here. Compiler thinks it's an 
Output<string>
, but at runtime it's just a 
string
. Forced to do this:
Copy code
{
                name: 'ENTRYPOINT_SHA',
                value: configMap.data.apply(data => {
                  const entrypoint = data['entrypoint.sh'] as unknown as string;
                  return sha1hash(entrypoint);
                }),
              }
I am still getting a replace where I would hope not to:
Copy code
-kubernetes:apps/v1:StatefulSet: (replace) 🔒
            [id=ethernetes/ethernetes-goerli]
            [urn=urn:pulumi:prod::ethernetes::ethernetes:k8s-eth-node$kubernetes:apps/v1:StatefulSet::ethernetes-goerli]
            [provider=urn:pulumi:prod::ethernetes::pulumi:providers:kubernetes::infrastructure::b7c38e43-a431-4928-b5fc-ba76f8843d16]
          ~ spec      : {
              ~ template            : {
                  ~ spec    : {
                      ~ containers    : [
                          ~ [0]: {
                                  ~ env           : [
                                      ~ [1]: {
                                              ~ value: "ed045838" => "069ec057"
                                            }
                                    ]
                                }
                        ]
                    }
                }
            }
g
Generally, changing the spec is going to cause a replacement.
m
I thought generally 
spec
updates just caused 
kubernetes:apps:StatefulSet  ethernetes-kovan    update      [diff: ~spec]
where it would do a rolling update
g
Oh, rereading I see you meant it’s replacing the entire StatefulSet. I meant that it should trigger Pod replacement. Can you provide the relevant code that’s causing this? Hard to tell what’s going on from the snippets
m
Huh so odd, now it is doing the expected thing.
Replace the 
ConfigMap
and update the 
StatefulSet
as a result
g
Unexpected replacements are often caused by hardcoded names. Not sure if that applies in this case?
m
I don't think so, but not entirely sure. Assuming that was a fluke, this is all working great and as expected now. Only oddity is the type discrepancy between compile and runtime
It could have been due to hard coded names, I will look into that.
The requirement to do
Copy code
configMap.data.apply(data => {
                  const entrypoint = data['entrypoint.sh'] as unknown as string;
                  return sha1hash(entrypoint);
is pretty odd though.
g
Yeah, that seems a bit odd. If you can provide the full snippet, we might be able to help simplify it
m
Not a big issue as it does seem to work like this, but this gist has everything relevant I think: https://gist.github.com/timmyers/374d10424de427ea9fd664ef97f4614d
And now I am back to having the stateful sets replaced attempting to do another ConfigMap strange. I'm not sure what is different
g
Copy code
const entrypoint = configMap.data.apply(data => data['entrypoint.sh']);
export const sha = entrypoint.apply(ep => sha1hash(ep));
m
👍 that works, thank you
👍 1
Still have the replace issue back somehow though haha
I do have hardcoded names on my 
StatefulSet
, that could be causing it?
g
You are specifying the 
.metadata.name
, which is probably the cause
m
How does that cause it?
g
If you leave that unset, it will get autonamed, and generally doesn’t have to replace
If it’s requiring a particular ConfigMap, it has to tear down the old one first
m
Is it logic deciding it needs replaced that may actually be wrong in this case? And autonaming sidesteps the issue.
g
Otherwise, it will create a new one, update the reference, and then delete the old one
I’ve got to run now, but basically, autonaming is almost always what you want. If that’s still not working for you, feel free to open an issue on GitHub, and we’ll take a look. https://github.com/pulumi/pulumi-kubernetes/issues/new
m
👍 I'll give autonaming a try, thanks!
I think that worked.
Open in Slack
PreviousNext
Powered by