Date
1 - 9 of 9
Sandbox Projects included from September 8 TOC meeting
|
andy shi
During the last CNCF sandbox review, the TOC wanted the K8s upstream to provide opinions of project OpenKruise. After the meeting, we reached out to Sig Apps and K8s Steering committee. The Steering committee directed us to Sig Arch instead. Since then, we have had discussions with both Sigs. For your convenience, I'm pasting both responses below. In summary, both Sigs evaluated the OpenKruise project and suggested OpenKruise is better to stay as an outside project instead of becoming part of upstream K8s. We have done our due diligence and hope to get another vote at the next review meeting. Best Regards, Andy Shi on behalf of project OpenKruise From Matt of Sig Apps: " We discussed OpenKruise in Kubernetes SIG Apps. I can now answer
questions asked of SIG Apps. In the meeting what OpenKruise is building
was discussed along with how things could operate between SIG Apps as a
sandbox project or K8s SIG sponsored project.
Experiments
happen all over. For example, OpenShift's work lead to what we now have
as the Workloads APIs. We don't believe they need or should be part of
the Kubernetes project. It is perfectly fine for them to be either k8s
SIG sponsored projects, CNCF projects, or some other project. In
this case OpenKruise desires to operate as a sandbox project and SIG
Apps is supportive of that. We have a path to collaborate as needed.
This
is more difficult. Upstream Kubernetes won't likely accept every new
type of controller. The direction is generally to have them installed as
3rd party controllers. The bar to move something into core Kubernetes
is now very high. Some successful features may make it into Kubernetes core. Others will likely always be recommended to be handled as 3rd party. OpenKruise
can have successful 3rd party CRDs and controllers that do not go into
Kubernetes itself. I expect this case to be likely.
SIG
Apps does not believe there should be one home for "all
workload-related CRD ideas". They can happen in many places and
innovation can happen under many projects. How those projects organize
around people and governance may vary. I hope this helps answer the questions of SIG Apps. If there are more I'm happy to try and chase them down. And, thanks for pointing OpenKruise at SIG Apps. It lead to a good conversation. Regards, Matt Farina" From John of Sig Arch: "We discussed this in the SIG Architecture meeting today. While generally
workload controllers are within scope of the Kubernetes project, it is
up to SIG Apps to decide if they are willing to take these on as
SIG-sponsored projects. As Matt suggests, it's fine for these to exist
as external workload controllers. With respect to
upstreaming, the preference of SIG Arch would be to see individual
features move into existing workload controllers as they mature, rather
than creation of whole new controllers. The goal here would be to avoid a
proliferation of controllers that makes choices very difficult for
consumers. Of course, if there is some fundamental difference between
the new controller and all existing ones, then a new one may be
warranted. But creation of a new one should be done with an abundance of
caution. Again this would ultimately be the decision of SIG Apps. Thanks, John" On Tue, Sep 8, 2020 at 1:05 PM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|
|
|
We discussed this in the SIG Architecture meeting today. While generally workload controllers are within scope of the Kubernetes project, it is up to SIG Apps to decide if they are willing to take these on as SIG-sponsored projects. As Matt suggests, it's fine for these to exist as external workload controllers. With respect to upstreaming, the preference of SIG Arch would be to see individual features move into existing workload controllers as they mature, rather than creation of whole new controllers. The goal here would be to avoid a proliferation of controllers that makes choices very difficult for consumers. Of course, if there is some fundamental difference between the new controller and all existing ones, then a new one may be warranted. But creation of a new one should be done with an abundance of caution. Again this would ultimately be the decision of SIG Apps. Thanks, John On Mon, Sep 21, 2020 at 1:31 PM <szihaI@...> wrote: The OpenKruise project agree with the Sig App's assessment completely. We, too, believe while up-streaming some of the features to the core workloads is possible, the majority of the controllers and features is best to remain as a separate project. |
|
|
|
andy shi
The OpenKruise project agree with the Sig App's assessment completely. We, too, believe while up-streaming some of the features to the core workloads is possible, the majority of the controllers and features is best to remain as a separate project.
Best regards, Andy Shi |
|
|
|
Matt Farina
We discussed OpenKruise in Kubernetes SIG Apps. I can now answer questions asked of SIG Apps. In the meeting what OpenKruise is building was discussed along with how things could operate between SIG Apps as a sandbox project or K8s SIG sponsored project.
Experiments happen all over. For example, OpenShift's work lead to what we now have as the Workloads APIs. We don't believe they need or should be part of the Kubernetes project. It is perfectly fine for them to be either k8s SIG sponsored projects, CNCF projects, or some other project. In this case OpenKruise desires to operate as a sandbox project and SIG Apps is supportive of that. We have a path to collaborate as needed.
This is more difficult. Upstream Kubernetes won't likely accept every new type of controller. The direction is generally to have them installed as 3rd party controllers. The bar to move something into core Kubernetes is now very high. Some successful features may make it into Kubernetes core. Others will likely always be recommended to be handled as 3rd party. OpenKruise can have successful 3rd party CRDs and controllers that do not go into Kubernetes itself. I expect this case to be likely.
SIG Apps does not believe there should be one home for "all workload-related CRD ideas". They can happen in many places and innovation can happen under many projects. How those projects organize around people and governance may vary. I hope this helps answer the questions of SIG Apps. If there are more I'm happy to try and chase them down. And, thanks for pointing OpenKruise at SIG Apps. It lead to a good conversation. Regards, Matt Farina On Wed, Sep 9, 2020, at 2:04 PM, Xiang Li wrote:
|
|
|
|
Li, Xiang
(I am familiar with the team behind the project, and the background of the project). OpenKurise itself is not an experiment. It supports some of the largest Kubernetes clusters in production environment at Alibaba and a few other large internet companies (https://github.com/openkruise/kruise/issues/289). For any sizable companies using Kubeternetes, it is not uncommon to have tens of generic controllers that are not specific to any particular application. The motivation of OpenKruise project is to find a subset of these controllers that are commonly useful to a number of users rather than just one company. So we can reduce some duplication, improve collaboration and help the community to grow. Yes, if some enhancements or workload types are popular enough that everyone wants then, we hope them to be upstreamed to Kubernetes project itself.
|
|
|
|
Amye Scavarda Perrin
The recording for the 9/8 meeting is up on YouTube: https://www.youtube.com/watch?v=q_FO3PWnkY4 On Wed, Sep 9, 2020 at 10:36 AM Liz Rice <liz@...> wrote:
--
Amye Scavarda Perrin | Program Manager | amye@... |
|
|
|
Liz Rice
OpenKruise is experimenting with a number of workload-related resource definitions, some of which are enhancements to existing core K8s resources. We're happy to see these experiments and want to support them, but we wondered if it makes more sense for them to belong within the purview of the Kubernetes project rather than as a standalone project? My understanding is that OpenKruise intends to eventually contribute successful experiments to upstream Kubernetes anyway. There's also a question about project scope. If the Kubernetes project would actually prefer these experiments to take place in a separate project, does that make OpenKruise the natural home for all workload-related CRD ideas, or some other scope? The discussion was recorded (I'm sure Amy can provide the link if she hasn't already circulated it) and that might be worth listening to for more context, if you have the time. On Wed, Sep 9, 2020 at 4:21 PM Matt Farina <matt@...> wrote:
|
|
|
|
Matt Farina
OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project. For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project? On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
|
|
|
|
Amye Scavarda Perrin
The TOC has reviewed the current Sandbox projects applying for inclusion. The projects included are: Backstage Tremor metal3-io Porter OpenYurt Open Service Mesh Other projects not brought to vote: checkov - further conversation needed re: roadmap, holding for updated roadmap protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject? Predator - no clear roadmap, resubmit with clearer roadmap SchemaHero - no clear roadmap, resubmit with clearer roadmap Keylime - scheduled for next closed meeting, September 22 As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" Welcome to these new sandbox projects! -- Amye Scavarda Perrin | Program Manager | amye@... |
|
|