On 6 Nov 2019, at 21:22, Alexis Richardson <alexis@...> wrote:



Previously we have had a period of general review, and then set a future date for a vote to ensure people make an effort to get comments in.  A bit like preparing for an exam I guess.

Keep an eye on this list and your GH issue, as community comments may appear. 

On Wed, 6 Nov 2019, 21:15 Kris Nova, <kris.nova@...> wrote:

Hey all,

Also a quick point of clarification - are we on standby until further notice with a formal vote? Unsure what we mean when we say “set a timeline”?



—
Kris Nova
Chief Open Source Advocate


> On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:
>
> Hey all,
>
> Strong +1 with Joe/Alexis
>
> Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.
>
> Thanks for your time and consideration here.
>
> —
> Kris Nova
> Chief Open Source Advocate
>
>
>> On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:
>>
>> Echoing Joe's call and amplifying to the TOC Contributors.  With
>> Kubecon around the corner, I am sure almost everyone is jammed.
>>
>>> On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
>>> <jbeda=vmware.com@...> wrote:
>>>
>>> Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>> From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
>>> Date: Wednesday, November 6, 2019 at 4:10 AM
>>> To: CNCF TOC <cncf-toc@...>
>>> Subject: [cncf-toc] Falco DD & Request for Incubation Vote
>>>
>>>
>>>
>>> TOC members;
>>>
>>>
>>>
>>> Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.
>>>
>>>
>>>
>>> As a reminder, our goals in moving to incubation include:
>>>
>>>
>>>
>>> * Moving Falco's build and release infrastructure to CNCF provided infrastructure.
>>>
>>> * Capturing and building on the current momentum of the project.
>>>
>>> * Publishing of end user case studies.
>>>
>>> * Further helping customers achieve compliance in Kubernetes/Cloud Native environments.
>>>
>>>
>>>
>>> Falco Due Diligence:
>>>
>>> https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq
>>>
>>>
>>>
>>> Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:
>>>
>>> https://sysdig.com/blog/understanding-common-library-implementation/
>>>
>>>
>>>
>>> Falco PR for Incubation:
>>>
>>> https://github.com/cncf/toc/pull/307
>>>
>>>
>>>
>>> Current Falco Release:
>>>
>>> https://github.com/falcosecurity/falco/releases/tag/0.18.0
>>>
>>>
>>>
>>>
>>>
>>> We look forward to feedback from the TOC and broader community.
>>>
>>>
>>>
>>> The Falco Team
>>>
>>>
>>
>>
>>

On 6 Nov 2019, at 16:09, Kris Nova <kris.nova@...> wrote:

Hey all,

Strong +1 with Joe/Alexis

Most of the Falco community will be at KubeCon as well if it would be helpful to meet in person to go over anything.

Thanks for your time and consideration here.

—
Kris Nova
Chief Open Source Advocate

On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:

Echoing Joe's call and amplifying to the TOC Contributors. With
Kubecon around the corner, I am sure almost everyone is jammed.

On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@...> wrote:

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.



Joe



From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote



TOC members;



Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.



As a reminder, our goals in moving to incubation include:



* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.



Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq



Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/



Falco PR for Incubation:

https://github.com/cncf/toc/pull/307



Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0





We look forward to feedback from the TOC and broader community.



The Falco Team

On 6 Nov 2019, at 14:23, alexis richardson <alexis@...> wrote:

Echoing Joe's call and amplifying to the TOC Contributors. With
Kubecon around the corner, I am sure almost everyone is jammed.

On Wed, Nov 6, 2019 at 2:17 PM Joe Beda via Lists.Cncf.Io
<jbeda=vmware.com@...> wrote:

Hello TOC folks – I’d love to help collect concerns/impressions/questions as we try and set a timeline to get a vote going.



Joe



From: <cncf-toc@...> on behalf of Michael Ducy <michael.ducy@...>
Date: Wednesday, November 6, 2019 at 4:10 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Falco DD & Request for Incubation Vote



TOC members;



Joe Beda, assisted by Kris Nova and myself, has completed the technical due diligence for Falco, and we would like to request that a formal vote be held for moving Falco to incubation.



As a reminder, our goals in moving to incubation include:



* Moving Falco's build and release infrastructure to CNCF provided infrastructure.

* Capturing and building on the current momentum of the project.

* Publishing of end user case studies.

* Further helping customers achieve compliance in Kubernetes/Cloud Native environments.



Falco Due Diligence:

https://docs.google.com/document/d/1TJCzW8dQ6858lw2UNY-H5LMnvEd4GzwjuOcDInimeyA/edit?ts=5dacfd96#heading=h.378jkvcve1nq



