Date   

Re: CDF Working Groups Proposal

Dan Lorenc <dlorenc@...>
 

Hey All,

I've made the requested followup edits to the WGs proposal to include SIGs. Please take a look and leave feedback before our next TOC meeting here:

Dan Lorenc

On Wed, Jun 19, 2019 at 1:48 AM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:
Yeah, let's fork this topic, and would love to nerd out on this!

On Tue, Jun 18, 2019 at 6:27 AM Andrew Phillips via Lists.Cd.Foundation <anph+cdf=google.com@...> wrote:
> "Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).

For deployment, would it make sense to initially focus on the domain model (i.e. what information a deployment task would need as input, what it might produce as output, and other concepts, e.g. a notion of environments, that might be required) rather than the actual implementation of deployment tasks themselves?

Happy to fork this off into a separate discussion as it seems tangential to this thread...

Regards

ap



--
Tara Hernandez
Engineering Manager Google Cloud




Re: Kubernetes Metric Tracking - Spartakus

Kohsuke Kawaguchi
 

Thanks! I took a quick look.

Some of the code is reusable. For example, the server side code that receives data submission and pushes the data into BigQuery. There's some hard coding of schema that needs tweaking, but really the whole thing is small enough forking is probably the fastest way to go.

I couldn't find any reference to the operational practice. The privacy policy, who gets access, how they anonymize/summarize data, etc. That's probably what we need to find out.

On Wed, Jun 19, 2019 at 9:29 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
This was the anonymous, opt-in usage collector I was referring to in yesterday's TOC meeting:

Dan Lorenc



--
Kohsuke Kawaguchi


Kubernetes Metric Tracking - Spartakus

Dan Lorenc <dlorenc@...>
 

This was the anonymous, opt-in usage collector I was referring to in yesterday's TOC meeting:

Dan Lorenc


Re: Metric Collection for CDF Projects

Olivier Vernin
 

Hi,

My two cents and sorry to be late in this discussion

Do we already have an idea of what we are looking for?
Which questions do we want to answer?

Today they are a **lot** of different ways to collect data and interpret them and some of them are more expensive than others.

Let answer this simple question:       
  "How many time that specific plugin was installed"
  => We can look at the access logs of the service responsible to provide plugins (External Data)
  => We can modify the application in order to send specific payload each time a user push the butoon 'Install that plugin'                              

In both cases, we'll know how many time we installed a specific plugin, but we can use internal or external data.
Depending on the project they don't required the same amount of work and they don't have same extensibility.

The way I understand this thread, we are looking for a standard way to collect data from cdf application themselves.

Either with generic tools and it sounds a bit like the opentracing/opencensus/opentelemetry project mission.
You can have a look to different tracer on the opentracing website https://opentracing.io/docs/supported-tracers/
They are OSS or coporate solutions,...

Or we build a custom application like Tyler did for Jenkins https://github.com/jenkinsci/jep/blob/master/jep/214/README.adoc
Depending on how flexible are the questions that we want to answer, this is maybe the only approach we have, but it will probably be less generic and more expensive.
Personally I would go down that path in last resort and unless we really know what we need.

I think the best starting point would be
* Collect all questions that the different CDF project would like to answer
* Identify patterns across projects
* Identify which kind of data we can use
* Clarify how reliable those datas are.
* Align with an approach

For those who doesn't know about it yet, there is a nice OSS initiative about OSS community metrics https://github.com/chaoss/metrics and it could be interesting to have a similar thing about generic metrics that we can collect from application and how we interpret them.

Cheers

Olivier

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---


On Tue, Jun 18, 2019, at 6:54 PM, Kohsuke Kawaguchi wrote:

On Tue, Jun 18, 2019 at 6:29 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
My suggestion is more on the order of "I don't want us to have to manage and keep this monitoring thing running." Our efforts are best spent on the CD projects themselves, not necessarily building out infrastructure to support metrics gathering.

+1. I've seen the (invisible) cost of keeping something up and running and maintained. IMHO it's better to consume those as services from someone else, effectively trading money with the effort.

Like I said, though, I'm not opposed to building something from scratch, but I want it to be a deliberate decision to do so.

