Date   

WG-Serverless - draft whitepaper

Doug Davis <dug@...>
 

All,
sorry I missed the call last week, was on vacation. Ken mentioned that I should send out a link to the latest version of the whitepaper, so here it is: https://docs.google.com/document/d/1UjW8bt5O8QBgQRILJVKZJej_IuNnxl20AJu9wA8wcdI/edit?ts=59831b77#heading=h.yiaul8is1ki
There are still quite a few things that need to be cleaned-up but any early comments/feedback are welcome.


thanks
-Doug Davis
_______________________________________________________
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


Final RFC on Notary project proposal

Chris Aniszczyk
 

Hey TOC and wider CNCF community, the Notary/TUF project (sponsored by Solomon) is looking for final feedback before we formally call for a vote: https://github.com/cncf/toc/pull/38

Please comment on their project proposal on GitHub, if there are no formal objections to calling a vote, I plan on doing it late next week.

Thanks!

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


Re: FYI: CNCF Project "Service Desk"

Brian Grant
 

This sounds great. Looking forward to it. Thanks!

On Tue, Aug 1, 2017 at 7:23 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
At the CNCF Governing Board strategy offsite on 7/28, Alexis presented the following slides on behalf of the TOC: https://goo.gl/8QLjK6

The Governing Board and CNCF staff was very supportive of his request for more transparency in regards to the services CNCF offers (and which projects use those), along with a consistent process for projects to request services (a service desk potentially via GitHub issues).

We plan to roll this out over the next month and will discuss this more at the TOC meeting today too if there any questions.

Thanks!

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

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



FYI: CNCF Project "Service Desk"

Chris Aniszczyk
 

At the CNCF Governing Board strategy offsite on 7/28, Alexis presented the following slides on behalf of the TOC: https://goo.gl/8QLjK6

The Governing Board and CNCF staff was very supportive of his request for more transparency in regards to the services CNCF offers (and which projects use those), along with a consistent process for projects to request services (a service desk potentially via GitHub issues).

We plan to roll this out over the next month and will discuss this more at the TOC meeting today too if there any questions.

Thanks!

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


TOC Agenda for 8/1/17

Chris Aniszczyk
 

Here's the TOC deck for tomorrow at 8am PT: https://goo.gl/ehtgts

