Thread
#kubernetes
    c

    chilly-plastic-75584

    7 months ago
    One more - I'm busy today 😉 Thank you for your effort Pulumi Pros 🙏 What change triggers a redeploy of a Kubernetes Configmap? #8952
    b

    bored-table-20691

    7 months ago
    Short answer - it will redeploy if any of the properties has changed (metadata or actual contents).
    What are you seeing in terms of behavior?
    c

    chilly-plastic-75584

    7 months ago
    I'll have to vet this then. I updated the Pulumi.dev.yaml > myproject:appconfig.port for example. This should have resulted in a new ConfigMap creation, not a value replace in the current configmap right? The configmap is immutable, I'd expect any change of content to result in replace action. I' don't think it was.
    q

    quiet-wolf-18467

    7 months ago
    Did you mark the config map as immutable? They're not immutable by default
    b

    bored-table-20691

    7 months ago
    I think Pulumi always treats ConfigMaps and Secrets as immutable, even if they’re not immutable from a Kubernetes perspective.
    @chilly-plastic-75584 I’d expect the ConfigMap to get replaced if any of the properties changed. Are you sure the values are changing in the way you think they are? You could always print the YAML you’re serializing and compare.
    c

    chilly-plastic-75584

    7 months ago
    sure thing. I'll investigate further. Good to know. Also one more related question. Since the configmap creates a file mount, and their is a container that then uses this configmap.... I'm assuming that the pod would need to restart to detect the new ConfigMap changes, right? Any articles on explicitly defining the dependency between them so a change in one resource that's not normally triggered ensures the other resource is refreshed/reloaded?cheers
    b

    bored-table-20691

    7 months ago
    If the ConfigMap is declared as a dependency of the Deployment (or whatever), it will update the Deployment defintion, because it needs to the config map reference. This will restart all the pods.
    So yes.
    q

    quiet-wolf-18467

    7 months ago
    I don't believe Pulumi does treat them as immutable, I've never seen that behaviour.
    b

    bored-table-20691

    7 months ago
    There’s some discussion in the Slack as well
    To be clear, it’s treating them logically as immutable, not
    immutable
    in the new Kubernetes capability sense.
    o

    orange-policeman-59119

    7 months ago
    @chilly-plastic-75584 this is a quirk of the Pulumi provider & I think Itay linked to the right thread. The Kubernetes provider treats them as immutable, and will generate a Replace action, but if you let Kubernetes autoname the provider, by not setting
    metadata.spec.name
    , changes to that value are treated as an update. If you set
    metadata.spec.name
    we generate a Replace on consumers, which can cause the unexpected behavior of deleting & recreating a Deployment, StatefulSet, etc.
    c

    chilly-plastic-75584

    7 months ago
    Updated discussion and posting in here too. If the configmap has a new value and I'm loading this into a container as a config file, I want the pod to be redeployed. So I'll check through this thread and see if that's possible by not setting name or such.
    b

    bored-table-20691

    7 months ago
    It should automatically happen if you don’t manually name the configmap - this is the default behavior.
    c

    chilly-plastic-75584

    7 months ago
    Yeah I'm doing this:
    cfgMap, err = corev1.NewConfigMap(ctx, configData.ServiceConfigMapName(), &corev1.ConfigMapArgs{
    		Metadata: &metav1.ObjectMetaArgs{
    			Labels: configData.AppPulumiStringMap(),
    		},
    		Data:      pulumi.StringMap{configData.Configdatamapname: pulumi.String(string(marshalledConfigVals))},
    		Immutable: pulumi.Bool(true),
    	}, pulumi.Provider(prov))
    I'm not setting metadata name explictly
    So I still see the autonamed prefix even if the 2nd param is setting the configmap name
    sorry suffix
    Right now it's doing
    myapi-project-adlkfsli
    style. It just isn't making the configmap be rebuilt when the marshalled string has a different value.
    o

    orange-policeman-59119

    7 months ago
    You should see that the suffix changes if you change the value in "data"
    c

    chilly-plastic-75584

    7 months ago
    It doesn't. Could I be conflicting with
    --refresh
    ?
    b

    bored-table-20691

    7 months ago
    What happens if you do
    pulumi preview
    - does it show the config map as needing an update?
    c

    chilly-plastic-75584

    7 months ago
    Like it's ignoring?
    • If I don't use --refresh and delete the configmap it won't redeploy it. • If i do use refresh it recognizes it's missing and redeploys
    But if refresh is saying "stop tracking" for some reason then that's a conflict i guess
    b

    bored-table-20691

    7 months ago
    refresh
    seems orthogonal here.
    o

    orange-policeman-59119

    7 months ago
    Deleting the configmap?
    c

    chilly-plastic-75584

    7 months ago
    Trying to test so manually delete. Refresh is required so it knows it's missing from target environment (at least when I tried last time)
    o

    orange-policeman-59119

    7 months ago
    ah... you shouldn't be manually deleting it, that will indeed cause issues
    b

    bored-table-20691

    7 months ago
    If you deploy your stack (which creates the configmap) using
    pulumi up
    , then update your config, then run
    pulumi up
    again - what happens?
    c

    chilly-plastic-75584

    7 months ago
    I love orthogons. My favorite shape
    o

    orange-policeman-59119

    7 months ago
    you should be able to just change the value of the data property on the configmap, & Pulumi will take care of creating a new configmap & deleting the old
    c

    chilly-plastic-75584

    7 months ago
    ok will try had been using watch
    and up on occasion. will try just up
    o

    orange-policeman-59119

    7 months ago
    if you delete a managed resource, how we handle that of course can vary but I wouldn't be surprised if that code path doesn't cause us to generate a new
    metadata.name
    or something like that
    c

    chilly-plastic-75584

    7 months ago
    So running
    mage pulumi:diff myproject dev
    (i love mage)... I get a new configmap
    I will try to run and see if it works now
    Maybe watch doesn't work for this for some reason
    That worked! Ok, so running watch --refresh didn't give the right workflow. I'm going to remove --refresh and see if it changes behavior
    o

    orange-policeman-59119

    7 months ago
    I honestly am not sure how watch and --refresh interact, I'd need to dig deeper. It doesn't refresh between every deploy does it?
    c

    chilly-plastic-75584

    7 months ago
    it refreshes but not the configmap + the associated resources. Using up
    Resources:
        ~ 2 updated
        +-1 replaced
        3 changes. 6 unchanged
    
    Duration: 16s
    that works!
    o

    orange-policeman-59119

    7 months ago
    awesome! glad that works
    c

    chilly-plastic-75584

    7 months ago
    Boom. Watch worked without refresh. Recreated configmap + redployed. The refresh doesn't work like I thought it would. I'll summarize my result on the associated github discussion. This refresh behavior definitely could use some more writing. It's far different than I expected especially this case of ignoring changed fields. Makes sense for kubernetes automated fields I guess, but totally unexpected behavior for me when expecting it to fix and align resources to my definition.
    o

    orange-policeman-59119

    7 months ago
    @chilly-plastic-75584 what's your "pulumi:diff" command perform? based on the comments so far I wonder if you've been using --refresh where you actually want "preview"?
    pulumi refresh
    and the refresh stage of
    pulumi up --refresh
    takes resources in your stack, as they existed at the last deployment, and compares them to what's currently deployed. It's basically doing
    kubectl get config ...
    and refreshing the state file.
    also diff there.
    o

    orange-policeman-59119

    7 months ago
    okay, yeah, I see you're doing a pulumi preview
    c

    chilly-plastic-75584

    7 months ago
    I expect refresh to do what you said and then to make sure anything different in my plan is updated to what it should be in code.
    b

    bored-table-20691

    7 months ago
    refresh won’t run an
    up
    - it’ll just edit the local state
    c

    chilly-plastic-75584

    7 months ago
    Right. I was combining
    watch --refresh
    o

    orange-policeman-59119

    7 months ago
    plan isn't a term I'm familiar with here, but I think the disconnect is that Pulumi manages a state file, you can inspect it via:
    pulumi stack export --file stack.json
    I think adding
    --refresh
    causes us to run a "refresh step" before other commands, e.g.:
    pulumi up --refresh
    is equivalent to
    pulumi refresh; pulumi up
    c

    chilly-plastic-75584

    7 months ago
    I wanted it detect the resource was gone or different and got things mixed up. K8 and pulumi is complicated 🙂 Well K8 is complicated by itself
    o

    orange-policeman-59119

    7 months ago
    I think
    pulumi watch --refresh
    is just
    pulumi refresh; pulumi watch
    (or if you're familiar with nodemon, watchexec, it's like
    pulumi refresh; watchexec pulumi up
    )
    b

    bored-table-20691

    7 months ago
    @orange-policeman-59119 I’m surprised that
    refresh
    would have any impact here, unless the resource was already updated on k8s.
    o

    orange-policeman-59119

    7 months ago
    I agree, I think you're right but I'm not an expert yet on it