On Tue, Jun 18, 2019 at 8:38 AM Sean McGinnis <sean.mcginnis@...> wrote:
I'll be "that guy", but I do hope that as we work on building open communities for open source software that we try to avoid using commercial offerings like Datadog if there are open source options out there that will at least meet most of the requirements. In may very well be the case that there are not, but I personally think it's worth the effort to try to make something work first before making the decision to use a commercial product or service.

Sean

On Tue, Jun 18, 2019 at 7:20 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
> is this email more of the "is there anything that we can reuse?" inquiry?

It's a bit of both. I'm not against gathering requirements and implementing something from scratch, but at the same time, I'd probably opt for using a "good enough" service from say Datadog or other hosted solution. I've never worked with the LF so I don't know what other organizational constraints and/or budget we're working with. Happy to explore this path if someone could point me in the right direction.

We can chat in more detail at the TOC today.

Travis

On Mon, Jun 17, 2019 at 6:53 PM Kohsuke Kawaguchi <kk@...> wrote:
OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?





--
Kohsuke Kawaguchi


Re: CDF Working Groups Proposal

Tara Hernandez
 

Yeah, let's fork this topic, and would love to nerd out on this!


On Tue, Jun 18, 2019 at 6:27 AM Andrew Phillips via Lists.Cd.Foundation <anph+cdf=google.com@...> wrote:
> "Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).

For deployment, would it make sense to initially focus on the domain model (i.e. what information a deployment task would need as input, what it might produce as output, and other concepts, e.g. a notion of environments, that might be required) rather than the actual implementation of deployment tasks themselves?

Happy to fork this off into a separate discussion as it seems tangential to this thread...

Regards

ap



--
Tara Hernandez
Engineering Manager Google Cloud




Re: Metric Collection for CDF Projects

Kohsuke Kawaguchi
 


On Tue, Jun 18, 2019 at 6:29 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
My suggestion is more on the order of "I don't want us to have to manage and keep this monitoring thing running." Our efforts are best spent on the CD projects themselves, not necessarily building out infrastructure to support metrics gathering.

+1. I've seen the (invisible) cost of keeping something up and running and maintained. IMHO it's better to consume those as services from someone else, effectively trading money with the effort.

Like I said, though, I'm not opposed to building something from scratch, but I want it to be a deliberate decision to do so.

On Tue, Jun 18, 2019 at 8:38 AM Sean McGinnis <sean.mcginnis@...> wrote:
I'll be "that guy", but I do hope that as we work on building open communities for open source software that we try to avoid using commercial offerings like Datadog if there are open source options out there that will at least meet most of the requirements. In may very well be the case that there are not, but I personally think it's worth the effort to try to make something work first before making the decision to use a commercial product or service.

Sean

On Tue, Jun 18, 2019 at 7:20 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
> is this email more of the "is there anything that we can reuse?" inquiry?

It's a bit of both. I'm not against gathering requirements and implementing something from scratch, but at the same time, I'd probably opt for using a "good enough" service from say Datadog or other hosted solution. I've never worked with the LF so I don't know what other organizational constraints and/or budget we're working with. Happy to explore this path if someone could point me in the right direction.

We can chat in more detail at the TOC today.

Travis

On Mon, Jun 17, 2019 at 6:53 PM Kohsuke Kawaguchi <kk@...> wrote:
OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?



--
Kohsuke Kawaguchi


TOC meeting today

Kohsuke Kawaguchi
 

Today is our TOC regular TOC meeting. 1.5 hours from now to be exact:

https://zoom.us/my/cdf.toc


--
Kohsuke Kawaguchi


Re: Metric Collection for CDF Projects

Travis Tomsu <ttomsu@...>
 

My suggestion is more on the order of "I don't want us to have to manage and keep this monitoring thing running." Our efforts are best spent on the CD projects themselves, not necessarily building out infrastructure to support metrics gathering.

Like I said, though, I'm not opposed to building something from scratch, but I want it to be a deliberate decision to do so.

On Tue, Jun 18, 2019 at 8:38 AM Sean McGinnis <sean.mcginnis@...> wrote:
I'll be "that guy", but I do hope that as we work on building open communities for open source software that we try to avoid using commercial offerings like Datadog if there are open source options out there that will at least meet most of the requirements. In may very well be the case that there are not, but I personally think it's worth the effort to try to make something work first before making the decision to use a commercial product or service.

