 Just to give a quick introduction. So what do we do with CD events? It's a common specification for continuous delivery event. So there's a lot of fragmentation in the CD space. There are a lot of tools that you can use for different parts of your workflow from writing code to getting a software into production. And all these different tools they interact with each other within each other in different ways. So often you have to build, I guess, this kind of metrics of integration point-to-point. It becomes really complex to maintain and troublesome. So we came up with the idea of, let's define a common language, common dictionary, using the event-based paradigm for all these tools to talk together in a common language so that we can kind of repaint the picture to something that looks more like this, where you have different tools in your pipeline and they can all send CD events, they can all declare what they are doing, and then you can have some kind of broker that collects these messages, store them, and then you can take decision based on this information you got from these events. You can apply policies, you can have triggers, and decide to trigger different parts of your workflow based on that. And so, yeah, so the main, I guess, idea within CD events is to bring interoperability to this space. And the other thing that we are looking to help with is observability, so that you can take informed decision in your pipeline, basically. So, because when we went from the initial picture to this event-driven approach, there are some questions that may become harder to answer, like what is running right now in your workflow, what steps have been executed, if things go wrong, where things broken, and how long does it take to run the whole thing. So, if we start storing events, collecting them and storing them, then we can bring this visibility and we can collect data, we can build metrics, we can provide nice view about the entire workflow. So, interoperability and observability, these are the two main things that we are trying to solve with CD events. Well, a bit of history, maybe. We started within the CD foundation. We have an interoperability special interest group. We started discussing about interoperability, and then another interest group was created out of it, specifically to look at the events in the area of interoperability. And so, the CD events project was born out of that, and we had the first commit in October 2020, and then it's an incubated project in the CDF since 2022. Is it 2020? I need to check the slides, sorry. So, we announced zero-one release in Detroit last year, and then the initial focus was orchestration event, software configuration management CI CD events, and other features that we have a cloud event binding. So, cloud events are a CNCF standard for envelope for events in the cloud native space. So, we have a binding so that you can send this CD event information through cloud events, and we initially released also Golang SDK and support for some developed metrics. And so, we have been working continuously on CD events, and we've brought some more features. So, we expanded our scope to continuous operations. So, we have incident events that allow us to kind of complete the side of Dora metrics that you can create with this data, and to do things like automation for remediations. So, we had great contribution from the TestCube folks that contributed test events, so they can be used for notification, test-driven automation. We did some work in the area of software supply chain security, so we introduced an artifact signed event that you can send when an artifact is being signed. And also, we have a lot of quality of life improvements, like we improved the ability of the specification, we introduced JSON schemas, we produced examples for each event. We also refreshed the website, hopefully to give a better experience when you're onboarding on CD events. We have some nice features in the SDK as well. I don't want to spend too much time here, and we got some really cool adoption. I think it was announced in the keynote already, but there are a lot of more projects we are talking to them, both we have today, so we have the work in progress, so we have the Jenkins that is done, so we have experimental supporting tech, don't we have Spinnaker that is happening, TestCube that is happening, but we also talk to a lot of other communities. We were in Amsterdam, at CubeCon, couple of weeks ago, I guess, and we spoke to Argo and Flags folks, we spoke to Harbour. Harbour, the registry project, they announced cloud event support, so they are interested in also using something like CD events. And other projects, TraceTest, JairReleaser, ShipRide, Jenkins X, they all expressed some interest in this. Okay, just keep through these, maybe I wanted to tell a little bit about the roadmap that we have in mind. So we definitely want to expand on supply chain security type of features. So right now we introduced this artifact signed event, but we want to have more better data model in CD events to capture information about bombs, provenance, attestation and all these features that are important to the supply chain security. Another feature that we started discussing is the ability of signing the event themselves so that you can actually trust that the content of the event has not been tampered with. This becomes important if you start relying on these events to build features that are important really for your execution workflow or some suggested even, we were discussing with the CNCF up delivery tag and a Qtcon. And one question that was really interesting is like, can you consider your set of events as a signature of your artifact? So if you have certain sequence of events happening, you say kind of this represents an attestation of this artifact. And yeah, you could think of a model like that, but you need to be able to trust your events again, right? So something that we, sorry, we had been working on for some time and hopefully we'll get in the next release and it's a very important feature is the ability to link events together. So we have context now within the events in the data model that we have that allows you to connect different events with each other. We have this concept of subjects. So subjects that are unique IDs so you can connect through events using this mechanism but we want to have the ability of having more explicit type of links within events. So we are discussing how to best implement this, right? So you want to be able to say like, okay, I got this my events storage and what are all the events that are related to this artifact or what are all the events that are related to this pipeline execution or what are, yeah, so that's the kind of things. We are discussing things like compositions. So we have certain data model assumptions today that are simplified because we wanted to get started and get the ball rolling. Like we have artifacts and deployments but we usually model like deployment is a deployment of one artifact but we want to have the ability to say, well, you could have a deployment of a composition of artifacts so the ability to compose this existing data model in more complex type of things. Yeah, there's plenty of work to do in documentation examples, SDKs, proof of concepts and yeah, so today I didn't mention that though let me go just back a little bit. So today, CD events is specification and SDKs but in this picture there is this broker in the middle with the policies and triggering bits and that becomes very important when you want to start receiving events and doing things based on that and we think that there is space for standardization in that area as well. We don't have that part in CD events today but we know that different initial adopters or people they implement this within different companies so that's an area where we can try and expand our scope and get some standardization as well. And so that's included in the roadmap here broker and policy. How are we doing in time? Yeah, so we, as I was mentioning we have a few collaborations ongoing with the, still with the CIG and the CDF so we have one special interest group in the CDF which is about best practices we shouldn't say they're interrupt and one initiative they're driving is the reference architecture within the CDF so we want to work with them to include CD events in the reference architecture and we talked as I mentioned with the CNCF tag up delivery and we are also discussing with the Value Stream Management Interoperability Group they're also interested in bringing interoperability in the Value Stream Management area and there is a good amount of overlap with what we are doing. Right, yeah. Yeah, I think that's enough. Hopefully people manage the lunch. Yeah, I would just open the floor for two questions, comments, ideas if people want to discuss about something please take the mic and I'll just. Yeah, so Andrea we were talking about the broker so when we were doing, we called the message bus but we used Kafka and I've been working on a concept of a workshop that does events and we were talking about using Red Panda is there a particular technology we've talked about with using for the brokers? Sorry, I just wanted to get some notes. So no, we have not talked about any specific technology yet. We have not talked really about this yet. But it's very much like to start the discussion so please. So in general, I'll tell you that our experience with Kafka has been fun. Is that why broker sounds very much like broken? Yeah, I'll say, well, no, look, the Jenkins guy is here I don't want to hurt his feelings but look, I'm going to tell you I don't like Java in my pipeline. I do have a bunch of Jenkins servers though. But I don't like the Java in the pipeline and then the first thing we ran into was the message limit size like when we were doing this which is three years ago, think in the past Kafka's default message size is one megabyte, right? And so we have, if you guys went to the Fidelity presentation they had this evidence server where they store their stuff. Well, we've got the same similar thing and we ended up putting a one megabyte limit on what you could put into it for the same reason because you didn't want to be able to put it on the Kafka but you couldn't put it on the Kafka bus if it was bigger than a megabyte. So had I been able to do it again I would use Red Panda, which is completely well, it's supposed to be Kafka, like Kafka-like like you don't have to change much to switch to Red Panda but it's missing some of the features. But what we found out was is that we didn't need the features. I just need somewhere to stick these messages and I need to be able to replay them if something dies. So if one of the consumers dies I just want to be able to go back to where it left off and pick up again. So that was something I was thinking about for a workshop, so. Ask, should the CD-1s project really endorse certain technologies or that type of stuff should go into reference implementation or something like CD-1s could come up with reference architecture here's the broker, we use Kafka, they use Rabbit MQ and different implementations could make choices of different technologies like CICD orchestrators or so. For the broker, using Red Panda would be reference and I'm not saying that the CD events should do anything other than say, hey we've got this JSON blob you need to be able to stick on the message bus you consume it however you want and if you want to use Rabbit MQ you get to do the bleeding when all the rabbits die. So, however you want to do this you want to use Red as fine when it runs out of memory and it dies, use it. And so that's what I was thinking more is that the Fresca reference architecture type thing where we go, hey we used Red Panda here but you can use whatever you want, right? And you get to pay the consequences, so. So are you kind of saying like maybe for MVP-1 we start with this initial broker and then expand to it with more capabilities because I agree, Kafka, I've dealt with enough Kafka to tell you, yeah, let's not go near that. So any more comments? They didn't have any wireless mics like this one, I was a kid. What were we talking about again? Kafka, Confluent, I've got Kafka Cloud, I've got Kafka on-prem and I've got a connector between the two of them so that I can run stuff in the cloud and run stuff on-prem, don't do that. Yeah, no, no, I hate Kafka. I'm just saying stay away from it but to be not specific to Red Panda, but for MVP-1, hey, here's what we're gonna do, MVP-2 will include RabbitMQ or whatever you wanna use. Whatever queuing system, is that what you're kind of building on? We can add more as more people adopt it. Yeah, so the idea here is that CDEvents doesn't say you need to use this queuing system or this message bus, CDEvents is like, we've got a JSON blob for you and it does really cool stuff, put it wherever you want, right? If God help you, if you wanna write it to a file on a Jenkins server and pick it up by the next Jenkins server and read it in, you can, right? Yeah. Exactly. Yeah. It's like, you're right, your solution is better. Get to work. That's how you get contributions, right? Yeah. Now the thing that we ran into is that I didn't wanna rebuild the brownfield pipeline so I've got this pipeline, it's well known, it's full of Jenkins nodes, which, you know, Jenkins guy over there, it's full of Jenkins nodes and I couldn't go in greenfield, it was some other thing. I couldn't rip out all the Jenkins and put the tecton in. I had to just say, okay, look, there's a JSON blob that you have to produce and you post it to my evidence server to use your terms and then the evidence server will put the message on the Kafka bus and then all the little robots that are watching that bus will just do stuff, right? And that's how we attacked it and it was because there's teams that like needed to use curl to post a JSON blob and I didn't wanna have them have to write Avro. What? With bash. That sounds beautiful. It does. No, and I fully agree that we, going back to Jenkins, let's just talk about that. I'm just kidding. No, let's not. We had, when we released a plugin for our team, we send data to Kinesis, but we're like, let's build this in a way so if someone wants to contribute, they can add a different endpoint. And so we built it in a way to where it's like, okay, right now you can do an HTTP endpoint or Kinesis, but if you wanna do it, we already have the general framework, you add a new button on the UBI, you add your classes, and now anyone can contribute and I think that's a great way to go. If you've gotta start with one and then say, here's a contribution if you wanna add a different broker type. So I think that'd be great. What did you guys use? Kinesis. Kinesis. So for the rest of the world, that doesn't wanna repeat the same experience over and over again, it'd be awesome to also contribute your findings. Like what you didn't like about Kafka, can we have not only an example, reference implementation, but also have running conversation on these other things. So you don't have to convince everyone over and over of the same thing. I'm glad we claim any technology. You're scrutiny, I mean, all software is bad. It's just a matter of what software works enough to get your job done that doesn't get you fired. Right? The nature of open. Yeah, that's right. Yeah. Open awkward and open embarrassed and open humiliated. That's right. It's all okay. Yeah, it's bleeding edge and you get to do the bleeding. And you get to keep all the pieces. That's all I got. None of that helped Andrea. You know, my Kafka rep is gonna be like, dude, what are you doing? Behind you? I just wonder, so a deployment release, is there any scope, obviously with the t-shirt open features or any scope for feature flagging? Because if you've got version one running, but you've got different feature flags operating on that version, then your version one doesn't really mean very much anymore. There are things going on inside that artifact that don't really have very much to do with the version. I wonder if CD events is gonna tackle that scope or is that out of scope? That's a great question. It's not something with considered yet, but it seems like something relevant to me because like you said, especially if we want the ability to connect events and I don't know, you have something changes in your production environment. Maybe there was no, there was a deployment, but not a deployment that brought in any new software version. That's something that changes the configuration. I guess it depends a little bit how you model an artifact, if an artifact is a combination of the software and the configuration that goes with it, or if it's, but like if you consider something like open feature, then you're storing the flags in a separate service, right? So the feature flags. And so it might be that you don't have any change at all in your main service, but you have a change in behavior because you actually have a, I guess you could see it as a deployment to the open feature configuration, but it may be something that we might want to model more accurately and more specifically. So yeah, that's a great question. I don't know if people have any comments on, yeah. Yeah, I just wanted to say that I agree with that assessment that that's like a part of a deployment. And one of the things that I get worried about, especially as we're expanding context, is that we're not, be sure that we're looking at it as, okay, is this a sub context of something, of a concept that already exists, right? And so you're talking at least, in the way at least I'm hearing it, it sounds like your feature flags are something that the deployment section of CD events should be implementing or thinking about or there's a place for it there as a part of that deployment, you wanna change this configuration as it's deployed. But then that's still a part of a deployment event and not something completely separate. And just understanding the context and where those things fit in, let's us put standardization around it, it allows for us really strong lasting language models. And that's the thing that I like most about CD events, this is the way that it's very well-sectioned. And as long as we think in terms of where are these events happening, what's the sub context, what are they a part of? We can get really, really, really granular about it and keep expanding it and make sure that CD events sticks around a long time. That's a very good point. That's why I brought it up here because I'm sure we don't all wanna fragment this to the nth degree and then it becomes useless that you've got an event for everything. We'll take this kind of offline, but a deployment is an artifact. To me, it's an artifact going out whereas feature flags happen at runtime without any sort of redeployment or anything. So sure. And to that point, it's like you can have something watching for this deployment event and then say, okay, I need some runtime changes, I need the media. Or you can signal it as part of the deployment saying, when this deploys, these are the runtime things that need to be done. Maybe that's the terminology then, a runtime event or something that happened. And then that's regardless of feature flags or security or anything that happened, yeah. So the one thing you have to be careful with is that if you get too many different topics, you can't tie them back together. And so we did with our event driven system since we're in ISV and I deliver these units that the customer can deploy, right? About 270 OCI images, for example. And they all have very RPM-like names because I'm an RPM guy. So they're name, version, release, platform ID package. That's how we track everything through the system. So if I deploy that name, version, release, platform ID package, the event has that data in it and you can tie it back together. And then you just reissue the data, right? And then so in the context of the deployment, what I would say is that if you have a deployment event and it has feature flags in it and you change the feature flags, that's a new deployment even though it's not. You put another event on the bus that says deployment and then maybe there's a deployment false and then you change the feature flags but that way you can track it because you're like, okay, give me all the events that happened for this deployment, right? And then so it gets really, really granular. And then so the one thing we did was that the NVRPP is what we call it. They're all strings and they can be whatever you want them to be. And so don't do that. It becomes a nightmare, that whole observability thing. Yeah, they're just a nightmare. So don't do that. Anybody else got anyone on that? I think the way that, well, the group that I work with, we're looking at links and way to link events across systems because this issue that you're talking about now, it's like what is gonna end up being the final product might have been deployed several places across several organizations to come up with something final. If we can't track that with links across multiple things, it's, you know, it gets lost in the shuffle quickly. But I agree with what you're saying and as long as we hold the categories strong at the higher levels, we can do things within granularity in that scope. And so it should be fine to do both, right? And this is about this organizational excellence where if we've categorized these things properly, we leave space for some granularity. We can hold our stories as they work best for those organizations. And at least when I first saw this, this is about this time last year, that was the first thing I noticed about it. That is, if we start at the top, we can control everything else as we flow down. So we're gonna be fine. You know how you get more microservices, right? You write a microservice and then you end up with five microservices and then you got 20 microservices and then you got a hundred microservices and then you're like, why do we have 270 microservices? The same thing happens with the categorization of the events, right? So you do have to have some self-control, right? Don't let him go and design this thing because he's just gonna be like, I don't think this will be a problem and a thousand event types later, you're like, oh, this is a problem. Oh, it's not. Yeah, it is. Then Jamie comes looking for you. Why they don't let me touch certain systems? Could I bring him down? Just a logistic question. I'm not very good at taking notes, but I'm doing as best as I can here and I'll stick them on GitHub in an issue and I would really appreciate it. I mean, if you have more opinion and better notes than I have to go in there and express farther your opinion, so to compensate for my lack of note-taking. Those notes look fine. Okay, yeah, oh, that's brilliant. So we can get a transcript. Cool. So I have a question, Andre. Just thinking from the Python SDK, how do we get this into like AWS code pipeline? How do we work with these cloud providers to like really bake in CD events? Yeah, that's a great question. Anyone got the answer? So I know that I'm pretty sure Azure and I know Azure supports cloud events and so if we have cloud events as the base envelope, then you extend the cloud events with whatever you want to extend it with and they should support it. And then the schema is, we provide a schema. We've got a schema, right, Andrea? Yeah. Don't write JSON without schema. So anyway, yeah, we provide them a schema and say, hey, look, we've got this really cool thing. You should adopt it. And then this is an extension of cloud events. You're not gonna break anything if you're only running cloud events. This is just an extension. Now, I don't know who we talk to you because those are corporate entities. Yeah. I mean, we're partners with Microsoft. They might listen. Yeah. We could probably just find their headquarters and then stroll up and say, hi. You wanna talk to us? Good. I'm all in. When? Yeah. Yeah. We should look into. Yeah. Yeah, no. I'm all in. I like this idea, yeah. But yeah, so I think the strategy has been to start like we're doing, integrating into tools, get a critical mass, get like people actually starting to use events and then it becomes easier to show the business value, the advantages. And then you go and have this conversation. So yeah. When are we getting that Rust SDK? Yeah. It was a joke. Like the hotness of Rust. I'd love to learn Rust and have time to write it myself. So if anyone is willing to spend like one day with me and show me how to get started, I can do it. So I mean, with this, I mean, if we, my view, I'll speak up. My view. Oh, it's recorded. Okay. So be careful what you say. What? Look, my view on this, pretty simple. One, I do believe that if you, we have projects, CI CD projects and CDF, they should be supporting CD events. This is not something that we tell them to do from the CDF TOC. We explain the benefits, why it's a good idea. I know Spinnaker is working on it. I know Jenkins is working on it. And the hope is to have a user of those two using CD events to say, this is the benefit. This is the value we get out of it. We start to add other things. At that point, it becomes a lot easier to go to the commercial CI CD providers and have them at it. Reach out to our friends at Harness, or our friends at Octopus to play. Once that happens, then it's approached the cloud vendors because they are very jealous of certainly the reach that Harness and Octopus have. And go to AWS and say, hey look, code pipeline really needs this. Go to Azure, Azure DevOps really needs this. So it becomes a lot easier. So I think the first step is we need to, at CDF, we need to work really hard to support our projects to support CD events. We need to show them that it's a good idea. The second thing is that then it's reaching out to our friends at Commercial CI CD. And then from there, I think it's the next step is the cloud. I think that's how you get there. I don't think you go straight to the cloud vendors because I don't think they're spending a lot of dev budget. And if you've got a dollar and you're AWS, where are you gonna spend it? EC2, RDS, or are you gonna spend it in DevOps line? Just adding to that one of the things that I think is super important is to reach beyond cloud for things delivery. Cloud is not the only place we deliver software or software is delivered. There are a lot of companies that are delivering smaller packages to devices, all types of devices that have all of the same problems to deal with. Creating some momentum around that will improve your ability to draw in cloud vendors because if a company is using CD events to solve problems outside of cloud and they can tie this to the work that's in the cloud, then that benefits them. So when we talk about evangelism and getting more buy-in on CD events, have we ever thought of doing a presentation to different foundation projects? I know that as a member for certain foundations, you get webinars and stuff, but have we ever thought about using this as a resource for other projects at CNCF or at the CDF? And just hosting an impromptu, not impromptu, because it'd be scheduled. But just an informative fact-finding, like this is who we are, this is what we're doing, and look for other projects to your point, Robert, to get them on board with using CD events, getting onboarded now as opposed to later so that they can bring their two cents and maybe there's answers along the way to serve some of the problems that you've just identified that these projects are actually trying to solve by virtue of being a project. Again, like we say, the CNCF has 159 projects housed within it, right? CDF has nine and there's the Eclipse Foundation, all these other foundations that are out there. And so I'm just wondering like, should we do to Dedece's point a broader stroke and look at not just cloud, but on-prem, IoT, that kind of thing, is this kind of in your roadmap for evangelism or is it something that maybe the CDF can help do, make some connections, try to figure this out? Yeah, that's a great question. So I think we've done advocacy in the context, I guess like KubeCon, open source summit, false dam, so we went to this kind of conferences and CDCon, of course, presenting the project. And we've been to talk to different project maintainers individually. So we have been, I think there is a new initiative of workshops as well within the CDF and one of the potential topic is CD events. So that would be in line, I think, with what you're suggesting. Yeah, so I think the more we do in that area, the better, if we can reach more community, that's great. The only thing in my experience, it takes a certain amount of effort from the CD events project side as well to be involved in the community, to getting things started and moving. And I mean, for Jenkins, I mean, the friends of Fidelity that did a great job of driving that. But I think in many cases, you need really to be there and be in the community work together on an RFC. And so, yeah, it's a scaling issue that I see, but that doesn't mean that we shouldn't spread the word more and more. So if we can expand our reach, for sure. Argo CD, I need it to make events. That's what I want. So let's go find the guy, he's here, right? And we'll go ask him, because you talked to them at KubeCon, right? Yeah, yeah, yeah. So, I mean, those are places where we could ask, can we get, and then, of course, as good citizens we need to go help and contribute upstream, start a pull request, all the hard part, right? And I've got in my copious amounts of free time. Let me ask you, you said Rust, is that the next critical thing we need to look at? Because I commented on the Rust SDK issue, I was like, oh, this looks fun. Well, if we build a Rust SDK, then we can run CD events from Wasm. I'm here all night. What do you need to say? Did I get it right? I have a question to you, Elin, and Jar, and Jamie. I don't see Jamie here. So you said you started using CD events for parts of your pipelines, isn't it? Do you visualize them? So, are you going to answer that, or? So we've just now collected the data and we're seeing a full picture because of CD events. And one of my awesome teammates is starting to build the dashboards, build the visualizations. Now that we have- There's no CD events. Yes, tying it end to end. So. It does not happen in open source. Yeah, like a React framework that takes the event and visualizes it for you so you don't have to go rewrite that code. Cause we did that in-house for our dashboards in our proprietary stuff that we did in open source. So, which I want to open source, but we learned a bunch of lessons while we were building ours and we're thinking that maybe we just green field it again and go build it again outside. And then, but yeah, the React framework like when it gets the event, it just creates the page. Maybe like, since you said something, you are looking at this might be a topic to start. No, I can't write JavaScript or React at all. You can write. I could do it in Rust. Mark, definitely. You can write your ideas. So we should move all of our dashboards to mark down. Oh. Oh. Oh, I like this. All I'm trying to say is like you are trying to figure out how to turn those into some kind of visualization. Right. So maybe that conversation could take place purely around CD events in the community. I don't know. Cause I was going to ask Andrea, information we're interested in is, like any other company that is interested in this, not unique to anybody. Haven't started that work yet. Like, how do I do call it? How do I do compliance, how to measure security? Even if, you know, it was a product, it's something that broke production. Sorry. So we want to build something. We should probably talk in this community to see how to start, because make sure we started in the right way that would benefit and then more people could join. Versus we building something and then even contributing it. Like we did with Jenkins, right? We built it first. And then we put in the open source. This one should probably be built in partnership with the open source. Yeah. I mean, that would be great. And whatever. I guess one of the objective of creating interoperability and standard from the beginning is to foster this kind of initiative to make sense, to begin with and then to exist and to happen. And I mean, the final open source code that is written to produce this kind of tools, it doesn't have to be in the CD events organization. It can be. That's something we can discuss. But as long as it happens in the open and with collaboration, I think it's beneficial for everyone. Because like when I think as a user, because I've worked for an end user company for a long time, like when you look at JSON, when you look at Slice, when you look at GitHub, you listen to talks, oh, this is great, all kinds of benefits. But when you show people some diagrams that shows things that takes those events and turns them into red, green, yellow boxes, connects them to each other, then people could see that the power of this much better. Instead of asking them to imagine stuff, we can show them. Here it is. This is the simplest thing you can get from this. You can come together as much as you like and create different views of your software development lifecycle based on the audience. Program manager needs different, something different than developer and security people, for example, just. Yeah, because you've all these personas in every organization and then this information can be just Slice, Dice, rolled up. Andrea, do you have that slide? Can we see that slide that had the things at the bottom? Yeah, and so all of those things underneath the broker, I mean, these are the potential, especially the metrics and the view. How, what we storm in, that was a great argument you guys had about it. I love that. Notification for the events and the view and the metrics are potential projects in themselves, right? And we have the context for metrics just around door metrics and what that would look like, but being able to have something that does that analysis, that shows you that end to end, that could be a project in itself. And the question, and this is not a CD events question, this is a CDF question, this might even be an interoperability sync question. These are all things that come out of interoperability. This is showcasing what's interoperable. It would be great if it's under the CD events umbrella and you took care of this for everybody. But I think as a community, we should step up and kind of find ways to do this with this good work that you're doing and extend it as a part of CDF and find projects like that and companies like the ones that are in here that have the need and want to drive it forward. Thanks. I would love to start on the spec, like a GitHub conversation around this to start having a discussion on ideas, tools, because this would be a lot of fun. I'm a stats person and I'm like, great, let's go. I don't want to write Python. I want to build and analyze data, but we have to have the data. Do you want us, can we start that? Just start a conversation? Yeah, absolutely. I mean, we can start a conversation. We can use the working groups we have today to discuss things. If things grow beyond what we can fit in our working group, we can spawn a new working group and we have like 20 people that they want to build a dashboard or a metrics tool, then they can start another working group. So, let's start, absolutely, and then we can scale this. Awesome, give me five minutes and I'll go start the post. No, I'm scared. I might need to. I've always seen people talking like, I see some new friends with us, like any thoughts around the project, any comments, like how do you feel based on what you are listening? Anyone wants to share their opinions? Careful, Fatih will sign you up for a work group. No, no. Yeah, hello. Yeah, I can share my opinion. The first time I see this project on this conference, I never heard about it. I'm like one of the speakers, I will be speaking tomorrow. How we do stuff in our company. But it's, I quite intrigued, honestly, because we do very similar things ourselves inside our company internally. And we essentially, when we were talking, I read through white paper and your specification and stuff. And it looks very like, thought out, like I mean, it's, you put an effort in it, which shows, and yeah, so it's, I feel right now, we build a lot of stuff ourselves. So we started using Kubernetes in 2015, a lot of stuff, which we have right now did not exist. And we had like, yeah, we're building stuff ourselves. So right now I feel like this, I want to participate essentially after hearings. And at least want to see how does it evolves. Maybe I can contribute, maybe I cannot. And I definitely want to see how it can be used by our company and how we can give back. So we're very impressed. Yay! All right, Katna. Hello. Nice to meet you all. So yeah, same as my colleague here. We are colleagues, my colleagues here. It's the first time that I hear about CD events. I saw it today while browsing the schedule. And yeah, it resonated a little bit with it. I saw some, like a similar project of standardization in the JavaScript world with some testing frameworks, like reporting through the same thing, like the same event so that you can have like the common standard set of reporting tools. And it was, that point was hard to, really adopt them in the like existing projects. So yeah, I think also here, if I got it right, also it's, I'm not sure. I mean, are there existing tools, I don't know, Tecton, Argo or many of the CDF tools that are using CD events? Yeah, so yeah, we're working with many communities. So we have support in Jenkins. So Tecton, we have an experimental controller that produces CD events and we have on the roadmap to get more out of experimental. We started, we have an RFC approved for Spinnaker. So implementation is ongoing. So that's happening. Yeah, so we spoke with other communities. I know Jenkins and Sheepright, they expressed some interest and they know, they're also both kind of related to Tecton. So as long as we, as soon as we get good support in Tecton, it makes it easier for them to build on top of that, to continue like CD event, yeah, adoption. So yeah, so we are working with several tools, communities. Yeah. That sounds good. I think it's really important like maybe for new tools that to start like to have this implemented like from the get go, I mean to popularize it. So that I mean, yeah, to just close the gap because if other tools are going to appear like, and they don't have these, then it would be the same story. It's hard to put it in when it is not like from the get go there. But yeah, I think overall, I mean standardization is always good, right? To have a standard set of events and this, at least from what I understood it's like, it will be great like it will be easy to connect tools between them because it will be a standard interface and it can be connected more easily. I mean, the ecosystem will be more open and it will not be close just like, okay, I have Spinnaker and I'm just working with Spinnaker because I cannot connect ARG or other CD tools. Yeah, so I know, keep the good work. Thank you. Thank you, yeah. I mean, there's a just quick story. So when I, I'm a maintainer of Tecton as well and it was implemented the cloud event support for Tecton. And so when I wrote the events there, I was like, okay, we use cloud events for the envelope because it's a standard. And so what do we put in the payload? And I was looking around for a standard about that and I found none. So I joined the interoperability working group and we started, we had the, oh, we have a discussion about events going on. Oh, that's great. And so that's my story and how I got to working on CD events because there was no standard and we are writing a new tool and we need a standard for that. So like to the point that you made, it's great if new tools being created, they can adopt these. And we are trying to do as much advocacy as possible to spread the word. So hopefully that happens, yeah. So since we are representing the back, back row, so I thought, okay, I can also take up the mic. So nice to meet you all. And this is the first time I'm also hearing about CD events. In my company, we are working, developing the internal developers portal. And we were trying to basically analyze all these tools which CNCF provides. We're trying to go open source as much as possible like everybody. And CNCF provides great tools in terms of deployments and things like that. CD events looks a very novel idea and standardizing the all, especially the CNCF tools first. We have Argo CD, we have Flux in this space, Jenkins. There are a few tools like CircleCI and all Shipwreck I heard. So yeah, definitely it's a great idea when we try to standardize things framework and something which can, I just want to talk about the adoption here. Something which, I'm sorry, something which really can add to adoption is the UI. Yes, it'll be like a cherry on the cake because this is something it is not available like, there are more propriety tools in this space who gives you the nice UI, UX, you talked about it. And if it is an actionable on top of that, like you have the events generated then you can take an action on that as well. Yeah, there'll be a standard set in that area as well. So just my two cents and great to be here. Great, yeah, that's a great point. And indeed, it will be great to have that kind of visualization happening in the open, in open source. So hopefully we can collaborate on building that. Yeah, I've been craving for something like that and building POCs and oh, now I have to visualize these and okay, let's print this log file with all the events and it's not that appealing. Yeah, so, yeah, great point, thanks. And thanks for joining today. Any more, anyone else who would like to bring up topic this class? Oh, yeah, Fatih, yeah, yeah, okay, yeah, Gerard and then, sorry, just. I know Fatih, we talked, what do we do with Github's, Atlassians, those organizations? Cause one of the things we did, those two did, was with event-driven architectures, distributed systems, like web books, you can configure anything at some point and our friends in JFrog here, if they had an out-of-the-box plug-in that would say that when you publish event or promote event or you do something, it automatically is generating a CD event for the purposes of the artifact here. If it was in SonarCube, it would be a SonarCube event with all that data and either CDF works with those vendors or those tools to create it once. They could be even open-sourced as part of the CDF project or the CD events project to hold everybody benefits, right? We build it once for the community and everybody, then we scale it very quickly. Like, we from the foundation, obviously, like JFrog is one of our members, very strong supporters. Like, we have been talking with our members and so on. That is one thing, but at the same time, if organizations like Videdi can also talk to vendors, then we could get their attention faster. Now, it's happening now because projects are adopting and some organizations, vendors, they are watching what's happening here and I'm sure we will start seeing some movement there, but if you want that to be faster, then you could pass the same message as well. What are you doing about this? Like, do you have any plans? Is it in your roadmap and so on to get that conversation closing loop, yeah? Yeah, so thanks for the presentation. Like, just to build up on what the last question was about, for things like get-up actions, would this fall into the same space for city event usage? Because there are many actions happening there and there's a lot that can be benefited if we can get feedback from, hey, this one happened. I don't know where it would help, but like from my own organization, we are pretty get-up action-driven and I don't know if this would be proper use case for city events. Yeah, I think, sorry. We do have a get-up action. I don't know the depth of it, but there is a get-up action, kind of not SDK, but that you can import. Well, we are working on a kind of adapter to transform like get-up action events or webbooks into city events in the kind of SCM type of space or like, I don't know, commit, create the pull request, open those kind of type of events. The other thing is, I mean you could generate events within the build destruction that you have in get-up actions. If you have abstractions that are not natively included in get-up actions, so let's say you're building an artifact or doing some type of testing and you want to send test, do you want to send events about that? You could probably trigger them within the action itself. And I think one of the things that we have in the roadmap is to have a JavaScript SDK as well, as I think a lot of, it's quite popular language in that space, but I don't know if that's what comes to mind, but I don't know if there are any other comments or ideas about get-up actions. Everything you do produces an event, right? And then like in my particular system, we kind of did it based off the audit trail and the audit trail produces the event, which is a little different from what we're talking about, but either way, you produce an event and somewhere you store that event and so the more events you track, the more data you have and then the more analytics you can do against it and the more decisions you can make. So the get-ups operation could definitely be tracked. Hey, we triggered this get-ups operation 17 times a day, right? Do we need to be triggered at 17 times a day? So there's all kinds of data to be gathered there to do metrics and do analytics against. So I would say everything produces an event. At least that's how we ran it. And just to kind of round this out, at least the way I was hearing you say it, yes, get-ups should produce CD events. I mean, that is what we're trying to say, but it circles back to this thing we were saying about the vendors, get-ups of vendor. And so if companies, I mean, J-Frog has stepped up and they're joining the thing, they are, I'm gonna just give them that note, right? Because they're sitting next to me. And yeah, it's gonna be in the J-Frog products. Yeah, okay, it's gonna be in, but the companies that have the need like Fidelity, like my company Apple, there's others in here, JP Morgan Chase, that I also work with those guys. We need to say this is the standard we want, and we need to contribute to it and say this is how we want it to work. And it will follow because we make the statement. And it will show up because we make the statement and we're the folks that buy the things. And that's why I'm here because I'm seeing this community of people, we're all solving the exact same problem, okay? There's not, the difference between this problem, company to company is not great enough to dismiss this as a way to do it, right? And so as long as that happens, we can get it to the next step. As long as we communicate, talk about our needs, come to the meeting, participate in the SIGs, do the things that you have to do to get into CDF to make your voice heard, to be sure that what your company needs is included. It will get included and then this will be the standard, okay? So we have a few minutes left. Yeah. Pressing. Is there a white paper? Oh, thanks, Tracy, for bringing them. Yeah, updated May 2nd, 2023. I made sure to put that there to differentiate between versions. Any last comments, questions before we wrap up? Yeah, just a simple question. Just to help my understanding if no one else have any questions. So you like showed like architectural pattern how to implement this kind of a system. And it does look like something like because it's a wind driven system and we built multiple wind system in the past that really look really closely to secure errors type of the system come out very responsibility segregation. And is it correct or not? Can it built in such way and do you trying to do something like it? Sorry, I'm not sure I got the question is built in. I mean, like, is it resemble secure as type? Oh correct. Even driving system in the core do I understand it correctly? Or does it not? Does it like contradicts to like if you see events as a commons? Yeah, the query sites is like your UIs or some kind of analysis engines which runs on this events and different types of components can generate another type of commons which are basically not like carries a state. No, yes? Yeah, so. Sorry. No, I'm just thinking. The idea is that you can build a state or state information out of the events that you generate but not single component. They don't need to be aware of the overall state of the system if it makes sense. Yeah, yeah, okay, thank you. Yeah, yeah, okay. I think if I was understanding that correctly, you can also use CD events to trigger other systems. There's the triggering to start a thing and then, you know, that is a so you can have some sort of stateful progression if that's what you want to build it. The interesting part, at least, again, when I first looked at it, is that you have the choice for how you want to build it. It is event-driven. That's the purposeful part of it for the brokerage and storing it. But if you wanted to go system to system to system, you can actually carry it that way. That was a use case. Yeah, ours is completely asynchronous. It's safe. And we let the development teams have an SDK and they were able to build their own toys that read and catch messages and do other things until they come back to our demos and they show us stuff and I'm like, I didn't think of that. And so you build the framework for the event-driven system. You've got the data type for the event-driven system that's defined. We're all speaking the same language. And then you can go and just build out whatever you want. It could be asynchronous. It could be synchronous. You could have pieces that depend on each other. We've got this concept of these watchers and they watch the Kafka bus from messages and then we have ones that do specific things. Like I've got one that like when you build this particular unit, it goes and deploys the documents, the documentation for it, right? I got another one where when the guy pushes the documentation and it gets uploaded, the watcher grabs it and publishes it outside to the rest of the world. And that's not even like part of the build pipeline or anything. These are just random use cases that you can use once you have the event-driven framework. So, great. Now explaining that to all of my developers was fun. Yeah, yeah. So, thanks everyone.