Date   

Re: [VOTE] [PAUSE] INCEPTION

Bryan Cantrill <bryan@...>
 


I'm sorry to have missed the call this week, but I think the term "Sandbox" is great -- in addition to its positive connotations of fun and play, it's also dirty and filled with sniffling toddlers, broken plastic toys, and the occasional cat poop.  Much, much better than "inception"!

        - Bryan


On Thu, Feb 8, 2018 at 6:48 PM, alexis richardson <alexis@...> wrote:
Hi all

In this week's TOC we converged on some possible changes to the
Inception tier, that can address issues that have been raised about
market perception & confusion.  It is most likely that Inception will
be replaced with a "Sandbox" tier.

Chris Aniszczyk is drafting a written statement proposing Sandbox and
associated changes and clarifications.  This will include much of the
discussion from the Zoom Chat on this week's TOC call.  This draft is
under active editing now:
https://docs.google.com/document/d/1MkuVT7Q6itn9ESW-iyqIXsEqTPBrStXlvzESg94933A/edit

Until the TOC has reviewed the Sandbox proposal we shall suspend
voting on Inception projects.  I apologise for any delays that are
caused by this.  For the avoidance of further confusion, Sandbox will
be presented *as soon as possible* which I hope means at the next TOC
call.

alexis






On Wed, Feb 7, 2018 at 10:55 PM, Yang Guan via Lists.Cncf.Io
<yangguan=google.com@lists.cncf.io> wrote:
> +1 (non-binding)
>





Re: [VOTE] SPIFFE project proposal (inception)

alexis richardson
 

Please note that as of 0945 UK time on 8 Feb 2018, voting is paused.



On Wed, Feb 7, 2018 at 10:55 PM, Yang Guan via Lists.Cncf.Io
<yangguan=google.com@...> wrote:
+1 (non-binding)


[VOTE] [PAUSE] INCEPTION

alexis richardson
 

Hi all

In this week's TOC we converged on some possible changes to the
Inception tier, that can address issues that have been raised about
market perception & confusion. It is most likely that Inception will
be replaced with a "Sandbox" tier.

Chris Aniszczyk is drafting a written statement proposing Sandbox and
associated changes and clarifications. This will include much of the
discussion from the Zoom Chat on this week's TOC call. This draft is
under active editing now:
https://docs.google.com/document/d/1MkuVT7Q6itn9ESW-iyqIXsEqTPBrStXlvzESg94933A/edit

Until the TOC has reviewed the Sandbox proposal we shall suspend
voting on Inception projects. I apologise for any delays that are
caused by this. For the avoidance of further confusion, Sandbox will
be presented *as soon as possible* which I hope means at the next TOC
call.

alexis






On Wed, Feb 7, 2018 at 10:55 PM, Yang Guan via Lists.Cncf.Io
<yangguan=google.com@...> wrote:
+1 (non-binding)


Re: [VOTE] SPIFFE project proposal (inception)

Yang Guan
 

+1 (non-binding)


Re: [VOTE] SPIFFE project proposal (inception)

Egor Guz <egor.guz@...>
 

+1 (non-binding)


Re: Incubating and Inception levels in marketing materials

alexis richardson
 

Erin

Let's sort out inception/sandbox and then we'll see. For the record,
I think "community support" is not an objective metric.

alexis

On Wed, Feb 7, 2018 at 4:33 PM, Erin Boyd <eboyd@...> wrote:
Alexis,
I guess it depends on what we plan to do with inception in terms of
acceptance, dd, marketing, etc..

I absolutely think it's imperative that we have community support at
incubation.

The concerns I am seeing voiced in several PRs during the DD for inception.

Does this better clarify my concerns to you?
Erin




On Mon, Feb 5, 2018 at 2:20 PM, alexis richardson <alexis@...>
wrote:

Erin

Please could you be specific? Do you think Inception and/or
Incubation should require Maintainers from more companies? I am not
promising changes, but *now* is the time to table and debate this. If
people have concerns, please invite them to voice them here or have a
sponsor do so on their behalf.

alexis


On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
Hi Alexis,
It's not a question, but just an observation of voiced 'concern' I see
on
many of the inception level requests, where the feedback is "where is
the
community support beyond company A", etc.

So redefining our "what is means to be Cloud Native" and including Open
Source as part of this primary driving directive, it seems
counter-intuitive
to accept projects, even at an inception level if they don't strong
community support.

Thoughts?
Erin



On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
wrote:

Erin

Thank you.

What is your question about community support?

Alexis


On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:

Alexis/Dan et all,
I appreciate the work it is to grow this foundation and ensure it
lands
in a healthy place, it's no small feat!

With the popularity of CNCF, it's 'endorsement' to projects is a huge
success factor.

And while I know we are current revamping definitions to provide
better
understanding of the stages of a project, I think many in the
community are
concerned that outside of this, perception is reality. Honestly, if I
am a
potential customer and looking at a project, just having it listed
(with a
bunch of other projects at different levels) on the CNCF website
probably
instills a certain amount of confidence in the project.

The criteria between inception to graduation is well documented and
understood by the TOC, but outside of that, I am not sure.
Many times it's been brought of that for instance, "community support
is
not sufficient for xyz project". We have agreed this is not a strict
requirement of inception, however those active in the Open Source
community
see this as criteria zero.

Also, do we have a good way of tracking technical concerns brought
forward from the DD to the next phase? Have we considered creating and
publishing a concrete timeline around each of these phases and what
the plan
is if projects don't meet these guidelines? I feel that many people
are
trying to provide good due diligence while also balancing their day
jobs, so
things are also getting possibly missed because the dates aren't well
defined. (I know I've mentioned this to Chris so sorry to feel like a
broken
record here).

Would love to hear other's thoughts around this.
Thanks,
Erin



On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
wrote:

Jess

That's really one for Dan but AIUI the whole website is in the
process
of being nurtured into an optimal state for 2018 .... So all
comments
good & timely, anywhere.

a



On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
wrote:
Quick question: what are the platinum members, the ones who paid
the
300k?

Do they need to be on the same slide / materials as the projects?
Is
that written into a contract or something? Also I'm more than happy
to
ask this on the call :)

On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
<alexis@...> wrote:
thanks Dan & team

@all TOC community, please do comment to Dan directly or on
tomorrow's TOC call


On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
wrote:
We'll be discussing maturity levels on the TOC call. This is just
a
quick
note that at the TOC's request, we revised CNCF marketing
materials
to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/


https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon
as
the
first projects graduate. The same project separation will carry
over
to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation
https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu





Re: Incubating and Inception levels in marketing materials

Erin Boyd
 

Alexis,
I guess it depends on what we plan to do with inception in terms of acceptance, dd, marketing, etc..

I absolutely think it's imperative that we have community support at incubation.

The concerns I am seeing voiced in several PRs during the DD for inception.

Does this better clarify my concerns to you?
Erin




On Mon, Feb 5, 2018 at 2:20 PM, alexis richardson <alexis@...> wrote:
Erin