Sean

On Tue, Jun 18, 2019 at 7:20 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
> is this email more of the "is there anything that we can reuse?" inquiry?

It's a bit of both. I'm not against gathering requirements and implementing something from scratch, but at the same time, I'd probably opt for using a "good enough" service from say Datadog or other hosted solution. I've never worked with the LF so I don't know what other organizational constraints and/or budget we're working with. Happy to explore this path if someone could point me in the right direction.

We can chat in more detail at the TOC today.

Travis

On Mon, Jun 17, 2019 at 6:53 PM Kohsuke Kawaguchi <kk@...> wrote:
OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?

_._,_._,_

--
You received this message because you are subscribed to the Google Groups "toc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to toc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/spinnaker.io/d/msgid/toc/CALvgmaR1Hta7TjhpyPoC70zU%2BZ3q9C7u7mSFwSfxid8CtjcBow%40mail.gmail.com.


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258


Re: CDF Working Groups Proposal

Andrew Phillips <anph+cdf@...>
 

> "Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).

For deployment, would it make sense to initially focus on the domain model (i.e. what information a deployment task would need as input, what it might produce as output, and other concepts, e.g. a notion of environments, that might be required) rather than the actual implementation of deployment tasks themselves?

Happy to fork this off into a separate discussion as it seems tangential to this thread...

Regards

ap


Re: Metric Collection for CDF Projects

Sean McGinnis <sean.mcginnis@...>
 

I'll be "that guy", but I do hope that as we work on building open communities for open source software that we try to avoid using commercial offerings like Datadog if there are open source options out there that will at least meet most of the requirements. In may very well be the case that there are not, but I personally think it's worth the effort to try to make something work first before making the decision to use a commercial product or service.

Sean

On Tue, Jun 18, 2019 at 7:20 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
> is this email more of the "is there anything that we can reuse?" inquiry?

It's a bit of both. I'm not against gathering requirements and implementing something from scratch, but at the same time, I'd probably opt for using a "good enough" service from say Datadog or other hosted solution. I've never worked with the LF so I don't know what other organizational constraints and/or budget we're working with. Happy to explore this path if someone could point me in the right direction.

We can chat in more detail at the TOC today.

Travis

On Mon, Jun 17, 2019 at 6:53 PM Kohsuke Kawaguchi <kk@...> wrote:
OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?

_._,_._,_


Re: Metric Collection for CDF Projects

Travis Tomsu <ttomsu@...>
 

> is this email more of the "is there anything that we can reuse?" inquiry?

It's a bit of both. I'm not against gathering requirements and implementing something from scratch, but at the same time, I'd probably opt for using a "good enough" service from say Datadog or other hosted solution. I've never worked with the LF so I don't know what other organizational constraints and/or budget we're working with. Happy to explore this path if someone could point me in the right direction.

We can chat in more detail at the TOC today.

Travis

On Mon, Jun 17, 2019 at 6:53 PM Kohsuke Kawaguchi <kk@...> wrote:
OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?


On Tue, Jun 11, 2019 at 8:52 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for starting this discussion Travis. I added it to the agenda for next week, Tuesday the 18th.

Dan Lorenc

On Tue, Jun 11, 2019 at 7:39 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
Friendly ping... Any thoughts or opinions on this? 

Would it be a bad idea to add this to the next TOC agenda?

Travis

On Wed, Jun 5, 2019 at 1:48 PM Travis Tomsu <ttomsu@...> wrote:
Hi CDF & Spinnaker governance committees,

