Date   

Re: Security policies for Kubernetes

Brian Grant
 

+mohr

If you have feedback on the kubernetes proposal, please do provide that feedback on the doc or on the issue.

On Thu, Nov 10, 2016 at 10:05 AM, Nicko van Someren via cncf-toc <cncf-toc@...> wrote:
Hi Alexis,

Thanks for that. I read through the Google Doc and added some comments.

One thing I think would be valuable to include in the security process is for there to be a broadcast mail to some 'announce' mailing list in advance of patches to high severity issues, indicating that a critical patch is imminent, with an expected release date but without full details of the issue. For large users with big IT infrastructure it may be necessary to schedule extra staff to install urgent patches quickly and having advanced notice of when this will be necessary is very helpful. Projects like OpenSSL usually send these out three days before security-critical releases (see https://goo.gl/BzElRC for examples).

Cheers,
Nicko









On Thu, Nov 10, 2016 at 10:26 AM, Alexis Richardson <alexis@...> wrote:
+nicko

On Thu, Nov 10, 2016 at 5:21 PM, Dan Kohn via cncf-toc <cncf-toc@...> wrote:
There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@...g>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

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





--
Nicko van Someren
CTO, Linux Foundation


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



Re: Security policies for Kubernetes

Brandon Philips <brandon.philips@...>
 

Thanks Dan. I plan on pushing more on this post-KubeCon. Hopefully get PRs up against the documentation in the coming days.

I will take this discussion under advisement but I think there are some clear people and process things we can get right before bike-shedding on disclosure process.

Cheers,

Brandon

On Thu, Nov 10, 2016 at 9:21 AM Dan Kohn <dan@...> wrote:
There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Draft graduation criteria

Dan Kohn <dan@...>
 

We believe we're Ready to call for a vote on the project graduation criteria. 

Could TOC members and others please add comments to the doc if they have additional concerns. 


Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>
 

I mailed a few of the OpenSSL team to ask them about this. Here's the reply from Rich Salz:

I’m not sure what greg heard, maybe it was well into the number of beers?

 

It’s not that we’re opposed, it’s that it is difficult.  We think we’re doing the right thing, and in Munich we made some tweaks but reconfirmed our plans.


I hope that clarifies things.


Cheers,

Nicko



On Thu, Nov 10, 2016 at 12:21 PM, Nicko van Someren <nicko@...> wrote:
That's interesting feedback. I was speaking to the VP of infrastructure at a major bank last week and he said that having a heads up from OpenSSL helps him hugely and he wished that more projects did it. I also had a request from one of the CII members asking for the same thing. Who in the OpenSSL team felt it didn't work? I would be interested to know what problems they find with this.

Cheers,
Nicko

On Thu, Nov 10, 2016 at 12:17 Greg KH <gregkh@...> wrote:
On Thu, Nov 10, 2016 at 11:05:01AM -0700, Nicko van Someren wrote:
> One thing I think would be valuable to include in the security process is for
> there to be a broadcast mail to some 'announce' mailing list in advance of
> patches to high severity issues, indicating that a critical patch is imminent,
> with an expected release date but without full details of the issue. For large
> users with big IT infrastructure it may be necessary to schedule extra staff to
> install urgent patches quickly and having advanced notice of when this will be
> necessary is very helpful. Projects like OpenSSL usually send these out three
> days before security-critical releases (see https://goo.gl/BzElRC for
> examples).

I think you might want to reconsider that, as over beers, the OpenSSL
team says that this type of thing really doesn't work and just causes
more problems...

But hey, remember that I'm on a project that does weekly releases
without telling anyone what the security fixes we made in them were, so
what do I know? :)

thanks,

greg k-h



--
Nicko van Someren
CTO, Linux Foundation
+1 (978) 821-0391


Re: Security policies for Kubernetes

Greg KH <gregkh@...>
 