Please could you be specific?  Do you think Inception and/or
Incubation should require Maintainers from more companies?  I am not
promising changes, but *now* is the time to table and debate this.  If
people have concerns, please invite them to voice them here or have a
sponsor do so on their behalf.

alexis


On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
> Hi Alexis,
> It's not a question, but just an observation of voiced 'concern' I see on
> many of the inception level requests, where the feedback is "where is the
> community support beyond company A", etc.
>
> So redefining our "what is means to be Cloud Native" and including Open
> Source as part of this primary driving directive, it seems counter-intuitive
> to accept projects, even at an inception level if they don't strong
> community support.
>
> Thoughts?
> Erin
>
>
>
> On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
> wrote:
>>
>> Erin
>>
>> Thank you.
>>
>> What is your question about community support?
>>
>> Alexis
>>
>>
>> On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:
>>>
>>> Alexis/Dan et all,
>>> I appreciate the work it is to grow this foundation and ensure it lands
>>> in a healthy place, it's no small feat!
>>>
>>> With the popularity of CNCF, it's 'endorsement' to projects is a huge
>>> success factor.
>>>
>>> And while I know we are current revamping definitions to provide better
>>> understanding of the stages of a project, I think many in the community are
>>> concerned that outside of this, perception is reality. Honestly, if I am a
>>> potential customer and looking at a project, just having it listed (with a
>>> bunch of other projects at different levels) on the CNCF website probably
>>> instills a certain amount of confidence in the project.
>>>
>>> The criteria between inception to graduation is well documented and
>>> understood by the TOC, but outside of that, I am not sure.
>>> Many times it's been brought of that for instance, "community support is
>>> not sufficient for xyz project". We have agreed this is not a strict
>>> requirement of inception, however those active in the Open Source community
>>> see this as criteria zero.
>>>
>>> Also, do we have a good way of tracking technical concerns brought
>>> forward from the DD to the next phase? Have we considered creating and
>>> publishing a concrete timeline around each of these phases and what the plan
>>> is if projects don't meet these guidelines? I feel that many people are
>>> trying to provide good due diligence while also balancing their day jobs, so
>>> things are also getting possibly missed because the dates aren't well
>>> defined. (I know I've mentioned this to Chris so sorry to feel like a broken
>>> record here).
>>>
>>> Would love to hear other's thoughts around this.
>>> Thanks,
>>> Erin
>>>
>>>
>>>
>>> On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
>>> wrote:
>>>>
>>>> Jess
>>>>
>>>> That's really one for Dan but AIUI the whole website is in the process
>>>> of being nurtured into an optimal state for 2018 ....  So all comments
>>>> good & timely, anywhere.
>>>>
>>>> a
>>>>
>>>>
>>>>
>>>> On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
>>>> wrote:
>>>> > Quick question: what are the platinum members, the ones who paid the
>>>> > 300k?
>>>> >
>>>> > Do they need to be on the same slide / materials as the projects? Is
>>>> > that written into a contract or something? Also I'm more than happy to
>>>> > ask this on the call :)
>>>> >
>>>> > On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
>>>> > <alexis@...> wrote:
>>>> >> thanks Dan & team
>>>> >>
>>>> >> @all TOC community, please do comment to Dan directly or on
>>>> >> tomorrow's TOC call
>>>> >>
>>>> >>
>>>> >> On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
>>>> >> wrote:
>>>> >>> We'll be discussing maturity levels on the TOC call. This is just a
>>>> >>> quick
>>>> >>> note that at the TOC's request, we revised CNCF marketing materials
>>>> >>> to
>>>> >>> clearly separate Incubating and Inception projects:
>>>> >>>
>>>> >>> https://www.cncf.io/
>>>> >>> https://www.cncf.io/projects/
>>>> >>>
>>>> >>> https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0
>>>> >>>
>>>> >>> We will obviously add a more prominent graduated section as soon as
>>>> >>> the
>>>> >>> first projects graduate. The same project separation will carry over
>>>> >>> to our
>>>> >>> marketing materials for KubeCon + CloudNativeCon.
>>>> >>> --
>>>> >>> Dan Kohn <dan@...>
>>>> >>> Executive Director, Cloud Native Computing Foundation
>>>> >>> https://www.cncf.io
>>>> >>> +1-415-233-1000 https://www.dankohn.com
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> >
>>>> > Jessie Frazelle
>>>> > 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
>>>> > pgp.mit.edu
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>
>
>





Re: Incubating and Inception levels in marketing materials

alexis richardson
 

Alex

Thanks for your patience in this.  Showing a mature and objective face to users is so important and I know you have been overwhelmed and doggedly doing the right thing. 

In terms of handling the issues below, the written proposal is the next step for all of us.  It may be efficient to liaise with Dan directly.  Your early feedback could help us avoid some iterations later.

A


On Wed, 7 Feb 2018, 16:08 Alex Chircop, <alex.chircop@...> wrote:
Following up on this thread and the discussion on the TOC call yesterday, I'd like to see better clarity overall in the marketing of how inception and incubation projects are differentiated.

The changes to the website, the text to the press releases,  and the landscape are all good first steps, however I worry that it does not achieve the goal of clearly differentiating the projects for end users.   Camille's comment about how the Apache foundation differentiates incubation projects (https://incubator.apache.org/) would be an option/example doing this better.

Some simple examples of how the confusion is being perpetuated right now:
*  On https://www.cncf.io/projects/, the inception and incubation projects are listed together under different headings, but with nothing to indicate that they have different criteria.  End users are very unlikely to make the effort to read and digest the graduation criteria, so any way of simply explaining the difference on the projects page would be helpful.
*  The press releases for both Rook (inception) and Vitess (incubator) both start with the tagline "Technical Oversight Committee (TOC) voted to accept xx as the yyth hosted project, alongside Kubernetes, Prometheus, ....".   Although there was text in the release about inception projects and graduation criteria, the bulk of the blogs and follow-on articles latched onto the first sentence and ran with that.   The tag line is that the projects are in the same box as Kubernetes or Prometheus.  From an end user point of view there is very little to determine difference in project maturity, size or adoption.

Anecdotally, I've personally spent a lot of effort answering questions in emails, slack & meetups over the last few days and can confirm that the confusion is real :-)

I believe that all work on cloud native projects benefits the community and the adoption of cloud native technologies in general, and inception projects supported by a foundation like the CNCF is useful - however getting the terminology right and following on through in all aspects of marketing is critical to ensure end users are getting the right information.   This is especially important in the "Cloud Native" world where there is certain amount of flux and constant change.

Thanks,
Alex