We will be hearing from the Jaeger project (https://github.com/uber/jaegerand the Serverless WG (https://github.com/cncf/wg-serverless) along with some updates from the last strategy offsite help by the CNCF GB.

Thanks and see everyone tomorrow!

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


Call for Action: One month to become a Founding Kubernetes Certified Service Provider

Dan Kohn <dan@...>
 

In early September, CNCF will be announcing the founding class of Kubernetes Certified Service Providers (KCSPs). If your company provides professional services to support Kubernetes deployments, please consider signing up to become part of the founding class.

The main benefits of becoming a KCSP are:
* Placement in a new section at the top of https://kubernetes.io/partners/ 
* Monthly private meetings with cloud native project leaders, TOC members, and representatives from the CNCF Governing Board
* Access to leads from end users looking for support

Requirements are:
* Three or more engineers who pass the Certified Kubernetes Administrator (CKA) exam
* Demonstrable activity in the Kubernetes community including active contribution
* A business model to support enterprise end users, including putting engineers at a customer site

The CKA exam is about to enter early release beta testing prior to the public release in September. It is an online, proctored, performance-based test that requires solving multiple issues from a command line. It takes 3 to 4 hours to complete, and costs $300, though a discount is available for beta testers to $100.

If your company is interested in becoming a KCSP, please do the following 4 things:

1. Ensure that your company is listed at https://kubernetes.io/partners/ and if not (or if the listing should be updated), please do so via the link at the top of that page.

2. Have 3 or more of your Kubernetes experts sign up for the beta test at: https://docs.google.com/forms/d/e/1FAIpQLSd9-6nL5L3SzWIddCSPoKeuX_Pdq_KHI8C4mQzcUryP-gu0dQ/viewform . Please have them use their company email so we can properly associate them. Within a week, we will send beta test dates, a discount coupon code, and instructions to register and schedule.


4. If you are not already on it, and want to track progress of the certification program over time, please subscribe to the Kubernetes Certification Working Group list: https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg

Questions or issues? Please email cncf-kcsp-support@... .
--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Re: openmetrics next steps

Richard Hartmann
 

Lee,

it's every 14 days, Tuesday 1900 CEST; not sure if we will follow
summer/winter or UTC once we get there.

You will get an invite to the address you sent from. If you could send
a short bio or something, that would be helpful. Long-term, we will
document the people involved on https://github.com/RichiH/OpenMetrics
along with everything else, I suspect.

Reading through the files and issues in that repo will get you up to speed.


RIchard

On Fri, Jul 21, 2017 at 3:24 PM, Lee Calcote <leecalcote@...> wrote:
Richard,

I wasn’t aware of the call on 7/18 (and missed it). When is the next call scheduled for?

- Lee

On Jul 19, 2017, at 5:26 AM, Richard Hartmann <richih@...> wrote:

Yes, carefully increasing participation is good. At the current stage,
I wouldn't want to be an artificial blocker in selection as I don't
know most people (yet), anyway. "Does this person have relevant
knowledge/experience and will they contribute positively" is the only
hard consideration at this point. We are currently seeing some
bikeshedding and feature creep; while that's always expected,
overloading discussions is my main concern, atm.

The Google people are networking and stackdriver with some
Borgmon/Monarch experience mixed in; Fabian said he will toss the repo
address and purpose into his k8s sig, but I didn't follow up on that
and/or verify, yet. I shall do so, but Fabian's on holiday atm.


Given the holiday season, these issues will collect and simmer for at
least a few weeks before I will make a call for Rough Consensus.


Richard

On Wed, Jul 19, 2017 at 11:14 AM, Alexis Richardson <alexis@...> wrote:
+stuart+brian fyi


Richard

IMO this planning process would benefit from *slightly* wider CNCF-TOC
involvement. Do you want to select & invite people or ask Ken & Lee to do
so?

BTW, are the google reps in your notes also from the k8s instrumentation
sig?

a





On Tue, Jul 18, 2017 at 7:17 PM, Richard Hartmann <richih@...> wrote:

Hi Chris,

sorry for being so late in replying. We didn't have the July 4th call
for obvious reasons, but we had our call just now; even if quite a few
people are on holiday.

The GDoc is still

https://docs.google.com/document/d/1q7HSZyRv4Ay4hTlva4uy8WPh5WlYv9S0Yy-xQS2vKo4/edit#
but I am splitting out most questions into
https://github.com/RichiH/OpenMetrics/issues so we have better
exposure and tracking for those questions. Again, if you want to
bounce these discussion to carefully hand-chosen people, you are more
than welcome to do so. Part of my intention behind the issues is to
get out of the echo chamber if whoever hapens to be in a particular
call.


Richard


Re: openmetrics next steps

Lee Calcote
 

Richard,

I wasn’t aware of the call on 7/18 (and missed it). When is the next call scheduled for?

- Lee

On Jul 19, 2017, at 5:26 AM, Richard Hartmann <richih@...> wrote:

Yes, carefully increasing participation is good. At the current stage,
I wouldn't want to be an artificial blocker in selection as I don't
know most people (yet), anyway. "Does this person have relevant
knowledge/experience and will they contribute positively" is the only
hard consideration at this point. We are currently seeing some
bikeshedding and feature creep; while that's always expected,
overloading discussions is my main concern, atm.

The Google people are networking and stackdriver with some
Borgmon/Monarch experience mixed in; Fabian said he will toss the repo
address and purpose into his k8s sig, but I didn't follow up on that
and/or verify, yet. I shall do so, but Fabian's on holiday atm.


Given the holiday season, these issues will collect and simmer for at
least a few weeks before I will make a call for Rough Consensus.


Richard

On Wed, Jul 19, 2017 at 11:14 AM, Alexis Richardson <alexis@...> wrote:
+stuart+brian fyi


Richard

IMO this planning process would benefit from *slightly* wider CNCF-TOC
involvement. Do you want to select & invite people or ask Ken & Lee to do
so?

BTW, are the google reps in your notes also from the k8s instrumentation
sig?

a





On Tue, Jul 18, 2017 at 7:17 PM, Richard Hartmann <richih@...> wrote:

Hi Chris,

sorry for being so late in replying. We didn't have the July 4th call
for obvious reasons, but we had our call just now; even if quite a few
people are on holiday.

The GDoc is still

https://docs.google.com/document/d/1q7HSZyRv4Ay4hTlva4uy8WPh5WlYv9S0Yy-xQS2vKo4/edit#
but I am splitting out most questions into
https://github.com/RichiH/OpenMetrics/issues so we have better
exposure and tracking for those questions. Again, if you want to
bounce these discussion to carefully hand-chosen people, you are more
than welcome to do so. Part of my intention behind the issues is to
get out of the echo chamber if whoever hapens to be in a particular
call.


Richard


Re: openmetrics next steps

Richard Hartmann
 

Yes, carefully increasing participation is good. At the current stage,
I wouldn't want to be an artificial blocker in selection as I don't
know most people (yet), anyway. "Does this person have relevant
knowledge/experience and will they contribute positively" is the only
hard consideration at this point. We are currently seeing some
bikeshedding and feature creep; while that's always expected,
overloading discussions is my main concern, atm.

The Google people are networking and stackdriver with some
Borgmon/Monarch experience mixed in; Fabian said he will toss the repo
address and purpose into his k8s sig, but I didn't follow up on that
and/or verify, yet. I shall do so, but Fabian's on holiday atm.


Given the holiday season, these issues will collect and simmer for at
least a few weeks before I will make a call for Rough Consensus.


Richard

On Wed, Jul 19, 2017 at 11:14 AM, Alexis Richardson <alexis@...> wrote:
+stuart+brian fyi


Richard

IMO this planning process would benefit from *slightly* wider CNCF-TOC
involvement. Do you want to select & invite people or ask Ken & Lee to do
so?

BTW, are the google reps in your notes also from the k8s instrumentation
sig?

a





On Tue, Jul 18, 2017 at 7:17 PM, Richard Hartmann <richih@...> wrote:

Hi Chris,

sorry for being so late in replying. We didn't have the July 4th call
for obvious reasons, but we had our call just now; even if quite a few
people are on holiday.

The GDoc is still

https://docs.google.com/document/d/1q7HSZyRv4Ay4hTlva4uy8WPh5WlYv9S0Yy-xQS2vKo4/edit#
but I am splitting out most questions into
https://github.com/RichiH/OpenMetrics/issues so we have better
exposure and tracking for those questions. Again, if you want to
bounce these discussion to carefully hand-chosen people, you are more
than welcome to do so. Part of my intention behind the issues is to
get out of the echo chamber if whoever hapens to be in a particular
call.


Richard


Re: openmetrics next steps

alexis richardson
 

+stuart+brian fyi


Richard

IMO this planning process would benefit from *slightly* wider CNCF-TOC involvement.  Do you want to select & invite people or ask Ken & Lee to do so?  

BTW, are the google reps in your notes also from the k8s instrumentation sig?

a





On Tue, Jul 18, 2017 at 7:17 PM, Richard Hartmann <richih@...> wrote:
Hi Chris,

sorry for being so late in replying. We didn't have the July 4th call
for obvious reasons, but we had our call just now; even if quite a few
people are on holiday.

The GDoc is still
https://docs.google.com/document/d/1q7HSZyRv4Ay4hTlva4uy8WPh5WlYv9S0Yy-xQS2vKo4/edit#
but I am splitting out most questions into
https://github.com/RichiH/OpenMetrics/issues so we have better
exposure and tracking for those questions. Again, if you want to
bounce these discussion to carefully hand-chosen people, you are more
than welcome to do so. Part of my intention behind the issues is to
get out of the echo chamber if whoever hapens to be in a particular
call.


Richard


Re: openmetrics next steps

Richard Hartmann
 

Hi Chris,

sorry for being so late in replying. We didn't have the July 4th call
for obvious reasons, but we had our call just now; even if quite a few
people are on holiday.

The GDoc is still
https://docs.google.com/document/d/1q7HSZyRv4Ay4hTlva4uy8WPh5WlYv9S0Yy-xQS2vKo4/edit#
but I am splitting out most questions into
https://github.com/RichiH/OpenMetrics/issues so we have better
exposure and tracking for those questions. Again, if you want to
bounce these discussion to carefully hand-chosen people, you are more
than welcome to do so. Part of my intention behind the issues is to
get out of the echo chamber if whoever hapens to be in a particular
call.


Richard


Re: Infrakit Questions

Zachary Smith
 

Thanks Solomon!

I also mis-used LinuxKit instead of InfraKit below.  Very much still catching up with the terms right now.

I also see this as very broad and there is so much that can be done with InfraKit, so I need to learn more and tinker more.  Looking forward to further conversation on this.

Thanks!

-Zac



Tuesday, June 27, 2017 2:27 PM
Rob, Zach, to clarify: do you have specific concerns about InfraKit that we should ask Dave to address?

My understanding is that 1) InfraKit is OS-agnostic and does not require LinuxKit 2) InfraKit does not impose an immutable operating system pattern.


