Date   

RFC: containerd and rkt project proposals for CNCF

Chris Aniszczyk
 

Hey CNCF TOC and wider community, we have two project proposals in queue:


Please look them over on GitHub and raise any issues / concerns.

We plan to call for an official vote by the end of this week or so for both projects.

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


Re: Followup: Today's CNCF TOC Call + Project Next Steps

Ihor Dvoretskyi
 

It's important for CNCF to own and foster the foundational technology for cloud-native computing. Having both containerd and rkt in CNCF would be a great outcome for the CNCF, for Kubernetes, and for the container and cloud ecosystems.

I second this. Having the container runtimes engines (containerd, rkt) together with the container cluster managing systems (Kubernetes) under a single foundation umbrella will bring the huge benefits for providing the solid end-user solutions.

On Fri, Mar 17, 2017 at 5:45 AM, Brian Grant via cncf-toc <cncf-toc@...> wrote:
On Wed, Mar 15, 2017 at 9:05 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
We had a full TOC meeting today with three community presentations!!!:


The next steps would be for a TOC member to sponsor and invite the project for a formal proposal. If you're interested in doing this, please let us know by replying here.

I'd like to sponsor both containerd and rkt. It's important for CNCF to own and foster the foundational technology for cloud-native computing. Having both containerd and rkt in CNCF would be a great outcome for the CNCF, for Kubernetes, and for the container and cloud ecosystems. Kubernetes and other container orchestrators need reliable, community-driven container runtimes scoped to container execution. Each runtime has its own strengths and use cases, and I hope that induction into CNCF unlocks opportunities for broader collaboration. 

As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google trends:

Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam) is towards unified batch and streaming.

More broadly, though, I would like to see CNCF become a good home for container/orchestrator-friendly data-processing platforms, as that critical category of workloads benefits from closer integration with the underlying orchestration platform.

--Brian


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



Re: https://pivotal.io/kubo

alexis richardson
 



On Fri, Mar 17, 2017 at 3:52 PM, Anthony Skipper <anthony@...> wrote:
>>What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools to Kubernetes will become easier and more mainstream over time

The only viable PaaS models going forward will be PaaS on top of CaaS.   With CaaS you can implement nearly any type of system, with PaaS that isn't neccessarily true.   The example of this is things like low latency trading systems, which you can't really implement on any existing PaaS solution, but can be made to work on a CaaS system.   So the writing is on the wall that anyone doing PaaS probably needs to replatform it ontop of CaaS.  

The funny question is what is the acronym for PaaS on CaaS?  (POC?)

CF runs on a CaaS called Diego, it's just not very well known or used with non-CF systems.  Kubernetes arguably supports more use cases already eg Openshift PaaS, and then others.

I do think that, over time, the industry will prefer a decreasing number of 'standard layers' for the cloud native stack.  It's not obvious how many can thrive at each layer, but I'd hope for more than one myself.  And all this will take time.  


 

On Fri, Mar 17, 2017 at 11:39 AM, Quinton Hoole via cncf-toc <cncf-toc@...> wrote:

Regarding Kubo, it’s not immediately obvious to me how useful it is in the long term (although I must stress that I’m definitely not a Cloud Foundry expert). 

Reading the Kubo docs it seems that it is, in essence, two pieces:

1.            A TCP routing system (load balancer) to get client traffic to Kubernetes-hosted services.

2.            A VM monitoring and management system (BOSH) to keep the VM’s (that Kubernetes is running on top of) deployed, healthy and scaled correctly.

In practice #1 is typically provided by a combination of the IaaS load balancers (e.g. AWS ELB, GCE LB, OpenStack LBaaS and associated plugins, etc), and Kubernetes integration with those.

#2 is usually provided by a combination of native IaaS VM auto-scaling (e.g. AWS Auto-scaling Groups, GCE Managed Instance Groups, OpenStack Autoscaling etc), and again, Kubernetes integration with those.