On 06/02/2018, 07:52, "cncf-toc@... on behalf of alexis richardson" <cncf-toc@... on behalf of alexis@...> wrote:

    Luis

    The CNCF does and should endorse cross-org maintainership.  It has to
    be realistic though.  Many projects have a very healthy lifecycle with
    just one group backing them, even when that group coincides with a
    single legal entity.

    a


    On Tue, Feb 6, 2018 at 5:15 AM, Luis Pab?n <luis@...> wrote:
    > Hi Alexis,
    >  I think it is more about having a healthy open community with multiple
    > consistent maintainers and contributors. Multiple backgrounds and agendas
    > increase the amount of innovation in the project, but projects with a single
    > company/maintainer might lack that drive.
    >
    > - Luis
    >
    > On Mon, Feb 5, 2018 at 4:20 PM, alexis richardson <alexis@...>
    > wrote:
    >>
    >> Erin
    >>
    >> Please could you be specific?  Do you think Inception and/or
    >> Incubation should require Maintainers from more companies?  I am not
    >> promising changes, but *now* is the time to table and debate this.  If
    >> people have concerns, please invite them to voice them here or have a
    >> sponsor do so on their behalf.
    >>
    >> alexis
    >>
    >>
    >> On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
    >> > Hi Alexis,
    >> > It's not a question, but just an observation of voiced 'concern' I see
    >> > on
    >> > many of the inception level requests, where the feedback is "where is
    >> > the
    >> > community support beyond company A", etc.
    >> >
    >> > So redefining our "what is means to be Cloud Native" and including Open
    >> > Source as part of this primary driving directive, it seems
    >> > counter-intuitive
    >> > to accept projects, even at an inception level if they don't strong
    >> > community support.
    >> >
    >> > Thoughts?
    >> > Erin
    >> >
    >> >
    >> >
    >> > On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
    >> > wrote:
    >> >>
    >> >> Erin
    >> >>
    >> >> Thank you.
    >> >>
    >> >> What is your question about community support?
    >> >>
    >> >> Alexis
    >> >>
    >> >>
    >> >> On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:
    >> >>>
    >> >>> Alexis/Dan et all,
    >> >>> I appreciate the work it is to grow this foundation and ensure it
    >> >>> lands
    >> >>> in a healthy place, it's no small feat!
    >> >>>
    >> >>> With the popularity of CNCF, it's 'endorsement' to projects is a huge
    >> >>> success factor.
    >> >>>
    >> >>> And while I know we are current revamping definitions to provide
    >> >>> better
    >> >>> understanding of the stages of a project, I think many in the
    >> >>> community are
    >> >>> concerned that outside of this, perception is reality. Honestly, if I
    >> >>> am a
    >> >>> potential customer and looking at a project, just having it listed
    >> >>> (with a
    >> >>> bunch of other projects at different levels) on the CNCF website
    >> >>> probably
    >> >>> instills a certain amount of confidence in the project.
    >> >>>
    >> >>> The criteria between inception to graduation is well documented and
    >> >>> understood by the TOC, but outside of that, I am not sure.
    >> >>> Many times it's been brought of that for instance, "community support
    >> >>> is
    >> >>> not sufficient for xyz project". We have agreed this is not a strict
    >> >>> requirement of inception, however those active in the Open Source
    >> >>> community
    >> >>> see this as criteria zero.
    >> >>>
    >> >>> Also, do we have a good way of tracking technical concerns brought
    >> >>> forward from the DD to the next phase? Have we considered creating and
    >> >>> publishing a concrete timeline around each of these phases and what
    >> >>> the plan
    >> >>> is if projects don't meet these guidelines? I feel that many people
    >> >>> are
    >> >>> trying to provide good due diligence while also balancing their day
    >> >>> jobs, so
    >> >>> things are also getting possibly missed because the dates aren't well
    >> >>> defined. (I know I've mentioned this to Chris so sorry to feel like a
    >> >>> broken
    >> >>> record here).
    >> >>>
    >> >>> Would love to hear other's thoughts around this.
    >> >>> Thanks,
    >> >>> Erin
    >> >>>
    >> >>>
    >> >>>
    >> >>> On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
    >> >>> wrote:
    >> >>>>
    >> >>>> Jess
    >> >>>>
    >> >>>> That's really one for Dan but AIUI the whole website is in the
    >> >>>> process
    >> >>>> of being nurtured into an optimal state for 2018 ....  So all
    >> >>>> comments
    >> >>>> good & timely, anywhere.
    >> >>>>
    >> >>>> a
    >> >>>>
    >> >>>>
    >> >>>>
    >> >>>> On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
    >> >>>> wrote:
    >> >>>> > Quick question: what are the platinum members, the ones who paid
    >> >>>> > the
    >> >>>> > 300k?
    >> >>>> >
    >> >>>> > Do they need to be on the same slide / materials as the projects?
    >> >>>> > Is
    >> >>>> > that written into a contract or something? Also I'm more than happy
    >> >>>> > to
    >> >>>> > ask this on the call :)
    >> >>>> >
    >> >>>> > On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
    >> >>>> > <alexis@...> wrote:
    >> >>>> >> thanks Dan & team
    >> >>>> >>
    >> >>>> >> @all TOC community, please do comment to Dan directly or on
    >> >>>> >> tomorrow's TOC call
    >> >>>> >>
    >> >>>> >>
    >> >>>> >> On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
    >> >>>> >> wrote:
    >> >>>> >>> We'll be discussing maturity levels on the TOC call. This is just
    >> >>>> >>> a
    >> >>>> >>> quick
    >> >>>> >>> note that at the TOC's request, we revised CNCF marketing
    >> >>>> >>> materials
    >> >>>> >>> to
    >> >>>> >>> clearly separate Incubating and Inception projects:
    >> >>>> >>>
    >> >>>> >>> https://www.cncf.io/
    >> >>>> >>> https://www.cncf.io/projects/
    >> >>>> >>>
    >> >>>> >>>
    >> >>>> >>> https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0
    >> >>>> >>>
    >> >>>> >>> We will obviously add a more prominent graduated section as soon
    >> >>>> >>> as
    >> >>>> >>> the
    >> >>>> >>> first projects graduate. The same project separation will carry
    >> >>>> >>> over
    >> >>>> >>> to our
    >> >>>> >>> marketing materials for KubeCon + CloudNativeCon.
    >> >>>> >>> --
    >> >>>> >>> Dan Kohn <dan@...>
    >> >>>> >>> Executive Director, Cloud Native Computing Foundation
    >> >>>> >>> https://www.cncf.io
    >> >>>> >>> +1-415-233-1000 https://www.dankohn.com
    >> >>>> >>>
    >> >>>> >>
    >> >>>> >>
    >> >>>> >>
    >> >>>> >
    >> >>>> >
    >> >>>> >
    >> >>>> > --
    >> >>>> >
    >> >>>> >
    >> >>>> > Jessie Frazelle
    >> >>>> > 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
    >> >>>> > pgp.mit.edu
    >> >>>> >
    >> >>>> >
    >> >>>> >
    >> >>>>
    >> >>>>
    >> >>>>
    >> >>>
    >> >
    >> >
    >>
    >>
    >>
    >
    >









Re: Incubating and Inception levels in marketing materials

Alex Chircop
 

Following up on this thread and the discussion on the TOC call yesterday, I'd like to see better clarity overall in the marketing of how inception and incubation projects are differentiated.

The changes to the website, the text to the press releases, and the landscape are all good first steps, however I worry that it does not achieve the goal of clearly differentiating the projects for end users. Camille's comment about how the Apache foundation differentiates incubation projects (https://incubator.apache.org/) would be an option/example doing this better.

