-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add containerd graduation review proposal #165
Conversation
|
||
With contributions from Microsoft and AWS, we believe that Azure and AWS are also looking at containerd for potential use within their public cloud offerings as well. | ||
|
||
**_Other Projects_** - While the above list provides a cross-section of well known uses of containerd, the simplicity and clear API layer for containerd has inspired many smaller projects around providing simple container management platforms. Two that have come from containerd community participants directly are Michael Crosby's [boss](https://github.com/crosbymichael/boss) project and Evan Hazlett's [stellar](https://github.com/ehazlett/stellar) project, as examples of higher layer functionality that can easily be built on the containerd base. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ibuildthecloud also has a project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rio is listed above; unless he has another one. I wouldn't put it past him :)
|
||
**_IBM Cloud Private (ICP)_** - IBM's on-premises cloud offering has containerd as a "tech preview" CRI runtime for the Kubernetes offered within this product for the past two releases, and plans to fully migrate to containerd in a future release. | ||
|
||
**_Google Cloud Kubernetes Engine (GKE)_** - offers containerd in "alpha clusters" on recent versions of Kubernetes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/alpha/beta/ ? cc @Random-Liu
cos_containerd OS images are available as a Beta feature in GKE v1.11 and higher.
https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
containerd will be beta when GKE v1.11 rollout, which is coming soon.
reviews/graduation-containerd.md
Outdated
|
||
**Committers from at least two organizations.** | ||
|
||
Containerd has had a variety of maintainers and reviewers since its inception, and currently have 14 committers representing NTT, Huawei, Docker, Google, IBM, Microsoft, Facebook, Tesla, and Cruise Automation. We also recognize **LGTM** rights for a group we call *reviewers*, of which there are currently five representing ZTE, Docker, and independants. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if containerd has a stable governing rules for maintainers. I think governing policy for maintainers' responsibility is quite healthy for the project, since I found that some members of containerd's maintainer list have not been active for a long time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand the comment correctly, you are right that we have some non-active maintainers. We were in the process of reaching out to them to understand their intention of continuing activity as a maintainer; the result of that is the PR that was just merged: containerd/project#12
This does not change the make-up of the maintainer organization representation by much, but I will update the graduation PR to make it correct with the current status. Let me know if you had any other concerns here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your update. Only this minor concern. Sincerely wish containerd could graduate soon.
65a7850
to
ec90794
Compare
+1 |
|
||
**_BuildKit_** - The Moby project's [BuildKit](https://github.com/moby/buildkit) can use either runC or containerd as build execution backends for building container images. BuildKit support has also been built into the Docker engine in recent releases, making BuildKit provide the backend to the `docker build` command. | ||
|
||
**_Docker engine_** - As noted in the opening paragraph, Docker continues to consume containerd as a key component within the Docker engine stack, and is actively working to remove Docker engine implementations where containerd implementations can be used as a replacement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it's worth to mention but katacontainers is doing official integration with containerd shimv2 api. We are hoping to merge the PR before KubeCon Seattle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great--just added Kata to the list of adopters!
|
||
Our project governance is clearly laid out in our [GOVERNANCE.md](https://github.com/containerd/project/blob/master/GOVERNANCE.md) document, including details on how to become a maintainer and how maintainer and contribution processes are handled. The maintainers for containerd, the CRI project, and all sub-projects are common, and maintained in our core project repo in the [MAINTAINERS](https://github.com/containerd/project/blob/master/MAINTAINERS) file. | ||
|
||
**Have a public list of project adopters for at least the primary repository.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also add https://github.com/firecracker-microvm/firecracker-containerd to the adopter list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added, thanks!
ec90794
to
26ea9f1
Compare
Updated adopter list with Kata containers and AWS Firecracker VMM |
This is not a CNCF requirement for graduation, but may be of interest to reviewers to note that the containerd security audit provided via the CNCF is now published: https://github.com/containerd/containerd#security-audit |
final RFC from @cncf/toc and community before we kick a vote off next week |
reviews/graduation-containerd.md
Outdated
|
||
**Committers from at least two organizations.** | ||
|
||
Containerd has had a variety of maintainers and reviewers since its inception, and currently have 12 committers representing Docker, NTT, Google, IBM, Microsoft, Facebook, Tesla, and Cruise Automation. We also recognize **LGTM** rights for a group we call *reviewers*, of which there are currently six reviewers representing ZTE, Huawei, Docker, Microsoft and an independent developer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 8 reviewers today: containerd/project#13. The two additional reviewers represent Alibaba.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the reminder! I will update the document @xiang90
26ea9f1
to
dde0eb3
Compare
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
dde0eb3
to
500d665
Compare
graduation vote is out https://lists.cncf.io/g/cncf-toc/message/2873 |
Hey @estesp a question from @jbeda
|
The graduation criteria simply states:
This is obviously not the full criteria. A GOVERNANCE.md that say "Joe decides everything" fulfills the criteria but obviously isn't acceptable. I read this more as create an independent, fair and vendor neutral governance structure. The fact that the Moby TSC is the ultimate arbitrator means that we should be examining that governance structure too. That is defined here. Basically the Moby TSC is voted on from each of the participating projects. Solomon Hykes also gets a vote. To really map the process here we'd have to dig into the individual projects. There are no requirements or protections against vendor majority on the Moby TSC. By a quick look, 4 out of the 7 members of the Moby TSC are Docker employees. And the Moby TSC process could change in the future. I'd feel much much better about voting to graduate containerd if it had an independent governance structure. |
Just to clarify some of the claims in the last comment:
I'm happy to respond to the broader discussion of whether Moby TSC is a proper "escape valve" for technical issues in containerd that cannot be resolved within the project itself. We have discussed it as a project recently, and feel fully free to use or not use the Moby TSC as an umbrella for governance, but haven't made any clear steps away from Moby TSC as a project to date. However I thought it would be useful to clarify some facts about the TSC before any rumor mills got wound up. :) |
I don't want to start any rumors so thanks for responding! Sorry I missed the restriction on max representation of a single company. I may be confused though as it looks like there are currently 4 ppl there from Docker (Justin, Stefan, Arnaud, Sebastian) going to 3 (with Stefan stepping down) and I would expect at max 2. (I may have company affiliation wrong though as this stuff isn't always obvious). All the same, I feel that we are on new ground here by having the technical arbitration for a project be outside of the project (and the CNCF). I also realize that the need to use the Moby TSC will be rare to nonexistent and that this is currently more of a theoretical concern than a practical one. How hard would it be to cut that cord before we close the vote? |
From @estesp points, I think this addresses much of the issues you raised and I don't think this should impact the graduation vote at this point. I'm not sure we want to cut the cord this close to the final vote unless others have issue with this. I would like this to be a thought out and reviewed decision among the maintainers of the project and not done in haste unless this is going to impact all the graduation work we have put in so far. As for going forward, I think this is something to bring up with the maintainers of the project and see of the Moby TSC is needed vs being totally independent. This is something I will take on and start the discussion go with the maintainers of the project. I think at this point in the project, the maturity of the project, we are able to move away from the Moby TSC but this is a decision for all the maintainers. As far as who is at Docker on the TSC, with Stefan stepping down, we only have Justin and Sebastian, Arnaud is not at Docker. |
|
Ah -- I was confused as Arnaud's personal web page still has him working for Docker: https://icecrime.net/about/. Thanks for the clarification. |
@icecrime update your website! 😂 |
After talking to @estesp about how the project works and how the TSC connection really is a theoretical concern I agree that it is unreasonable to ask to change the governance at the 11th hour. But I do encourage the project to look to remove this connection. But that'll have to happen separate from this vote. |
@jbeda that sounds totally reasonable to me and we will get the discussion started with the containerd maintainers and community. Thanks! |
@jbeda The question about the Moby TSC was helpful. I'm not sure it's a problem, but I found it odd when I noticed it recently. However, we have no explicit policy regarding "protections against vendor majority". The most relevant criterion is "Have committers from at least two organizations." I don't think we should impose a new "majority" policy on the fly for this specific graduation proposal. For example, would that imply that no project where 50% of the commits / contributions come from a single organization can graduate? That's not an issue for containerd, but would be an issue for at least 8 other projects. If we did want to impose such a policy, we should think about how we can help projects broaden their contributor bases, which perhaps we should do regardless. |
@bgrant0607 -- yes -- I'm not imposing new requirements here but just digging into the details of the whole governance structure of the project (which does import the Moby TSC). We should follow up separately on updating the graduation requirements to something that is more meaningful than "has some governance". Let's take the discussion off this issue. |
+1 binding TOC votes (8/9): |
The submitted markdown document contains our proposal for graduation for the containerd CNCF project.
cc: @crosbymichael
Signed-off-by: Phil Estes estesp@linux.vnet.ibm.com