Explore TAG Workloads Foundation: Advancing Cloud Native Ex... Stephen R, Yuan T, Marlow W & Kante Y

This talk addresses the TAG Workloads Foundation and aims to clarify its purpose within the cloud-native ecosystem under the CNCF. The speakers explain that a Technical Advisory Group (TAG) facilitates cross-project communication, supports technical expertise, and helps identify gaps within project contributions. They elaborate on the restructuring that reduced the number of tags from eight to five, focusing on workloads, components, and lifecycle management. Additionally, they highlight the importance of community involvement and present ongoing initiatives, such as batch scheduling and CI/CD practices. The discussion includes the criteria for projects to progress through stages of maturity, from sandbox to graduated status, emphasizing the collaborative nature of the technology landscape.

Uh, my name is Steve Rust. I work at Akamai Cloud as a principal architect. I'm also a tech lead for TAG Workloads Foundation. Hi, I'm Marla Wornicky. I am a chair for the working group sorry, subproject batch subproject USB working group. And also a uh lead for the Slinky project over at Nvidia. Hi everyone, my name is Yuanta. I'm with Red Hat and I'm also coach here

for this tag. Hi everyone, I'm Kente. I'm from Huawei Cloud AI. We are a AI agent company. So, I'm also the tech lead of the uh tech workloads and also working on some community projects as well. So, thanks everyone for coming. We're going to talk about TAG Workloads Foundation and start off with really what is a tag at all? Um, talk about some restructuring that took place

within the last year. Um, specifically what this tag does, Workloads Foundation. Go into our community activities. And then really this is all about the projects. So, uh really shout out to the projects and all the great work that's being done there. And then how you might be able to get involved yourself. Uh, so what is a tag? A tag is uh not listed here as what that

actually means, but it stands for Technical Advisory Group. So, this is a official body within the CNCF. Uh, and its main goal is really to support projects uh in many ways. Um, and really scale a lot of the contributions by the technical community in the form of projects. Um, we'll get into what scaling means. Um, as well as well as really uh help with cross-project communication and

support So, there are many projects um in the ecosystem. And a tag is one uh avenue to help help the projects. Uh, often times uh facilitate communication between different projects that are sort of aligned on similar technologies, maybe cross uh collaboration. And then if there are missing pieces within uh the the projects that are maybe missing, we can help identify areas uh could reach out to other

projects that are not part of CNCF, and maybe help them become a member in the future. Um, and the the TOC, the Technical Oversight Committee, is a small group of people. So, tags are there to kind of augment their work uh and help with the the great amount of work that exists to kind of coordinate all these things. And then um provide technical expertise And again work

with projects and people like yourselves uh as they move through the ecosystem and the landscape. And this is why scaling is important because there are many projects and a limited number of volunteers. We are all volunteers in this organization. So, uh these are the list of the current five tags. We are right in the middle there, the the Workloads Foundation. And as you can see there's a

broad scope here from containers and virtual machines up to scheduling and uh WebAssembly, serverless, as well as things like CICD and so forth. So, uh it's a broad range here. Uh, so again just to reiterate and kind of go through here, reaching out to projects is a big thing. Um, and supporting uh a lot of the projects work. Uh, having a kind of the a place to

go to. So, I'm a new project. I want to maybe be involved in CNCF. Where do I go? Who do I talk to? A tag you can find kind of aligned with your um area of work. And then tag members will uh also assist with uh technical reviews. So, that's when you're applying for sandbox or going for uh kind of the different levels through incubation and graduation,

there's a review process along the way. And uh us in the tag can help assist with that as well as provide review ourselves as well. Um, there are initiatives which we will uh such as white papers um that the community works on and gets published officially through the CNCF blog. And everything we do is in the open, right? So, it's open to everyone, public meetings. Um, and

anyone is welcome to join. So, when I talk about the technical review, just kind of defining, there is a standard process. And we [snorts] defined and kind of formalized this a little bit more last year. to really define standards across the tags so that we could apply um kind of the the review process and rigor uh equally across the the different bodies of of of the the

different tags. Um, and then again as you're going through the different levels, there's certain phases for sandbox that you'd want to look at for questions and things to concentrate on. And as you get in through incubation and graduation, that gets a lot more in-depth into uh the life cycle of your project. >> [snorts] >> Um, so just quickly, I mentioned the kind of the reboot from last

year. There used to be eight tags. Um, a lot of what was focused in workloads was formerly called runtime. And now we are down to five tags. And if you'd like to know kind of the history of how we got to where we are today, um there's the original issue and then kind of the explanation for um why the tags were restructured recently. Okay, and over to

you. Yeah, so what is our tag, right? TAG Workloads Foundation's mission is to define and advance practices and standards for running fundamental cloud-native workloads. Whether they are like execution environments or life cycle management, um this is our mission to help improve And we have a long list of topics that we are interested in ranging from containers, special OS, runtime to CICD. And things that are out scope

