CoreDNS Operator: Hash ConfigMap Name for RollingUpgrades

[stealthybox]

Feature to consider:

The operator could hash the configMap bytes and then update the name by appending the hash to it. The Deployment would then be updated to reference this new name.
This would allow the Deployment with multiple replicas to undergo a proper (and safe) RollingUpdate. (Changing the value of a ConfigMap is a common source of error for config rollouts)

Currently, we are just changing the value of the configmap and relying on the CoreDNS pods to use the reload plugin, but this could be optional.

This mechanism is fully supported by kustomize's configMapGenerator should we integrate kustomize into the operator.

/kind feature

[annp1987]

Hi @stealthybox:
I tried to add configMapGenerator to kustomization.yaml file such as:

configMapGenerator:
    - name: coredns
      files:
      - /etc/coredns/Corefile
commonAnnotations:
    configHash: ""

But I don't know how to use kustomize build command to update manifest (channels/packages/coredns/1.3.1/manifest.yaml). Do you have any idea?

In case, I need to update version of coredns from 1.3.1 to 1.4.0. How should I do it? :-)

Thanks :-)

[annp1987]

@stealthybox: ah, I should add kustomization.yaml file to channels/packages/coredns/, right?

[stealthybox]

You can add the kustomization.yaml to that directory -- that can work.

You'll need to change the way the manifests are applied inside of the operator code so that they use kustomize to process the YAML files.
@johnsonj and @justinsb wrote that portion.
I believe you need to modify a dependency of the operator.

[annp1987]

I appreciated your help on this issue. Do you think we should change something in https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern/blob/master/pkg/patterns/addon/pkg/loaders/fs.go#L49 with adding kustomize to process the YAML files or any advice?

[johnsonj]

I think purely running kustomize build to get this functionality could be an issue in the current state.

The loader is the first step for the operator, it loads all of the manifests into memory, the next steps are to run various mutations on that manifest. If we rely on kustomize to hash the configmap name and it's done before the mutations are applied, then the operator may modify the configmap after it's been hashed/named. I think that would be confusing and easy to mess up.

The configmap name hashing is probably the last (or one of the last) transforms you want to do on the manifest objects. If you wrote a transform to do this it could be added to the End chain.

I think a broader kustomize integration could solve this but it requires some thought

[annp1987]

Hi @johnsonj,

Thank you so much for your great suggestion. I'm making code following your idea and will push for review soon.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[nodece]

Hi guys, I will contribute it in GSCO 2020, Is it a hot update issue?
Update ConfigMap then look like coreDNS should can reload get latest config.

is it that so?

[johnsonj]

/remove-lifecycle rotten

This issue should now be ready to be fixed via kubernetes-sigs/kubebuilder-declarative-pattern#66 - The remaining work should be to update the dependency and replace the (manifest)[https://github.com/kubernetes-sigs/cluster-addons/tree/master/coredns/channels/packages/coredns/1.3.1] with a kustomize manifest

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rajansandeep]

I believe this has been done with #50

/close

[k8s-ci-robot]

@rajansandeep: Closing this issue.

In response to this:

I believe this has been done with #50

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.