Thank you to everyone who came and participate in the in-person work time at the Vancouver Summit. It was great for people to be able to meet—many for the first time—and the in-person time always helps move things forward a little quicker and build those relationships that we can take home. So thank you!

For those of you who couldn’t attend, I’ve summarized the major take aways below. Notes were taken on this etherpad[1] throughout the week.

1.0 Release
1.0 Post Mortem
Release Cadence
Exploring Zuul CI
Security Collateral/Team
9Pfs
Working Committee updates

The in-person time we had in Vancouver is very similar to what we would have in Denver in September at the PTG[2]. I’d like to encourage folks to put that on their calendar so we can have more of these conversations.

It’s out! The release was well received by people attending, on social, in the press. People are very excited about this project and to see where we go.

Overall the first release went well, especially considering that we were all coming together for the first time. Biggest areas for improvement:

1. Documentation: We were rushed to update and review our docs at the end of the release cycle, rather than documenting as we went along. Documentation needs to be a priority, potentially to the point of gating PRs if there’s not documentation, so we don’t find ourselves in the docs crunch again.

2. Feature prioritization agreement: We were using ‘release-gating’, ‘p1’, ‘p2’, etc, but without having agreement about how those were assigned and that those tagged features were the top features, or conversely not following the tags and prioritizing other features that were not critical. Before we dig too much into the 1.1+ work, we need to collectively prioritize and tag features so there’s understanding about what we need to be working on.

3. Maintainer audit: We need to audit who the current maintainer are for each repo, make sure that’s an active list, and make sure our owner files are discoverable. We also need to identify and add more SMEs to the repos.

4. CI system: Our CI system is getting a bit too slow for moving things quickly as we grow. We need to see about running jobs in parallel

We agreed that long term, we need to be a time-based release, but we seem to be at a temporary impasse where 1) there are a small handful of nearly-done features that did not make it into 1.0 that might be done very soon 2) we don’t have a good sense of what an appropriate time metric is for us yet.

The proposal we arrived at is to temporarily be a feature-based release, decided by the Architecture Committee, to move some of these nearly-done items out the door quickly, but transition to a time-based release in the near future once it becomes more obvious what a reasonable release cadence might look like for us (the transition time to be decided by the Architecture Committee). This proposal could definitely use some input from others who have gotten open source projects off the ground :)

This was an item tabled from February until we met up at the Summit. Funnily enough, the job dependency bug that cropped up during the Summit is exactly what Zuul solves, so it was perfect timing to chat. The big benefits (for us) of Zuul are that 1) Zuul can run sequenced repos gated together 2) It’s a service we wouldn’t have to run ourselves, including the security patches etc that we’re responsible for right now in Jenkins. It gives us a CI system with less work for us!

The Zuul team is going to start with the proxy repo to give us a feel of Zuul. They’ll have an Azure driver in the near future (and we agreed to lend some of our credits for testing that), but for now we’ll run it on Vexxhost to demo it.

There’s lots of excitement around Kata, but one thing that’s missing is security collateral that people can take to their teams to show that Kata takes security seriously. These are things like data flows, threat models, pen testing, and a dedicated security group within our community to show that we take security seriously. To get this going, I’m hoping our supporting companies can pitch in security team time and resources to help build these items out collectively. Drop us a note if this is you or your org can help—we have potential users standing on the sidelines waiting for this and I think it’s a critical piece of our project’s growth.

We talked about this one extensively; it’s a big one! 9P is a limitation for some distros, and might hit performance issues in the future. There’s lots of comments in the etherpad, but what will help drive this forward is better understanding the storage needs of Kata users/potential users. This will help give direction for where “life beyond 9P” should go. If this is you, you can post a note on the ML with your use case and share some insight.

The Working Committee (marketing, advocacy, community committee) also met in Vancouver. Reflecting on 1.0 reception, we need to be producing content in two categories: 1) Deep dives on Kata—demos, technical details 2) General information on containers security and “why Kata”. On the later, there’s still not enough education out there about the security profile of containers and why a solution like Kata is needed, or what it can help.

Conference season is also upon us, and there’s no reason Kata shouldn’t be everywhere! In the WC meeting today, we started this etherpad[4] to keep track of what conferences people intend to submit to. Please add where you are submitting your Kata talks!