On Thu, Nov 10, 2016 at 12:41:46PM -0700, Nicko van Someren wrote:
It's also worth noting that precisely because the Linux kernel team put out a
release every single week the scheduling of IT resources for deployment is not
a problem. People know in advance when your releases are going to drop. It is
more valuable to have the advanced notice if you don't have a highly regular
delivery schedule.
Ah, but I don't, I'm a horrible release maker. I did 3 releases 2 weeks
ago, none last week, and then one this week. Or was it one last week, I
can't remember... And all were on different days of the week, with no
apparent reasoning behind when each is made[1] (some came later than
announced, some earlier, and one with no announcement at all, and this
was just the past 3 weeks.)

So no, no one knows when our stable kernel releases are going to happen,
heck, I don't even know that :)

sorry,

greg k-h

[1] - It's my travel schedule that drives most of it, combined with when
security bugs are found and fixed in Linus's tree, which happen
unexpectedly as expected, or when embargos leak early, as happened
with DirtyC0w[2].

[2] - DirtyC0w is proof that even when everything goes right on the
project's security team side (kernel team was properly notified of
problem in the wild, fix was found, backports to all relevant
kernels were made and tested, embargo was planned, distros were
notified ahead of time), it's really up to the other groups you
notify to not mess up in order to keep it all together, which
failed horribly here (embargo was leaked to the public from a
distro, random companies knew there was a pending problem weeks
early due to a different leak, competing OS team decides to make
fun of the situatation and make a web site, etc.). So I'm really
all for not telling _anyone_ outside of the project's team about
security issues, as it always seems to go wrong.


Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>
 

On Thu, Nov 10, 2016 at 2:57 PM, Greg KH <gregkh@...> wrote:
​...​

Users might get warm and fuzzies thinking that this is the only time
they need to update, but really, they should be updating all the time.
Announcing it ahead of time really doesn't help companies fix their
infrastructure problems properly.

​I don't disagree but in the absence of a highly regular release cadence, or in the case of an out-of-cycle release, it is still valuable to know when a new​ release is coming.

But that's my comments, and not the OpenSSL's teams comments, I can't
recall their exact reasons.  I suggest talking to them at their next
hackfest about it to get all of the details.

​I will do. Thanks for raising the issue.

Cheers,
Nicko​


--
Nicko van Someren
CTO, Linux Foundation
+1 (978) 821-0391


Re: Security policies for Kubernetes

Greg KH <gregkh@...>
 

On Thu, Nov 10, 2016 at 07:21:34PM +0000, Nicko van Someren wrote:
That's interesting feedback. I was speaking to the VP of infrastructure at a
major bank last week and he said that having a heads up from OpenSSL helps him
hugely and he wished that more projects did it. I also had a request from one
of the CII members asking for the same thing. Who in the OpenSSL team felt it
didn't work? I would be interested to know what problems they find with this.
Users might get warm and fuzzies thinking that this is the only time
they need to update, but really, they should be updating all the time.
Announcing it ahead of time really doesn't help companies fix their
infrastructure problems properly.

But that's my comments, and not the OpenSSL's teams comments, I can't
recall their exact reasons. I suggest talking to them at their next
hackfest about it to get all of the details.

thanks,

greg k-h


Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>
 

It's also worth noting that precisely because the Linux kernel team put out a release every single week the scheduling of IT resources for deployment is not a problem. People know in advance when your releases are going to drop. It is more valuable to have the advanced notice if you don't have a highly regular delivery schedule.

Cheers,
Nicko


On Thu, Nov 10, 2016 at 12:21 PM, Nicko van Someren <nicko@...> wrote:
That's interesting feedback. I was speaking to the VP of infrastructure at a major bank last week and he said that having a heads up from OpenSSL helps him hugely and he wished that more projects did it. I also had a request from one of the CII members asking for the same thing. Who in the OpenSSL team felt it didn't work? I would be interested to know what problems they find with this.

Cheers,
Nicko

