 First, let me introduce myself. My name is Ricardo, Marginale de Oliveira. That's how people call me in Portuguese. I'm a senior software engineer at Red Hat. And trust me, this is my profile picture. I'm saying that because, fun fact, it's my first time here within the Kubeflow team. And people saw that picture, and they didn't trust it. It was me. I don't know why. Anyway. Well, let's get straight to the point. Let's talk about the agenda. We have to know more about what exactly is Kubeflow. I know that people might just describe as an MLL platform, or maybe a full AI solution, maybe. But anyways, I think it's always good to draw a line here for people to understand what the Kubeflow project is. Then we're going to expose a little bit of data of our last user survey that was held mid-last year, I guess. So based on that user survey data, we're going to talk about the good parts, the bad parts, and guess what? The missing parts of Kubeflow. Then as part of the release team, and more precisely, I am responsible for, I am the release manager for the upcoming 1.9 release for Kubeflow. So we're going to talk a little bit about the roadmap for Kubeflow 1.9, what you guys are expecting to see. And also, just talk about the future. And we're not saying maybe we can do something different in that talk. Instead of finishing the talk with Q&A, questions, and answers, we can try to change it to comments, the future of Kubeflow, right? OK, so that's a recent picture of the architecture of Kubeflow, I guess. I think it's recent. So that describes basically that Kubeflow is something to be made on top of Kubernetes for hybrid cloud. So we can use on self-hosted local environment or even public clouds, right? There are some components that composes the Kubeflow distribution, like, for example, notebooks, pipelines. I think those are the oldest components we have. Central dashboard, training operator, cat tip, case serve, and others, right? All of them are based on other open source libraries, just like Jupter, PyTorch, and so on. So basically, that's what we call it the Kubeflow distribution, right? So this one is just a snippet of the user survey data held in 2023. So you can get some key takeaways of that about, like, what are the most common components used by the users? So pipelines, notebooks, cat tip, those are the top three. There are other things to discuss about that, but I don't want to go deep into each of these bullets. Let's try to do it differently. Let's talk about the good parts of the Kubeflow, right? People love pipelines. People love notebooks, cat tip, and the case serve. That's according to the user survey, right? Of course, recently, we noticed that with the transition to KIPv2, things are not going so well, right? Feature parity is not, well, it's not 100% development. There are notebooks. There's a planning for a notebooks 2.0 that is still ongoing. There's cat tip that's still missing. Thanks here for LLM training or hyper parameter training. And there's case serve with some other things that needs to be improved. But no matter what we say here, according to the last user survey, those are the good parts of the Kubeflow that we need to focus more on making them more stable, right? At least that was according to the last user survey. So what about the bad parts of Kubeflow? I think I heard someone saying right there about the installation. So deployment, as I can see, most users here are deploying from raw manifests. And I guess they are doing, I think, from master branch. But yeah, we understand that this is a pain point, especially because there are other things around here. Like for example, we made a change in the documentation recently to describe the installation process through two different methods, from the raw manifest and from the distributions. But the distribution tables might be outdated, might be using older Kubeflow versions. So there are some parts of that that doesn't look good for users. Speaking about the documentation, there are undocumented parts of some components. I can't talk about the pipelines because it was the one I'm more familiarized with that has a lot of components inside pipelines that's not well documented. It's not even documented, right? Exit handler. Does anyone know what it is? It's not documented, right? It's not part of the documentation. There's also tutorials and the part of upgrades that we need to talk more about it, right? So getting this data from the user survey, we understand that those are the things that we need to focus more on what is going wrong with those parts and what we should do to make them better, right? Again, it's not me that's going to answer the question. It's not the Kubeflow team, it's you, the users, right? Okay, moving on to the last part of the section of parts of Kubeflow, those are the missing parts. The user survey asks for missing parts that, for example, model registry. I think it was the biggest desire component that you users want to see in the Kubeflow distribution. There's monitoring models and there's initial setup. I think it's also part of the installation. But I wasn't here when this user survey was held, so I'm not sure if that's the good context about installation and initial setup. Maybe it's the date two of the pipeline's installation. That's my expectation on what is the missing parts of Kubeflow. And I get it and I think this is part of something that's not, again, not documented in Kubeflow documentation. So I have the Kubeflow installation, what's next? What I should do to keep my environment stable, reliable, and how do I prepare for upcoming upgrades, breaking changes, and so on? Again, I don't have the answer yet. I'm expecting that you guys will help me on that. But all I can tell you is that, at least for model registry, that's the easiest thing to work with right now, is that, yes, we're looking for adding what I can say is a model registry component, okay? As for the others, maybe we need to discuss more about what are the right expectations on monitoring models on initial setup. Okay, so for roadmap of Kubeflow 1.9. This is extracted from the roadmap file, which is merged into the Kubeflow repo. We're gonna target the Kubeflow Kubernetes 1.29, right? I think that's the latest table release. Maybe I'm wrong, 1.30 is the right release. Not yet, I think, yep. And there's also, there's a working progress to have Kubeflow as a CNCF-graduated project. There's some work during the Kubeflow 1.9 release to make that transition to become graduated under CNCF. There's still a lot of work to do, but we're still working on it. We're working hard, by the way. Those, there are the LLM APIs that will be part of the training, sorry, the training operator and cat-tip. The new component, as I said, model registry will be part of Kubeflow 1.9 at alpha release. Don't expect too much of an alpha release. It's just to say, hey, this is what we think it's what the model registry looked like. What are your feedbacks on that? So I really appreciate, if you guys can tell me more about what do you expect of a model registry component, if what we're doing for a model registry component, it's exactly what it looks like, and what we should do to make it better. There's another thing that we notice in Kubeflow pipelines that since they migrated to version two, they prepared to something like having an agnostic way to connect pipeline engines. And they started with Argo, then they brought Tecton as a pipeline engine. So far, those are two separate components. There's KIP and KIP Tecton. The plan for 1.9 is to merge them into a single code base. So that makes really sense what the pipeline engine agnostic architecture means, right? And we're not saying that maybe someone else might contribute to another pipelines backend implementation using the same code base. That's what we wanted to do when we envisioned the IRMO and the pipelines backend agnostic architecture. Awesome. There's this tight deadline for Spark operator. It was a recent thing that we did for Kubeflow. Spark operator was donated to the Kubeflow project, but it was a very recent transition. I think it was not more than a week ago that this happened, but it's just some kind of a spoiler here to say, hey, there will be a new component out there. Maybe you guys are gonna like it. Maybe you guys are gonna hate it, but it's always good to hear from you the feedback for that. So this is what we want for Kubeflow 1.9. There will be for sure a lot more Kubeflow releases to plan about it. So what are our expectations here? That is a broader picture, not only for the Kubeflow code itself or the distribution, but we want to finalize the CMCF graduation to finally say that Kubeflow is a CMCF graduated project. We want to establish a TOC that's the name for the technical oversight committee to help make the governance of Kubeflow from a technical perspective way better improve the decision-making on what's better, what best fits for the Kubeflow project. We already have the steering committee established. There are some of them here in this room. We want to do the conformance testing because it's all about distributions, right? I see that the majority of people are deploying Kubeflow from raw manifest. I don't know if that's just because they want to get more control over manifest or just because they don't know what the distribution looks like. What is a distribution means? So is the block KF distribution is open data hub distribution, AWS distribution? Does no one know about that particular definition of distribution? Probably with the conformance testing we can make this distribution meaning more concrete in the Kubeflow project. And there's also ARM64 that we want to make. I know that some of the components are already ARM64 enabled. Some of them are not, but we want to make this the full project by ARM64 support. And that's what I'm just announcing here. We are hosting another user survey to gather more information and more updated information about the Kubeflow community. This one will be a bit different from what we did in the past. There will be split into phases and the link I just sharing here is part of the phase one. So we want to get more information about the user's profile and what the users like better or dislike better in Kubeflow so we can make more accurate data to make decisions better at this point. Don't worry about copying the URL here. I'll be sharing on the Kubeflow slack. Sorry. Oh, there's a queue. And there's a QR code that is going to... In the back on the table. Awesome. Thank you, Amber. That's how improvement looks like. All right. Sorry. You got it. All right, guys. So that's the time that we're gonna dedicate some more minutes about asking the users what are your pain points. We really want to hear you guys what makes Kubeflow better, what makes Kubeflow maybe not so good or what are the missing parts of the Kubeflow, what we're missing here. So it's everything about users, users and users, right? So that's it. Thank you. I have to defend Ricardo to some degree here, especially regarding the installation upgrade stuff because we are really missing your feedback. For example, we just released Kubeflow 108.1, the first to release candidate a few weeks ago and so far we have not received much feedback. So if it continues like this, we cannot improve the installation and upgrade process very much. We need testers who come to us well. It went completely smooth. It's amazing. Oh, I had this problem and so on. And then for the next release candidate, we can improve, but this is only possible with your help. Thank you, Julius. Yeah, I'm gonna reinforce that as well. It's part of continuous improvement to give more feedbacks from the community. So we really appreciate that you guys try out the one, what it won, RCZero release. Let us know about your thoughts if there are any blockers bugs in what is missing in that release. So I really appreciate your help with getting more feedbacks on that. Any questions, comments? Any other comments? Everybody's happy. We're not. We're not satisfied over at, as you can see from all this slide. Yeah, maybe that's my talk is useless and people loves Kubeflow. But here we go. The way it is. Hey, what I see is that you have some issue with communication with the community. So if you go back, let's say two years, what would you have to do differently? So you have more feedbacks. So a lot of you we found out today that you're getting Kubeflow straight from manifest. You're not getting it from distributions, you all that are in here. But a lot of our users are getting it from our distributions that we have yet to have a real definition of. But we do have a list there. And so we don't have insight into those pain points. And when COVID happened and we weren't getting together like this, we were missing that feedback for a long time. So we're just now starting to get that feedback again because there was this out of sight, out of mind, like a lot of projects happened during COVID. So now we're trying to be back at top of mind to our users again. So we do have issues collecting data, which is why we're pushing that survey very hard here because a lot of you aren't sitting in our Slack channel. You're not on our Kubeflow Discuss mailing list. You're not in our working group meetings, but yet we know there's pain points. And so we wanna let you all know, as Ricardo pointed out here, where we can meet you at and we have all these different places and now we're meeting you here today. So please take the time to fill out that survey or jump in our Slack channel or join our Kubeflow Discuss or any of our working groups and help us improve because we wanna improve for you, not for our health, but for yours and for your projects and your organizations. We want to improve to make it easier for you. And I really appreciate that question because I just found another missing part of Kubeflow, where to get help, where to get feedback. So like Emerson, there's this Slack channel, there's Slack workspace. Now we're doing through a different transition because of the CNSF graduation. We are now focusing more on having the Kubeflow channel on CNSF workspace, but our Kubeflow is like workspace, it's still very active. So no matter what your feedback, your questions, you can reach out on any of these Slack workspaces and ask questions, right? So in one time, we're gonna say, hey guys, let's move everyone to the CNSF workspace and then we're gonna focus on answering questions on the CNSF Slack workspace. But for now, reach out to any place you want and let your advice be heard. Hi, thanks for presentation, thanks for your work. I just have a minor comment. So I mean, I understand that you want to see feedback for release candidate versions. Yes, but my personal opinion is that with current installation process, it's actually quite hard for me, for example, to deploy free release candidates, for example, just to test them because it's a lot of work. If I use distribution, it's probably easier, yes, but if I use pure manifests, well, what I'm trying to say is that probably if there was a home chart, for example, then it would have been much more easier. I just, okay, it's a release candidate. I would just change text, image text for everything I want. I do have them deploy, how great. And well, it's broken. I know that it's broken and now I can start from opening this rest. You know, I did something and so on, but personal opinion, minor comment. Thank you. Yeah, no worries. We know that some people like customized, some people like home charts, some people like operators. I didn't say that loud. But yeah, we understand that it's more an opinionated thing than understanding the full picture on what makes an installation break every time. I think the root cause of it might be undocumented installation steps or better installation steps documented. And yeah, we are not discarding having home charts in the release. If that's like the most desired feature, maybe it's time to rethinking the way we distribute queue flow for users, right? Thank you so much for our feedback. We really appreciate if other people could chime in and say maybe it's better move to another solution that makes installation better. That's what we need to understand for our users. So from the solution perspective, what is the biggest pain points, right? Upgrades, we know that it's the biggest one. Installation, initial setup are the other ones. But that's it. Let's think that this is part of the big decision to make considerable changes in the project. And now we have a break. I think we're actually over two minutes when we're supposed to let y'all go. So thanks for the questions. Come back in at 25 after and we'll start talking about Catube and training operators and other good stuff. So hope to see you back at 25 after.