Some simple examples of how the confusion is being perpetuated right now:
* On https://www.cncf.io/projects/, the inception and incubation projects are listed together under different headings, but with nothing to indicate that they have different criteria. End users are very unlikely to make the effort to read and digest the graduation criteria, so any way of simply explaining the difference on the projects page would be helpful.
* The press releases for both Rook (inception) and Vitess (incubator) both start with the tagline "Technical Oversight Committee (TOC) voted to accept xx as the yyth hosted project, alongside Kubernetes, Prometheus, ....". Although there was text in the release about inception projects and graduation criteria, the bulk of the blogs and follow-on articles latched onto the first sentence and ran with that. The tag line is that the projects are in the same box as Kubernetes or Prometheus. From an end user point of view there is very little to determine difference in project maturity, size or adoption.

Anecdotally, I've personally spent a lot of effort answering questions in emails, slack & meetups over the last few days and can confirm that the confusion is real :-)

I believe that all work on cloud native projects benefits the community and the adoption of cloud native technologies in general, and inception projects supported by a foundation like the CNCF is useful - however getting the terminology right and following on through in all aspects of marketing is critical to ensure end users are getting the right information. This is especially important in the "Cloud Native" world where there is certain amount of flux and constant change.

Thanks,
Alex

On 06/02/2018, 07:52, "cncf-toc@... on behalf of alexis richardson" <cncf-toc@... on behalf of alexis@...> wrote:

Luis

The CNCF does and should endorse cross-org maintainership. It has to
be realistic though. Many projects have a very healthy lifecycle with
just one group backing them, even when that group coincides with a
single legal entity.

a

On Tue, Feb 6, 2018 at 5:15 AM, Luis Pab?n <luis@...> wrote:
> Hi Alexis,
> I think it is more about having a healthy open community with multiple
> consistent maintainers and contributors. Multiple backgrounds and agendas
> increase the amount of innovation in the project, but projects with a single
> company/maintainer might lack that drive.
>
> - Luis
>
> On Mon, Feb 5, 2018 at 4:20 PM, alexis richardson <alexis@...>
> wrote:
>>
>> Erin
>>
>> Please could you be specific? Do you think Inception and/or
>> Incubation should require Maintainers from more companies? I am not
>> promising changes, but *now* is the time to table and debate this. If
>> people have concerns, please invite them to voice them here or have a
>> sponsor do so on their behalf.
>>
>> alexis
>>
>>
>> On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
>> > Hi Alexis,
>> > It's not a question, but just an observation of voiced 'concern' I see
>> > on
>> > many of the inception level requests, where the feedback is "where is
>> > the
>> > community support beyond company A", etc.
>> >
>> > So redefining our "what is means to be Cloud Native" and including Open
>> > Source as part of this primary driving directive, it seems
>> > counter-intuitive
>> > to accept projects, even at an inception level if they don't strong
>> > community support.
>> >
>> > Thoughts?
>> > Erin
>> >
>> >
>> >
>> > On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
>> > wrote:
>> >>
>> >> Erin
>> >>
>> >> Thank you.
>> >>
>> >> What is your question about community support?
>> >>
>> >> Alexis
>> >>
>> >>
>> >> On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:
>> >>>
>> >>> Alexis/Dan et all,
>> >>> I appreciate the work it is to grow this foundation and ensure it
>> >>> lands
>> >>> in a healthy place, it's no small feat!
>> >>>
>> >>> With the popularity of CNCF, it's 'endorsement' to projects is a huge
>> >>> success factor.
>> >>>
>> >>> And while I know we are current revamping definitions to provide
>> >>> better
>> >>> understanding of the stages of a project, I think many in the
>> >>> community are
>> >>> concerned that outside of this, perception is reality. Honestly, if I
>> >>> am a
>> >>> potential customer and looking at a project, just having it listed
>> >>> (with a
>> >>> bunch of other projects at different levels) on the CNCF website
>> >>> probably
>> >>> instills a certain amount of confidence in the project.
>> >>>
>> >>> The criteria between inception to graduation is well documented and
>> >>> understood by the TOC, but outside of that, I am not sure.
>> >>> Many times it's been brought of that for instance, "community support
>> >>> is
>> >>> not sufficient for xyz project". We have agreed this is not a strict
>> >>> requirement of inception, however those active in the Open Source
>> >>> community
>> >>> see this as criteria zero.
>> >>>
>> >>> Also, do we have a good way of tracking technical concerns brought
>> >>> forward from the DD to the next phase? Have we considered creating and
>> >>> publishing a concrete timeline around each of these phases and what
>> >>> the plan
>> >>> is if projects don't meet these guidelines? I feel that many people
>> >>> are
>> >>> trying to provide good due diligence while also balancing their day
>> >>> jobs, so
>> >>> things are also getting possibly missed because the dates aren't well
>> >>> defined. (I know I've mentioned this to Chris so sorry to feel like a
>> >>> broken
>> >>> record here).
>> >>>
>> >>> Would love to hear other's thoughts around this.
>> >>> Thanks,
>> >>> Erin
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
>> >>> wrote:
>> >>>>
>> >>>> Jess
>> >>>>
>> >>>> That's really one for Dan but AIUI the whole website is in the
>> >>>> process
>> >>>> of being nurtured into an optimal state for 2018 .... So all
>> >>>> comments
>> >>>> good & timely, anywhere.
>> >>>>
>> >>>> a
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
>> >>>> wrote:
>> >>>> > Quick question: what are the platinum members, the ones who paid
>> >>>> > the
>> >>>> > 300k?
>> >>>> >
>> >>>> > Do they need to be on the same slide / materials as the projects?
>> >>>> > Is
>> >>>> > that written into a contract or something? Also I'm more than happy
>> >>>> > to
>> >>>> > ask this on the call :)
>> >>>> >
>> >>>> > On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
>> >>>> > <alexis@...> wrote:
>> >>>> >> thanks Dan & team
>> >>>> >>
>> >>>> >> @all TOC community, please do comment to Dan directly or on
>> >>>> >> tomorrow's TOC call
>> >>>> >>
>> >>>> >>
>> >>>> >> On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
>> >>>> >> wrote:
>> >>>> >>> We'll be discussing maturity levels on the TOC call. This is just
>> >>>> >>> a
>> >>>> >>> quick
>> >>>> >>> note that at the TOC's request, we revised CNCF marketing
>> >>>> >>> materials
>> >>>> >>> to
>> >>>> >>> clearly separate Incubating and Inception projects:
>> >>>> >>>
>> >>>> >>> https://www.cncf.io/
>> >>>> >>> https://www.cncf.io/projects/
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0
>> >>>> >>>
>> >>>> >>> We will obviously add a more prominent graduated section as soon
>> >>>> >>> as
>> >>>> >>> the
>> >>>> >>> first projects graduate. The same project separation will carry
>> >>>> >>> over
>> >>>> >>> to our
>> >>>> >>> marketing materials for KubeCon + CloudNativeCon.
>> >>>> >>> --
>> >>>> >>> Dan Kohn <dan@...>
>> >>>> >>> Executive Director, Cloud Native Computing Foundation
>> >>>> >>> https://www.cncf.io
>> >>>> >>> +1-415-233-1000 https://www.dankohn.com
>> >>>> >>>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> >
>> >>>> >
>> >>>> > Jessie Frazelle
>> >>>> > 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
>> >>>> > pgp.mit.edu
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >
>> >
>>
>>
>>
>
>