Technical Explanation of Falco's Architecture and relationship to the Kernel/eBPF capture interface:

https://sysdig.com/blog/understanding-common-library-implementation/



Falco PR for Incubation:

https://github.com/cncf/toc/pull/307



Current Falco Release:

https://github.com/falcosecurity/falco/releases/tag/0.18.0





We look forward to feedback from the TOC and broader community.



The Falco Team

• How does this relate to the proposed Runtime SIG? (https://docs.google.com/document/d/1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA/edit)
• How do we look at the differences between WGs and SIGs?
  • At a procedural level SIGs are rooted with the TOC and seen as an extension. WGs don’t have a formal relationship to the TOC.

Yes, although it probably makes most sense to house it under sig-apps if most of their attention is on the app dev part, rather than runtime infra. One of the sigs needs to carry the can for the wg. The WG should interact with sig-runtime regarding the runtime infra aspects.

Get Outlook for Android
________________________________
From: Alexis Richardson <alexis@...>
Sent: Saturday, November 2, 2019 8:21:00 AM
To: Quinton Hoole <qhoole@...>
Cc: Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>; Doug Davis <dug@...>; cncf-toc@... <cncf-toc@...>; jbeda@... <jbeda@...>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

so:

TOC
SIG-Apps & SIG-Runtime
WG-Serverless is a 'shared' WG between the 2 SIGs

?





On Sat, Nov 2, 2019 at 3:19 PM Quinton Hoole <qhoole@...> wrote:

I agee Liz

I think serverless app development falls under sig-apps, and serveless runtimes fall under sig-runtime.
It's pretty common for work groups to span across a few SIGs.

Q

________________________________
From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>
Sent: Saturday, November 2, 2019 4:53 AM
To: Doug Davis <dug@...>; cncf-toc@... <cncf-toc@...>; jbeda@... <jbeda@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

Thanks for the reminder on this Joe.

The Serverless WG has already been performing that role of defining the landscape in their space, identifying gaps, writing white papers... The bit we’re missing is the liaison that we have between TOC and SIGs, which I for one think is valuable.

After seeing that “Topic 4” diagram I am open to the idea of broadening to SIG App Platform. I foresee some confusion between that and SIG App Delivery with those names, though. Naming is hard.

I would love to hear thoughts from more folks on the relationship between Serverless and the new Runtime SIG - we could certainly discuss on the next TOC call. Personally I don’t think SIG Runtime is a natural home for CloudEvents, function frameworks and so on, so I think there is a real gap.

But there is some overlap already: Virtual Kubelet falls into Runtime’s charter, but also appears on the Serverless landscape. Runtime feels like the more natural home; is Serverless really the right place for VK on the landscape?


Liz
On 31 Oct 2019, 15:11 +0000, Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...>, wrote:

Hey fellow TOC members – poke on this? Thoughts?



A couple of questions in my mind:

How does this relate to the proposed Runtime SIG? (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA%2Fedit&;data=02%7C01%7Cqhoole%40futurewei.com%7C0d053b29616f4f7d5c3d08d75fa84c2b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637083048767538606&amp;sdata=8gj%2Fd42ZZdqiWwnmi6VvlnFmDkdXaidrnp6lE%2FU7ffg%3D&amp;reserved=0)
How do we look at the differences between WGs and SIGs?

At a procedural level SIGs are rooted with the TOC and seen as an extension. WGs don’t have a formal relationship to the TOC.



Joe



From: <cncf-toc@...> on behalf of Doug Davis <dug@...>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG



TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo%2Fedit%23bookmark%3Did.qv45kp7nb29b&;data=02%7C01%7Cqhoole%40futurewei.com%7C0d053b29616f4f7d5c3d08d75fa84c2b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637083048767538606&amp;sdata=wzylCjWw9C0D6UYG3SjCmzO%2FjigzKczvshM%2Bj8spzls%3D&amp;reserved=0

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.


thanks
-Doug Davis/Mark Peek/Ken Owens

I agee Liz

I think serverless app development falls under sig-apps, and serveless runtimes fall under sig-runtime.
It's pretty common for work groups to span across a few SIGs.

Q

________________________________
From: cncf-toc@... <cncf-toc@...> on behalf of Liz Rice via Lists.Cncf.Io <liz=lizrice.com@...>
Sent: Saturday, November 2, 2019 4:53 AM
To: Doug Davis <dug@...>; cncf-toc@... <cncf-toc@...>; jbeda@... <jbeda@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] Serverless WG and the AppDelivery SIG

