|
Re: CDF Working Groups Proposal
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
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
|
|
|
Kubernetes Metric Tracking - Spartakus
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.
They are OSS or coporate solutions,...
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.
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
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.
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: 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.
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
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?
toggle quoted messageShow quoted text
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.
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.
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.
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.
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...
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.
--
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
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.
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.
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.
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.
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...
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.
--
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
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.
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.
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.
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.
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...
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.
--
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
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.
toggle quoted messageShow quoted text
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.
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.
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.
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...
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.
--
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:
Being as I helped with this governance model, I am happy to answer any practical questions.
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.
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.
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...
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.
--
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
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.
toggle quoted messageShow quoted text
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.
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.
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...
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.
--
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:
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.
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...
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.
--
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
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...
:)
--
Tara Hernandez Engineering Manager Google Cloud
|
|
|
Re: Metric Collection for CDF Projects
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
|
|
|