Hence my above question around Kubo’s long-term usefulness.

 

What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools to Kubernetes will become easier and more mainstream over time (through, for example, Cloud Foundry to Kubernetes API adaptors).

Q

 

 

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-bounces@...o> on behalf of "Afra, Ziad via cncf-toc" <cncf-toc@...>
Reply-To: "Afra, Ziad" <ziad.afra@...>
Date: Friday, March 17, 2017 at 08:20
To: Alexis Richardson <alexis@...>
Cc: "cncf-toc@..." <cncf-toc@...>


Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

 

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

 

-----Original Message-----

From: Alexis Richardson [mailto:alexis@...]

Sent: Friday, March 17, 2017 11:15 AM

To: Afra, Ziad (MLES)

Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

The lowest friction adoption path for CNCF technologies in the CF

community is via add-ons, accessed via the CF service broker

mechanism.  Kubo is a step in that direction because existing CF users

may wish to deploy Kubernetes using the same infra automation as they

use for CF, ie. BOSH.  This move is therefore a win win.  We'll see if

it gets much traction in the next few months - I hope it does.

 

 

 

 

On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad  via cncf-toc

<cncf-toc@...> wrote:

Hi All, seen this? what is everyone’s view?

 

 

 

Thanks

 

Ziad

 

 

 

 

==============================================================================

Please access the attached hyperlink for an important electronic

communications disclaimer:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


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




Re: https://pivotal.io/kubo

Anthony Skipper <anthony@...>
 

>>What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools to Kubernetes will become easier and more mainstream over time

The only viable PaaS models going forward will be PaaS on top of CaaS.   With CaaS you can implement nearly any type of system, with PaaS that isn't neccessarily true.   The example of this is things like low latency trading systems, which you can't really implement on any existing PaaS solution, but can be made to work on a CaaS system.   So the writing is on the wall that anyone doing PaaS probably needs to replatform it ontop of CaaS.  

The funny question is what is the acronym for PaaS on CaaS?  (POC?)

On Fri, Mar 17, 2017 at 11:39 AM, Quinton Hoole via cncf-toc <cncf-toc@...> wrote:

Regarding Kubo, it’s not immediately obvious to me how useful it is in the long term (although I must stress that I’m definitely not a Cloud Foundry expert). 

Reading the Kubo docs it seems that it is, in essence, two pieces:

1.            A TCP routing system (load balancer) to get client traffic to Kubernetes-hosted services.

2.            A VM monitoring and management system (BOSH) to keep the VM’s (that Kubernetes is running on top of) deployed, healthy and scaled correctly.

In practice #1 is typically provided by a combination of the IaaS load balancers (e.g. AWS ELB, GCE LB, OpenStack LBaaS and associated plugins, etc), and Kubernetes integration with those.

#2 is usually provided by a combination of native IaaS VM auto-scaling (e.g. AWS Auto-scaling Groups, GCE Managed Instance Groups, OpenStack Autoscaling etc), and again, Kubernetes integration with those.

Hence my above question around Kubo’s long-term usefulness.

 

What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools to Kubernetes will become easier and more mainstream over time (through, for example, Cloud Foundry to Kubernetes API adaptors).

Q

 

 

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-bounces@....io> on behalf of "Afra, Ziad via cncf-toc" <cncf-toc@...>
Reply-To: "Afra, Ziad" <ziad.afra@...>
Date: Friday, March 17, 2017 at 08:20
To: Alexis Richardson <alexis@...>
Cc: "cncf-toc@..." <cncf-toc@...>


Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

 

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

 

-----Original Message-----

From: Alexis Richardson [mailto:alexis@...]

Sent: Friday, March 17, 2017 11:15 AM

To: Afra, Ziad (MLES)

Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

The lowest friction adoption path for CNCF technologies in the CF

community is via add-ons, accessed via the CF service broker