Rob, you suggest more review: specifically what should we review? I think we should aim to get to "yes" or "no" in a timely fashion.


Tuesday, June 27, 2017 1:32 PM
I'd agree with Rob here.  LinuxKit is certain a component, but I think that the full hardware and network lifecycle associated with booting "all the things" is a pretty broad and messy space right now, particularly across private datacenters vs public clouds.

-Zac




--
Zachary Smith, CEO of Packet
Tuesday, June 27, 2017 11:27 AM
Responding to request from TOC meeting last week...

I think that Day 1 and Day 2 provisioning is key area for CNCF to cover; however, I think that the space is transforming in several different ways so I would suggest more review by the TOC.  Obviously, I have an interest in this since I'm a lead on Digital Rebar.  For that reason, I'm reluctant to push against or pull for related projects.

For LinuxKit specifically, I think the emphasis on immutable operating systems should be considered carefully.  There are many benefits to this approach but they cannot be applied generally to legacy workloads and management tooling.  I believe that operational adoption is accelerated when tooling fits well with both new and existing ops models.

Again - I'm happy to show how we solve this problem with Digital Rebar at a TOC.  It's not just about physical provisioning - managing server life-cycle in multiple infastructures is a key design requirement.  Tooling that does not address the full life-cycle may actually make management harder over time.

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
Tuesday, June 6, 2017 11:56 AM
+1 to Alexis and Rob.