On Thu, Nov 10, 2016 at 12:17 Greg KH <gregkh@...> wrote:
On Thu, Nov 10, 2016 at 11:05:01AM -0700, Nicko van Someren wrote:
> One thing I think would be valuable to include in the security process is for
> there to be a broadcast mail to some 'announce' mailing list in advance of
> patches to high severity issues, indicating that a critical patch is imminent,
> with an expected release date but without full details of the issue. For large
> users with big IT infrastructure it may be necessary to schedule extra staff to
> install urgent patches quickly and having advanced notice of when this will be
> necessary is very helpful. Projects like OpenSSL usually send these out three
> days before security-critical releases (see https://goo.gl/BzElRC for
> examples).

I think you might want to reconsider that, as over beers, the OpenSSL
team says that this type of thing really doesn't work and just causes
more problems...

But hey, remember that I'm on a project that does weekly releases
without telling anyone what the security fixes we made in them were, so
what do I know? :)

thanks,

greg k-h



--
Nicko van Someren
CTO, Linux Foundation
+1 (978) 821-0391


Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>
 

That's interesting feedback. I was speaking to the VP of infrastructure at a major bank last week and he said that having a heads up from OpenSSL helps him hugely and he wished that more projects did it. I also had a request from one of the CII members asking for the same thing. Who in the OpenSSL team felt it didn't work? I would be interested to know what problems they find with this.

Cheers,
Nicko


On Thu, Nov 10, 2016 at 12:17 Greg KH <gregkh@...> wrote:
On Thu, Nov 10, 2016 at 11:05:01AM -0700, Nicko van Someren wrote:
> One thing I think would be valuable to include in the security process is for
> there to be a broadcast mail to some 'announce' mailing list in advance of
> patches to high severity issues, indicating that a critical patch is imminent,
> with an expected release date but without full details of the issue. For large
> users with big IT infrastructure it may be necessary to schedule extra staff to
> install urgent patches quickly and having advanced notice of when this will be
> necessary is very helpful. Projects like OpenSSL usually send these out three
> days before security-critical releases (see https://goo.gl/BzElRC for
> examples).

I think you might want to reconsider that, as over beers, the OpenSSL
team says that this type of thing really doesn't work and just causes
more problems...

But hey, remember that I'm on a project that does weekly releases
without telling anyone what the security fixes we made in them were, so
what do I know? :)

thanks,

greg k-h


Re: Security policies for Kubernetes

Greg KH <gregkh@...>
 

On Thu, Nov 10, 2016 at 11:05:01AM -0700, Nicko van Someren wrote:
One thing I think would be valuable to include in the security process is for
there to be a broadcast mail to some 'announce' mailing list in advance of
patches to high severity issues, indicating that a critical patch is imminent,
with an expected release date but without full details of the issue. For large
users with big IT infrastructure it may be necessary to schedule extra staff to
install urgent patches quickly and having advanced notice of when this will be
necessary is very helpful. Projects like OpenSSL usually send these out three
days before security-critical releases (see?https://goo.gl/BzElRC for
examples).
I think you might want to reconsider that, as over beers, the OpenSSL
team says that this type of thing really doesn't work and just causes
more problems...

But hey, remember that I'm on a project that does weekly releases
without telling anyone what the security fixes we made in them were, so
what do I know? :)

thanks,

greg k-h


Re: Security policies for Kubernetes

Nicko van Someren <nicko@...>
 

Hi Alexis,

Thanks for that. I read through the Google Doc and added some comments.