mechanism.  Kubo is a step in that direction because existing CF users

may wish to deploy Kubernetes using the same infra automation as they

use for CF, ie. BOSH.  This move is therefore a win win.  We'll see if

it gets much traction in the next few months - I hope it does.

 

 

 

 

On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad  via cncf-toc

<cncf-toc@...> wrote:

Hi All, seen this? what is everyone’s view?

 

 

 

Thanks

 

Ziad

 

 

 

 

==============================================================================

Please access the attached hyperlink for an important electronic

communications disclaimer:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


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



Re: https://pivotal.io/kubo

Solomon Hykes
 

Ziad, since you mentioned Docmer here is my take on your question. The type of convergence we're seeing is Kube+containerd and cloudfoundry+containerd. With the donation of containerd to CNCF underway, Docker is positioned as a direct competitor to Openshift in the enterprise container management space.

For anyone interested in comparing infrastructure management tools for Kubernetes provisioning and upgrading, I recommend checking out Infrakit. I'm hearing lots of Kubernetes operators mention it as something they're playing with.


Here is an example how we use it to scale Docker in swarm mode: https://blog.docker.com/2017/03/infrakit-docker-swarm-mode-fault-tolerant-self-healing-cluster/

If anyone is interested in discussing the same use case for Infrakit+Kubernetes, let me know we would be happy to do more in that area.


On Friday, March 17, 2017, Afra, Ziad via cncf-toc <cncf-toc@...> wrote:
Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

-----Original Message-----
From: Alexis Richardson [mailto:alexis@...]
Sent: Friday, March 17, 2017 11:15 AM
To: Afra, Ziad (MLES)
Cc: cncf-toc@...
Subject: Re: [cncf-toc] https://pivotal.io/kubo

The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism.  Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH.  This move is therefore a win win.  We'll see if
it gets much traction in the next few months - I hope it does.




On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad  via cncf-toc
<cncf-toc@...> wrote:
> Hi All, seen this? what is everyone’s view?
>
>
>
> Thanks
>
> Ziad
>
>
>
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>



===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: https://pivotal.io/kubo

Quinton Hoole
 

Regarding Kubo, it’s not immediately obvious to me how useful it is in the long term (although I must stress that I’m definitely not a Cloud Foundry expert). 

Reading the Kubo docs it seems that it is, in essence, two pieces:

1.            A TCP routing system (load balancer) to get client traffic to Kubernetes-hosted services.

2.            A VM monitoring and management system (BOSH) to keep the VM’s (that Kubernetes is running on top of) deployed, healthy and scaled correctly.

In practice #1 is typically provided by a combination of the IaaS load balancers (e.g. AWS ELB, GCE LB, OpenStack LBaaS and associated plugins, etc), and Kubernetes integration with those.

#2 is usually provided by a combination of native IaaS VM auto-scaling (e.g. AWS Auto-scaling Groups, GCE Managed Instance Groups, OpenStack Autoscaling etc), and again, Kubernetes integration with those.

Hence my above question around Kubo’s long-term usefulness.

 

What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools to Kubernetes will become easier and more mainstream over time (through, for example, Cloud Foundry to Kubernetes API adaptors).

Q

 

 

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-bounces@...> on behalf of "Afra, Ziad via cncf-toc" <cncf-toc@...>
Reply-To: "Afra, Ziad" <ziad.afra@...>
Date: Friday, March 17, 2017 at 08:20
To: Alexis Richardson <alexis@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

 

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

 

-----Original Message-----

From: Alexis Richardson [mailto:alexis@...]

Sent: Friday, March 17, 2017 11:15 AM

To: Afra, Ziad (MLES)

Subject: Re: [cncf-toc] https://pivotal.io/kubo

 

The lowest friction adoption path for CNCF technologies in the CF

community is via add-ons, accessed via the CF service broker

mechanism.  Kubo is a step in that direction because existing CF users

