Skip to content
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

Proposal for Special Purpose Operating System Working Group #1154

Closed
rajaskakodkar opened this issue Aug 25, 2023 · 15 comments
Closed

Proposal for Special Purpose Operating System Working Group #1154

rajaskakodkar opened this issue Aug 25, 2023 · 15 comments
Assignees
Labels

Comments

@rajaskakodkar
Copy link

rajaskakodkar commented Aug 25, 2023

Hello TOC members 👋,

We at TAG Runtime, would like to propose a new Working Group for Special Purpose Operating System. There has been an ever growing interest around special purpose OSs, especially, container OSs in the community and we have come together to draft a proposal for this Working Group. We would like to inform of the proposal and request the TOC's approval to formalise and launch the working group. We'll follow that up by finalising the leadership of the working group and formalising meeting times and other logistics.

WG Charter PR can be found here: cncf/tag-runtime#75

Here's an excerpt from the WG's Charter document.


Background

Special Purpose Operating Systems are designed to run well defined workloads with minimal boilerplate of dependencies suited for niche use cases.

In the cloud native world, these workloads include containers, however, they can be extended to other special purpose workloads such as WASM, etc.

Mission Statement

The special purpose operating system working group (wg-sp-os) focuses on the operations, best practices and guidance on running cloud native workloads on operating systems, including, but not limited to containers, across orchestrators such as Kubernetes and other cloud-native projects. The immediate focus of the working group will be to work on container OSs, however, other areas such as WASM would still be part of the charter of the working group. For future cloud native related efforts, the charter of the working group would be extended upon consensus in the community. The working group aims to:

  • Foster an ecosystem for collaboration between existing projects
  • Educate users with unbiased and common understanding of special purpose OSs
  • Identify gaps in the landscape and attract new projects to the ecosystem

Scope

The working group is focused on the following areas:
Guidance on Cloud Native practices for Container OSs which include:

  • Lifecycle and configuration management
  • Resource utilization
  • Upgrade scenarios
  • Long Term Support constraints
  • Compatibility with container runtimes
  • Flexibility and interoperability with container orchestration solutions which includes Compatibility with kubelet API versus host dbus/systemd in the case of Kubernetes workloads
  • Best practices for security considerations for cloud native container os workloads
  • Best practices for integration with softwares designed for management and monitoring of the hosts, such as antivirus agents.

Deliverables

  • Publications, presentations, and whitepapers on areas related to running cloud native workloads on special purpose OSs
    • Potential whitepaper ideas:
      • Guidance on LTS: How does LTS in Kubernetes impact special purpose/container OSs?
      • What is a container operating system for cloud native workloads?
  • Integration with the Kubernetes project
    • Exploring the area of providing an interface for OS in Kubelet, similar to CNI or CSI. A single interface to work with Kubelet to work across distributions.
  • Guidance on usage and technical support for running container workloads on OSs
  • Exploration and looking beyond the horizon of container workloads and incorporating other workloads such as WASM on special purpose OSs with close collaboration with WASM Working Group.
  • Collaboration within the community on related areas like edge computing, etc
  • Collaboration for any fixes or contributions to upstream projects like the Linux kernel
  • Integration with other projects in the community like Cluster API
    • Exploring the area for a standard abstraction for special purpose OSs to interact with Cluster API, with respect to bootstrap providers, etc.
  • Metrics - provides guidelines for project planning in terms of resource usage.
  • Ecosystem updates - provides updates on the landscape of cloud-native projects on the special purpose OSs at conferences, in publications, and to the TAG Runtime.

Thanks,
Rajas

cc @raravena80 @helayoty @nikhita

@nikhita
Copy link
Member

nikhita commented Aug 25, 2023

+1 as TAG Runtime Liaison.

@cathyhongzhang @RichiH as other TAG Runtime liaisons, please approve.

@nikhita nikhita added the for-liaison-approval for tasking from TAGs that require their TOC Liaison approval label Aug 25, 2023
@rochaporto
Copy link
Contributor

Not a TAG Liaison, but i also +1 this proposal.

@ZhengZhenyu
Copy link

Looking forward to see this group running, very interested to be a part of it.

@cathyhongzhang
Copy link

There are various types of container OSes as well as minimal/optimized OSes for running containers. Will this WG cover all those or will it propose a new container OS? The delivery includes a new interface between the OS and Kubelet similar to CNI. Interesting idea. I am wondering how you will position CRI and containerd/crio-o in the integration of the container OS with Kubelet.

@raravena80
Copy link
Contributor

I don't think the goal for this WG is to create a new SP OS. But rather the creation of common standards that can be used by all the various SP OS (and ultimately end users). All of this through collaboration from the members of the various related open source projects. The community has already been at work creating this proposal for the last 2 months. Thanks for putting it together. +1 nb.

@stmcginnis
Copy link

Will this WG cover all those or will it propose a new container OS?

