Date   

[VOTE] Screwdriver.cd

Dan Lorenc <dlorenc@...>
 

The screwdriver.cd project has been formally proposed for inclusion in the CDF. The proposal information can be found here: https://github.com/cdfoundation/toc/pull/22

And the team's presentation to the TOC can be found here.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

Dan Lorenc


Security SIG Proposal

Kay Williams <kayw@...>
 

Hi all,

Here is the proposal we mentioned at this morning's TOC meeting. You can also find the document here.

https://docs.google.com/document/d/1QHD628FJ4s9lyWtPUtzdTr2fbmnhyuB_908cfsJzDqU/edit. Feel free to make comments in the document, or send an email if you have questions.

Kay

---------------------------------------------------------------------

CDF Security SIG Proposal

1. Overview
The Security SIG creates designs, specifications, shared code and processes to enable security across the software supply chain.

2. CDF TOC Sponsor willing to regularly monitor the SIG and ensure it remains useful and productive
Dan Lorenc

3. A proposed meeting schedule, with a sample agenda
Bi-weekly meetings.

Sample agenda:
. Review proposed modifications to SIG charter or working groups
. Summary presentations/discussions from existing working groups
. Plan for quarterly face-to-face meetings

4. Details on any outcomes, or deliverables

The SIG will deliver designs, specifications, shared code and processes that meet the following goals:
. Enable actions performed while writing code, compiling, testing, and distributing software to be manifest and verifiable.
. Enable consumers of software to specify and implement policy over consumed software.
. Enable administrators to inventory and audit software used within their organizations.
. Enable detection and prevention of software tampering at runtime.
. Provide mechanisms for breaches in the integrity of software to be communicated and remediated. 
. Provide mechanisms for consumers to recover from compromised or untrusted software.

5. A list of initial members, and a chair. There should be at least 3 different companies represented

Initial members:
. Microsoft
. Google
. TBD

Chair: Kay Williams, Microsoft

6. Any resources needed from the CDF to accomplish the task. This can include funding, marketing, technical expertise or other resources. Note that some types of resources may require allocation from the Governing Board.

Initial resources include support with meetings, mailing lists, and location for sharing SIG activities, documents and results.


Re: Regrets for tomorrow

Dan Lorenc <dlorenc@...>
 


On Mon, Jul 15, 2019, 12:55 PM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Happy to run the meeting. As a reminder, please add agenda items to the doc here: https://docs.google.com/document/d/13RdGmhYt0QKRziQ67G48vTs9gakLAfk4u_usADZNrSg/edit?ts=5d2ca898#

On Mon, Jul 15, 2019 at 10:57 AM Kohsuke Kawaguchi <kk@...> wrote:
Hi,

I will be travelling in Asia and I won't be able to make it to the TOC meeting tomorrow. I'm hoping Dan Lorenc will be present and run the meeting.

--
Kohsuke Kawaguchi


Re: Regrets for tomorrow

Dan Lorenc <dlorenc@...>
 

Happy to run the meeting. As a reminder, please add agenda items to the doc here: https://docs.google.com/document/d/13RdGmhYt0QKRziQ67G48vTs9gakLAfk4u_usADZNrSg/edit?ts=5d2ca898#


On Mon, Jul 15, 2019 at 10:57 AM Kohsuke Kawaguchi <kk@...> wrote:
Hi,

I will be travelling in Asia and I won't be able to make it to the TOC meeting tomorrow. I'm hoping Dan Lorenc will be present and run the meeting.

--
Kohsuke Kawaguchi


Regrets for tomorrow

Kohsuke Kawaguchi
 

Hi,

I will be travelling in Asia and I won't be able to make it to the TOC meeting tomorrow. I'm hoping Dan Lorenc will be present and run the meeting.

--
Kohsuke Kawaguchi


Re: CDF Working Groups Proposal

Dan Lorenc <dlorenc@...>
 

As a followup to our last discussion, I've transformed the original Google doc into markdown on Github and sent a PR with the proposal:

If you haven't taken a look yet, please do so now. I'm hoping we can discuss once more next week then call a vote.

Dan Lorenc

On Mon, Jun 24, 2019 at 1:38 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
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




TOC Meeting video recording now live on Youtube

Dan Lopez <dlopez@...>
 

Hello TOC 

The video from today's Screwdriver.cd presentation to the TOC is now live on Youtube. 

TOC Meeting 07.02.19

Best,

--
Dan Lopez
The Linux Foundation
+1 415.735.5881


Re: [cdf-gb] Screwdriver preso slides - Thank you!

Dan Lopez <dlopez@...>
 

Hi TOC

Here is the recording from today's presentation from the Screwdriver.cd team:


Best

--
Dan Lopez
The Linux Foundation
+1 415.735.5881




Re: CDF Working Groups Proposal

Kay Williams <kayw@...>
 

Hi everyone, I have created a draft proposal for a Security SIG. You can find the proposal at the link below.  I have also included it as a link in Dan’s Working Groups Proposal document. Comments are most welcome.

 

https://docs.google.com/document/d/1QHD628FJ4s9lyWtPUtzdTr2fbmnhyuB_908cfsJzDqU/edit?usp=sharing

 

From: cdf-toc@... <cdf-toc@...> On Behalf Of Dan Lorenc via Lists.Cd.Foundation
Sent: Sunday, June 23, 2019 11:38 PM
To: cdf-toc@...
Subject: Re: [cdf-toc] 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

 

 


Screwdriver preso slides - Thank you!

Dan Lopez <dlopez@...>
 

Hi TOC
From the Screwdriver.cd presentation today, slide deck attached

Best,
--
Dan Lopez
The Linux Foundation
+1 415.735.5881


---------- Forwarded message ---------
From: Rosalie <rosalie.bartlett@...>
Date: Tue, Jul 2, 2019 at 9:38 AM
Subject: Screwdriver preso slides - Thank you!
To: Dan Lopez <dlopez@...>


Thank you again!

Rosalie


TOC meeting tomorrow

Kohsuke Kawaguchi
 

Tomorrow 4pm GMT/9am PT is our TOC regular TOC meeting:

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


--
Kohsuke Kawaguchi


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

701 - 720 of 858