I'd like to kickstart the conversation about how we track project-level metrics across the CDF. Specifically, I'm interested in instrumenting Spinnaker (and/or Spinnaker's lifecycle helper Halyard) with something that will report high-level usage.

This is very likely to be a problem for all projects, so I'm curious about how the LF has handled this in the past.

At Google, engineering teams would be subject to a privacy review of all data collected, if/how it is anonymized, and the opt-in/out mechanism. Since the CDF owns these projects, I don't think Google's internal process applies here, so... how should we go about this?

The Spinnaker Steering Committee has talked about this in the past, and aside from establishing some baseline requirements (i.e. transparency in what is collected, easy opt-out, don't rely on vendors to anonymize the data), I don't think any other action has been taken.

Travis

P.S. Thanks to Tyler for his blog post on Jenkins stat collection for reference.


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258



--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "toc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to toc+unsubscribe@....
To view this discussion on the web visit https://groups.google.com/a/spinnaker.io/d/msgid/toc/CAN4CQ4w6zOiE-BLYeTyTv8DOGqyaqRWN9PG8X7Hz%2BpDMdZsNqQ%40mail.gmail.com.


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258


Re: CDF Working Groups Proposal

Kay Williams <kayw@...>
 

Agree, thanks Dan (and Kohsuke).

 

Let me give a concrete example for a Supply Chain Security SIG. This is something Microsoft and GitHub are willing to dedicate resources to and help drive (in collaboration with others). We would like very much to work with a community like the CDF. This is not a Microsoft or GitHub issue alone. And while we are beginning to invest significant resources in this area, we do not want to do it alone. Others are investing as well. We want to join our collective effort and go farther, faster. This is an industry issue. We believe it will take collaboration across many partners and all aspects of the CD process.

 

Objective:

Ensure security (including policy and validation) for software artifacts at each stage of the supply chain from component developer, through package repositories, to application development to end customer runtime operation.

 

 

What the group hopes to gain from the CDF:

Security is an industry wide concern. It spans all aspects of Continuous Delivery tooling from SCM through CI/CD. Given this, it would seem a natural fit with the CDF charter – ‘A Neutral Home for the Next Generation of Continuous Delivery Collaboration’.

 

How would the group like to meet/operate:

For this topic, it makes sense for a group to meet and operate with a long term charter (like a CNCF SIG), with short term (e.g. 6 month) milestones to make progress.

 

Anything else to add:

Working groups could make sense as a construct for defining the short term milestones, but short term milestones could also be left up to the SIG to define.

 

Hope this helps.

 

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Kohsuke Kawaguchi via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 5:12 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

Thanks Dan for doing this, and seeing the difference in what WGs and SIGs mean for different groups is fascinating! One of WGs that I've been more familiar with is W3C WG, which is different still from those mentioned in here. I'm also close to how the Jenkins project uses SIG and "team."

 

I think it's useful to step back and think about what problems we are trying to solve. I'm not sure if we have an alignment on that.

 

Dan's document says his WG proposal is for "a temporary group of collaborators focused on completing a defined task." Looking at the lifecycle, maybe it's for the CDF to delegate a certain task to a smaller circle of people who will have easier time doing it (e.g., CDF summit organization), or maybe it's to help people who want to drive certain initiatives by giving them the visibility, the authority, and other necessary support (e.g., usage metrics collection.) Or maybe something else.

 

FWIW, the problem I see that is worth solving now is to give visibility to technology efforts that are happening on the ground. Take Tekton & Jenkins X collaboration for example. I've heard that there are good things happening there, but I don't know where that is happening. I'm lucky in that I know who are involved, but I'm pretty sure people who are not close to the center have little idea that this is happening, or where they can participate. That translates to missed opportunities for more contributors, more encouragement to existing contributors, and more bragging opportunities of good things that are coming out of the CDF. I think the TOC has a vested interest in propping this up and support good stuff that's already happening.

 

The other problem I see that is worth solving is a facilitation for people of similar interest to find each other. In a large loosely connected community, people who have a passion to a certain aspect has hard time finding other likeminded people, and they won't get a place to engage themselves. I've seen this a lot in the Jenkins project. When you have a place for likeminded people to talk to each other, sometimes interesting projects/initiatives/efforts come out of it. Just today at the GB meeting, we were talking about the interest of end user companies to get together to compare notes and learn from each other. I won't be surprised if an ongoing conversation like that identifies the opportunities for them to join hands to solve a common problem.

 

What are the problems people are seeing that are worth solving now?

 

 

On Mon, Jun 17, 2019 at 4:41 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Chris.  It sounds like the CNCF model is a better fit (at the foundation level).

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Chris Aniszczyk via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

Here's a doc outlining the difference between CNCF/k8s SIGs, really mostly about code ownership:

 

 

They serve different purposes and CNCF SIGs were mostly created to help scale the CNCF TOC with project reviews and also provide an area to focus.

 

On Mon, Jun 17, 2019 at 7:27 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

image.png

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


 

--

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


 

--

Kohsuke Kawaguchi


Re: CDF Working Groups Proposal

Kohsuke Kawaguchi
 

Thanks Dan for doing this, and seeing the difference in what WGs and SIGs mean for different groups is fascinating! One of WGs that I've been more familiar with is W3C WG, which is different still from those mentioned in here. I'm also close to how the Jenkins project uses SIG and "team."

I think it's useful to step back and think about what problems we are trying to solve. I'm not sure if we have an alignment on that.

Dan's document says his WG proposal is for "a temporary group of collaborators focused on completing a defined task." Looking at the lifecycle, maybe it's for the CDF to delegate a certain task to a smaller circle of people who will have easier time doing it (e.g., CDF summit organization), or maybe it's to help people who want to drive certain initiatives by giving them the visibility, the authority, and other necessary support (e.g., usage metrics collection.) Or maybe something else.

FWIW, the problem I see that is worth solving now is to give visibility to technology efforts that are happening on the ground. Take Tekton & Jenkins X collaboration for example. I've heard that there are good things happening there, but I don't know where that is happening. I'm lucky in that I know who are involved, but I'm pretty sure people who are not close to the center have little idea that this is happening, or where they can participate. That translates to missed opportunities for more contributors, more encouragement to existing contributors, and more bragging opportunities of good things that are coming out of the CDF. I think the TOC has a vested interest in propping this up and support good stuff that's already happening.

The other problem I see that is worth solving is a facilitation for people of similar interest to find each other. In a large loosely connected community, people who have a passion to a certain aspect has hard time finding other likeminded people, and they won't get a place to engage themselves. I've seen this a lot in the Jenkins project. When you have a place for likeminded people to talk to each other, sometimes interesting projects/initiatives/efforts come out of it. Just today at the GB meeting, we were talking about the interest of end user companies to get together to compare notes and learn from each other. I won't be surprised if an ongoing conversation like that identifies the opportunities for them to join hands to solve a common problem.

What are the problems people are seeing that are worth solving now?


On Mon, Jun 17, 2019 at 4:41 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Chris.  It sounds like the CNCF model is a better fit (at the foundation level).

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Chris Aniszczyk via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

Here's a doc outlining the difference between CNCF/k8s SIGs, really mostly about code ownership:

 

 

They serve different purposes and CNCF SIGs were mostly created to help scale the CNCF TOC with project reviews and also provide an area to focus.

 

On Mon, Jun 17, 2019 at 7:27 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

image.png

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


 

--

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



--
Kohsuke Kawaguchi


Re: CDF Working Groups Proposal

Dan Lorenc <dlorenc@...>
 

My general hesitation on wholesale copying cncf sigs is that there are relatively few of them so I have had much of a chance to observe them in action.

Kubernetes sigs have a much clearer role (at least in my head), but that model doesn't really fit things at the foundation level where there isn't a concrete codebase to own.

Putting naming and taxonomies aside, I think it would be very helpful for me if anyone interested in forming some kind of group could explain some of the following:

What the group's objective is?
What the group hopes to gain from the CDF.
How the group would like to meet/operate.
Anything else you think is important.

I wrote this proposal with a few concrete ideas in mind, but I think we could improve it with more examples to work off of and think through.

Dan Lorenc

On Mon, Jun 17, 2019, 6:41 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Chris.  It sounds like the CNCF model is a better fit (at the foundation level).

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Chris Aniszczyk via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

Here's a doc outlining the difference between CNCF/k8s SIGs, really mostly about code ownership:

 

 

They serve different purposes and CNCF SIGs were mostly created to help scale the CNCF TOC with project reviews and also provide an area to focus.

 

On Mon, Jun 17, 2019 at 7:27 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


 

--

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


Re: CDF Working Groups Proposal

Kay Williams <kayw@...>
 

Thanks Chris.  It sounds like the CNCF model is a better fit (at the foundation level).

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Chris Aniszczyk via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

Here's a doc outlining the difference between CNCF/k8s SIGs, really mostly about code ownership:

 

 

They serve different purposes and CNCF SIGs were mostly created to help scale the CNCF TOC with project reviews and also provide an area to focus.

 

On Mon, Jun 17, 2019 at 7:27 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

image.png

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


 

--

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


Re: CDF Working Groups Proposal

Chris Aniszczyk
 

Here's a doc outlining the difference between CNCF/k8s SIGs, really mostly about code ownership:


They serve different purposes and CNCF SIGs were mostly created to help scale the CNCF TOC with project reviews and also provide an area to focus.

On Mon, Jun 17, 2019 at 7:27 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

image.png

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103



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


Re: CDF Working Groups Proposal

Kay Williams <kayw@...>
 

Thanks Jaice for sharing.

 

At first blush the Kubernetes (project) model seems more complex than the CNCF (foundation) model.  Do you happen to have a comparison of the two? Can we get away with a simpler model at the foundation level? What are the factors to consider?

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Jaice Singer DuMars via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 4:14 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

 

image.png

 

Being as I helped with this governance model, I am happy to answer any practical questions.

 

All the best,

Jaice

 

 

On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:

Kay: Gotcha, thanks for the clarification 

 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.

 

 

On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 


 

--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


Re: CDF Working Groups Proposal

Jaice Singer DuMars <jaice@...>
 

This is how Kubernetes does governance. I created this graphic some time ago to help make it easier to understand:

image.png

Being as I helped with this governance model, I am happy to answer any practical questions.

All the best,
Jaice


On Mon, Jun 17, 2019 at 2:14 PM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:
Kay: Gotcha, thanks for the clarification 

So, if I'm understanding it correctly the diff between working groups (shorter term, finer granularity efforts) and SIGs (longer term, broader standards work) seems like a good breakdown.


On Mon, Jun 17, 2019 at 12:56 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

It may not be too much more to bite off?  The CNCF SIG model feels well thought out. Perhaps we can adopt it with little more than a search/replace from CNCF -> CDF.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:31 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

I broadly agree with the "two-tier" model and should have made that more clear in my proposal. k8s (and more recently the CNCF) splits these up into "working groups" and "special interest groups", with the latter being the longer-running version. I didn't try to bite off both of these at the same time, but maybe we should.

 

Dan Lorenc

 

On Mon, Jun 17, 2019 at 2:25 PM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

I am not sure if we want/need to define all the top-level items for now.  I just threw out some items as possible examples.  The larger question is the two-tier structure.

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Tara Hernandez via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 12:21 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] CDF Working Groups Proposal

 

"Deployment" is pretty broad, I worry that such a group would be working with a LOT of conditionals, e.g. on-prem vs cloud, service vs. serverless, maybe even baremetal vs. VM/Container (sadly probably still pretty common).  On the other hand, this is also probably one of the hotter topic areas as far as engaging with enterprise/corp devs.

 

So... perhaps start with some prelim scoping discussions?

 

:)

 