One thing I think would be valuable to include in the security process is for there to be a broadcast mail to some 'announce' mailing list in advance of patches to high severity issues, indicating that a critical patch is imminent, with an expected release date but without full details of the issue. For large users with big IT infrastructure it may be necessary to schedule extra staff to install urgent patches quickly and having advanced notice of when this will be necessary is very helpful. Projects like OpenSSL usually send these out three days before security-critical releases (see https://goo.gl/BzElRC for examples).

Cheers,
Nicko









On Thu, Nov 10, 2016 at 10:26 AM, Alexis Richardson <alexis@...> wrote:
+nicko

On Thu, Nov 10, 2016 at 5:21 PM, Dan Kohn via cncf-toc <cncf-toc@...> wrote:
There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@...g>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

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





--
Nicko van Someren
CTO, Linux Foundation
+1 (978) 821-0391


Re: Security policies for Kubernetes

Chenxi Wang
 

Hi, Twistlock is a member and is a Container security company. We have been working with Google/GCP/Kubernetes for some time. We'd love to contribute. We'll start on the Github thread. 

Chenxi

On Thu, Nov 10, 2016 at 9:21 AM, Dan Kohn via cncf-toc <cncf-toc@...> wrote:
There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

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




--
Chenxi Wang, Ph.D.
Chief Strategy Officer, Twistlock
@chenxiwang
+1.650.224.7197


Re: Security policies for Kubernetes

alexis richardson
 

+nicko

On Thu, Nov 10, 2016 at 5:21 PM, Dan Kohn via cncf-toc <cncf-toc@...> wrote:
There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

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



Security policies for Kubernetes

Dan Kohn <dan@...>
 

There was a question at the Kubernetes panel Monday night about how to handle security reports now that Kubernetes is a CNCF rather than a Google project.

Brandon Phillips seems to have already gotten a good start on this at https://github.com/kubernetes/kubernetes/issues/35462 and in the linked Google Doc.

I presume he and Sarah Novotny will let CNCF staff know if they want any CNCF-hosted mailing lists or other infrastructure.

But I wanted to flag this publicly in case anyone on the TOC list wanted to chime in. I'm also cc'ing Greg KH, in case he might want to add any comments about the kernel security process.
--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Re: [VOTE] Fluentd Project Proposal

alexis richardson
 

hooray


On Tue, Nov 8, 2016 at 4:12 PM, Chris Aniszczyk
<caniszczyk@linuxfoundation.org> wrote:
Yes we are all set Alexis, the official announcement will go out this
morning:
https://github.com/cncf/toc/pull/20#issuecomment-259040513

On Tue, Nov 8, 2016 at 12:17 AM, Alexis Richardson via cncf-toc
<cncf-toc@lists.cncf.io> wrote:

I believe that means we have six YES votes and Fluentd accepted.

Chris, please let us know when the voting officially 'closes'.




On Tue, Nov 8, 2016 at 3:21 AM, Camille Fournier via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Yes


On Nov 7, 2016 9:46 PM, "Solomon Hykes via cncf-toc"
<cncf-toc@lists.cncf.io> wrote:

Yes.

On Wed, Nov 2, 2016 at 7:38 AM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
After a significant amount of community discussion, the Fluentd
project
proposal is ready for an official vote by the TOC:
https://github.com/cncf/toc/pull/20

Description: Fluentd is an open source data collector that allows to
implement an unified logging layer. Fluentd’s 600+ plugins connect it
to
many data sources and data outputs. Fluentd has a large adopter
community
consisting of Atlassian, LINE, Microsoft, Nintendo and GREE within
others.

The project TOC sponsor is Brian Grant. The full details can be found
on
GitHub:
https://github.com/cncf/toc/pull/20/files

Anyways, please vote!

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

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

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



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


Re: [VOTE] Fluentd Project Proposal

Chris Aniszczyk
 

Yes we are all set Alexis, the official announcement will go out this morning:

On Tue, Nov 8, 2016 at 12:17 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
I believe that means we have six YES votes and Fluentd accepted.

Chris, please let us know when the voting officially 'closes'.




On Tue, Nov 8, 2016 at 3:21 AM, Camille Fournier via cncf-toc
<cncf-toc@...> wrote:
> Yes
>
>
> On Nov 7, 2016 9:46 PM, "Solomon Hykes via cncf-toc"
> <cncf-toc@...> wrote:
>>
>> Yes.
>>
>> On Wed, Nov 2, 2016 at 7:38 AM, Chris Aniszczyk via cncf-toc
>> <cncf-toc@...> wrote:
>> > After a significant amount of community discussion, the Fluentd project
>> > proposal is ready for an official vote by the TOC:
>> > https://github.com/cncf/toc/pull/20
>> >
>> > Description: Fluentd is an open source data collector that allows to
>> > implement an unified logging layer. Fluentd’s 600+ plugins connect it to
>> > many data sources and data outputs. Fluentd has a large adopter
>> > community
>> > consisting of Atlassian, LINE, Microsoft, Nintendo and GREE within
>> > others.
>> >
>> > The project TOC sponsor is Brian Grant. The full details can be found on
>> > GitHub:
>> > https://github.com/cncf/toc/pull/20/files
>> >
>> > Anyways, please vote!
>> >
>> > --
>> > Chris Aniszczyk (@cra) | +1-512-961-6719
>> >
>> > _______________________________________________
>> > cncf-toc mailing list
>> > cncf-toc@...
>> > https://lists.cncf.io/mailman/listinfo/cncf-toc
>> >
>> _______________________________________________
>> cncf-toc mailing list
>> cncf-toc@...
>> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



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


Re: [VOTE] Fluentd Project Proposal

alexis richardson
 

I believe that means we have six YES votes and Fluentd accepted.

Chris, please let us know when the voting officially 'closes'.




On Tue, Nov 8, 2016 at 3:21 AM, Camille Fournier via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
Yes


On Nov 7, 2016 9:46 PM, "Solomon Hykes via cncf-toc"
<cncf-toc@lists.cncf.io> wrote:

Yes.

On Wed, Nov 2, 2016 at 7:38 AM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
After a significant amount of community discussion, the Fluentd project
proposal is ready for an official vote by the TOC:
https://github.com/cncf/toc/pull/20

Description: Fluentd is an open source data collector that allows to
implement an unified logging layer. Fluentd’s 600+ plugins connect it to
many data sources and data outputs. Fluentd has a large adopter
community
consisting of Atlassian, LINE, Microsoft, Nintendo and GREE within
others.

The project TOC sponsor is Brian Grant. The full details can be found on
GitHub:
https://github.com/cncf/toc/pull/20/files

Anyways, please vote!

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

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

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


Re: [VOTE] Fluentd Project Proposal

Camille Fournier
 

Yes


On Nov 7, 2016 9:46 PM, "Solomon Hykes via cncf-toc" <cncf-toc@...> wrote:
Yes.

On Wed, Nov 2, 2016 at 7:38 AM, Chris Aniszczyk via cncf-toc
<cncf-toc@...> wrote:
> After a significant amount of community discussion, the Fluentd project
> proposal is ready for an official vote by the TOC:
> https://github.com/cncf/toc/pull/20
>
> Description: Fluentd is an open source data collector that allows to
> implement an unified logging layer. Fluentd’s 600+ plugins connect it to
> many data sources and data outputs. Fluentd has a large adopter community
> consisting of Atlassian, LINE, Microsoft, Nintendo and GREE within others.
>
> The project TOC sponsor is Brian Grant. The full details can be found on
> GitHub:
> https://github.com/cncf/toc/pull/20/files
>
> Anyways, please vote!
>
> --
> Chris Aniszczyk (@cra) | +1-512-961-6719
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] Fluentd Project Proposal

