Tracking TOC PR for Serverless Workflow Specification: cncf/toc#376

This may need help from a GitHub admin.

The current website like on the TAG-Runtime repo points to https://cncf.io/projects. We now have https://tag-runtime.cncf.io/. It would be great to update this link to go the TAG-specific site now.

Options abound!
Want to discuss in next TAG Runtime meeting, @raravena80?
cncf-TAG-runtime-logos.pdf

Provide guidance on maturity levels of projects in the landscape.

Recently, we're talking with different communities on how to support WASM (WebAssembly) in the cloud-native environment; and we found it's necessary to align different implementations with specifications.

So I'd like to propose a new working group for WASM and build related specifications for the community.

I'll draft a proposal with more detail on that working group; if any more comments, please let me know.

I've recently got the page feedback buttons to work on the CNCF Glossary site (see at the bottom of the page). They feed events into our cncf.io Google Analytics 4 property which we can later create reports on to see which pages get good feedback, which do not.

Would we like this feature activating for the TAG Runtime site? If not, please just close this issue.

TOC issue:

cncf/toc#335

Relevant github issue: kubernetes/k8s.io#4780

Need to notify projects of the registry endpoint changes.

Authors:
Andy Anderson, KubeStellar / IBM Research
Frank Brockners, Cisco Systems
Joel Roberts, Cisco Systems

Reviewers:
Brandon Wick, Aarna Networks
Herve Muyal, Cisco Systems
Tomoya Fujita, Sony
R. Prakash, eOTF

Published: DATE
Presentation Materials

Objective
Building on the Edge Native Application Principles white paper, developed by the IoT Edge Working Group (originally published January 17, 2023), this supplemental paper shows how these principles can be translated into practice by recommending design behaviors for developing applications for edge environments.

Edge native application design builds on cloud native application design (see e.g., “Architecting Applications for Kubernetes'' or “Twelve-Factor App methodology”). However, several qualities of the edge and the cloud differ. Consequently, edge native application design includes several cloud native design principles and expands them accordingly. The paper was developed by the IoT Edge Working Group and may be expanded and / or edited in the future.

link: https://docs.google.com/document/d/1Ehgrq5ws7xQl5CqUIibSZMjLtAO0Sbe5SGf590U6ImA/edit?pli=1

Create a document to describe the CNAI group's mission/vision/strategy

For new joiners of the AI WG, provide a guide to detail steps on how to contribute to the group.

Recently, we're talking with different community on how to support batch workload in cloud native environment; and we found it's necessary to align different implementation with a specification, it'll be easier for the framework to do the integration, e.g. kubeflow.

So I'd like to propose a new working group for batch workload, and build related specification for the community, e.g. kubeflow community can use this specification to work with k8s, Volcano and Yunikorn, or event with Slurm, HTCondor :)

I'll draft a proposal with more detail on that working group; if any more comments, please let me know :)

Review and assess Virtual Kubelet Incubation and make a recommendation to the TOC.

TOC PR: cncf/toc#296

The Cloud Native AI landscape is a project that aims to provide a comprehensive overview of the cloud native AI ecosystem.

The goal of the landscape is to build it up to a minimal level of usefulness and then merge it into the CNCF landscape as a group. More information about the CNCF landscape is available at https://landscape.cncf.io/.

• The landscape is being developed by a community of volunteers.
• The landscape is open to contributions from anyone.
• The landscape is licensed under the Apache License 2.0.

@ronaldpetty

TOC PR: cncf/toc#386

More details here: https://docs.google.com/document/d/11_6pvPzd956QONIxHuDP155eBRrd89xSC1tYVRy3KvI/edit#heading=h.z0eti03fxfmv

I'm opening this issue to track the KEDA Graduation review/presentation for cncf/toc#925.

Hello!

Following up to this email on sig-runtime, I got a few answers in direct messages. I suspect Github is a better forum to discuss :) !

General Information

Goal of the workgroup: Solve issues related to Device Management across the cloud native space!
Target Audience: Both device vendors and container runtime and orchestrator maintainers in this group as well as anyone interested in the area.
Meetings: TBD, most likely once every other week at the start

Immediate Goal

We are creating this working group with the immediate goal in mind to create a common plugin system for all runtimes as well as ensure that the different orchestrator out there end up using this plugin mechanism.

