Date   

Re: [VOTE] CoreDNS Project Proposal

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

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:
>
> I agree with Camille -- while an admirable start (and a good name), CoreDNS
> is just too new and too small: the project itself was only conceived of in
> March, and by any metric (GH issues, contributors, commits, followers,
> stars, releases, social media mentions) it remains nascent.  So I would say
> the answer to CoreDNS is not so much "no" as "not yet".
>
> 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:
>>
>> -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:
>>>
>>> +1
>>>
>>>
>>>
>>> From: <cncf-toc-bounces@....io> 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
>>>
>>> +1
>>>
>>>
>>> On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc,
>>> <cncf-toc@...> wrote:
>>>>
>>>> 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:
>>>>
>>>> Miek Gieben github: miekg
>>>>
>>>> Michael Richmond github: mrichmon
>>>>
>>>> github: splack
>>>>
>>>> Felix Cantournet github: fcantournet
>>>>
>>>> github: leelynne
>>>>
>>>> Matt Layher github: mdlayher
>>>>
>>>> Vasily Vailyev github: pixelbender
>>>>
>>>> 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:
>>>>
>>>> much of the CoreDNS code plugs into the framework to add DNS behavior.
>>>>
>>>> CoreDNS provides a wrapper around the framework to provide a DNS-tuned
>>>> command-line interface.
>>>>
>>>> Go dependencies:
>>>>
>>>> Go package: mholt/caddy (ASLV2
>>>> https://github.com/mholt/caddy/blob/master/LICENSE.txt)
>>>>
>>>> Go package: beorn7/perks (MIT
>>>> https://github.com/beorn7/perks/blob/master/LICENSE)
>>>>
>>>> Go package: coreos/etcd (ASLv2
>>>> https://github.com/coreos/etcd/blob/master/LICENSE)
>>>>
>>>> Go package: flynn/go-shlex (ASLv2
>>>> https://github.com/flynn-archive/go-shlex/blob/master/COPYING)
>>>>
>>>> Go package: fsnotify/fsnotify (BSD
>>>> https://github.com/fsnotify/fsnotify/blob/master/LICENSE)
>>>>
>>>> Go package: golang/protobuf (BSD
>>>> https://github.com/golang/protobuf/blob/master/LICENSE)
>>>>
>>>> Go package: hashicorp/go-syslog (MIT
>>>> https://github.com/hashicorp/go-syslog/blob/master/LICENSE)
>>>>
>>>> Go package: matttproud/golang_protobuf_extensions
>>>> (ASLv2https://github.com/matttproud/golang_protobuf_extensions/blob/master/LICENSE
>>>>
>>>> Go package: miekg/dns (BSD
>>>> https://github.com/miekg/dns/blob/master/LICENSE)
>>>>
>>>> Go package: patrickmn/go-cache (MIT
>>>> https://github.com/patrickmn/go-cache/blob/master/LICENSE)
>>>>
>>>> Go package: prometheus/client_golang
>>>> (ASLv2https://github.com/prometheus/client_golang/blob/master/LICENSE)
>>>>
>>>> Go package: prometheus/client_model
>>>> (ASLv2https://github.com/prometheus/client_model/blob/master/LICENSE)
>>>>
>>>> Go package: prometheus/common (ASLv2
>>>> https://github.com/prometheus/common/blob/master/LICENSE)
>>>>
>>>> Go package: prometheus/procfs (ASLv2
>>>> https://github.com/prometheus/procfs/blob/master/LICENSE)
>>>>
>>>> Go package: ugorji/go (MIT
>>>> https://github.com/ugorji/go/blob/master/LICENSE)
>>>>
>>>> Go package: xenolf/lego (MIT
>>>> https://github.com/xenolf/lego/blob/master/LICENSE)
>>>>
>>>> Go package: golang/x/crypto (BSD
>>>> https://github.com/golang/crypto/blob/master/LICENSE)
>>>>
>>>> Go package: golang/x/net (BSD
>>>> https://github.com/golang/net/blob/master/LICENSE)
>>>>
>>>> Go package: golang/x/sys (BSD
>>>> https://github.com/golang/sys/blob/master/LICENSE)
>>>>
>>>> Go package: natefinch/lumberjack.v2 (MIT
>>>> https://github.com/natefinch/lumberjack/blob/v2.0/LICENSE)
>>>>
>>>> Go package: square/go-jose.v1 (ASLv2
>>>> https://github.com/square/go-jose/blob/master/LICENSE)
>>>>
>>>> Kubernetes (for CoreDNS → Kubernetes integration)
>>>> (ASLv2https://github.com/kubernetes/kubernetes/blob/master/LICENSE)
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
> _______________________________________________
> 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



--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere


Re: [cncf-marketing] my slides on cloud native from Software Circus

NASSAUR, DOUGLAS C <dn283x@...>
 

Love auto correct. Sorry folks. Not sure where the me came from. Typed new. 

Regards, Doug

On Sep 2, 2016, at 2:27 PM, NASSAUR, DOUGLAS C via cncf-toc <cncf-toc@...> wrote:

Was planning on attacking that in the me architecture committee. 

Regards, Doug

On Sep 2, 2016, at 2:01 PM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

thanks JJ

it would be very helpful if someone or some people could form a group to codify patterns & example apps!



On Fri, 2 Sep 2016, 18:51 Joseph Jacks, <jjacks@...> wrote:
*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course.  I used the draft reference stack to
illustrate the technologies we are looking for.  I spoke about
software, standards vs conventions etc.  At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF.  So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing
_______________________________________________
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


Re: [cncf-marketing] my slides on cloud native from Software Circus

NASSAUR, DOUGLAS C <dn283x@...>
 

Was planning on attacking that in the me architecture committee. 

Regards, Doug

On Sep 2, 2016, at 2:01 PM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

thanks JJ

it would be very helpful if someone or some people could form a group to codify patterns & example apps!



On Fri, 2 Sep 2016, 18:51 Joseph Jacks, <jjacks@...> wrote:
*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course.  I used the draft reference stack to
illustrate the technologies we are looking for.  I spoke about
software, standards vs conventions etc.  At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF.  So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [cncf-marketing] my slides on cloud native from Software Circus

alexis richardson
 

yes it would be excellent to involve Brendan (and Microsoft?) and David, if they are interested 

key patterns also include pretty much anything that netflix have published as oss.. 



On Fri, 2 Sep 2016, 19:03 Joseph Jacks, <jjacks@...> wrote:

​I am extremely interested in this and would love to contribute / join in. I feel that a few folks can contribute a lot. Brendan Burns is one. He and David Oppenheimer wrote a USENIX paper that extrapolates a bit on a couple EIPs in container-based manifestations.


https://www.usenix.org/node/196347


JJ.



From: Alexis Richardson <alexis@...>
Sent: Friday, September 2, 2016 2:00 PM
To: Joseph Jacks; cncf-toc@...; cncf-gb@...
Subject: Re: [cncf-marketing] my slides on cloud native from Software Circus
 
thanks JJ

it would be very helpful if someone or some people could form a group to codify patterns & example apps!



On Fri, 2 Sep 2016, 18:51 Joseph Jacks, <jjacks@...> wrote:
*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course.  I used the draft reference stack to
illustrate the technologies we are looking for.  I spoke about
software, standards vs conventions etc.  At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF.  So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

Joseph Jacks <jjacks@...>
 

​I am extremely interested in this and would love to contribute / join in. I feel that a few folks can contribute a lot. Brendan Burns is one. He and David Oppenheimer wrote a USENIX paper that extrapolates a bit on a couple EIPs in container-based manifestations.


https://www.usenix.org/node/196347​


JJ.



From: Alexis Richardson <alexis@...>
Sent: Friday, September 2, 2016 2:00 PM
To: Joseph Jacks; cncf-toc@...; cncf-gb@...
Subject: Re: [cncf-marketing] my slides on cloud native from Software Circus
 
thanks JJ

it would be very helpful if someone or some people could form a group to codify patterns & example apps!



On Fri, 2 Sep 2016, 18:51 Joseph Jacks, <jjacks@...> wrote:
*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course.  I used the draft reference stack to
illustrate the technologies we are looking for.  I spoke about
software, standards vs conventions etc.  At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF.  So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

alexis richardson
 

thanks JJ

it would be very helpful if someone or some people could form a group to codify patterns & example apps!



On Fri, 2 Sep 2016, 18:51 Joseph Jacks, <jjacks@...> wrote:
*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course.  I used the draft reference stack to
illustrate the technologies we are looking for.  I spoke about
software, standards vs conventions etc.  At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF.  So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

Joseph Jacks <jjacks@...>
 

*Very* well done, Alexis. I can't wait until we unpack the PATTERNS piece. This is key to pragmatically codifying Cloud Native for users. I keep going back to EIPs here: http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
________________________________________
From: cncf-marketing-bounces@... <cncf-marketing-bounces@...> on behalf of Alexis Richardson via cncf-marketing <cncf-marketing@...>
Sent: Friday, September 2, 2016 2:41 AM
To: cncf-toc@...; cncf-marketing@...; cncf-gb@...
Subject: [cncf-marketing] my slides on cloud native from Software Circus

Hi

I gave a keynote yesterday at Software Circus in Amsterdam. The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course. I used the draft reference stack to
illustrate the technologies we are looking for. I spoke about
software, standards vs conventions etc. At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF. So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

alexis richardson
 

happy to


On Fri, 2 Sep 2016, 15:20 Douglas Nassaur, <dcnatt@...> wrote:
Well done sir. When you get a few minutes let's discuss a couple points re the ra that I've discussed with Ken. I've been doing similar talks and I'd like to see if we can align on a couple points.

Thanks for sharing and representing.

Sent from my iPad

> On Sep 2, 2016, at 2:41 AM, Alexis Richardson via cncf-marketing <cncf-marketing@...> wrote:
>
> Hi
>
> I gave a keynote yesterday at Software Circus in Amsterdam.  The bulk
> of my talk was about CNCF and why it needs to exist, interspersed with
> some personal opinions of course.  I used the draft reference stack to
> illustrate the technologies we are looking for.  I spoke about
> software, standards vs conventions etc.  At the end I said a few words
> about appc, Docker and long term stability, and the "open" platform.
>
> Afterwards a lot of people said it was the first time they had
> understood CNCF.  So I must have done something right :-/
>
> The slides are here -
> https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p
>
> Trigger warning - first section contains product promotion that some
> may wish to skip.
>
> alexis
> _______________________________________________
> cncf-marketing mailing list
> cncf-marketing@...
> https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

Douglas Nassaur <dcnatt@...>
 

Well done sir. When you get a few minutes let's discuss a couple points re the ra that I've discussed with Ken. I've been doing similar talks and I'd like to see if we can align on a couple points.

Thanks for sharing and representing.

Sent from my iPad

On Sep 2, 2016, at 2:41 AM, Alexis Richardson via cncf-marketing <cncf-marketing@...> wrote:

Hi

I gave a keynote yesterday at Software Circus in Amsterdam. The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course. I used the draft reference stack to
illustrate the technologies we are looking for. I spoke about
software, standards vs conventions etc. At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF. So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis
_______________________________________________
cncf-marketing mailing list
cncf-marketing@...
https://lists.cncf.io/mailman/listinfo/cncf-marketing


Re: [cncf-marketing] my slides on cloud native from Software Circus

Zachary Smith
 

excellent stuff, Alexis!  

-zac



On Fri, Sep 2, 2016 2:41 AM, Alexis Richardson via cncf-marketing cncf-marketing@... wrote:

Hi


I gave a keynote yesterday at Software Circus in Amsterdam. The bulk

of my talk was about CNCF and why it needs to exist, interspersed with

some personal opinions of course. I used the draft reference stack to

illustrate the technologies we are looking for. I spoke about

software, standards vs conventions etc. At the end I said a few words

about appc, Docker and long term stability, and the "open" platform.


Afterwards a lot of people said it was the first time they had

understood CNCF. So I must have done something right :-/


The slides are here -

https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p


Trigger warning - first section contains product promotion that some

may wish to skip.


alexis

_______________________________________________

cncf-marketing mailing list

cncf-marketing@...

https://lists.cncf.io/mailman/listinfo/cncf-marketing




Zachary Smith, CEO of Packet
+1 212.812.4178


my slides on cloud native from Software Circus

alexis richardson
 

Hi

I gave a keynote yesterday at Software Circus in Amsterdam. The bulk
of my talk was about CNCF and why it needs to exist, interspersed with
some personal opinions of course. I used the draft reference stack to
illustrate the technologies we are looking for. I spoke about
software, standards vs conventions etc. At the end I said a few words
about appc, Docker and long term stability, and the "open" platform.

Afterwards a lot of people said it was the first time they had
understood CNCF. So I must have done something right :-/

The slides are here -
https://docs.google.com/presentation/d/1slyvCus5PfOG-H2Ll0OjlxGTeUc-lf8cH1KsU71SopI/edit#slide=id.p

Trigger warning - first section contains product promotion that some
may wish to skip.

alexis


Re: [ANN] Incubator: node-feature-discovery (our first incubator project!)

alexis richardson
 

- kubernetes-dev
+ cncf-toc


All,

We are getting close to the point where we'll need to set out the
principles for exiting Incubation at CNCF. Recall that we agreed to
put all projects into Incubation as an initial simplifying assumption
while CNCF/TOC was getting started in Q1 2016. Now that more
prospective Cloud Native projects are coming through the pipe, with a
range of characteristics, we can more concretely define incubation.

To that end, I want to point out* this high quality piece of work
(below) from Brandon, Sarah and Brian. Kubernetes has a very specific
shape and spirit, and may have different gating concerns for
incubation. But: please take a look. Perhaps we could adapt this
document into a CNCF Incubation model.

alexis

* and praise





On Tue, Aug 30, 2016 at 10:50 PM, Brandon Philips
<brandon.philips@...> wrote:
Hello Everyone-

We recently created a process for creating new projects under Kubernetes,
which we call the "incubator". You can read all about it over on the
community repo.

The very first project to go into Incubation is node-feature-discovery which
you can learn more about on the Overview page. Welcome aboard!

If you have any questions please reach out to Connor and Balaji (on cc).

Incubation team:
Sponsor: Dawn Chen
Champion: David Opp
SIG: sig-node

Thank You!

Brandon

--
You received this message because you are subscribed to the Google Groups
"Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to kubernetes-dev+unsubscribe@....
To post to this group, send email to kubernetes-dev@....
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-dev/CAD2oYtNC4NDHMEO8t2nJL0MxoWN5n5MfLmBiEcr2KBCbT0NAig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] CoreDNS Project Proposal

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:

I agree with Camille -- while an admirable start (and a good name), CoreDNS
is just too new and too small: the project itself was only conceived of in
March, and by any metric (GH issues, contributors, commits, followers,
stars, releases, social media mentions) it remains nascent. So I would say
the answer to CoreDNS is not so much "no" as "not yet".

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:

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

+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

+1


On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc,
<cncf-toc@...> wrote:

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:

Miek Gieben github: miekg

Michael Richmond github: mrichmon

github: splack

Felix Cantournet github: fcantournet

github: leelynne

Matt Layher github: mdlayher

Vasily Vailyev github: pixelbender

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:

much of the CoreDNS code plugs into the framework to add DNS behavior.

CoreDNS provides a wrapper around the framework to provide a DNS-tuned
command-line interface.

Go dependencies:

Go package: mholt/caddy (ASLV2
https://github.com/mholt/caddy/blob/master/LICENSE.txt)

Go package: beorn7/perks (MIT
https://github.com/beorn7/perks/blob/master/LICENSE)

Go package: coreos/etcd (ASLv2
https://github.com/coreos/etcd/blob/master/LICENSE)

Go package: flynn/go-shlex (ASLv2
https://github.com/flynn-archive/go-shlex/blob/master/COPYING)

Go package: fsnotify/fsnotify (BSD
https://github.com/fsnotify/fsnotify/blob/master/LICENSE)

Go package: golang/protobuf (BSD
https://github.com/golang/protobuf/blob/master/LICENSE)

Go package: hashicorp/go-syslog (MIT
https://github.com/hashicorp/go-syslog/blob/master/LICENSE)

Go package: matttproud/golang_protobuf_extensions
(ASLv2https://github.com/matttproud/golang_protobuf_extensions/blob/master/LICENSE

Go package: miekg/dns (BSD
https://github.com/miekg/dns/blob/master/LICENSE)

Go package: patrickmn/go-cache (MIT
https://github.com/patrickmn/go-cache/blob/master/LICENSE)

Go package: prometheus/client_golang
(ASLv2https://github.com/prometheus/client_golang/blob/master/LICENSE)

Go package: prometheus/client_model
(ASLv2https://github.com/prometheus/client_model/blob/master/LICENSE)

Go package: prometheus/common (ASLv2
https://github.com/prometheus/common/blob/master/LICENSE)

Go package: prometheus/procfs (ASLv2
https://github.com/prometheus/procfs/blob/master/LICENSE)

Go package: ugorji/go (MIT
https://github.com/ugorji/go/blob/master/LICENSE)

Go package: xenolf/lego (MIT
https://github.com/xenolf/lego/blob/master/LICENSE)

Go package: golang/x/crypto (BSD
https://github.com/golang/crypto/blob/master/LICENSE)

Go package: golang/x/net (BSD
https://github.com/golang/net/blob/master/LICENSE)

Go package: golang/x/sys (BSD
https://github.com/golang/sys/blob/master/LICENSE)

Go package: natefinch/lumberjack.v2 (MIT
https://github.com/natefinch/lumberjack/blob/v2.0/LICENSE)

Go package: square/go-jose.v1 (ASLv2
https://github.com/square/go-jose/blob/master/LICENSE)

Kubernetes (for CoreDNS → Kubernetes integration)
(ASLv2https://github.com/kubernetes/kubernetes/blob/master/LICENSE)

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.

_______________________________________________
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

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] CoreDNS Project Proposal

Bryan Cantrill <bryan@...>
 


I agree with Camille -- while an admirable start (and a good name), CoreDNS is just too new and too small: the project itself was only conceived of in March, and by any metric (GH issues, contributors, commits, followers, stars, releases, social media mentions) it remains nascent.  So I would say the answer to CoreDNS is not so much "no" as "not yet".

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:

-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:
+1



From: <cncf-toc-bounces@...o> 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

+1


On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc, <cncf-toc@...> wrote:
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:

  • Miek Gieben github: miekg

  • Michael Richmond github: mrichmon

  • github: splack

  • Felix Cantournet github: fcantournet

  • github: leelynne

  • Matt Layher github: mdlayher

  • Vasily Vailyev github: pixelbender

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:

  1. much of the CoreDNS code plugs into the framework to add DNS behavior.

  2. CoreDNS provides a wrapper around the framework to provide a DNS-tuned command-line interface.

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.

_______________________________________________
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



Re: [VOTE] CoreDNS Project Proposal

alexis richardson
 

Agreed. 


On Tue, 30 Aug 2016, 15:14 Doug Davis, <dug@...> wrote:

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.


[1] Sec 9: "All such contributions should meet a set criteria created by the TOC and ratified by the Governing Board"

thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Alexis Richardson via cncf-toc ---08/30/2016 08:48:29 AM---Thanks Camille. This issue will also come up with Heron.

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: Camille Fournier <skamille@...>, Carlos Alonso <calonso@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Date: 08/30/2016 08:48 AM


Subject: Re: [cncf-toc] [VOTE] CoreDNS Project Proposal

Sent by: cncf-toc-bounces@...





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:

    -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:
    +1

    +1


    On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc, <cncf-toc@...> wrote:

      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:
        • Miek Gieben github: miekg
        • Michael Richmond github: mrichmon
        • github: splack
        • Felix Cantournet github: fcantournet
        • github: leelynne
        • Matt Layher github: mdlayher
        • Vasily Vailyev github: pixelbender
      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:

        1. much of the CoreDNS code plugs into the framework to add DNS behavior.
        2. CoreDNS provides a wrapper around the framework to provide a DNS-tuned command-line interface.


Re: [VOTE] CoreDNS Project Proposal

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.


[1] Sec 9: "All such contributions should meet a set criteria created by the TOC and ratified by the Governing Board"

thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Alexis Richardson via cncf-toc ---08/30/2016 08:48:29 AM---Thanks Camille. This issue will also come up with Heron.

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: Camille Fournier <skamille@...>, Carlos Alonso <calonso@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Date: 08/30/2016 08:48 AM
Subject: Re: [cncf-toc] [VOTE] CoreDNS Project Proposal
Sent by: cncf-toc-bounces@...





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:



Re: [VOTE] CoreDNS Project Proposal

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:

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

+1


On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc, <cncf-toc@...> wrote:
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:

  • Miek Gieben github: miekg

  • Michael Richmond github: mrichmon

  • github: splack

  • Felix Cantournet github: fcantournet

  • github: leelynne

  • Matt Layher github: mdlayher

  • Vasily Vailyev github: pixelbender

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:

  1. much of the CoreDNS code plugs into the framework to add DNS behavior.

  2. CoreDNS provides a wrapper around the framework to provide a DNS-tuned command-line interface.

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.

_______________________________________________
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


Re: [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:
+1



From: <cncf-toc-bounces@....io> 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

+1


On Thu, 25 Aug 2016, 05:37 Jonathan Boulle via cncf-toc, <cncf-toc@...> wrote:
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:

  • Miek Gieben github: miekg

  • Michael Richmond github: mrichmon

  • github: splack

  • Felix Cantournet github: fcantournet

  • github: leelynne

  • Matt Layher github: mdlayher

  • Vasily Vailyev github: pixelbender

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:

  1. much of the CoreDNS code plugs into the framework to add DNS behavior.

  2. CoreDNS provides a wrapper around the framework to provide a DNS-tuned command-line interface.

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.

_______________________________________________
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


Re: CNCF TOC: Reminder to vote on CoreDNS project proposal

Elissam
 

+1

Sent from my tiny device

On Aug 29, 2016, at 11:00 AM, Kenneth Owens (kenowens) via cncf-toc <cncf-toc@...> wrote:

+1

 

<image001.jpg>

Kenneth Owens
CTO
Cisco Intercloud Services
kenowens@...
Phone: +1 408 424 0872
Mobile: +1 314 591 5708


Cisco.com

<image002.png> <image003.png> <image004.png> 

 

<image005.gif> Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

 

From: Chris Aniszczyk [mailto:caniszczyk@...]
Sent: Friday, August 26, 2016 6:23 PM
Subject: CNCF TOC: Reminder to vote on CoreDNS project proposal

 

Here's a link: https://ponymail.cncf.io/thread.html/Zpirhh93puai3eh

 

It was sent out to the cncf-toc list very recently.

 

Have a great weekend :)

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: CNCF TOC: Reminder to vote on CoreDNS project proposal

Kenneth Owens (kenowens) <kenowens@...>
 

+1

 

Kenneth Owens
CTO
Cisco Intercloud Services
kenowens@...
Phone: +1 408 424 0872
Mobile: +1 314 591 5708


Cisco.com

   

 

Think before you print. Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

 

From: Chris Aniszczyk [mailto:caniszczyk@...]
Sent: Friday, August 26, 2016 6:23 PM
Subject: CNCF TOC: Reminder to vote on CoreDNS project proposal

 

Here's a link: https://ponymail.cncf.io/thread.html/Zpirhh93puai3eh

 

It was sent out to the cncf-toc list very recently.

 

Have a great weekend :)

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

6841 - 6860 of 7192