I'd really like to see a good breakdown comparison between Infrakit and digital rebar, bosh, cloudformation, fog,and others

Alex Baretto




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
Tuesday, June 6, 2017 11:51 AM
All,

I'd be happy to present / demo Digital Rebar to provide another cloud native perspective on how to address hybrid infrastructure automation.  I believe that would help provide a helpful perspective on operational concerns and how to address them in a way that fits the CNCF community.  As you know, we've been heavily involved in the Kubernetes community and have been showing an approach that uses the community Ansible for Kubernetes.  We've also done demos also showing LinuxKit integration.

Rob

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle


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

--
Zachary Smith, CEO @ Packet
+1 212.812.4178
zac@...


Recording/Notes from 7/11/17 TOC Meeting

Chris Aniszczyk
 

Here's the recording from today's meeting, it will eventually live/trimmed down on the CNCF Youtube channel but we're dealing with some issues there: https://goo.gl/PJPRNj

As a quick summary, we formally invited Notary/TUF, rook and Vitess to submit project proposals that will be voted upon by the TOC on a future date.

The next TOC meeting will happen on August 1st where Jaeger (https://github.com/uber/jaeger) and Envoy (https://github.com/lyft/envoy) will present.

Thanks!

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


Re: Infrakit Questions

Rob Hirschfeld
 

Sorry... I keep doing that!   InfraKit.


On Tue, Jul 11, 2017 at 10:04 AM Alexis Richardson <alexis@...> wrote:
do you mean Linuxkit or Infrakit, Rob?

On Tue, Jul 11, 2017 at 4:01 PM, Rob Hirschfeld via cncf-toc <cncf-toc@...> wrote:
Solomon,

Sorry for the delay - ToC meeting tomorrow reminded me that this was pending....

The Docker team has done a good job answering questions.  My point is that this area has a lot of churn right now and the scope of LinuxKit is huge and evolving.  Since it's very pluggable, it appears to be a "do anything."

My expectation would be that narrowly defined components would be faster to bring into CNCF and something with a large scope would move slower.   I'd have similar reservations about Digital Rebar in it's integrated form which is why I offered to demo it.

Note: I do agree that LinuxKit and our Digital Rebar efforts are collaborative. especially on the metal provision side. 

Rob


On Tue, Jun 27, 2017 at 1:27 PM Solomon Hykes <solomon.hykes@...> wrote:
Rob, Zach, to clarify: do you have specific concerns about InfraKit that we should ask Dave to address?

My understanding is that 1) InfraKit is OS-agnostic and does not require LinuxKit 2) InfraKit does not impose an immutable operating system pattern.


