CoreDNS Operator: Hash ConfigMap Name for RollingUpgrades about cluster-addons HOT 13 CLOSED

I believe this has been done with #50

/close

from cluster-addons.

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 :-)

from cluster-addons.

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

from cluster-addons.

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.

from cluster-addons.

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?

from cluster-addons.

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

from cluster-addons.

Hi @johnsonj,

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

from cluster-addons.

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

from cluster-addons.

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

from cluster-addons.

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?

from cluster-addons.

/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

from cluster-addons.

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

from cluster-addons.

@rajansandeep: Closing this issue.

from cluster-addons.