Elections | Q&A | What are the current pain points with the AC and how to solve them?
Folks,
As the first question of the Q&A, I'd like to hear from every candidate on the $usbject, and I will also answer those questions in a different email.
What are the pain points you have with the current Architecture Committee? And what's your idea to improve those points?
I'm expecting all sorts of answers here, from technical parts to community involvement. With this in mind, please, speak up! :-)
Best Regards,
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
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@gmail.com Date: Monday, November 14, 2022 at 11:58 AM To: Fabiano Fidêncio fabiano@fidencio.org Cc: kata-dev kata-dev@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
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@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@gmail.com *Date: *Monday, November 14, 2022 at 11:58 AM *To: *Fabiano Fidêncio fabiano@fidencio.org *Cc: *kata-dev kata-dev@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:
Time zones, daylight savings
Participation - online and offline.
Reviews
Non core-code contributions
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@lists.katacontainers.io https://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Hi Fabiano
Regarding some of the pain points of AC and new usecase， I have the following immature thoughts:
1. As a developer and community maintainer of the kata container, since 2018, one of the biggest impressions to me is that the kata community lacks planning and information synchronization for some major features and major version upgrades. For example, at the end of the year, should we review some of the past, what major features we have implemented, discuss and make decisions about which features kata needs to focus on next year, which areas to invest in, and reach a consensus in the community, Let both community participants and users have a psychological expectation.
2. The second is that we now use kata as a k8s cloud-native runtime to make kata more cloud-native, thereby affecting more investment in the k8s community. For example, we have always wanted to make shimv2 support sandbox semantics, and let cni and csi add support for kata pass-through network and volume pass-through.
3. Expand the influence of kata AC meeting. Now the participants of AC meeting are basically fixed to those few people. Can we let some main developers share the architecture and design principles of some key features on a regular basis? This can attract some new developers and make the community more active.
4. For adding some new usecases, I wonder if we can add some usecases related to function computing, such as introducing some end-to-end optimization solutions to meet the fast startup and high-density deployment of function computing.
Let me reply to my own question, and add some of the interesting points raised.
Eric mentioned:
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.
And I partially disagree with that. While we didn't have conflits to solve as part of the Architecture Committee, I think we're lacking the "leading by example" attitude. I see the Architecture Committee, or a Technical Steering Committee, of any project as not only the place where conflicts will be solved, or ideas will come from, but I do also expect the participants to be "down in the trenches" to understand the possible issues of the project, and also to be responsive when tagged by other community members (and here we also touch the part related to offline discussions). I currently feel we don't do enough of that.
Archana mentioned:
(...) it also makes it highly difficult to track high-priority issues and features that need attention in terms of agreed direction.
And I agree with that. However, IMHO, we go back to the "leading by example" topic. Every now and then we get explicitly tagged to issues, and there's absolutely zero reply for weeks, if not for months. If I were to be a newcomer, I'd be quite frustrated by that, sincerely.
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.
And we had that, a dedicated session to triage issues, which was not very popular and not a bunch of people joined. IMHO, this goes back to the same point raised above, as even when we did the triage, every now and then we'd tag reviewers and no replies would be provided.
...
At the moment I'm writing this down I've read Fupan's and Feng's answers as well, and to everything I didn't reply to, I must say that I agree.
In general, from my experience in the past 2 years serving the community as part of the Architecture Committee, I've felt the following pain points: * Lack of "hands on" help with the issues raised by the community, be those related to coding, reviewing, triaging, or spreading the word about the project. * Lack of planning, as mentioned by Fupan, but I also understand that having several companies behind the project, each company with its own interests, makes this a little bit tricky to organise. * Lack of investment on user-experience to help grow the project. * This is not totally the Architecture Committee's fault, but I think the Architecture Committee should be paying a reasonable amount of attention to the entry points of the project, including technical documentation on best practices for deploying / upgrading / managing Kata Containers. * Lack of recognition of key members of the community * We've added more and more people to the maintainers group, and I'm happy about that, but it's hard to even find any documentation on how to add a new member to project, what's expected, and if a member doesn't fit what would be a reasonable feedback for the member to improve and try again.
All in all, let me repeat myself here, I agree with the majority of the pain points raised, and I appreciate those who took time to bring those up.
Please, do *not* take any of the points I brought up as a critique to one or another specific person, those are all points that I consider myself having to improve as well.
Best Regards,
participants (5)
-
Eric Ernst
-
Fabiano Fidêncio
-
Feng Wang
-
fupan li
-
Shinde, Archana M