Just to add some more context on some of the background of this proposal:

This partly came about from folks from Flatcar, CoreOS, Bottlerocket, Talos, and others getting together to discuss common concerns with working on container-optimizes operating systems. There was some desire to form a open community space for folks interested in this (somewhat niche, but growing) space to be able to come together to collaborate, share ideas, and help promote the idea of using a specialized OS.

It is also the hope that this will provide end user's somewhere more obvious to go to share ideas, use cases, and challenges they are facing when trying to use these kinds of OSs in the cloud native space.

@cathyhongzhang
Copy link

LGTM. +1 Binding.

@Yuanrong-Li
Copy link

Will this WG cover all those or will it propose a new container OS?

Just to add some more context on some of the background of this proposal:

This partly came about from folks from Flatcar, CoreOS, Bottlerocket, Talos, and others getting together to discuss common concerns with working on container-optimizes operating systems. There was some desire to form a open community space for folks interested in this (somewhat niche, but growing) space to be able to come together to collaborate, share ideas, and help promote the idea of using a specialized OS.

It is also the hope that this will provide end user's somewhere more obvious to go to share ideas, use cases, and challenges they are facing when trying to use these kinds of OSs in the cloud native space.

I'm glad to see this proposal. KubeOS (https://github.com/openeuler-mirror/KubeOS) is also a container OS that incorporates OS management into Kubernetes, for example, upgrading nodes using Kubernetes or configuring nodes using Kubernetes.
Looking forward to see the creation of this WG .Hope to be a part of it and discuss with those interested in container OS.

@ChaoyiHuang
Copy link

ChaoyiHuang commented Aug 28, 2023

Hi, Marcin and I presented image comaptibility spec proposal to OCI in last weekly meeting, in order to define specification to describe container special requirements to the host OS where the container will run. Based on the meeting discussion, a working group PR is going to be sumbitted.

Image Compatibility Spec:

https://docs.google.com/presentation/d/1F9GnCm2sULuyTJ5BEFZlL8Qjab81DK7g9Oy6qBfe5Qs/edit?usp=sharing

https://docs.google.com/document/d/1lzwh8DGMu5vXXHwJmnewYIMffkcOEvH8owX4UYjRcw0/edit#heading=h.fcxt9vheg92c

these efforts can be coordinated.

@mfranczy
Copy link

Hey, as @ChaoyiHuang mentioned, we believe, we identified a missing puzzle in the OCI standard, the compatibility spec that should describe container requirements (like kernel features, modules or out-of-tree drivers).

The scope of the proposed working group here includes

Lifecycle and configuration management

The configuration, as I understand, should be also influenced by container requirements (like required kernel module). Do you think we can combine the effort?

@stmcginnis
Copy link

Thanks for the links. Looking through the presentation, I think this would be something that would impact any host OS - specialized for running containers as well as general purpose operating systems.

This may be a good example of how having this proposed working group could help. I don't think the efforts can be combined as they are trying to address slightly different things, but this could provide a good venue for fostering the collaboration between the efforts to try to enable support once there are OCI changes proposed, which could hopefully help accelerate support.

@ChaoyiHuang
Copy link

ChaoyiHuang commented Aug 29, 2023

Agree to @stmcginnis these efforts are addressing different things, with some area related.

The item "configuration management" for container OS in this WG seems to define how to configure the container OS through custom resources, not sure including kernel boot parameters, kernel modules, kernel type(realtime kernel or not), etc or not. it seems mainly about OS configuration execution to meet container application demand.

The OCI image compatibility spec proposal is to define how to describe container appliation specical requirements to the host OS, including kernel boot parameters, kernel modules, kernel type(realtime kernel or not), etc. It does not cover how to configure the OS.

If container application special requirements to the container OS can be dicovered through images, then these requirements could be the input for validation when configuring the container OS through applying regarding CRs.

Colloboration will benefit both efforts.

@nikhita
Copy link
Member

nikhita commented Aug 30, 2023

Turns out we don't have a documented process for WG creation...
I have created #1159 to document this.

@TheFoxAtWork while we merge the PR -- given that we have binding +1s from 2/3 TAG Runtime liaisons and an additional +1 from a TOC member (@rochaporto), do you think we can go ahead with WG creation?

@TheFoxAtWork
Copy link
Contributor

Yes. Thank you.

@nikhita nikhita removed the for-liaison-approval for tasking from TAGs that require their TOC Liaison approval label Aug 30, 2023
@nikhita
Copy link
Member

nikhita commented Aug 30, 2023

@TheFoxAtWork thanks.

@rajaskakodkar @raravena80 WG is approved now 🎉

Closing this issue. Please reach out on slack if you need any further help setting up the WG.

@nikhita nikhita closed this as completed Aug 30, 2023
@github-project-automation github-project-automation bot moved this from New to Done in CNCF TOC Board Aug 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

No branches or pull requests