This other 'top tier' categories seem good to me...

 

On Mon, Jun 17, 2019 at 10:59 AM Kay Williams via Lists.Cd.Foundation <kayw=microsoft.com@...> wrote:

What would folks think about following a two tiered model?

 

Top-Tier

The top tier would be a more formal, long-running structure along logical, functional areas of need.  This would be similar to CNCF SIGs or OCP Projects.

 

CNCF - SIGs

OCP - Projects

 

For the CD Foundation, example top-tier items might include the following:

  • Supply Chain Security
  • Pipelines
  • Validation
  • Deployment

 

Second-Tier

The second tier would be a shorter-term structure with specific goals, deliverables and timelines. I think of this as what Dan is defining below in the working group proposal.

 

In the case of Software Supply Chain security (a broad topic) I am imagining we might have shorter working groups (or sprints?) that are largely time-bound.

 

2019.2 deliverables (2nd half 2019)

2020.1 deliverables (1st half 2020)

2020.2 deliverables (2nd half 2020)

Etc.

 

Thoughts from others?

Kay

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Monday, June 17, 2019 8:42 AM
To: cdf-toc@...
Subject: [cdf-toc] CDF Working Groups Proposal

 

Hey All,

 

This topic has come up a few times since kicking off the CDF TOC, and I promised to put together a proposal on the lifecycle of working groups. I got a doc started here.

 