Rob, you suggest more review: specifically what should we review? I think we should aim to get to "yes" or "no" in a timely fashion.

On Tue, Jun 27, 2017 at 10:32 AM, Zachary Smith via cncf-toc <cncf-toc@...> wrote:
I'd agree with Rob here.  LinuxKit is certain a component, but I think that the full hardware and network lifecycle associated with booting "all the things" is a pretty broad and messy space right now, particularly across private datacenters vs public clouds.

-Zac

On Tue, Jun 27, 2017 at 11:27 AM, Rob Hirschfeld via cncf-toc <cncf-toc@...> wrote:
Responding to request from TOC meeting last week...

I think that Day 1 and Day 2 provisioning is key area for CNCF to cover; however, I think that the space is transforming in several different ways so I would suggest more review by the TOC.  Obviously, I have an interest in this since I'm a lead on Digital Rebar.  For that reason, I'm reluctant to push against or pull for related projects.

For LinuxKit specifically, I think the emphasis on immutable operating systems should be considered carefully.  There are many benefits to this approach but they cannot be applied generally to legacy workloads and management tooling.  I believe that operational adoption is accelerated when tooling fits well with both new and existing ops models.

Again - I'm happy to show how we solve this problem with Digital Rebar at a TOC.  It's not just about physical provisioning - managing server life-cycle in multiple infastructures is a key design requirement.  Tooling that does not address the full life-cycle may actually make management harder over time.

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:56 AM, Alex Baretto <axbaretto@...> wrote:
+1 to Alexis and Rob.

I'd really like to see a good breakdown comparison between Infrakit and digital rebar, bosh, cloudformation, fog,and others

Alex Baretto



On Tue, Jun 06, 2017 at 08:51 Rob Hirschfeld via cncf-toc <Rob Hirschfeld via cncf-toc > wrote:
All,

I'd be happy to present / demo Digital Rebar to provide another cloud native perspective on how to address hybrid infrastructure automation.  I believe that would help provide a helpful perspective on operational concerns and how to address them in a way that fits the CNCF community.  As you know, we've been heavily involved in the Kubernetes community and have been showing an approach that uses the community Ansible for Kubernetes.  We've also done demos also showing LinuxKit integration.

Rob

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


Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:41 AM, Alexis Richardson <alexis@...> wrote:
Thanks David, Patrick et al., for Infrakit pres today!

https://docs.google.com/presentation/d/1Lzy94UNzdSXkqZCvrwjkcChKpU8u2waDqGx_Sjy5eJ8/edit#slide=id.g22ccd21963_2_0


Per Bryan's Q re Terraform, it would also be good to hear about BOSH &
Infrakit feature comparison.  And other related tech you see in the
space.




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




--
Zachary Smith, CEO of Packet

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


--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

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


--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522