Thanks for the reminder on this Joe.

The Serverless WG has already been performing that role of defining the landscape in their space, identifying gaps, writing white papers... The bit we’re missing is the liaison that we have between TOC and SIGs, which I for one think is valuable.

After seeing that “Topic 4” diagram I am open to the idea of broadening to SIG App Platform. I foresee some confusion between that and SIG App Delivery with those names, though. Naming is hard.

I would love to hear thoughts from more folks on the relationship between Serverless and the new Runtime SIG - we could certainly discuss on the next TOC call. Personally I don’t think SIG Runtime is a natural home for CloudEvents, function frameworks and so on, so I think there is a real gap.

But there is some overlap already: Virtual Kubelet falls into Runtime’s charter, but also appears on the Serverless landscape. Runtime feels like the more natural home; is Serverless really the right place for VK on the landscape?


Liz
On 31 Oct 2019, 15:11 +0000, Joe Beda via Lists.Cncf.Io <jbeda=vmware.com@...>, wrote:

Hey fellow TOC members – poke on this? Thoughts?



A couple of questions in my mind:

How does this relate to the proposed Runtime SIG? (https://docs.google.com/document/d/1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA/edit)
How do we look at the differences between WGs and SIGs?

At a procedural level SIGs are rooted with the TOC and seen as an extension. WGs don’t have a formal relationship to the TOC.



Joe



From: <cncf-toc@...> on behalf of Doug Davis <dug@...>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG



TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://docs.google.com/document/d/1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo/edit#bookmark=id.qv45kp7nb29b

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.


thanks
-Doug Davis/Mark Peek/Ken Owens

Hey fellow TOC members – poke on this?  Thoughts?

 

A couple of questions in my mind:

• How does this relate to the proposed Runtime SIG? (https://docs.google.com/document/d/1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA/edit)
• How do we look at the differences between WGs and SIGs? 
• At a procedural level SIGs are rooted with the TOC and seen as an extension.  WGs don’t have a formal relationship to the TOC.

 

Joe

 

From: <cncf-toc@...> on behalf of Doug Davis <dug@...>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG

 

TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://docs.google.com/document/d/1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo/edit#bookmark=id.qv45kp7nb29b

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.


thanks
-Doug Davis/Mark Peek/Ken Owens

Hey fellow TOC members – poke on this?  Thoughts?

 

A couple of questions in my mind:

• How does this relate to the proposed Runtime SIG? (https://docs.google.com/document/d/1rftGB1Wkc_VcG9gz0072uCUHIddViGtLwaO4boEb4qA/edit)
• How do we look at the differences between WGs and SIGs? 
• At a procedural level SIGs are rooted with the TOC and seen as an extension.  WGs don’t have a formal relationship to the TOC.

 

Joe

 

From: <cncf-toc@...> on behalf of Doug Davis <dug@...>
Date: Monday, October 21, 2019 at 7:33 PM
To: "cncf-toc@..." <cncf-toc@...>
Subject: [cncf-toc] Serverless WG and the AppDelivery SIG

 

TOC members,

On a previous TOC call there was a request for feedback from the Serverless WG as to whether or not it would be a good fit for inclusion in the new AppDelivery SIG. During last week's WG call this topic was discussed and the net result is that the WG members felt that while there is some possible overlap, the scope of the WG is different enough that the SIG would not be an appropriate home for the WG. As a concrete example, it seems as though a project like CloudEvents (which came out of the WG's work) would not be in-scope for the AppDelivery SIG. With that, the WG thinks that a separate SIG might be more appropriate.

However, the creation of a Serverless SIG might be too limited in scope. One of the things that we're noticing is that the lines between CaaS, PaaS, FaaS and Serverless are getting blurry. Which means the distinction between the various platforms, or underlying technologies for each *aaS, is becoming less clear. Instead, the differences are becoming more akin to configuration settings rather than entirely distinct platform considerations. As such, the WG felt that an "AppPlatform" SIG might be more appropriate. This SIG could then focus on the underlying hosting technologies leveraged by higher-level SIGs (such as AppDelivery). It would be something along the lines of "Topic 4" in the diagram here: https://docs.google.com/document/d/1gMhRz4vEwiHa3uD8DqFKHGTSxrVJNgkLG2WZWvi9lXo/edit#bookmark=id.qv45kp7nb29b

We can discuss this on a future TOC call, but if the TOC is interested in this we can take the action item to write-up a formal charter to further clarify the proposal that we have in mind.


thanks
-Doug Davis/Mark Peek/Ken Owens