I'd appreciate any feedback on the doc, and hope to discuss tomorrow in the TOC meeting. If TOC members like the general direction, the next steps would be to iterate in this doc and then move this to a PR and vote.

 

Dan Lorenc


 

--

Tara Hernandez

Engineering Manager Google Cloud

 

 



--
Tara Hernandez
Engineering Manager Google Cloud





--

Jaice Singer DuMars

Cloud Native Strategy

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103


Re: How Jenkins project usage statistics work

Kohsuke Kawaguchi
 

Loved reading it! It's interesting how other people interpret my technical decisions!

Not that it matters really, but the main reason the communication went through user's browser was the ease of use -- so that people don't have to configure a proxy setting for Jenkins server. Setting a proxy configuration for JVM is painful, and explaining how to do so to people even more so, because as a Java web application there were many different servlet containers people were using. 

On Thu, May 23, 2019 at 8:06 AM Tara Hernandez via Lists.Cd.Foundation <tarahernandez=google.com@...> wrote:
I love the fact the bit about the basement.  The original Bugzilla and Tinderbox test instances sat in my garage for a couple of years before Mozilla.org finally go around to offering up some space in their racks...

:)

On Thu, May 23, 2019 at 7:39 AM R. Tyler Croy <rtyler@...> wrote:

I can finally check off this todo item! Below is the system description of how
Jenkisn project usage statistics are generated, stored, processed, and
published.

    https://brokenco.de/2019/05/23/jenkins-usage-stats.html



