Trigger to redeploy containers when a secret changes

[danni]

Updating a secret should redeploy all deployments who mount that secret so that the latest version of the secret is automatically reflected in the cluster.

[0xmichalis]

We should consider a solution similar to the outcome of kubernetes/kubernetes#22368.

cc: @smarterclayton @ironcladlou

[mwoodson]

We have run into this issue in Openshift Ops. We change secrets, but nothing redeploys. Then, our service is broken.

[0xmichalis]

cc: @mfojtik @legionus relevant to the discussion we had today.

[mfojtik]

@Kargakis i wonder how you will trigger a new deployment in kube when the secret changes (without changing the PodSpec).

[0xmichalis]

@Kargakis i wonder how you will trigger a new deployment in kube when the secret changes (without changing the PodSpec).

See kubernetes/kubernetes#22368 (comment)

[mfojtik]

@Kargakis so ConfigMap will have version and you will refer to it in podSpec?

[0xmichalis]

@Kargakis so ConfigMap will have version and you will refer to it in podSpec?

There are two options discussed. IIUC:

1. Config map template is inlined in the deployment just like the pod template spec. A change to the config map template will make the deployment controller create a new config map, mount it in the deployment, profit.
2. User creates a config map and adds an owner reference to it.

oc create configmap registry --owner=dc/registry --from-file=config.yml

The deployment controller watches for config maps, spots the owner reference, mounts that cm in the deployment it references, profit.

I am in favor of the second option as it solves secret updates too whereas with 1. we would need to additionally inline a secrets template in the deployment and overbloat the resource. Let's join the discussion upstream.

[liggitt]

ownerReferences don't have the infomation you need to create the mount. It also means that if the dc is deleted, the configmap is deleted

[0xmichalis]

ownerReferences don't have the infomation you need to create the mount.

What more do you need than a reference?

It also means that if the dc is deleted, the configmap is deleted

If the configmap is not shared, then it makes sense to me. If you want the config map to stay around, you will have to remove the owner reference (if that's possible).

[0xmichalis]

What more do you need than a reference?

The path can be provided in the deployment.

[smarterclayton]

This should be part of the generic trigger controller, and must be level
driven. We probably can't afford to do a one off solution for each type of
thing we want to trigger on.

On Fri, Aug 26, 2016 at 4:39 PM, Michail Kargakis notifications@github.com
wrote:

What more do you need than a reference?

The path can be provided in the deployment.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7019 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p8jcSGMWYvp3ITdekHR3W__AcCfVks5qj08JgaJpZM4HTAua
.

[0xmichalis]

Triggers is what I have been thinking. Users specify a ConfigMapTrigger that optionally holds a mount path and a container name and when the controller notices a CM that holds a foo deployment reference, it mounts that map in foo. Same story about secrets.

[liggitt]

We already have a way to specify mount information in the spec. Don't duplicate that in the triggers. The triggers should just have the name of the thing you want to trigger on.

[smarterclayton]

I don't want to add it to the API objects though - why wouldn't I want a trigger on deployments or daemon sets? Let's discuss on Monday / Tuesday and pull together a proposal for a level driven trigger.

[0xmichalis]

Trello'd: https://trello.com/c/C8HTTOob/909-secret-change-trigger

[micw]

Edit: removed, wrong issue tracker ^^ sorry.

[exhuma]

Has this ever been solved? Trello shows a "sign-up" popup and then redirects to the default board, making it impossible to read the card details.