uh are things that are not mentioned on the left. And also any end-user directed and initiatives are also out of scope. And obviously anything that's not cloud-native are also out of scope. And this is the current leadership of the TAG Workloads Foundation. So, now we're going to talk a little bit about the work that's happening within side the tag. Um we have exactly one subproject at the

moment. If you would like to do a different subproject, please please propose one. There's a nice lovely link to a set of issues. Um, I'm part of the batch systems subproject. We I feel like we do useful stuff. Um, we have a lot of people come in and talk about problems in batch scheduling and other well, it's just batch scheduling. But there's a lot of topics to

cover with batch scheduling. So, we've talked about data locality, we've talked about topology across the cluster, topology on the node. We have um queued up a workloads API which I know is coming out in this current release. Um so, Kevin Hannon's going to come in and discuss that. We have a lot of really interesting topics with me and them. we also have this landscape document that we

maintain. These are the current projects that exist um within batch we have meetings bi-weekly on Tuesdays at 8:00 a.m. PST, which isn't too convenient for Asia, but it does hit both Europe and America the America area. Um these are our examples of our discussions. Um, current initiatives, we have the scheduling for cloud-native AI. We have a white paper we hope is mostly completed. We're just waiting for

final review from the talk to publish. Um and then we've started this benchmarking project which I was talking to Nikki about earlier. Um, but basically how we find utilization for a cluster if you have a particular scheduler. So, you don't want 40% utilization as your max utilization. You want as close to 100 as you can get. So, there is some prior work done on a framework. So,

we're trying to figure out how to get that going forward. And then we'll talk a little bit about initiatives. This white paper was the batch subproject and one of the AI groups under the talk. And if you want to go read it, feel free. It's mostly in state. Um, you can also go and join it and comment on it if there's stuff that we're missing. Um, there's

also this group that's looking for contributors. Um, it would be nice to get it off the ground. So, if you are interested in a gentic systems, please reach out. There's a QR code. Um, add comments to the GitHub link. Is anyone needing to do that? Okay. We have roughly 30 other initiatives underway. You can go to this link and look at the various set of them. We

have some examples here. Or you can propose one if one is interesting to you that we isn't currently going on, we can talk about it. Um and you're welcome to push it forward. We always need more help. And there's also a concept of community groups. So we don't have any running now, but if you have a particular subject that you need discussed um you start a community

group and then you can have discussions with that. That's a little more informal. And then here we go. You see we have a lot of initiatives, so we want more contributor to join our community. And then let's move to projects. So I mean, we are engineers, so we are more familiar with projects, right? Steve mentioned like uh as a tag we we basically have two goals. Like

the first one is like to identify the the gap as a common problem across different projects across the community and then we try to find a solution. And another one is like um we hope to grow grow like help you grow your project, right? So it's not about the community, but also like we we will evaluate your project especially when you like uh moving your project from

one stage to another one from like sandbox to incubating from incubating to graduated. So we'll check the health and the maturity of your project. So first let's talk about the graduate graduated projects. it's not easy to be a graduate project. You have to do quite a lot of things. The first of all you like you have to be widely adopted across the community to to prove that

you are somehow like important standard component across And also we we need like under a good condition of the governance. For example, you have a diverse approval group because we we don't want our project be controlled be controlled by a company, right? And yeah, also security and compliance is also very important. So we we actually have a like long list of the requirements for the to graduate

a project. So if you if you if you are interested, if you have a project you want to be a graduate project, you can click the link and see the detail here. So let's start with like a CICD we are quite familiar with like we have the floss and Argo graduated like many years ago. But if you take a look at today's CICD GitOps is somehow the

common pattern for the to deploy the workload today. And also database are very important. You lose your data, you lose your user. So we have like Vitess and TiKV and also many years ago. I mean, yeah, 6 years And then we have the scheduler and the orchestration. Yeah, like Kubernetes is the first uh graduated project in CNCF and we also have KEDA which is and the Knative

for like zero to one auto scaling and the Crossplane for like you know uh you don't need to write code to deploy your infrastructure deploy your platform. So they Knative and the Crossplane graduated last year. So it's not very far. And then we have the container registry like Harbor. Like you can use Harbor to store your image in the OCI formats and the Dragonfly to uh like

OCI artifact distribution and and also I I want to share one interesting thing I I've seen this day. You know, this day we have AI and the AI model is quite quite large. So distributing the AI model is is very I mean painful because I mean again the model is very large. So I saw some innovation in the Harbor and the Dragonfly. They they collaborated together. Like

you can right now you can package your model as the OCI format and you can use the Harbor to store your model and then and then you can using the Dragonfly to dispatching your model. So it's it's somehow a convincing and a solid solution to me. So yeah, if you if you are building something like model service it it might be interesting. And we are very glad

