[tracking bug] CoreDNS Operator

[johnsonj]

Description
CoreDNS Operator aims to manage the lifecycle of the CoreDNS installation in the cluster. It is concerned with the installation, updating, and configuration of CoreDNS.

Project Goal
Define the set of milestones and criteria for productionizing the CoreDNS operator. The current operator is a proof of concept of the add-on library. The goal of the alpha operator is to provide a minimal feature set that is manageable, predictable, and reliable in a production environment.

• Issue: Implement CoreDNS operator smoke test.
  Implementing and validating various scenarios like creation, deletion, configuration change, etc.
  This work will require adding multiple versions to the CoreDNS version directory.
• Issue: Provide metrics in the kubebuilder-declarative-pattern library
  A user should be able to emit metrics on the Prometheus metrics endpoint. Metrics should be written to the controller-runtime Prometheus Registry.
• Issue: Integrate Kustomize with kubebuilder-declarative-pattern
  Finish and share design doc.
• Issue: Implement rolling updates for ConfigMap
  Rolling update for Configs should use hashed names (kustomize supports this) Issue

[johnsonj]

Pulling in the content from @Abhik1998 's issue #40

[vanou]

Hello. I would like to work on issues listed here.
Can I work on them till GSoC 2020 starts? Or, because these issues are registered as GSoC 2020, there is no way to work on them?

[Abhik1998]

@vanou I will be working upon them.

[vanou]

@Abhik1998 I understand. Sorry for worrying.

[eloyekunle]

@Abhik1998 Projects are open to all interested GSoC participants. Only when your proposal is accepted by the organization will you be working on it.

[Abhik1998]

@eloyekunle you are right but @vanou is not a GSoC participant.

[vanou]

Yes. I’m not GSoC participant.
Cheer up @Abhik1998 !

However, if and only if you don’t finish these issues in GSoC terms, I would like to work on this (if possible).

[johnsonj]

I adjusted the branding on this issue. This an open source project and our roadmap is open to all participants (GSoC or otherwise).

This particular issue we want to land before GSoC fully begins. This could help cluster-api migrate to the newest CoreDNS release without implementing a specific upgrade process.

[vanou]

I understand. I'll do my best.
Thanks.

[vanou]

First, I'll tackle Provide metrics in the kubebuilder-declarative-pattern library .

[vanou]

Now I'm working on 2nd issue, and after I finish it, I would like to tackle 1st issue(Implement CoreDNS operator smoke test).

[vanou]

(Replying to this message on #36 )

Heyy @vanou, Care to release one issue?

Hi @somtochiama . Sorry for late reply.

I'm working on Provide metrics in the kubebuilder-declarative-pattern library. However my colleague @longkb working on #46 related to Integrate Kustomize with kubebuilder-declarative-pattern left company at end of this March and I was delegated access to this PR from him.

Now there is two options for us:

1. As you are now working on,
   • you take assignee of kustomize integration issue and work on it
   • and I give up Apply kustomize to hashing configMap's name #46 (because this issue is closely related to kustomize integration issue)
     (or can I work on Apply kustomize to hashing configMap's name #46 after you finish kustomize integration issue?)
   • and I concentrate on Provide metrics in the kubebuilder-declarative-pattern library & Implement CoreDNS operator smoke test (or one of it) which I currently have assignee.
2. Another way is
   • I un-assign me from Provide metrics in the kubebuilder-declarative-pattern library & Implement CoreDNS operator smoke test
   • and you take assignee of above two
   • then l work on Apply kustomize to hashing configMap's name #46 & kustomize integration issue

Which one is better for you. And sorry for annoying you. If you reply to this, it is thankful for me.

[vanou]

Any way, currently I’m working on Provide metrics in the kubebuilder-declarative-pattern library, currently, I unassign me from #36.

Sorry.

[somtochiama]

@vanou Thank you for being considerate! I will pick up #36. Although, I will wait for the #50 to be merged before starting as it introduces significant file changes

[vanou]

@somtochiama OK. And sorry for I haven't unassigned me from #36 , now I have.
Thank you.

[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

[neolit123]

/remove-lifecycle rotten

[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

[atoato88]

What's the current status of this, does anyone know that?
Is it OK to close this issue?

Some issues related to this topic are described in top of this PR.

• CoreDNS Operator: Smoke Tests #36 : closed by fejta-bot, current status is unknown..
• Emit Reconciliation Metrics kubebuilder-declarative-pattern#65 : closed
• kustomize integration kubebuilder-declarative-pattern#56 : closed by fejta-bot, but some PRs related to this are merged.
• CoreDNS Operator: Hash ConfigMap Name for RollingUpgrades #27 : closed

Mainly, related PRs are merged, but I'm not sure whether can I close or not.

[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

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/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.