Open Stack

Hi Fabiano,

A lot of what Eric and Archana say resonate with me. Here are some
additional observations regarding the AC and the community in general.
Disclaimer: I have not been in a lot of open source projects, so it can be
because my expectations are just too high :)

1. Some of the key areas of the project are under-invested, such as
security, performance, stability and production readiness. First of all,
from what I have seen, our handling of security tickets lacks a bit of
seriousness and sense of urgency. Even though there is a documented
Vulnerability
Handling
<https://github.com/kata-containers/community#vulnerability-handling>
process, I'm not sure if it has been followed. This is kinda ironic
considering a lot of the users come to Kata for stronger security. Second,
there is no documented performance benchmarking procedure and data. There
are many ways to achieve better performance on Kata Containers but they're
not publicised. Last but not least, there is still a lot of room to improve
the stability and production readiness. We don't have test coverage for a
lot of critical path code. One example for lack of production readiness,
there still isn't a way to only get the agent error log out of the guest
VM. These three aspects are fundamental for attracting more production use
cases. I'm hoping the AC can steer more attention of the community toward
these three aspects. One suggestion is that we can form special task
forces/virtual teams to own these areas so that there is a bit more focus.

2. The community has been quieter than before. The Kata Community is active
in terms of new PRs submitted but not so much in discussions no matter
online or offline. Not trying to single out anyone, but some of the AC
members have been pretty "quiet" too. I think we need more leaders (a.k.a.
AC members) to step up and participate in the community more.

3. The Kata Containers project is getting bigger/more complicated with new
features such as CoCo and rust-shim. It's becoming harder to keep up with
all the PRs. It's not clear how the different decisions are made and what
the potential impacts are. It's also not clear who is the
stakeholder/decision maker. For example, right now I'm scared to update our
downstream to 3.0 because I don't know what the unknowns are and who I can
go to if something is wrong. I wonder if we can have a designated owner/POC
for each component. The owner can be one person or a team. This assigned
"ownership" can also make PRs/issue triage more streamlined.

Thanks,
Feng



On Mon, Nov 14, 2022 at 2:51 PM Shinde, Archana M <
archana.m.shinde at intel.com> wrote:

> Hi Fabiano,
>
>
>
> Eric has made some great points on how we can improve our community. I
> agree with him on those and also don’t see a lot of challenges with the
> architecture committee itself, but our overall community participation can
> be improved a good deal.
>
> There are quite a few participants and development efforts going on today
> in the Kata community along with greater end-user adoption. While this is
> obviously very positive for the project, it also makes it highly difficult
> to track high-priority issues and features that need attention in terms of
> agreed direction. While it has been pretty useful to have an issue for
> every PR raised, it also sometimes makes it difficult to find issues that
> are raised by our end users (Maybe we can solve this simply by making good
> use of github labels in the future). While I can urge everyone in the
> community to be proactive about this including myself, I have been trying
> to see if we can take any concrete steps to address this. I feel dedicating
> 10-15 min every AC meeting to triage over high priority issues opened over
> the last week could be a useful step.
>
> I also feel the PR review rota process needs to revisited to make sure
> people listed on the rota process will dedicate the necessary time to
> review not only PRs but also issues opened that week. We used to be quite
> diligent about this earlier, but not as much recently. We also need to make
> sure that not it is just not handful of partcipants taking part in this.
> Same goes for the release process, as Eric as pointed out. While it is not
> just a couple of companies involved in the release process any longer, I do
> feel there is ample scope for improvement here.
>
> Another area we can improve is in getting consolidated feedback from
> customers using Kata in production. I think we do need to revisit this from
> time to time to get valuable feedback from customers in what pain points
> they see with Kata. I don’t fully have a picture on how best this can be
> done, but perhaps making sure we have a session in our bi-yearly PTG to
> invite some of our end-users beforehand would be a good step. This is
> something we can ask OIF to help with.
>
> For the Kata AC itself, I  believe we can do better in terms of having
> some more cross-project presentations on our AC call, for eg having
> virtiofs folks come in and talk about some of the recent work they have
> been doing in their project.
>
>
>
> These are some of the things that I can think of currently to improve the
> community health. I’ll send a follow up email if I think of anything else.
>
>
>
> Thanks,
>
> Archana Shinde
>
>
>
>
>
> *From: *Eric Ernst <eric.g.ernst at gmail.com>
> *Date: *Monday, November 14, 2022 at 11:58 AM
> *To: *Fabiano Fidêncio <fabiano at fidencio.org>
> *Cc: *kata-dev <kata-dev at lists.katacontainers.io>
> *Subject: *Re: [kata-dev] Elections | Q&A | What are the current pain
> points with the AC and how to solve them?
>
> Hey Fabiano,
>
>
>
> I don't feel there are that many challenges with respect to the
> architecture committee *itself* to day, as we haven't had a ton of need to
> specifically exercise it. I think if we step back and look at the Kata
> Containers community itself, I can think of a few areas we can highlight as
> challenges:
>
> 1) Time zones, daylight savings
>
> 2) Participation - online and offline.
>
> 3) Reviews
>
> 4) Non core-code contributions
>
> 5) Varied views on what is important for the project
>
>
>
> (1) is mostly a joke, but seriously.  For (2), this is somewhat a response
> to (1). We have contributors spread across all timezones, which makes
> regular live collaboration a challenge. For me, I know I can either stay up
> late and catch our friends in APAC, or wake up early to get more cycles
> with our EU partners. I think that while the AC meeting calls are a great
> forcing function to meet, we need to make sure we are effective at getting
> attention and collaboration on issues offline as well -- for example though
> GitHub issues. This should be the primary communication as it'll allow for
> the most community equity (time and langauge), as well as a good forcing
> function to ensure we have a higher level of collaboration in place so the
> AC calls are as effective as possible.
>
>
>
> For (3) -- I feel guilty of this, but we need to make sure we all make
> time for helping with reviews.
>
>
>
> For (4) -- we have been very reliant on a few heros to make sure our "less
> shiny" code that keeps the project stable is maintained. While it has
> improved, I worry that we need to have more contributors to our CI and CD
> infrastructure.
>
>
>
> For (5) -- As each group has their own use cases for Kata Containers,
> there are naturally different views on what is top priority for the
> project. As an example, I am very tied at the moment to the Go
> implementation of the kata shim - as a result all of my development and
> fixes are against this. Knowing I will need to migrate to another
> implementation in the future is a stress-point for me, and a risk for my
> usage. Having said that, I know *not* migrating is also a risk, as a large
> percentage of our users are focusing on the rust shim.  This is a
> trade-off, and knowing that we need to plan for and accommodate such
> conflicting priorities is a big part of driving this project.
>
>
>
> -Eric
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> https://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.katacontainers.io/pipermail/kata-dev/attachments/20221114/5ec70bb9/attachment.htm>