Re: Infrakit Questions

alexis richardson
 

do you mean Linuxkit or Infrakit, Rob?

On Tue, Jul 11, 2017 at 4:01 PM, Rob Hirschfeld via cncf-toc <cncf-toc@...> wrote:
Solomon,

Sorry for the delay - ToC meeting tomorrow reminded me that this was pending....

The Docker team has done a good job answering questions.  My point is that this area has a lot of churn right now and the scope of LinuxKit is huge and evolving.  Since it's very pluggable, it appears to be a "do anything."

My expectation would be that narrowly defined components would be faster to bring into CNCF and something with a large scope would move slower.   I'd have similar reservations about Digital Rebar in it's integrated form which is why I offered to demo it.

Note: I do agree that LinuxKit and our Digital Rebar efforts are collaborative. especially on the metal provision side. 

Rob


On Tue, Jun 27, 2017 at 1:27 PM Solomon Hykes <solomon.hykes@...> wrote:
Rob, Zach, to clarify: do you have specific concerns about InfraKit that we should ask Dave to address?

My understanding is that 1) InfraKit is OS-agnostic and does not require LinuxKit 2) InfraKit does not impose an immutable operating system pattern.


Rob, you suggest more review: specifically what should we review? I think we should aim to get to "yes" or "no" in a timely fashion.

On Tue, Jun 27, 2017 at 10:32 AM, Zachary Smith via cncf-toc <cncf-toc@...> wrote:
I'd agree with Rob here.  LinuxKit is certain a component, but I think that the full hardware and network lifecycle associated with booting "all the things" is a pretty broad and messy space right now, particularly across private datacenters vs public clouds.

-Zac

On Tue, Jun 27, 2017 at 11:27 AM, Rob Hirschfeld via cncf-toc <cncf-toc@...> wrote:
Responding to request from TOC meeting last week...

I think that Day 1 and Day 2 provisioning is key area for CNCF to cover; however, I think that the space is transforming in several different ways so I would suggest more review by the TOC.  Obviously, I have an interest in this since I'm a lead on Digital Rebar.  For that reason, I'm reluctant to push against or pull for related projects.

For LinuxKit specifically, I think the emphasis on immutable operating systems should be considered carefully.  There are many benefits to this approach but they cannot be applied generally to legacy workloads and management tooling.  I believe that operational adoption is accelerated when tooling fits well with both new and existing ops models.

Again - I'm happy to show how we solve this problem with Digital Rebar at a TOC.  It's not just about physical provisioning - managing server life-cycle in multiple infastructures is a key design requirement.  Tooling that does not address the full life-cycle may actually make management harder over time.

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:56 AM, Alex Baretto <axbaretto@...> wrote:
+1 to Alexis and Rob.

I'd really like to see a good breakdown comparison between Infrakit and digital rebar, bosh, cloudformation, fog,and others

Alex Baretto



On Tue, Jun 06, 2017 at 08:51 Rob Hirschfeld via cncf-toc <Rob Hirschfeld via cncf-toc > wrote:
All,

I'd be happy to present / demo Digital Rebar to provide another cloud native perspective on how to address hybrid infrastructure automation.  I believe that would help provide a helpful perspective on operational concerns and how to address them in a way that fits the CNCF community.  As you know, we've been heavily involved in the Kubernetes community and have been showing an approach that uses the community Ansible for Kubernetes.  We've also done demos also showing LinuxKit integration.

Rob

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


Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:41 AM, Alexis Richardson <alexis@...> wrote:
Thanks David, Patrick et al., for Infrakit pres today!

https://docs.google.com/presentation/d/1Lzy94UNzdSXkqZCvrwjkcChKpU8u2waDqGx_Sjy5eJ8/edit#slide=id.g22ccd21963_2_0


Per Bryan's Q re Terraform, it would also be good to hear about BOSH &
Infrakit feature comparison.  And other related tech you see in the
space.




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




--
Zachary Smith, CEO of Packet

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


--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

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



Re: Infrakit Questions

Rob Hirschfeld
 

Solomon,