Re: [VOTE] SPIFFE project proposal (inception)

Quinton Hoole
 

+1 (non-binding)

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc@...> on behalf of Chris Aniszczyk <caniszczyk@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Thursday, February 1, 2018 at 07:44
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] [VOTE] SPIFFE project proposal (inception)

The TOC has decided to invite SPIFFE (https://github.com/spiffe) as an INCEPTION level CNCF project, sponsored by Brian Grant from the TOC.

SPIFFE (Secure Production Identity Framework For Everyone) provides a secure identity, in the form of a specially crafted x509 certificate, to every workload in a modern production environment: https://spiffe.io

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/68

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

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


Re: [VOTE] SPIFFE project proposal (inception)

Aabhas Sharma <aabhas@...>
 

+1 non-binding

--
- Aabhas


Re: [VOTE] SPIFFE project proposal (inception)

Christian Posta
 

+1 (non-binding)

--
Christian Posta
twitter: @christianposta




Re: [VOTE] SPIFFE project proposal (inception)

Ben Schmoker
 

+1 non-binding


Re: [VOTE] SPIFFE project proposal (inception)

Daniel Bryant
 

+1 (non-binding)

On Tue, Feb 6, 2018 at 12:08 AM, Vipin Chamakkala <vipin@...> wrote:
+1 (non binding)

--
w o r k — b e n c h

Vipin Chamakkala
Principal



Re: Incubating and Inception levels in marketing materials

alexis richardson
 

Luis

The CNCF does and should endorse cross-org maintainership. It has to
be realistic though. Many projects have a very healthy lifecycle with
just one group backing them, even when that group coincides with a
single legal entity.

a

On Tue, Feb 6, 2018 at 5:15 AM, Luis Pab?n <luis@...> wrote:
Hi Alexis,
I think it is more about having a healthy open community with multiple
consistent maintainers and contributors. Multiple backgrounds and agendas
increase the amount of innovation in the project, but projects with a single
company/maintainer might lack that drive.

- Luis

On Mon, Feb 5, 2018 at 4:20 PM, alexis richardson <alexis@...>
wrote:

Erin

Please could you be specific? Do you think Inception and/or
Incubation should require Maintainers from more companies? I am not
promising changes, but *now* is the time to table and debate this. If
people have concerns, please invite them to voice them here or have a
sponsor do so on their behalf.

alexis


On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
Hi Alexis,
It's not a question, but just an observation of voiced 'concern' I see
on
many of the inception level requests, where the feedback is "where is
the
community support beyond company A", etc.

So redefining our "what is means to be Cloud Native" and including Open
Source as part of this primary driving directive, it seems
counter-intuitive
to accept projects, even at an inception level if they don't strong
community support.

Thoughts?
Erin



On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
wrote:

Erin

Thank you.

What is your question about community support?

Alexis


On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:

Alexis/Dan et all,
I appreciate the work it is to grow this foundation and ensure it
lands
in a healthy place, it's no small feat!

With the popularity of CNCF, it's 'endorsement' to projects is a huge
success factor.

And while I know we are current revamping definitions to provide
better
understanding of the stages of a project, I think many in the
community are
concerned that outside of this, perception is reality. Honestly, if I
am a
potential customer and looking at a project, just having it listed
(with a
bunch of other projects at different levels) on the CNCF website
probably
instills a certain amount of confidence in the project.

The criteria between inception to graduation is well documented and
understood by the TOC, but outside of that, I am not sure.
Many times it's been brought of that for instance, "community support
is
not sufficient for xyz project". We have agreed this is not a strict
requirement of inception, however those active in the Open Source
community
see this as criteria zero.

Also, do we have a good way of tracking technical concerns brought
forward from the DD to the next phase? Have we considered creating and
publishing a concrete timeline around each of these phases and what
the plan
is if projects don't meet these guidelines? I feel that many people
are
trying to provide good due diligence while also balancing their day
jobs, so
things are also getting possibly missed because the dates aren't well
defined. (I know I've mentioned this to Chris so sorry to feel like a
broken
record here).

Would love to hear other's thoughts around this.
Thanks,
Erin



On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
wrote:

Jess

That's really one for Dan but AIUI the whole website is in the
process
of being nurtured into an optimal state for 2018 .... So all
comments
good & timely, anywhere.

a



On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
wrote:
Quick question: what are the platinum members, the ones who paid
the
300k?

Do they need to be on the same slide / materials as the projects?
Is
that written into a contract or something? Also I'm more than happy
to
ask this on the call :)

On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
<alexis@...> wrote:
thanks Dan & team

@all TOC community, please do comment to Dan directly or on
tomorrow's TOC call


On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
wrote:
We'll be discussing maturity levels on the TOC call. This is just
a
quick
note that at the TOC's request, we revised CNCF marketing
materials
to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/


https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon
as
the
first projects graduate. The same project separation will carry
over
to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation
https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu





Re: Incubating and Inception levels in marketing materials

alexis richardson
 

Bob

Thanks for this.

There is a consistent theme that we heard at the F2F in Austin and
again since, that was addressed on the last TOC call and obviously
needs more discussion.

Consider this sequence:
- small project is at super early stage
- joins CNCF with inception status || maintainers form a company
- is deluged with press & VC money
- everyone else is disgruntled, jointly and severally

Is this always an anti-pattern?

a

On Mon, Feb 5, 2018 at 10:58 PM, Bob Wise <bob@...> wrote:
Since the moment is opening up for debate, I will make a stand (again) that
we should require cross-org maintainership.
I believe this might help with some of Jesse Frazelle's commentary recently
as well, although only she could say. :-)

Generally this is a way to not only ensure that the projects are really of
sufficient interest to users, but also to contributors.
We acknowledge this in what it takes to graduate, anyway.

We do not require it at the outset, while at the same time a small company
might be getting funded or gaining market share based on getting to one of
these states.
Since projects are getting so much press at the first stage of acceptance,
they are getting a lot of the value without returning that value to the
community in the form of shared control.

It's not too much to ask (and we should ask) that to receive the CNCF
endorsement that real dedication (not just future expectation) to multi-org
maintainership is required at all phases.

-Bob


On Mon, Feb 5, 2018 at 1:20 PM, alexis richardson <alexis@...>
wrote:

Erin

Please could you be specific? Do you think Inception and/or
Incubation should require Maintainers from more companies? I am not
promising changes, but *now* is the time to table and debate this. If
people have concerns, please invite them to voice them here or have a
sponsor do so on their behalf.

alexis


On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
Hi Alexis,
It's not a question, but just an observation of voiced 'concern' I see
on
many of the inception level requests, where the feedback is "where is
the
community support beyond company A", etc.