Suffice it to say, I think we can do something better in the future :)



--
GitHub:  https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2





--
Tara Hernandez
Engineering Manager Google Cloud





--
Kohsuke Kawaguchi


Re: Metric Collection for CDF Projects

Kohsuke Kawaguchi
 

OK,

So it sounds like the homework is to find a prior art inside the LF. I'll write a few emails to people I know.

I suspect the answer is that this hasn't been done before, and then we'd have to produce a system that does this, with some legal assistance from the LF (a privacy policy would be needed to describe that system, for example), and the CDF paying for the operating cost. When it gets real, I'm sure other sister foundations will be interested in it.

If things go that route, is there any interest from somebody within the Spinnaker project to gather the requirements and implement (or procure) a system? I'm pretty sure the Jenkins project would love to switch from our current system to it, and I can try to find some contributors who are interested.

Or is this email more of the "is there anything that we can reuse?" inquiry?


On Tue, Jun 11, 2019 at 8:52 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for starting this discussion Travis. I added it to the agenda for next week, Tuesday the 18th.

Dan Lorenc

On Tue, Jun 11, 2019 at 7:39 AM Travis Tomsu via Lists.Cd.Foundation <ttomsu=google.com@...> wrote:
Friendly ping... Any thoughts or opinions on this? 

Would it be a bad idea to add this to the next TOC agenda?

Travis

On Wed, Jun 5, 2019 at 1:48 PM Travis Tomsu <ttomsu@...> wrote:
Hi CDF & Spinnaker governance committees,

I'd like to kickstart the conversation about how we track project-level metrics across the CDF. Specifically, I'm interested in instrumenting Spinnaker (and/or Spinnaker's lifecycle helper Halyard) with something that will report high-level usage.

This is very likely to be a problem for all projects, so I'm curious about how the LF has handled this in the past.

At Google, engineering teams would be subject to a privacy review of all data collected, if/how it is anonymized, and the opt-in/out mechanism. Since the CDF owns these projects, I don't think Google's internal process applies here, so... how should we go about this?

The Spinnaker Steering Committee has talked about this in the past, and aside from establishing some baseline requirements (i.e. transparency in what is collected, easy opt-out, don't rely on vendors to anonymize the data), I don't think any other action has been taken.

Travis

P.S. Thanks to Tyler for his blog post on Jenkins stat collection for reference.


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258


--
Travis Tomsu | Software Engineer | ttomsu@... | 614-205-9258



--
Kohsuke Kawaguchi

721 - 740 of 867