Solomon Hykes
 

Yes.

On Wed, Nov 2, 2016 at 7:38 AM, Chris Aniszczyk via cncf-toc
<cncf-toc@lists.cncf.io> wrote:
After a significant amount of community discussion, the Fluentd project
proposal is ready for an official vote by the TOC:
https://github.com/cncf/toc/pull/20

Description: Fluentd is an open source data collector that allows to
implement an unified logging layer. Fluentd’s 600+ plugins connect it to
many data sources and data outputs. Fluentd has a large adopter community
consisting of Atlassian, LINE, Microsoft, Nintendo and GREE within others.

The project TOC sponsor is Brian Grant. The full details can be found on
GitHub:
https://github.com/cncf/toc/pull/20/files

Anyways, please vote!

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

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


Re: [VOTE] End User Reference Architecture v1.0

Jonathan Boulle <jonathan.boulle@...>
 

Yes

On 27 October 2016 at 15:14, Doug Davis via cncf-toc <cncf-toc@...> wrote:

Overall it looks good. Just two things that jumped out at me that are missing:
1 - multi-tenancy. I don't think we need to say much, other than its an issue, and while it could appear on several charts, perhaps the "Orchestration & Management Layer" one might be the best single spot for it.
2 - clustering. Probably on the same slide too. While its implied, I just want to be clear that people need to think about how to scale and cluster many many nodes and this arch isn't just for small/single node envs.


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