So redefining our "what is means to be Cloud Native" and including Open
Source as part of this primary driving directive, it seems
counter-intuitive
to accept projects, even at an inception level if they don't strong
community support.

Thoughts?
Erin



On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
wrote:

Erin

Thank you.

What is your question about community support?

Alexis


On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:

Alexis/Dan et all,
I appreciate the work it is to grow this foundation and ensure it
lands
in a healthy place, it's no small feat!

With the popularity of CNCF, it's 'endorsement' to projects is a huge
success factor.

And while I know we are current revamping definitions to provide
better
understanding of the stages of a project, I think many in the
community are
concerned that outside of this, perception is reality. Honestly, if I
am a
potential customer and looking at a project, just having it listed
(with a
bunch of other projects at different levels) on the CNCF website
probably
instills a certain amount of confidence in the project.

The criteria between inception to graduation is well documented and
understood by the TOC, but outside of that, I am not sure.
Many times it's been brought of that for instance, "community support
is
not sufficient for xyz project". We have agreed this is not a strict
requirement of inception, however those active in the Open Source
community
see this as criteria zero.

Also, do we have a good way of tracking technical concerns brought
forward from the DD to the next phase? Have we considered creating and
publishing a concrete timeline around each of these phases and what
the plan
is if projects don't meet these guidelines? I feel that many people
are
trying to provide good due diligence while also balancing their day
jobs, so
things are also getting possibly missed because the dates aren't well
defined. (I know I've mentioned this to Chris so sorry to feel like a
broken
record here).

Would love to hear other's thoughts around this.
Thanks,
Erin



On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
wrote:

Jess

That's really one for Dan but AIUI the whole website is in the
process
of being nurtured into an optimal state for 2018 .... So all
comments
good & timely, anywhere.

a



On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
wrote:
Quick question: what are the platinum members, the ones who paid
the
300k?

Do they need to be on the same slide / materials as the projects?
Is
that written into a contract or something? Also I'm more than happy
to
ask this on the call :)

On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
<alexis@...> wrote:
thanks Dan & team

@all TOC community, please do comment to Dan directly or on
tomorrow's TOC call


On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
wrote:
We'll be discussing maturity levels on the TOC call. This is just
a
quick
note that at the TOC's request, we revised CNCF marketing
materials
to
clearly separate Incubating and Inception projects:

https://www.cncf.io/
https://www.cncf.io/projects/


https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0

We will obviously add a more prominent graduated section as soon
as
the
first projects graduate. The same project separation will carry
over
to our
marketing materials for KubeCon + CloudNativeCon.
--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation
https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu





Re: updating what it means to be "Cloud Native"

Brian Grant
 

Another take:

Cloud-Native technologies are designed to operate with high velocity at scale in dynamic and distributed environments, such as public clouds and software-defined data centers. Such Cloud-Native applications, services, platforms, and infrastructure are engineered to provide and/or enable self service and high levels of automation through techniques such as abstraction, operability, observability, resilience, agility, elasticity, and loose coupling. They utilize approaches such as declarative APIs and microservices, and include mechanisms such as application containers and service meshes.

The mission of the Cloud Native Computing Foundation is to advance the state of the art and drive adoption of Cloud-Native technologies by fostering an ecosystem of open-source projects that are portable, vendor-neutral, and interoperable through well defined interfaces.

On Fri, Feb 2, 2018 at 5:22 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...> wrote:
Another go:

The mission of the Cloud Native Computing Foundation is to drive the adoption of technologies designed for modern dynamic, distributed environments, such as public clouds and private data centers. Cloud-native applications, services, platforms, and infrastructure are engineered to provide and/or enable operability, observability, elasticity, resilience, and agility. The Foundation seeks to foster an ecosystem interoperable Cloud-Native technologies and to advance the state of the art by fostering open-source projects that embody and/or support these attributes:


  • Operability: Expose control of application/system lifecycle.

  • Observability: Provide meaningful signals for observing state, health, and performance.

  • Elasticity: Grow and shrink to fit in available resources and to meet fluctuating demand.

  • Resilience: Fast automatic recovery from failures.

  • Agility: Fast deployment, iteration, and reconfiguration.


Example technologies and patterns that can be used to implement the above attributes, such as declarative configuration, APIs, application containers, and service meshes, are discussed in more detail in Schedule A, below.




On Fri, Feb 2, 2018 at 9:10 AM, Justin Garrison <justinleegarrison@...> wrote:
Do you mind if we incorporate some/all of them?

​Not at all. Please do! I shared them​
 
​so they could be incorporated​

I prefer the engineered attributes:
  • Operable
  • Observable
  • Elastic
  • Resilient
  • Agile
Over the end goals:
  • Scalable
  • Durable
  • Continuous
I agree. Many things can claim to be "scalable" but every design decision has trade-offs. How you get to scalability is what matters most to differentiate cloud native from other approaches. Some of the words might be interpreted as an end goal instead of an attribute (e.g. agile) so it may be hard to make a clear distinction. Deciding on specific attributes will be the hard part.

Maybe we can find more specific and descriptive German words since it has a word for pretty much everything (j/k)


--
Justin Garrison
justingarrison.com

On Fri, Feb 2, 2018 at 8:26 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:
On Tue, Jan 30, 2018 at 11:13 PM, Yaron Haviv <yaronh@...> wrote:

I’m also more aligned with Justin’s definition, the way I usually describe Cloud-Native architecture in my posts is that it provides:

 

  • Durability — services must sustain component failures
  • Elasticity — services and resources grow or shrink to meet demand
  • Continuity — versions are upgraded while the service is running

 

I think declarative may be the way to achieve those, but can be added explicitly

Containers, unikernels, serverless, foo… are ways to implement this


As much as I'm a strong proponent of declarative configuration and APIs (and declarative APIs :-)), I agree that they are implementation techniques. I think we should provides examples of such techniques, but probably not in the mission statement.
 

 

Yaron

iguazio, CTO

 

From: <cncf-toc@...> on behalf of Bryan Cantrill <bryan@...>
Reply-To: "cncf-toc@..." <cncf-toc@...>
Date: Wednesday, 31 January 2018 at 8:30
To: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] updating what it means to be "Cloud Native"

 

 

Wow, I really like Justin's (and Kris's) definitions.  As I read Brian's proposed attributes, it occurred to me how much software we have that is indisputably cloud native and yet doesn't exhibit the attributes as described.  I think part of the problem is that it's too focused on artifact attributes and not on the principles behind those attributes.  Justin's definitions are more expansive in that regard and (from my perspective, anyway), a better fit for us...

 

        - Bryan

 

 

On Tue, Jan 30, 2018 at 9:42 PM, Justin Garrison <justinleegarrison@...> wrote:

This is just my opinion. Feedback is encouraged. I did a lot of thinking about definitions when writing Cloud Native Infrastructure with Kris Nova last year.

 

In the book I define cloud native infrastructure as

 

Cloud native infrastructure is infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose of running applications.

 

​The definitions for the CNCF are not just about running infrastructure and also impact how applications are designed and managed.

 

I defined cloud native applications as

 