to see the collaboration between different And the container runtime we have a containerd CRI-O which are the fundamental project components around the like CNCF community, right? Okay, then let's move to incubating projects. So uh I think the the uh several difference here is like as a incubating project you don't need to be like widely adopted across the community, but you have to have some several user. And

also you have to prove that you are growing your community. For for example, you have you have the roadmap for your project and you have like you are growing the your maintainer team. So it means like okay, we want to moving in the same we we are moving in the in the right And also we have the like a template for the incubating projects here. So yeah,

feel free to create. And a lot of projects here like Kuma. We also have the Kuma maintainer here. So and we also have KubeFlow, Volcano, OpenKruise. So yeah. And for the OS container runtime virtual machine like KubeVirt, Lima, Firecracker. So Lima just became became incubating project last year. So And all the serving we have a serving serving is you know, serving is really really important these days.

And when we talking about the WebAssembly we also have WasmCloud. So all kinds of workloads we can see here. Okay, so uh about sandbox. So sandbox is something like the the the initial stage of the project and uh it usually represents the innovation and some experimental ideas. So yeah, if yeah, we we we can talk about how to apply for a sandbox later, but yeah. So we

highlight four projects here. AMD yesterday highlighted in the keynote and the Kai scheduler for AI scheduling and the KubeElastic like we we we usually talking about when we talking about auto scaling we talking about scaling from zero to one one to end, but the KubeElastic focus on scale to zero. So it's it's quite interesting. And also we have Open uh Choreo it's like it's like developer platform

for you. Like it includes the CICD GitOps observability. So yeah, worth to take a look. And then I hand over to you and to talk about how to get involved. So hopefully you guys are not overwhelmed by all the projects and initiatives we just mentioned, right? Uh we we'd love to give you some ideas on like high level at high level on how to get like really

involved in this tag. So we have the they are bi-weekly community and also like Slack channels for you to raise anything that you want to discuss and mailing list. You can also contribute to all the initiatives, subprojects and white white papers that were mentioned by Ken and Mauro. And you can also help with the project reviews. So if there's any project that are to move levels or

to join CNCF there are dedicated there are dedicated subproject review meetings that you can join regularly to and contribute to something called domain technical reviews. I believe you mentioned that Steven mentioned that in his slide. And you can also work through the project review process, right? You can work with different project maintainers and CNCF TOC members and also tag members. Um and at KubeCon you can help

us with a tag booth. We don't have one this time, but we may apply for it in the future. And you you can also contribute to the maintainer session content if you'd like to bring up any initiatives and any work basically any work that you're working on that are relevant to this tag. Uh so >> to mention the sandbox application. You want to talk about >> No,

maybe maybe Mauro can Okay. So yeah, sorry. I forgot to mention that we also have if you want to apply for a sandbox application, you just open ticket in the under the TOC repo and you will be waiting in the queue and we have a dedicated meeting we call a subproject review meeting to review the project and hopefully good luck to you. Yeah. Yeah, that's pretty much

it. But if you can think about other ways and help us recruit more community members to contribute, let us know and feel free to join us. Thank you. >> [applause] >> Yeah, I guess we can take questions cuz we have 9 minutes. Okay. Hello everyone. My name is Mauro. I am one of the maintainers at Kairos. We are a sandbox project. I was wondering why we didn't

show up in the list there to start cuz we're part of the workloads foundation. We're an operating system just like Flatcar, but we're at the sandbox level. I don't know if there was some process to submit it or something. No, no, it's okay. I'm asking not not That's a great question. Thank you for bringing that up. So, we literally just finished the slides within the last this

week or last week. Like Uh so, that's why I mentioned here like anyone can help us contribute the content to maintainer sessions. There obviously things that we can miss. Uh we are all human beings. We can all make mistakes. So, yeah. If you have anything that we should pay attention to or call out in the community meetings or through CNCF social media, uh just let us know.

Okay. And the actual question that was just because I just said but so, we uh Kairos itself is a lifecycle management for different Linux distributions uh via image-based immutable systems. Uh but now we came up with our own Linux distribution and it's it's part of the project itself. We don't know what's the process there. Like is it already included as part of the CNCF? For For us

it has the same licensing. Is it it's within the same repositories that we already use? Do we have to do a formal application to get uh hydro Hayden included? I don't know. Or is it just a given uh that is part of the CNCF so to speak? Anyone want to answer or I can also chime in. I I I can start. Um I guess I don't know

the the process of this was created after Kairos, right? So, you usually if you have a subproject as part of your main project, that would automatically be included. Okay. Um so, I'm not sure if that's the case for uh since you added it after. Uh I would suspect it would be, but we can certainly work with you and chat about that and and figure out the right