Alexis Richardson via cncf-toc ---10/26/2016 01:41:40 PM---A global service catalogue is an interesting idea. If it is "like DNS but for cloud native apps" th

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: "Ram, J" <j.ram@...>, Brian Grant <briangrant@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Date: 10/26/2016 01:41 PM
Subject: Re: [cncf-toc] [VOTE] End User Reference Architecture v1.0
Sent by: cncf-toc-bounces@...





A global service catalogue is an interesting idea.  If it is "like DNS but for cloud native apps" then it presupposes an "HTTP but for cloud native apps".  Such as a service broker protocol for discovery, binding and monitoring.


On Wed, 26 Oct 2016, 18:24 Ram, J via cncf-toc, <cncf-toc@...> wrote:
     

     

    From: Brian Grant [mailto:briangrant@...]
    Sent:
    Monday, October 24, 2016 8:18 PM
    To:
    Ram, J [Tech]
    Cc:
    Chris Aniszczyk; cncf-toc@...
    Subject:
    Re: [cncf-toc] [VOTE] End User Reference Architecture v1.0

     

    On Mon, Oct 24, 2016 at 5:28 AM, Ram, J via cncf-toc <cncf-toc@...> wrote:

     

    Sorry, I missed that last call. So apologies if this was discussed.

    Two thoughts/Questions that come to mind when looking thru the slides:

     

    a)      Emphasis on security seem to be missing. It might be implicit, but being explicit might be useful.  So calling out some aspects of it in application definition, orchestration and runtime would change that. I suspect that orchestration and runtime would get more interesting if complex security policies are modelled in the application definition.

    Given that security spans all the layers and is a complex topic, I'm not sure what we'd add at the current level of detail. 

     

    b)      Not sure if this is group to address: I feel, that no consistent implementation or standard for Service Directory exist. The most consistent yellow pages we seem to have DNS. For the new generation of applications, is that enough?  Should we call out Service directory under service management?

    Service naming, discovery, load balancing, and routing (service fabric/mesh approaches) are intended to be covered by slide 6. Is there a specific terminology clarification that you'd like to see? Or would you like us to merge the "Coordination" and "Service Management" sub-bullets into a single list?

     

    What exactly do you mean by "service directory"?

    [JRAM] to reiterate this maybe outside the scope of this discussion. My observation, is that there is no consistent standard for any client to search, lookup and find service providers in the global network in a consistent fashion. DNS is the closest adopted standard and is not really designed for the level of dynamism we need in this new Cloud Based model. Lack of this is clearly emphasized by trickery played in networking stack and DNS stack. Another observation is that there is no global catalogue of all services that are available in the network at internet scale. Every seems to be having their own version of “directory” implementation. In our case, we have DNS, Zookeeper, url router, etc to just name a few…

     

     

    The question for us to answer minimally is: do we want to address this problem architecturally and as a standard ?

     

     

     

     

     

     

     

    From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Chris Aniszczyk via cncf-toc
    Sent:
    Monday, October 24, 2016 7:15 AM
    To:
    cncf-toc@...
    Subject:
    [cncf-toc] [VOTE] End User Reference Architecture v1.0

     

    Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):

     

    http://drive.google.com/open?id=1uMw2wkK0ubmc3khxqIuxK_rLK_wN89tNCnK7gDmTGR8

     

    This is a call to formalize the reference architecture, so TOC members please vote!

     

    --

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


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



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


6501 - 6520 of 6983