Sorry for the delay - ToC meeting tomorrow reminded me that this was pending....

The Docker team has done a good job answering questions.  My point is that this area has a lot of churn right now and the scope of LinuxKit is huge and evolving.  Since it's very pluggable, it appears to be a "do anything."

My expectation would be that narrowly defined components would be faster to bring into CNCF and something with a large scope would move slower.   I'd have similar reservations about Digital Rebar in it's integrated form which is why I offered to demo it.

Note: I do agree that LinuxKit and our Digital Rebar efforts are collaborative. especially on the metal provision side. 

Rob


On Tue, Jun 27, 2017 at 1:27 PM Solomon Hykes <solomon.hykes@...> wrote:
Rob, Zach, to clarify: do you have specific concerns about InfraKit that we should ask Dave to address?

My understanding is that 1) InfraKit is OS-agnostic and does not require LinuxKit 2) InfraKit does not impose an immutable operating system pattern.


Rob, you suggest more review: specifically what should we review? I think we should aim to get to "yes" or "no" in a timely fashion.

On Tue, Jun 27, 2017 at 10:32 AM, Zachary Smith via cncf-toc <cncf-toc@...> wrote:
I'd agree with Rob here.  LinuxKit is certain a component, but I think that the full hardware and network lifecycle associated with booting "all the things" is a pretty broad and messy space right now, particularly across private datacenters vs public clouds.

-Zac

On Tue, Jun 27, 2017 at 11:27 AM, Rob Hirschfeld via cncf-toc <cncf-toc@...> wrote:
Responding to request from TOC meeting last week...

I think that Day 1 and Day 2 provisioning is key area for CNCF to cover; however, I think that the space is transforming in several different ways so I would suggest more review by the TOC.  Obviously, I have an interest in this since I'm a lead on Digital Rebar.  For that reason, I'm reluctant to push against or pull for related projects.

For LinuxKit specifically, I think the emphasis on immutable operating systems should be considered carefully.  There are many benefits to this approach but they cannot be applied generally to legacy workloads and management tooling.  I believe that operational adoption is accelerated when tooling fits well with both new and existing ops models.

Again - I'm happy to show how we solve this problem with Digital Rebar at a TOC.  It's not just about physical provisioning - managing server life-cycle in multiple infastructures is a key design requirement.  Tooling that does not address the full life-cycle may actually make management harder over time.

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:56 AM, Alex Baretto <axbaretto@...> wrote:
+1 to Alexis and Rob.

I'd really like to see a good breakdown comparison between Infrakit and digital rebar, bosh, cloudformation, fog,and others

Alex Baretto



On Tue, Jun 06, 2017 at 08:51 Rob Hirschfeld via cncf-toc <Rob Hirschfeld via cncf-toc > wrote:
All,

I'd be happy to present / demo Digital Rebar to provide another cloud native perspective on how to address hybrid infrastructure automation.  I believe that would help provide a helpful perspective on operational concerns and how to address them in a way that fits the CNCF community.  As you know, we've been heavily involved in the Kubernetes community and have been showing an approach that uses the community Ansible for Kubernetes.  We've also done demos also showing LinuxKit integration.

Rob

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


Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO/Founder (rob@...)

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle

On Tue, Jun 6, 2017 at 8:41 AM, Alexis Richardson <alexis@...> wrote:
Thanks David, Patrick et al., for Infrakit pres today!

https://docs.google.com/presentation/d/1Lzy94UNzdSXkqZCvrwjkcChKpU8u2waDqGx_Sjy5eJ8/edit#slide=id.g22ccd21963_2_0


Per Bryan's Q re Terraform, it would also be good to hear about BOSH &
Infrakit feature comparison.  And other related tech you see in the
space.




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




--
Zachary Smith, CEO of Packet

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


--
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522


Re: Notary/TuF & GPG (& Harbor)

Justin Cappos
 

I own the repo (and just made that clearer in the authors / readme).  Thanks for pointing that out!

Justin

On Mon, Jul 10, 2017 at 10:20 PM, David Lawrence <david.lawrence@...> wrote:
Hi Brian,