answer. Awesome. Thank you very much. I think that was a actually a a great question. I've been observing like similar situations for many different projects. So, I for example, Argo project has its own governance. Um We have clearly defined what are the four core projects within Argo. But then there's also a separate GitHub organization called Argo project labs where we host additional projects that falling into like

the the formal governance of Argo. And there are also projects like Kubeflow who are adding new like new uh projects. And there are also like projects donated from other communities that are wishing to join Kubeflow. Uh so, I guess like different projects handle it in a different way. So far, nobody's complaining about it, but this is definitely something we may want to bring it to uh maybe

CNCF TOC's attention to see if there's anything uh we need to do. Sorry if I may. Yeah, because um there are topics there that are a little bit more complex. Like for the all the codebases for example, it's just a GitHub repository. It's not a problem. But uh what about logos and you know, everything that comes behind in terms of legal, intellectual property, and all of I

don't know uh if we need to talk to someone directly. Yeah. I can answer the logo. The logo one, there's a CNCF group that does logos. So, you'd probably just work with them to make sure that it was allowed. Perfect. Thank you. Maybe I Alex, we have a TOC member with us here today. So, so I would I would suggest in in that case you speak to

the um the the the CNCF staff that you were doing the onboarding with for for the sandbox because they would have the process for for onboarding the the the subproject and the intellectual property logos, name, and all of those sort of things. As Stephen said, if it is a subproject and it's like loosely defined, then you probably actually don't need to do anything. Although it would factor

into the maturity cycle when you then go to incubation later on. I just want to add one more thing. Like if you have questions on like marketing, legal, and anything specific. I have every maintainer has access to the CNCF help help desk. So, you can submit issues if you want to answers quickly. Any other questions? >> Hi. Um Hello. Um I'm Lucas. I have a question about

You You mentioned a lot about the workload being CCD, a little bit of of K serve, etc. Um more and more saying um better production in a Kubernetes ecosystem, you could be leveraging one of those one of those um building blocks CCD itself in a way that you you blend with other tech core technology. Say, you want to CCD, but on top of that on top of

that you want to maybe uh use a bit of AI uh in a in a you know, do CCD in a node, but use maybe a model that you have in in K serve as a different step. Is Is there any um way to see if the existing projects are intertwined already in that in that regard? If if they are kind of sharing aspirations of Okay, my

CCD my Argo CD is I see K agents as an example, right? The Do you have like Cilium and and Argo CD agents? But maybe for the the other core building blocks CCD if if Kubernetes could have this vertical where or just horizontal, should I say, where all the all the building blocks could could have maybe a shared common uh idea behind like more like aligned to

K K agents and K serve K gateway. That's uh like I guess it's project specific. It depends on how each project communicate with each other. Like some maintainers from different project, they do share ideas and ask for collaborations every once a while. But there's I don't think there's any established formal process for it. Uh understood. You know, because sometimes technology comes so fast that maybe everybody's to

adopt at the same time and create this kind of flakes that you go you adopt one technology like K K serve in ML ML flow, etc. Uh but then you have something like um Kuberay or or VLLM. I saw that you mentioned uh LLMD as one of the projects. I wonder the the steering towards adopting from from this type perspective will be what's going to be the

next progression of that. Depends on the ecosystem, I guess, Yeah, it depends. Like for example, like model on the model infant side, it's a pretty crowded space and very competitive as well. Uh different vendors may have different solutions. Uh even though we have like working group serving within Kubernetes, right? People tend to come up with uh new project. But there are also like shared common parts like

the gateway API inference extension, uh inference perfect. Some projects can be shared across different um uh vendor specific projects. So, in the future we hope each project can come up with reusable components uh to be shared with each other. For example, like RMD is using uh Nvidia Dynamo snake soil library and K serve has integration with RMD. So, there's a lot of collaboration going on among the

these different projects. So, yeah, I don't know if anyone want to add. So, I have a one example, right? I think uh you are mentioning the inference extension. Uh you before it's like it's a side project. I'm not side project. It's It's a project and not belong to the gateway API. But now we are thinking about like moving the API back to the gateway API to make

it more standard. So, it mean it So, it mean we can share the same API across different communities. I think this is something uh the community is doing, but it's more like uh project driven, not like not um yeah. Yeah, yeah, yeah. So, maybe but but it's a good point like should we like identify the gaps and uh like have a like a consistent API across different

projects and uh yeah. But this is a good good good point. I just want to say one point about different projects maybe doing the same thing as well. That that's actually im- important and the CNCF is is here to ensure multiple projects exist and not pick one in in particular. Um and a lot of times through sandbox reviews and through kind of the maturity levels uh opportunities

for collaboration between those projects can be identified as well. Like maybe you're doing the same thing, so use a common library and develop that together. Um but having diversity amongst, you know, any technology, having multiple things is is actually critically important. Cool. And I think we are just about out of time, so thank you very much. We'll be here for any other questions. Thank