[VOTE] CoreDNS Project Proposal
Jonathan Boulle <jonathan.boulle@...>
Fellow TOC members: The CoreDNS team has iterated on their project proposal to a final version after feedback and it's now time to vote. Proposal is available here and also embedded below. To kick things off, here's my +1. thanks, Jonathan --- Name of project: CoreDNS Description CoreDNS is a fast, flexible and modern DNS server. Its performant and flexible implementation allows CoreDNS to be easily extended to support various data sources and to implement rich DNS service behaviors: for example, response caching, query rewrite, load-balancing, zone transfer and signing. CoreDNS is the successor of SkyDNS (https://github.com/skynetservices/skydns), a DNS server that uses etcd as its datastore backend. SkyDNS is widely used in cloud deployments, but lacks the flexibility we envision for CoreDNS. Sponsor / Advisor from TOC: Jonathan Boulle Unique Identifier: coredns License: Apache License v2.0 Source control repositories: https://github.com/miekg/coredns Initial Committers:
Infrastructure requirements (CI / CNCF Cluster): N/A Issue tracker: https://github.com/miekg/coredns Website: https://coredns.io Release methodology and mechanics: As a young project, no method for official releases has been established, and no official releases have been made; the current rule is that the master branch is production-ready at all times. A more formal release process is on its way, and may introduce semantic versioning, but a final decision has not yet been made. Precompiled binaries will be distributed by hooking into Caddy’s download website (https://caddyserver.com/download), where "DNS" will be a Server Type option. Social media accounts: Twitter: @corednsio Existing sponsorship: Infoblox contributing developer time to implement CoreDNS→Kubernetes integration component. Existing community: The community is small, but growing. Current number of Twitter followers is 100+ (after a week of having the Twitter account). By aligning ourselves with the Caddy community, we hope to leverage Caddy’s popularity for CoreDNS. By positioning CoreDNS as a better SkyDNS, we hope to entice existing users of SkyDNS to migrate to and embrace CoreDNS. External Dependencies CoreDNS depends on Caddy (https://caddyserver.com/). Caddy is a framework that CoreDNS uses in two ways:
Go dependencies:
Statement on alignment with CNCF mission: CoreDNS is a focused, lightweight DNS server. A microservice philosophy guides the internal design of CoreDNS. Individual DNS functions are provided by discrete, composable plugins that are enabled via runtime configuration. CoreDNS can be thought of as a DNS protocol head that can be configured to front various backend data sources. A flexible DNS server is a necessary component to provide “Naming and Discovery” services to containers running in the CNCF distributed system services environment. Comparison with KubeDNS: The incumbent DNS service for Kubernetes, “kubedns”, consists of four components: * etcd provides a DNS data cache, * kube2sky provides the mechanism for updating the etcd data cache, * skydns provides the DNS service based on the data cached in etcd, * exechealthz provides health-check status. Running CoreDNS with Kubernetes requires only the coredns component. CoreDNS does not require a separate data cache or update service. CoreDNS includes an optional health-check “middleware” component that can be used for service monitoring. CoreDNS provides a cleaner, more extensible codebase as compared to SkyDNS. (Both SkyDNS and CoreDNS were authored primarily by Miek Gieben.) CoreDNS is currently being extended to operate directly with Kubernetes to access the service data. This “middleware” implementation for CoreDNS provides the same client-facing behavior as KubeDNS. The pipeline-based design of CoreDNS allows easy extension to use any container orchestrator as a DNS data source. With the Kubernetes middleware, CoreDNS can be considered as an alternative to SkyDNS with lower runtime complexity. Performance testing to compare against SkyDNS is pending. |
|
alexis richardson
+1 On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc, <cncf-toc@...> wrote:
|
|
Carlos Alonso <calonso@...>
+1
From: <cncf-toc-bounces@...> on behalf of Alexis Richardson via cncf-toc <cncf-toc@...>
Reply-To: Alexis Richardson <alexis@...> Date: Thursday, August 25, 2016 at 5:39 AM To: Jonathan Boulle <jonathan.boulle@...>, "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] [VOTE] CoreDNS Project Proposal
|
|
Camille Fournier
-1. I think the project has great potential but is too early to be included in the foundation. I would love to see it again once it has gone through a full release cycle and gotten a little bit of adoption. C On Aug 26, 2016 8:09 AM, "Carlos Alonso via cncf-toc" <cncf-toc@...> wrote:
|
|
alexis richardson
Thanks Camille. This issue will also come up with Heron. Perhaps we need to start putting gating conditions into the process eg Yes you can be in cncf but you cannot leave incubation until <conditions stated upfront> On Tue, 30 Aug 2016, 14:26 Camille Fournier, <skamille@...> wrote:
|
|
Doug Davis <dug@...>
The CNCF charter mentions that the TOC would define the criteria for new projects to join the CNCF [1], perhaps now would be a good time to formalize that so that everyone can evaluate the proposed projects against the same set of guidelines - and of course, so that potential projects can have a clear finish line to shoot for so they don't submit too soon. Thanks Camille. This issue will also come up with Heron. Perhaps we need to start putting gating conditions into the process eg Yes you can be in cncf but you cannot leave incubation until <conditions stated upfront> On Tue, 30 Aug 2016, 14:26 Camille Fournier, <skamille@...> wrote:
C
+1
The CoreDNS team has iterated on their project proposal to a final version after feedback and it's now time to vote. Proposal is available here and also embedded below. To kick things off, here's my +1. thanks, Jonathan --- Name of project: CoreDNS Description CoreDNS is a fast, flexible and modern DNS server. Its performant and flexible implementation allows CoreDNS to be easily extended to support various data sources and to implement rich DNS service behaviors: for example, response caching, query rewrite, load-balancing, zone transfer and signing. CoreDNS is the successor of SkyDNS (https://github.com/skynetservices/skydns), a DNS server that uses etcd as its datastore backend. SkyDNS is widely used in cloud deployments, but lacks the flexibility we envision for CoreDNS. Sponsor / Advisor from TOC: Jonathan Boulle Unique Identifier: coredns License: Apache License v2.0 Source control repositories: https://github.com/miekg/coredns Initial Committers: Issue tracker: https://github.com/miekg/coredns Website: https://coredns.io Release methodology and mechanics: As a young project, no method for official releases has been established, and no official releases have been made; the current rule is that the master branch is production-ready at all times. A more formal release process is on its way, and may introduce semantic versioning, but a final decision has not yet been made. Precompiled binaries will be distributed by hooking into Caddy’s download website (https://caddyserver.com/download), where "DNS" will be a Server Type option. Social media accounts: Twitter: @corednsio Existing sponsorship: Infoblox contributing developer time to implement CoreDNS→Kubernetes integration component. Existing community: The community is small, but growing. Current number of Twitter followers is 100+ (after a week of having the Twitter account). By aligning ourselves with the Caddy community, we hope to leverage Caddy’s popularity for CoreDNS. By positioning CoreDNS as a better SkyDNS, we hope to entice existing users of SkyDNS to migrate to and embrace CoreDNS. External Dependencies CoreDNS depends on Caddy (https://caddyserver.com/). Caddy is a framework that CoreDNS uses in two ways:
2. CoreDNS provides a wrapper around the framework to provide a DNS-tuned command-line interface. CoreDNS is a focused, lightweight DNS server. A microservice philosophy guides the internal design of CoreDNS. Individual DNS functions are provided by discrete, composable plugins that are enabled via runtime configuration. CoreDNS can be thought of as a DNS protocol head that can be configured to front various backend data sources. A flexible DNS server is a necessary component to provide “Naming and Discovery” services to containers running in the CNCF distributed system services environment. Comparison with KubeDNS: The incumbent DNS service for Kubernetes, “kubedns”, consists of four components: * etcd provides a DNS data cache, * kube2sky provides the mechanism for updating the etcd data cache, * skydns provides the DNS service based on the data cached in etcd, * exechealthz provides health-check status. Running CoreDNS with Kubernetes requires only the coredns component. CoreDNS does not require a separate data cache or update service. CoreDNS includes an optional health-check “middleware” component that can be used for service monitoring. CoreDNS provides a cleaner, more extensible codebase as compared to SkyDNS. (Both SkyDNS and CoreDNS were authored primarily by Miek Gieben.) CoreDNS is currently being extended to operate directly with Kubernetes to access the service data. This “middleware” implementation for CoreDNS provides the same client-facing behavior as KubeDNS. The pipeline-based design of CoreDNS allows easy extension to use any container orchestrator as a DNS data source. With the Kubernetes middleware, CoreDNS can be considered as an alternative to SkyDNS with lower runtime complexity. Performance testing to compare against SkyDNS is pending. _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc |
|
alexis richardson
Agreed. On Tue, 30 Aug 2016, 15:14 Doug Davis, <dug@...> wrote:
|
|
Bryan Cantrill <bryan@...>
More generally, I would like each proposal to answer two (additional) questions: "What do we bring to the CNCF?" and "What would we like the CNCF to bring to us?" I feel that the CNCF projects under incubation have clear answers to these questions -- but it is much less clear for me in the case of CoreDNS... - Bryan On Tue, Aug 30, 2016 at 5:26 AM, Camille Fournier via cncf-toc <cncf-toc@...> wrote:
|
|
alexis richardson
Bryan & Camille
I'm travelling, so apologies for brevity. 1. I don't think it should matter that a project is "small" in scope, in the sense of being "narrow". Do one thing and do it well etc etc,... is an OK thing for some projects. 2. Being "new" is more of an issue. In order to focus on projects that speak for themselves, while we are still a young organisation and figuring out what matters, it is helpful to require some production use, for instance. 3. Ultimately I think we need a way to recognise and perhaps help projects that are important but novel. At ContainerCon, Ben Hindman, Chris Aniszcxyk and I had a discussion about this that we hope to share with the wider group. TL;DR -- we want to propose a "Seed" stage for young projects. There should be a frequent pruning out of Seed projects that are not succeeding. From Seed, projects may graduate into the CNCF. And yes, we should establish clearer criteria for leaving Incubation soon. 4. Bryan, on the creation of additional criteria in the process: yes, we can certainly do this if it clarifies what we are trying to achieve. alexis On Tue, Aug 30, 2016 at 5:45 PM, Bryan Cantrill via cncf-toc <cncf-toc@...> wrote:
|
|
Benjamin Hindman
I agree with Camille/Bryan that the project is young and we shouldn't put the name of CNCF on a project that could cause a production user to have a very bad experience. This will not help the CNCF brand. I also think, however, that the CNCF should make some bets or take some risks in order to help drive change or innovation in the industry. These are opposing goals. To reconcile this I think we need to revisit the notion of "incubation" in CNCF and introduce a new concept that lets us bring in projects that we believe have strong futures but don't yet have the mark of "CNCF production software". IMHO the best (easiest?) path forward is to revisit CoreDNS after we've put this in place, it would easily get my +1 then. On Tue, Aug 30, 2016 at 9:11 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Bryan & Camille --
Benjamin Hindman Founder of Mesosphere and Co-Creator of Apache Mesos Follow us on Twitter: @mesosphere |
|
Solomon Hykes <solomon.hykes@...>
+1
On Thu, Aug 25, 2016 at 2:37 AM, Jonathan Boulle via cncf-toc <cncf-toc@...> wrote: Fellow TOC members: |
|
alexis richardson
thanks!
I'd like to discuss 'seed' projects, tomorrow On Mon, Sep 5, 2016 at 10:08 PM, Benjamin Hindman via cncf-toc <cncf-toc@...> wrote: I agree with Camille/Bryan that the project is young and we shouldn't put |
|
Brian Grant
I'm abstaining for now. I don't feel I've/we've done adequate due diligence. I was familiar with Prometheus and am familiar with SkyDNS, but haven't had time to look more closely at CoreDNS. For example, what is its interface to systems providing discovery/naming data? Can new sources be added without modification to CoreDNS? Why is CoreDNS embedded in a webserver? How hard would it be to link against Caddy without patching it, which seems like a fragile way to avoid forking? How hard would it be to eliminate the Caddy dependency entirely? On Thu, Aug 25, 2016 at 2:37 AM, Jonathan Boulle via cncf-toc <cncf-toc@...> wrote:
|
|
alexis richardson
many thanks Brian
I am going to work on drafting a 'seed stage' proposal for projects not yet in production use. re: your specific qns, let's sync offline with miek & team On Wed, Sep 7, 2016 at 5:25 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I'm abstaining for now. |
|
Hi Brian,
I discussed your questions with Miek and Michael. Please see below. Thanks, John
CoreDNS provide a middleware architecture that enables access to different data sources just by changing or adding to the configuration file. Today, Kubernetes, etcd, and files are supported. New data sources can be added by implementing a CoreDNS middleware component. All middleware components implement a well-defined middleware plugin interface. The middleware components are compiled into the CoreDNS binary. Interfaces exist to separate the CoreDNS engine from the middleware implementations. However, middleware components are not dynamically discovered at runtime. CoreDNS currently does need to be modified for each new middleware. Ultimately these modifications are: • registration of the middleware with CoreDNS (this is the stuff to setup config file parsing). • statically compiled binary — all middleware are currently statically linked in the CoreDNS binary. CoreDNS is not embedded in a web server. The Caddy project started as a composition-based web server implementation. However, Caddy has evolved to be a framework intended to be used to implement arbitrary stateless request/response protocols such as HTTP and DNS. CoreDNS is one of the first projects that leverage the newly generalized Caddy framework.Why is CoreDNS embedded in a webserver? How hard would it be to link against CoreDNS previously existed as a fork of Caddy reusing a large part of the Caddy middleware management and invocation functionality. Now that the Caddy project has generalized the middleware management and invocation mechanisms it is preferable to utilize Caddy as runtime framework. Caddy is simply another go dependency for CoreDNS, although removing that dependency is not feasible. _______________________________________________ |
|