https://pulumi.com logo
Powered by
m

millions-judge-24978

04/05/2019, 9:22 PM
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

white-balloon-205

04/05/2019, 9:30 PM
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

millions-judge-24978

04/05/2019, 9:32 PM
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

gorgeous-egg-16927

04/05/2019, 10:25 PM
Generally, changing the spec is going to cause a replacement.
m

millions-judge-24978

04/05/2019, 10:28 PM
I thought generally 
spec
updates just caused 
kubernetes:apps:StatefulSet  ethernetes-kovan    update      [diff: ~spec]
where it would do a rolling update
g

gorgeous-egg-16927

04/05/2019, 10:33 PM
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

millions-judge-24978

04/05/2019, 10:34 PM
Huh so odd, now it is doing the expected thing.
Replace the 
ConfigMap
and update the 
StatefulSet
as a result
g

gorgeous-egg-16927

04/05/2019, 10:35 PM
Unexpected replacements are often caused by hardcoded names. Not sure if that applies in this case?
m

millions-judge-24978

04/05/2019, 10:36 PM
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

gorgeous-egg-16927

04/05/2019, 10:38 PM
Yeah, that seems a bit odd. If you can provide the full snippet, we might be able to help simplify it
m

millions-judge-24978

04/05/2019, 10:41 PM
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

gorgeous-egg-16927

04/05/2019, 10:56 PM
Copy code
const entrypoint = configMap.data.apply(data => data['entrypoint.sh']);
export const sha = entrypoint.apply(ep => sha1hash(ep));
m

millions-judge-24978

04/05/2019, 10:57 PM
👍 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

gorgeous-egg-16927

04/05/2019, 10:58 PM
You are specifying the 
.metadata.name
, which is probably the cause
m

millions-judge-24978

04/05/2019, 10:59 PM
How does that cause it?
g

gorgeous-egg-16927

04/05/2019, 10:59 PM
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

millions-judge-24978

04/05/2019, 11:00 PM
Is it logic deciding it needs replaced that may actually be wrong in this case? And autonaming sidesteps the issue.
g

gorgeous-egg-16927

04/05/2019, 11:00 PM
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

millions-judge-24978

04/05/2019, 11:03 PM
👍 I'll give autonaming a try, thanks!
I think that worked.
Powered by