A cloud native application is engineered to run on a platform and is designed for resiliency, agility, operability, and observability. Resiliency embraces failures instead of trying to prevent them; it takes advantage of the dynamic nature of running on a platform. Agility allows for fast deployments and quick iterations. Operability

​ ​

adds control of application life cycles from inside the application instead of relying on external processes and monitors. Observability provides information to answer questions about application state.

 

A possible elevator pitch could be something like.

 

Declarative, dynamic, resilient, and scalable.​

 

For me these expand to mean

 

Declarative APIs backed by infrastructure as software (not static code) that converge on a desired state. This applies to infrastructure, policy, application deployments, everything!

Dynamic because of the high rate of change and making frequent deployments (applications and infrastructure). This also can be used to describe service discovery as well as testing patterns and service mesh style routing.

Resilient to changes and discovery of environments. Microservices is one pattern for this but it also can include other options. Resiliency enables reliability which is the single most important factor of complex systems (or so I've read from numerous sources)

Scalable means applications need to be packaged in a way to scale horizontally instead of vertically. Ideally this would be containers but it can also be what I'd call "accidental containers" for things like lambda, app engine, or any PaaS where you don't explicitly package your code into an executable unit.


 

--
Justin Garrison
justingarrison.com

 

On Tue, Jan 30, 2018 at 4:49 PM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

Good point. I'll think about that (and am open to suggestions). "Automation" is a bit too terse, and not differentiated from the numerous automation systems of the past.

 

On Tue, Jan 30, 2018 at 4:45 PM, Bob Wise <bob@...> wrote:

Although the new definition is deeper and more inclusive, I think it is much less approachable especially to an less technical audience.

 

The "container packaged, dynamically managed, micro service oriented" was (and is) a great elevator pitch. It's simple, and has really helped give

those in organizations trying to sell upward on transformation paths great clear air cover. I think we would all agree that containers incorporate

many of the approaches indicated in the bits below. 

 

If we are going to replace those points (rather than enhance them) can we work on three simple bullets, or something that helps the entry?

 

-Bob

 

 

 

On Tue, Jan 30, 2018 at 9:30 AM, Brian Grant via Lists.Cncf.Io <briangrant=google.com@...ncf.io> wrote:

The CNCF Charter contains a definition of "Cloud Native" that was very Kubernetes-focused. This definition proved to be inadequate during a number of recent discussions, particularly those around "cloud-native storage" in the Storage WG. I would like to update the definition. My first attempt follows. 

 

Existing charter text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self healing multi-tenant nodes.

Cloud native systems will have the following properties:

(a) Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and simplify operations for cloud native applications.

(b) Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine efficiency and resource utilization while reducing the cost associated with maintenance and operations.

(c) Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

Proposed text:

 

The Foundation’s mission is to create and drive the adoption of a new computing paradigm, dubbed Cloud-Native computing, designed to facilitate a high velocity of change to applications, services, and infrastructure at scale in modern distributed-systems environments such as public clouds and private datacenters, while providing high degrees of security, reliability, and availability. To that end, the Foundation seeks to shape the evolution of the technology to advance the state of the art for application management and to foster an ecosystem of Cloud-Native technologies that are interoperable through well defined interfaces, and which are portable, vendor-neutral, and ubiquitous.

 

The following are some attributes of Cloud Native:

  • Cloud-native services should enable self-service. For instance, cloud-native resources should be self-provisioned from an elastic pool that for typical, on-demand usage appears to be of unlimited capacity.
  • Cloud-native environments are dynamic. They necessitate self-healing and adaptability of applications and services running in such environments.
  • Cloud-native applications, services, and infrastructure facilitate high-velocity management at scale via continuous automation, which is enabled by externalizing control, supporting dynamic configuration, and providing observability. In particular, resource usage is measured to enable optimal and efficient use.
  • Cloud-native services and infrastructure are decoupled from applications, with seamless and transparent consumption experiences.

 

Non-exhaustive, non-exclusive examples of mechanisms and approaches that promote Cloud-Native approaches include:

  • Immutable infrastructure: Replace individual components and resources rather than updating them in place, which rejuvenates the components/resources, mitigates configuration drift, and facilitates repeatability with predictability, which is essential for high-velocity operations at scale.
  • Application containers: Running applications and processes in containers as units of application deployment isolates them from their operational environments as well as from each other, facilitates higher levels of resource isolation, fosters component reuse, enables portability, increases observability, and standardizes lifecycle management.
  • Microservices: Loosely coupled microservices significantly increase the overall agility and maintainability of applications, particularly for larger organizations.
  • Service meshes: Service meshes decouple service access from the provider topology, which reduces the risk of operational changes, and support inter-component observability.
  • Declarative configuration: Intent-oriented configuration lets users focus on the What rather than the How, and reserves latitude for automated systems achieve the desired state.
  • Event-driven execution: Enables agile, reactive automated processes, and facilitates systems integration.

 

As new Cloud-Native techniques and technologies emerge, they will be incorporated into the Foundation’s portfolio of recommended practices, approaches, and projects.

 

 

 

 

 






Re: Incubating and Inception levels in marketing materials

Luis Pab?n
 

I think that is a great idea. +1

On Mon, Feb 5, 2018 at 3:24 PM, Camille Fournier <skamille@...> wrote:
The way that Apache separates out its "incubator" projects from full projects is that incubation projects are not listed in the main list of Apache projects, but rather on the incubator.apache.org subsite. It might be worth examining an approach like that to make clear the distinction.

C

On Mon, Feb 5, 2018 at 2:06 PM, alexis richardson <alexis@...> wrote:
Erin

Thank you. 

What is your question about community support?

Alexis


On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:
Alexis/Dan et all,
I appreciate the work it is to grow this foundation and ensure it lands in a healthy place, it's no small feat!

With the popularity of CNCF, it's 'endorsement' to projects is a huge success factor.

And while I know we are current revamping definitions to provide better understanding of the stages of a project, I think many in the community are concerned that outside of this, perception is reality. Honestly, if I am a potential customer and looking at a project, just having it listed (with a bunch of other projects at different levels) on the CNCF website probably instills a certain amount of confidence in the project.

The criteria between inception to graduation is well documented and understood by the TOC, but outside of that, I am not sure.
Many times it's been brought of that for instance, "community support is not sufficient for xyz project". We have agreed this is not a strict requirement of inception, however those active in the Open Source community see this as criteria zero.

Also, do we have a good way of tracking technical concerns brought forward from the DD to the next phase? Have we considered creating and publishing a concrete timeline around each of these phases and what the plan is if projects don't meet these guidelines? I feel that many people are trying to provide good due diligence while also balancing their day jobs, so things are also getting possibly missed because the dates aren't well defined. (I know I've mentioned this to Chris so sorry to feel like a broken record here).

Would love to hear other's thoughts around this.
Thanks,
Erin
 


On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...> wrote:
Jess

That's really one for Dan but AIUI the whole website is in the process
of being nurtured into an optimal state for 2018 ....  So all comments
good & timely, anywhere.

a



On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...> wrote:
> Quick question: what are the platinum members, the ones who paid the 300k?
>
> Do they need to be on the same slide / materials as the projects? Is
> that written into a contract or something? Also I'm more than happy to
> ask this on the call :)
>
> On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson <alexis@...> wrote:
>> thanks Dan & team
>>
>> @all TOC community, please do comment to Dan directly or on tomorrow's TOC call
>>
>>
>> On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...> wrote:
>>> We'll be discussing maturity levels on the TOC call. This is just a quick
>>> note that at the TOC's request, we revised CNCF marketing materials to
>>> clearly separate Incubating and Inception projects:
>>>
>>> https://www.cncf.io/
>>> https://www.cncf.io/projects/
>>> https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0
>>>
>>> We will obviously add a more prominent graduated section as soon as the
>>> first projects graduate. The same project separation will carry over to our
>>> marketing materials for KubeCon + CloudNativeCon.
>>> --
>>> Dan Kohn <dan@...>
>>> Executive Director, Cloud Native Computing Foundation https://www.cncf.io
>>> +1-415-233-1000 https://www.dankohn.com
>>>
>>
>>
>>
>
>
>
> --
>
>
> Jessie Frazelle
> 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
> pgp.mit.edu
>
>
>







Re: Incubating and Inception levels in marketing materials

Luis Pab?n
 

Hi Alexis,
 I think it is more about having a healthy open community with multiple consistent maintainers and contributors. Multiple backgrounds and agendas increase the amount of innovation in the project, but projects with a single company/maintainer might lack that drive.

- Luis

On Mon, Feb 5, 2018 at 4:20 PM, alexis richardson <alexis@...> wrote:
Erin

Please could you be specific?  Do you think Inception and/or
Incubation should require Maintainers from more companies?  I am not
promising changes, but *now* is the time to table and debate this.  If
people have concerns, please invite them to voice them here or have a
sponsor do so on their behalf.

alexis


On Mon, Feb 5, 2018 at 8:24 PM, Erin Boyd <eboyd@...> wrote:
> Hi Alexis,
> It's not a question, but just an observation of voiced 'concern' I see on
> many of the inception level requests, where the feedback is "where is the
> community support beyond company A", etc.
>
> So redefining our "what is means to be Cloud Native" and including Open
> Source as part of this primary driving directive, it seems counter-intuitive
> to accept projects, even at an inception level if they don't strong
> community support.
>
> Thoughts?
> Erin
>
>
>
> On Mon, Feb 5, 2018 at 12:06 PM, alexis richardson <alexis@...>
> wrote:
>>
>> Erin
>>
>> Thank you.
>>
>> What is your question about community support?
>>
>> Alexis
>>
>>
>> On Mon, 5 Feb 2018, 19:02 Erin Boyd, <eboyd@...> wrote:
>>>
>>> Alexis/Dan et all,
>>> I appreciate the work it is to grow this foundation and ensure it lands
>>> in a healthy place, it's no small feat!
>>>
>>> With the popularity of CNCF, it's 'endorsement' to projects is a huge
>>> success factor.
>>>
>>> And while I know we are current revamping definitions to provide better
>>> understanding of the stages of a project, I think many in the community are
>>> concerned that outside of this, perception is reality. Honestly, if I am a
>>> potential customer and looking at a project, just having it listed (with a
>>> bunch of other projects at different levels) on the CNCF website probably
>>> instills a certain amount of confidence in the project.
>>>
>>> The criteria between inception to graduation is well documented and
>>> understood by the TOC, but outside of that, I am not sure.
>>> Many times it's been brought of that for instance, "community support is
>>> not sufficient for xyz project". We have agreed this is not a strict
>>> requirement of inception, however those active in the Open Source community
>>> see this as criteria zero.
>>>
>>> Also, do we have a good way of tracking technical concerns brought
>>> forward from the DD to the next phase? Have we considered creating and
>>> publishing a concrete timeline around each of these phases and what the plan
>>> is if projects don't meet these guidelines? I feel that many people are
>>> trying to provide good due diligence while also balancing their day jobs, so
>>> things are also getting possibly missed because the dates aren't well
>>> defined. (I know I've mentioned this to Chris so sorry to feel like a broken
>>> record here).
>>>
>>> Would love to hear other's thoughts around this.
>>> Thanks,
>>> Erin
>>>
>>>
>>>
>>> On Mon, Feb 5, 2018 at 9:20 AM, alexis richardson <alexis@...>
>>> wrote:
>>>>
>>>> Jess
>>>>
>>>> That's really one for Dan but AIUI the whole website is in the process
>>>> of being nurtured into an optimal state for 2018 ....  So all comments
>>>> good & timely, anywhere.
>>>>
>>>> a
>>>>
>>>>
>>>>
>>>> On Mon, Feb 5, 2018 at 4:16 PM, Jessica Frazelle <me@...>
>>>> wrote:
>>>> > Quick question: what are the platinum members, the ones who paid the
>>>> > 300k?
>>>> >
>>>> > Do they need to be on the same slide / materials as the projects? Is
>>>> > that written into a contract or something? Also I'm more than happy to
>>>> > ask this on the call :)
>>>> >
>>>> > On Mon, Feb 5, 2018 at 11:14 AM, alexis richardson
>>>> > <alexis@...> wrote:
>>>> >> thanks Dan & team
>>>> >>
>>>> >> @all TOC community, please do comment to Dan directly or on
>>>> >> tomorrow's TOC call
>>>> >>
>>>> >>
>>>> >> On Mon, Feb 5, 2018 at 4:08 PM, Dan Kohn <dan@...>
>>>> >> wrote:
>>>> >>> We'll be discussing maturity levels on the TOC call. This is just a
>>>> >>> quick
>>>> >>> note that at the TOC's request, we revised CNCF marketing materials
>>>> >>> to
>>>> >>> clearly separate Incubating and Inception projects:
>>>> >>>
>>>> >>> https://www.cncf.io/
>>>> >>> https://www.cncf.io/projects/
>>>> >>>
>>>> >>> https://docs.google.com/presentation/d/1BoxFeENJcINgHbKfygXpXROchiRO2LBT-pzdaOFr4Zg/edit#slide=id.g2c13d20ecb_1_0
>>>> >>>
>>>> >>> We will obviously add a more prominent graduated section as soon as
>>>> >>> the
>>>> >>> first projects graduate. The same project separation will carry over
>>>> >>> to our
>>>> >>> marketing materials for KubeCon + CloudNativeCon.
>>>> >>> --
>>>> >>> Dan Kohn <dan@...>
>>>> >>> Executive Director, Cloud Native Computing Foundation
>>>> >>> https://www.cncf.io
>>>> >>> +1-415-233-1000 https://www.dankohn.com
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> >
>>>> > Jessie Frazelle
>>>> > 4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
>>>> > pgp.mit.edu
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>
>
>





Re: [VOTE] SPIFFE project proposal (inception)

Vipin Chamakkala <vipin@...>
 

+1 (non binding)

--
w o r k — b e n c h

Vipin Chamakkala
Principal


110 Fifth Avenue, Fifth Floor
New York, New York 10011
work-bench.com

5661 - 5680 of 7339