may wish to deploy Kubernetes using the same infra automation as they

use for CF, ie. BOSH.  This move is therefore a win win.  We'll see if

it gets much traction in the next few months - I hope it does.

 

 

 

 

On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad  via cncf-toc

<cncf-toc@...> wrote:

Hi All, seen this? what is everyone’s view?

 

 

 

Thanks

 

Ziad

 

 

 

 

==============================================================================

Please access the attached hyperlink for an important electronic

communications disclaimer:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


Re: https://pivotal.io/kubo

alexis richardson
 

which one of those is brownfield?  ;-)


On Fri, Mar 17, 2017 at 3:20 PM Afra, Ziad <ziad.afra@...> wrote:
Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

-----Original Message-----
From: Alexis Richardson [mailto:alexis@...]
Sent: Friday, March 17, 2017 11:15 AM
To: Afra, Ziad (MLES)
Cc: cncf-toc@...
Subject: Re: [cncf-toc] https://pivotal.io/kubo

The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism.  Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH.  This move is therefore a win win.  We'll see if
it gets much traction in the next few months - I hope it does.




On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad  via cncf-toc
<cncf-toc@...> wrote:
> Hi All, seen this? what is everyone’s view?
>
>
>
> Thanks
>
> Ziad
>
>
>
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>



===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================


Re: https://pivotal.io/kubo

Afra, Ziad <ziad.afra@...>
 

Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.

What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.

-----Original Message-----
From: Alexis Richardson [mailto:alexis@weave.works]
Sent: Friday, March 17, 2017 11:15 AM
To: Afra, Ziad (MLES)
Cc: cncf-toc@lists.cncf.io
Subject: Re: [cncf-toc] https://pivotal.io/kubo

The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.




On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Hi All, seen this? what is everyone’s view?



Thanks

Ziad




==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================


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


===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================


Re: https://pivotal.io/kubo

alexis richardson
 

The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.




On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Hi All, seen this? what is everyone’s view?



Thanks

Ziad




==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================


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


https://pivotal.io/kubo

Afra, Ziad <ziad.afra@...>
 

Hi All, seen this? what is everyone’s view?

 

Thanks

Ziad




==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================


Re: Heron

Chris Aniszczyk
 

+Karthik to make sure he sees these emails as a chance to give feedback.

If I recall from the call that was a question that BrianG may have asked. Karthik mentioned some things of why CNCF (vs other places) but I'll defer to him to answer any questions as he's the project representative.

On Fri, Mar 17, 2017 at 10:00 AM, Jonathan Boulle via cncf-toc <cncf-toc@...> wrote:

I would echo Brian's sentiments - I also have some concerns about Heron's cloud-native suitability and path to integration with any of the existing or proposed CNCF projects; I think it's still hard for me to understand why we're a more suitable choice than Apache.

Alexis Richardson via cncf-toc <cncf-toc@...> schrieb am Fr., 17. März 2017, 11:56:
Moving Heron to new thread.

All - comments on Heron?  I think Brian raises some good questions
about alignment with our mission (below).




On Fri, Mar 17, 2017 at 3:56 AM, Quinton Hoole via cncf-toc
<cncf-toc@...> wrote:
..
> I don’t know enough about Heron and the related ecosystem to have an on that
> opinion yet.
>
> Q
>
> From:  Brian Grant via cncf-toc
....
> As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google
> trends:
>
> https://trends.google.com/trends/explore?q=%2Fm%2F0ndhxqz,Apache%20Storm,%2Fm%2F0fdjtq
>
>
>
> Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam)
> is towards unified batch and streaming.
>
>
>
> More broadly, though, I would like to see CNCF become a good home for
> container/orchestrator-friendly data-processing platforms, as that critical
> category of workloads benefits from closer integration with the underlying
> orchestration platform.
>
>
>
> --Brian
>
>
>
>
> _______________________________________________
> 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




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