From a vendor and runtime perspective:

• This will lower the entry bar for device support in runtimes
• Allow uniformity and reduce the overall maintenance cost.

From a user perspective:

• Increase the UX Uniformity
• Ensure that the deployment story allows for simple and consistent deployments (e.g: Containers in Kube)

Broader Charter

Over this immediate milestone, the charter of the group is to solve issues that Devices faces in the cloud native space, such as Intel's over the fabric FPGAs or other use cases that we hope to capture over this groups' lifecycle!

A draft Charter Document is available here and contributors should feel free to rewrite, reframe or discuss any topic they see fit: https://bit.ly/container-device-interface-wg-charter

Some Members

• Intel: Ed Bartosh, Ukri Niemimuukko, Alexander Kanevskiy
• Mellanox: Adrian Chiris, Moshe Levi
• NVIDIA: Renaud Gaubert
• Podman: Mnrunal Patel
• Containerd: Mike Brown

We are hoping to start the first meeting by next week and from what I gather from different participants, it looks like we are spread out across the European and North American Time Zones.

See the below doodle for people to indicate what their preferred time is: https://doodle.com/poll/ucchuvc8vxhfftsd

/cc @mikebrow @mrunalp @kad @k82cn @raravena80 @moshe010 @dmcgowan @Random-Liu @yujuhong @adrianchiris @bart0sh @uniemimu

Hello!

I would like to bring up the topic of third party device support in container runtimes and orchestration engines.

In the past the way we had solved this problem is through the device plugin mechanism.
However, over the past 2 years this system has been used, we noticed that this wasn't exactly the right approach.
Some of the issues we've noticed:

• Devices support is kubernetes specific and can't be reused / extended at the runtime level. 
  e.g: you can have GPU / FPGA support in kubernetes but there's no --fpga option in docker or --device=fpga
• By being "on top" of the CRI, we don't have access to the container specification preventing us from doing any operations based on container information
• We are seeing vendors use docker's default runtime / custom runtimes and the CRIO hooks as workarounds in addition to the device plugin.

After discussing this in sig-node and at Kubecon US (there's also some more context here), we circled on an approach to standardize device support at the runtime level (similar to the CNI)such that kubernetes could re-use this support through the CRI.

For now I've summarized this here: https://github.com/RenaudWasTaken/cdi Let me know if this is something that fits this groups purpose and if people are interested in helping push this!

One of the questions which was surfaced was if this work is K8s specific.
A huge component of the discussion is about designing (and implementing) a specification for Runtimes to support third party plugins.

There is however a smaller component that probably fits more under sig-node which would consist in transitioning the device-plugin system to this new CDI system.

cc @raravena80 @kad

Thanks!

Executive Summary

• For CNCF Community: promote AI education and recognize community member participation and become CNCF ambassadors. Drive community visibility, and match challenges and solutions.
• For Companies that work on CNCF AI projects: recognize their community contribution in a tangible way by promoting their open source technologies news

More details here: https://docs.google.com/document/d/1L-gP001biKswpLTX6X0iC2QfLZHBESPpa-VA3KfbhXU/edit

KubeEdge is applying for incubation -- Issue to track

I noticed the page https://tag-runtime.cncf.io/wgs/cnaiwg/ is missing our contact information still (slack channel mainly). I went to add it and found some funky looking markdown (new to me that is). Is there a guide on how to add content (aside fork).

It would be good to add more details about WGs, including their meeting details, and links to artifacts generated by them on the website.

TOC PR: cncf/toc#311

Presentation slides

Tracking the proposal from here:

TOC PR: cncf/toc#318

Github
Slides

Following SIG-Security steps: cncf/tag-security#314. It would be nice to have a tool like https//otter.ai for our meetings like @timfong888 mentioned.

Tracking TOC PR for Metal3: cncf/toc#408

#121

TAG-Runtime has four active working groups, and a new is about to be created. Hence, we would like to set up a 2-month (maybe quarterly?) meeting with all TAG-Runtime working group chairs/TLs.
The meeting will be for WGs status update, to discuss the progress, and to help with ongoing issues.

cc: @kad @elezar @k82cn @stackedsax @kate-goldenring @cantbewong @dejanb @devigned @endocrimes