Justin Cappos CC'd will have to answer on the precise ownership of the tuf repo. Answers to the other questions follow:

  • What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
    • Content (images) is considered to have a canonical name independent of where it is stored. Notary servers will happily service any names for which they are configured (generally this means they will service any name the requesting user can get a JWT for from the appropriate authorizing server for which notary holds a public cert). Containerd has been working recently to support this same model. A given notary server will serve consistent data for a given name, and one notary server can be used to service many image repositories. A key thing to note is that the name of the content must be consistent, this is because that name is included in the notary repository. This reduces the chance that notary data can be misused in the case that a key is reused across multiple repos. I'm happy to go in to more depth if that's interesting, it's just a long, complex explanation, and this is already a relatively verbose answer.
  • Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
    • Absolutely, this is one of the things the docker security team has been pushing in our secure software supply chain talks over the last year+
  • The main benefit compared to just signing an image digest is revocation?
    • Other significant benefits I would count as equal to revocation: freshness, delegation to alternate signers, painless key compromise recovery in many situations (this one I would put higher than revocation as a benefit).
  • Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
    • Not explicitly, it would be very short. TUF is a description of a minimal data structure and update process, Notary is a Golang implementation of that, and DCT is an integration of Notary in to docker (with some opinions on delegation priority and which keys are online vs offline)
If more explanation is needed I'm happy to provide it, or if I missed the mark on any of the answers, let me know.

Thanks,

David

On Mon, Jul 10, 2017 at 6:54 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote:
Follow-up questions on Notary:
  • What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
  • Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
  • The main benefit compared to just signing an image digest is revocation?
  • Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
  • Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
Thanks.

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




Re: Notary/TuF & GPG (& Harbor)

David Lawrence <david.lawrence@...>
 

Hi Brian,

Justin Cappos CC'd will have to answer on the precise ownership of the tuf repo. Answers to the other questions follow:

  • What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
    • Content (images) is considered to have a canonical name independent of where it is stored. Notary servers will happily service any names for which they are configured (generally this means they will service any name the requesting user can get a JWT for from the appropriate authorizing server for which notary holds a public cert). Containerd has been working recently to support this same model. A given notary server will serve consistent data for a given name, and one notary server can be used to service many image repositories. A key thing to note is that the name of the content must be consistent, this is because that name is included in the notary repository. This reduces the chance that notary data can be misused in the case that a key is reused across multiple repos. I'm happy to go in to more depth if that's interesting, it's just a long, complex explanation, and this is already a relatively verbose answer.
  • Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
    • Absolutely, this is one of the things the docker security team has been pushing in our secure software supply chain talks over the last year+
  • The main benefit compared to just signing an image digest is revocation?
    • Other significant benefits I would count as equal to revocation: freshness, delegation to alternate signers, painless key compromise recovery in many situations (this one I would put higher than revocation as a benefit).
  • Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
    • Not explicitly, it would be very short. TUF is a description of a minimal data structure and update process, Notary is a Golang implementation of that, and DCT is an integration of Notary in to docker (with some opinions on delegation priority and which keys are online vs offline)
If more explanation is needed I'm happy to provide it, or if I missed the mark on any of the answers, let me know.

Thanks,

David

On Mon, Jul 10, 2017 at 6:54 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote:
Follow-up questions on Notary:
  • What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
  • Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
  • The main benefit compared to just signing an image digest is revocation?
  • Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
  • Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
Thanks.

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



Re: Notary/TuF & GPG (& Harbor)

Brian Grant
 

Follow-up questions on Notary:
  • What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository? 
  • Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
  • The main benefit compared to just signing an image digest is revocation?
  • Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
  • Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
Thanks.


FYI: Intro to Kubernetes course via edX.org

Chris Aniszczyk
 

Today, CNCF announced the availability of our new Intro to Kubernetes course. You can read more about the new course here: https://www.linuxfoundation.org/announcements/linux-foundation-cncf-and-edxorg-announce-new-free-intro-to-kubernetes-course

This free course is open for immediate enrollment at: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x


Thanks!

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

6121 - 6140 of 7167