Re: Heron

Jonathan Boulle <jonathan.boulle@...>
 

I would echo Brian's sentiments - I also have some concerns about Heron's cloud-native suitability and path to integration with any of the existing or proposed CNCF projects; I think it's still hard for me to understand why we're a more suitable choice than Apache.

Alexis Richardson via cncf-toc <cncf-toc@...> schrieb am Fr., 17. März 2017, 11:56:

Moving Heron to new thread.

All - comments on Heron?  I think Brian raises some good questions
about alignment with our mission (below).




On Fri, Mar 17, 2017 at 3:56 AM, Quinton Hoole via cncf-toc
<cncf-toc@...> wrote:
..
> I don’t know enough about Heron and the related ecosystem to have an on that
> opinion yet.
>
> Q
>
> From:  Brian Grant via cncf-toc
....
> As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google
> trends:
>
> https://trends.google.com/trends/explore?q=%2Fm%2F0ndhxqz,Apache%20Storm,%2Fm%2F0fdjtq
>
>
>
> Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam)
> is towards unified batch and streaming.
>
>
>
> More broadly, though, I would like to see CNCF become a good home for
> container/orchestrator-friendly data-processing platforms, as that critical
> category of workloads benefits from closer integration with the underlying
> orchestration platform.
>
>
>
> --Brian
>
>
>
>
> _______________________________________________
> 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


Heron

alexis richardson
 

Moving Heron to new thread.

All - comments on Heron? I think Brian raises some good questions
about alignment with our mission (below).

On Fri, Mar 17, 2017 at 3:56 AM, Quinton Hoole via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
..
I don’t know enough about Heron and the related ecosystem to have an on that
opinion yet.

Q

From: Brian Grant via cncf-toc
....
As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google
trends:

https://trends.google.com/trends/explore?q=%2Fm%2F0ndhxqz,Apache%20Storm,%2Fm%2F0fdjtq



Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam)
is towards unified batch and streaming.



More broadly, though, I would like to see CNCF become a good home for
container/orchestrator-friendly data-processing platforms, as that critical
category of workloads benefits from closer integration with the underlying
orchestration platform.



--Brian




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


Re: Followup: Today's CNCF TOC Call + Project Next Steps

alexis richardson
 

Brian

Your offer is most welcome.

Let's follow up with the project leads to request a document with their full proposal, and explore timing.

Alexis


On Fri, 17 Mar 2017, 03:57 Quinton Hoole via cncf-toc, <cncf-toc@...> wrote:

+1 for containerd and rkt.

I don’t know enough about Heron and the related ecosystem to have an on that opinion yet.

 

Q

From: <cncf-toc-bounces@...> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Thursday, March 16, 2017 at 20:45
To: Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Followup: Today's CNCF TOC Call + Project Next Steps

 

On Wed, Mar 15, 2017 at 9:05 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:

We had a full TOC meeting today with three community presentations!!!:

 

 

The next steps would be for a TOC member to sponsor and invite the project for a formal proposal. If you're interested in doing this, please let us know by replying here.

 

I'd like to sponsor both containerd and rkt. It's important for CNCF to own and foster the foundational technology for cloud-native computing. Having both containerd and rkt in CNCF would be a great outcome for the CNCF, for Kubernetes, and for the container and cloud ecosystems. Kubernetes and other container orchestrators need reliable, community-driven container runtimes scoped to container execution. Each runtime has its own strengths and use cases, and I hope that induction into CNCF unlocks opportunities for broader collaboration. 

 

As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google trends:

 

Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam) is towards unified batch and streaming.

 

More broadly, though, I would like to see CNCF become a good home for container/orchestrator-friendly data-processing platforms, as that critical category of workloads benefits from closer integration with the underlying orchestration platform.

 

--Brian

 

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


Re: Followup: Today's CNCF TOC Call + Project Next Steps

Quinton Hoole
 

+1 for containerd and rkt.

I don’t know enough about Heron and the related ecosystem to have an on that opinion yet.

 

Q

From: <cncf-toc-bounces@...> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Thursday, March 16, 2017 at 20:45
To: Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Followup: Today's CNCF TOC Call + Project Next Steps

 

On Wed, Mar 15, 2017 at 9:05 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:

We had a full TOC meeting today with three community presentations!!!:

 

 

The next steps would be for a TOC member to sponsor and invite the project for a formal proposal. If you're interested in doing this, please let us know by replying here.

 

I'd like to sponsor both containerd and rkt. It's important for CNCF to own and foster the foundational technology for cloud-native computing. Having both containerd and rkt in CNCF would be a great outcome for the CNCF, for Kubernetes, and for the container and cloud ecosystems. Kubernetes and other container orchestrators need reliable, community-driven container runtimes scoped to container execution. Each runtime has its own strengths and use cases, and I hope that induction into CNCF unlocks opportunities for broader collaboration. 

 

As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google trends:

 

Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam) is towards unified batch and streaming.

 

More broadly, though, I would like to see CNCF become a good home for container/orchestrator-friendly data-processing platforms, as that critical category of workloads benefits from closer integration with the underlying orchestration platform.

 

--Brian

 


Re: Followup: Today's CNCF TOC Call + Project Next Steps

Brian Grant
 

On Wed, Mar 15, 2017 at 9:05 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
We had a full TOC meeting today with three community presentations!!!:


The next steps would be for a TOC member to sponsor and invite the project for a formal proposal. If you're interested in doing this, please let us know by replying here.

I'd like to sponsor both containerd and rkt. It's important for CNCF to own and foster the foundational technology for cloud-native computing. Having both containerd and rkt in CNCF would be a great outcome for the CNCF, for Kubernetes, and for the container and cloud ecosystems. Kubernetes and other container orchestrators need reliable, community-driven container runtimes scoped to container execution. Each runtime has its own strengths and use cases, and I hope that induction into CNCF unlocks opportunities for broader collaboration. 

As for Heron, I'm not seeing the demand for Storm/Heron. For example, Google trends:

Spark still has a lot of steam, and AIUI the trend (e.g., using Apache Beam) is towards unified batch and streaming.

More broadly, though, I would like to see CNCF become a good home for container/orchestrator-friendly data-processing platforms, as that critical category of workloads benefits from closer integration with the underlying orchestration platform.

--Brian


Followup: Today's CNCF TOC Call + Project Next Steps

Chris Aniszczyk
 

We had a full TOC meeting today with three community presentations!!!:


The next steps would be for a TOC member to sponsor and invite the project for a formal proposal. If you're interested in doing this, please let us know by replying here.

Thanks!

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


today's TOC slides in PPT format

alexis richardson
 

for ziad and others behind *walls


sign up here if you will be in berlin

alexis richardson
 


Re: Call for agenda

alexis richardson
 

done! (thanks Chris A)

On Wed, Mar 15, 2017 at 2:06 PM, Quinton Hoole <quinton.hoole@huawei.com> wrote:
Hi Alexis



Please add (to the CI section of slide 8):



· Proposal - A CI Workflow Platform for the CNCF
https://goo.gl/50UoRt



(as per the email that you kindly forwarded yesterday)



Thanks



Q



From: <cncf-toc-bounces@lists.cncf.io> on behalf of Alexis Richardson via
cncf-toc <cncf-toc@lists.cncf.io>
Reply-To: Alexis Richardson <alexis@weave.works>
Date: Monday, March 13, 2017 at 06:45
To: Alexis Richardson via cncf-toc <cncf-toc@lists.cncf.io>
Subject: [cncf-toc] Call for agenda



All,



Please send any agenda requests for this week's TOC.



a

_______________________________________________

cncf-toc mailing list

cncf-toc@lists.cncf.io

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

6261 - 6280 of 6984