Jenkins Cloud Native SIG, 18 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 12 3 21 Cloud Native Sig Discussion on CloudEvents!

Description

Excellent discussion on CloudEvents! And the proposed Jenkins GSoC project idea of CloudEvents plugin. :)

A

Great welcome to uh today's spa native sig meeting really happy because we have um regina salatino today, uh who's joined us to discuss um some cloud events, work and welcome. Marcia. Do you want to say hi.

B

Hello, everyone. Yes, I'm super happy to be here and super happy to be a mentor again for google summer of code. I've been, I was doing, mentoring way back when I was working at brethren and I've been missing that for for so long, and I think that just this mixed between junking sex and cloud events, it's kind of like the perfect thing for for me to come back and help here. So whatever I can do to help, I will be doing that.

A

That is awesome. Thank you. So much for being here, um do you want to talk a bit actually because you're you're here with um shown? Would you like to speak a bit about your ideas for the cloud events plug-in and how that's evolved recently in your work.

C

Thank you like uh joining uh and uh we'll definitely need like a lot of help regarding some cloud event, specific uh subject, matter, expertise and thanks for joining. So uh this the idea for the cloud events plug-in we just have had like out of the blue and the first time I actually threw this idea against. Someone was oleg and he said. Okay. This is a great idea. Probably you should do it and then, after that, we brought it up again in uh the cloud event: seg, sorry, the cloud native, sick and yeah.

C

It's good to have you. So the idea for the cloud events plug-in was basically just be able to listen on cloud events, be able to trigger uh jenkins jobs on cloud events and also, uh you know, be able to emit cloud events for uh jenkins jobs projects or whatever events that are being created uh by jenkins and kind of uh like uh have it in the cloud events format.

C

Instead of the format that is there right now, there is a plug-in called rather plug-in, which you are looking at initially, and this plug-in basically uh kind of helps like kind of helps with the eventing and stuff. And initially we were thinking of, like you know, converting those uh events which you see in the statistics, the other plugins to like cloud events plugin, but um I was uh doing some reading up yesterday and I figured I I was under the impression that discovery and subscription was already implemented for cloud events.

C

So I don't think that's the case I was so do. Do you have any idea like about the discovery and subscription when it might get uh like so.

D

C

In the cloud sdk and probably.

D

C

What an idea of what you might have of how events should be uh done in jenkins.

B

Yeah, so that's a very good question so, like the subscription and discovery, it's kind of like a work that it's starting, so I wouldn't rely on that that much for the the scope of this project right so in general, what comes to my mind when you mention cloud events and jenkins is exactly what you mentioned. So basically it's a plugin that is going to emit events whenever you run things inside jenkins and also an endpoint that it will be exposed for people to be able to submit cloud events to jenkins itself.

B

I think that that's pretty much what like the scope of the work should be and again, when I'm saying emitting events, that's usually sending a post request to a url that you can configure as soon as you provide that we can hook that thing with other tools that are going to be able to deal with forwarding cloud events to our systems and doing all that stuff.

B

So it is pretty simple: it's pretty well scoped the only problem that you will have and that's the problem that we are also trying to solve there in the cdf is the format of the events. And what events do you emit right?

B

We should try to avoid emitting jenkins specific events, because if you emit jenkins specific events, then you are like tied to the jenkins ecosystem. But if you emit like a standardized events, then you can interact with other tools and that's basically what we are trying to achieve there in the cdf.

B

So my proposal to you would be to start like experimenting with creating a plugin for jenkins that basically emits cloud events and then also exposing an endpoint for consuming cloud events coming from other systems, and then we can focus on the format of the events themselves.

B

Right, like you, can start with a simple cloud event with not much data, making sure that you can emit the these events at the right times when, when you know, when jenkins triggered a job or when it finished and then figuring out, what uh information is available inside the jobs for being able to include that into the events, you need to kind of like figure it out.

B

What's kinda like the unique identifier for all the events that you're going to use related to the jobs right like you will need to correlate all these events that are related to the same kind like pipeline execution and uh that's kind of like where the the you know, the details becomes a little bit more tricky.

B

That's why I would love to first kinda like see something like a plugin that it's emitting an event basically and consuming an event, and then we can just go into the details of the data that we're going to include in each uh different event that it's going to be emitted by jenkins. Does that sounds like a good plan or it's? Is it too complicated?.

C

Yeah, this is actually the same thing I was thinking of uh like starting off with uh emitting events uh like on events such as you know, starting a job or completion of a job like these would be like good places to start. So the idea uh where I got this from was basically techtone has uh uh support for cloud events and uh it kind of uh ms cloud events in in that way.

C

So uh in the design dock, you might have seen it just shared with you earlier uh in that design dock you, you must have seen that there are these. uh There is a table of cloud events which I've written and uh uh I'll just share it again, just in case.

A

Would you like to share your screen.

C

Okay, so this is. This is basically like uh what cape I came up with initially like how these events wait. Wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait.

B

We cannot see your screen, we can just.

C

I cannot see.

B

Your screen, no, no, not right now! Okay, right! Do you see that.

A

No not yet it just says: you've started, but it's it's still black. It's probably loading.

B

Yeah, can you try to like.

C

B

Sharing again.

C

Oh yeah I'll do that, I'm using another laptop right now, so it's not set up for zone.

C

So, there's a table at the very end uh which I will talk about a little bit uh so yeah this this I this this table. I I made based on the tecton uh cloud events table and what the resource looks like the event uh that happens on that resource and what the event type should look like, and this is the event type which would be emitted like at every event.

C

So if, if uh so, if a job is started, the event which emits which is emitted, the event type on that event would be okay, the job is started and the data regarding that job would be given. So when you say that uh you know those event, the format should be uh a bit more generic and not jenkins specific. I I didn't understand how we could steer away from like being generic in.

B

Good good good good, so we are defining kind of like as part of the cd foundation, these kind of like generic events, for this exact same reason right like if you do this, you emit these events tecton. It's not going to be able to understand these events right because they have a different set of events. So, basically what we are creating is this shared language between these tools, so they can exchange events and react based on different events. I think that I don't want to confuse you with that right now.

B

I think that if you get this working moving to emitting all the other generic events will be kind of like an easy thing to do, or maybe it can be a parallel plugin that we can create right, like it's going to be pretty similar. Just the events, format and the event types are going to be a little bit different, but it's the same mechanism.

B

So as soon as you can emit events for now and listen to events, that's something that I can see down there that it's listening for cloud events, I'm not entirely sure. How are you going to do that, but, as soon as you can do that, that's good right, like that's, definitely like a starting point.

C

So uh it's better to uh so. The point of this plugin is uh kind of interoperability between different things. So I think, if we start from the beginning to aim at uh you know uh supporting gender given. That would be. That would be something good. So uh when you say that these uh events, they are not very, they are not uh genetic types. So what would what would a generic one look like? Do you have like an example that you could get.

B

Yeah, I can send you a link so to some pull requests that we are trying to manage right now in the cdf that are basically defining these events. But it's basically the same thing but again, for example, the event type. It's not going to be io.jenkins, it's going to be probably something cdf related right and probably we are not going to use the the name job for it, which is kinda like a.

D

B

Concept, it's going to be something like task or step, or something like that or pipeline.

E

B

Example right so it's kind of like the terminology, the vocabulary and then the event types that needs to be a little bit more generic. But again, as you assume, I figure right like the content of the cloud events that you're emitting like the way of emitting the events, it's going to be the same.

B

D

One of the.

B

Things one of the things that I think that we can do as part of this project is also create. For example, the java mappings, like the java objects that are going to represent these generic events.

B

So so, then you can go to the plugin and add that dependency to that library, which is basically just defining the structure of this event. If that makes sense,.

E

Can you repeat that line please um the java mapping one.

B

The last the last part.

E

B

So, for example, right like this is going to be I'm guessing that this is going to be a java object that is going to be created inside the jenkins plugin, and then we are going to use the cloud events sdk in java to emit the events, basically right, so as part of this project, what we can do is like.

B

Instead of creating like a java object inside the jenkins plugin itself, we can create a separate jar file, a library that includes this kind like events, definition and then we can just definitely plug in the generic ones. Whenever we have them, we can also help building those generic events. uh While we are doing this project.

E

Kind of modularity.

B

Yes, yes, definitely most, mostly because of that, like the.

D

Interoperability.

B

uh Idea there that we would love to listen for cloud events, and we are not. We don't want to be restricted to just only listen for these events. Right for these.

D

B

So I wonder, I wonder if you have already like a git repository or something that we can have discussions or maybe create issues in there. I think that that will be useful.

C

So we uh so we uh started a bootstrap repo yesterday, uh let me send it on the chat here.

B

If you can add it to the document, that's good I mean so I can have that document as a.

C

C

uh And I'll also give edit rights to you, so you can uh probably expand it based on what you feel like can.

D

C

Have your email id? Yes, I will just put it here in the chat. Okay,.

B

Have you seen, have you seen something already for listening for cloud events inside like the plugin? Is that possible, exposing kind of like a rest, endpoint.

C

uh We haven't looked at the technical details, but it should be possible because uh I think the prometheus plugin works in a similar way. If I'm not.

D

Github github webhook one is very similar.

C

D

uh There's also the actual github plugin as well. Is that exposure to get her point for listening.

B

Make sense yeah it's pretty similar to that, so just exposing a rest endpoint where we can listen to events and then we need to. We will need to think about how to map events to do things inside jenkins right, but that's part of the definition I guess of the plugin.

B

So what happens when I receive a cloud event? What do I do with it and what kind of events do I support and which ones are not supported? For example,.

C

So when a cloud event comes by, uh you should be able to uh kind of put a cloud event trigger on a job uh which is listening on a specific cloud event and once that cloud event comes by, uh you should be able to trigger that job like if the uh if it is listening on something like a tech on a job completion uh like a task task run completion and uh this cloud event is uh the job is listening on this cloud event, uh so the job will be triggered by that. So that's good.

C

That is like the initial idea uh for uh implementation, yeah so and though, and the main configuration for all this, so the the only the question I have here is gareth. Maybe oh, you can also help out with this is: where do we uh do? We keep all the uh so all the information regarding what events we should listen on like on the sources for the events in the global plug-in configuration or in the jobs.

C

This is one doubt I have, because should it be global or should it be like localized to a job? Basically.

D

Are you talking about like a sort of a global allow list of events to filter on.

C

Yeah, something like that.

D

That's, I think, if you, if you wanted to do like yeah like like a a global or only interest in these types of events, then yeah global plugin configuration makes sense there. um You may also want to do it on the job trigger as well to say, like I'm, actually only interested in this particular type of event.

C

So, on the job trigger, I was thinking like we could, reference back to the uh global plug-in configuration uh and choose from there. uh Why I was thinking of doing in the global plug-in configuration. Is it it would be. This is more of an admin thing. You know like allowing certain cloud events.

D

C

Get into the system treating certain cloud events and allowing certain projects to listen on certain clouds. Otherwise I don't know, maybe I'm overthinking the security aspects of this, of what events could be listed on what you can't cannot listen on. So that's why I was thinking if you should uh keep it like. You know, per job basis like we're on a job. The user can define the source for the cloud events and or should we do it on the global configuration.

D

I can see there being a use in the at some point in the future for having the ability to filter out events of a particular type um if you've got a like a bad actor in a system. That's sending um invalid events or something like that. You know you may want an argument to filter something out for a period of time. That might be useful, but.

D

I think that's like a yeah future thing cara, I think you're gonna say something. Then.

A

Well, okay, these are just ideas, but one one thing you could do if you wanted to be able to control which events were going to be emitted from a certain pipeline. You really could write um a policy for that.

A

I think that is actually a great use case for a policy, and I see you know cd pipeline and then in terms of what who okay, when you have like okay, so these events are admitted and they're put in what, like a a cue that people can subscribe to like an information that is that pretty much how the system so then you could, you could have permissions right on who listens to that or is there? Is there not a way to filter who has access to what.

B

Yeah, but that should be outside of jenkins right, so jenkins, shouldn't have control, so jenkins should just admit it to an end point and forget about it: kinda yeah. We can then write some other components to deal with more complex things in there, but I wouldn't start with that. That's yeah that goes into more complex.

C

A

C

I think piping.

A

C

Yeah, so you were saying.

A

I I was just wanting. I was asking about the work, the event sega is doing and have you defined? um Have you been looking at how to define the data formats for the events? Is that already done, or is that, is that an outstanding question.

B

That's working progress and I'm really pushing to merge a couple of like. I have five pull requests in there, basically defining the vocabulary- and there has been a lot of conversations about like the initial vocabulary, I'm hoping to be able to get that merged by monday and basically, what will follow up from there is the definition of that vocabulary in cloud events terminology.

B

So at least the metadata of the events should be there and with that we can already go and create, for example, like a java model for those events- and I also have like a draft implementation in go for a go library. So that's where I am right now and uh unfortunately I really need to have those pull requests merged to then move forward and create the cloud events.

B

Definition, that's what I'm saying it's not there yet, but if we start with just sending like the cloud events that uh vita via beta is proposing right now, we can just move forward with that. Then swap the cloud events, definitions later.

C

Yep that that does sound like a good place to start and later on, we could add a issue or like a story for extending the extending to cdf events.

B

B

I don't don't get me wrong, defining the jenkins specific events. I think that it's also a valid thing to do right. It is something valid, uh but for interoperability I would just definitely go with the cdf event, so maybe the plugin is doing both and you can select by configuration which events are emitted.

C

Yeah that does sound like a good idea like that also gives us like some time uh to kind of figure out, like uh you know the initial bits without having to wait for the cloud event, the uh stuff to like wait for the events, uh cdf events to work itself out. So uh so you were saying: you've implemented a uh initial uh library improv for this one.

B

Yeah, so basically, what I've created is a small two things, this library that basically emits cloud events using go, and I have because I've been working on the vocabulary. I've already implemented some of these cloud events and then that library basically also provides you like a binary that you can use from the command line to emit the events.

B

So that's another possibility, so I'm not entirely sure the limitations from like building jackings plugin, but if you can call a binary from jenkins plugin, we can definitely use that or we can just create the same library in java. That's that shouldn't be a problem.

B

It's not a big thing. Just.

C

Time consuming it's it's basically like uh probably you can use it to like uh debug a cloud events listener.

C

So if it's emitting events, you could probably use it to or debug like a cloud and switch now, which someone is writing, because uh initially uh source sagar was actually asking me earlier like how should he get started on this and all I suggested that he uh he first like tried to emit events uh out of the jenkins plug-in and then and then kind of move ahead from there, and I am not sure how the listening part will work, because we're gonna have to read up on how the web of trigger plugin works and stuff so, but it it could probably be similar.

B

Yeah there is, there is one project in in the native uh community that basically, I think it's called sockeye or something like that that basically allows you to define that project as a sync for the events, and you can graphically see the events that are arriving there. So, basically, I think let me find it for you. I will just look for it and place it here in the.

B

B

Yeah I've just placed it there, so basically yeah. I think it's just a simple user interface that allows you to receive cloud events and see them kind of like while they are arriving.

B

It isn't go so that might not be the best thing but uh but yeah. I think that if you are planning to see and try to debug what's happening inside the plugins and see what are the events that are being emitted using something like that might help.

C

Yeah this is this- is this would actually be a very nice for debugging.

C

Yeah I'm going to put this down in the design dock as well.

B

Also, one thing: if, if I can mention something, is there any way to get like a jenkins instance in the cloud where we can put this flying.

C

We can oh so we can spin off jenkins, probably in a mini cube or something or like, uh while testing. So when we are testing the plug-in, uh we usually use mvn hpi run that's what I use for running the plug-in locally, with the jenkins instance, and then jenkins runs with just the plugin installed, and you can test the plugin from there yeah this.

C

Does that answer your question.

B

uh Yeah yeah, I was thinking more like on provisioning it somewhere in the cloud, I'm not sure if cloud which can provide us that but yeah, I think that like as soon as we can run it locally. I think it's fine for now, but then, if we want to connect different tools, uh it might be better to run it like you know, in a cloud provider or something, but that's fine, I mean we can definitely leave that for later.

A

When we get to the point.

A

I was just gonna say when we get to the point where we do need that I I can ask okay.

A

Sorry I interrupted you.

C

No like uh I was just- I was just asking for debugging purposes, because I was uh I was thinking like uh like I've, never used jenkins directly from the cloud or like debug max I've done this, like uh my jenkins, would run in an openshift cluster and we would and uh to test it against the openshift api. We would have to uh lower the uh we had to load the plugin into the volume and then restart the jenkins container, and then you know go ahead from there and test it yeah! It's it's a one minute.

C

It's it's a one minute uh task, but that one minute is long because, because jenkins takes a long time to restart so so uh I I recently have figured out that uh working locally is much easier in that way, because uh jenkins takes a a lot less time to start and you can, you can easily iterate on your portfolio.

C

But probably will figure it.

B

Out sounds good, sounds good, so do we have enough uh for getting started with that.

C

Yeah, I think so, oh what.

A

Do you say yeah, I think this has been great. I really wanted you two to meet and and to start uh projects, so this has been really successful. Thank you all right.

B

Yeah so now you have my email feel free to write me like to my private email and uh send me the links for github. If you add that to the repository, if you want to have like a weekly catch-up, that will be good just to see how it starts going, uh but no pressure right, like you, you have your times. Whenever you make some progress, let me know I.

C

Because uh cloud events is something that is, uh that is very cool, to see uh that this is the such kind of uh standardization is happening, and it's it's really nice to see like different tools coming together and like, and it's just it's it's great. So yes,.

B

Yeah awesome feel free to again feel free to bring me any time, and I will definitely keep you updated about the generic events. Progress. If I make substantial progress, I will let you know, and I will try to push you into that direction whenever those things are ready not before.

C

Yes, definitely that that would be nice thanks, molly great.

B

No worries a pleasure. Thank you, cara for the introduction.

A

Yep great, thank you for being here great meeting. um Excellent, any other ask any questions before we go or issues topics to discuss.

E

Yeah so um currently um today I was dealing with cloud events and how to send it through http server to catch up it on the another um local host port. So um it is maybe a coding related stuff. So maybe I will um should I ask now or like it's just a coding related stuff like yeah, yeah, okay,.

F

um Just a second.

F

Let me share the link.

F

E

Can I share a screen just to show that, like it's just a snippet of code, please.

A

Yeah, I I think you should be able to.

F

E

So are you able to see my screen? Yes uh so like here um I made a https server, so started a server on localhost 8080 and I read the door calls over java sdk.

E

So here it's making our cloud events and then attack, and here it's making the http uh url collection. But um I don't know exactly what here this line of code doing actually- and I read the doc also so um I'm unable to understand completely like how this is writing what it is actually doing. If you know like.

B

Yeah, I think that's encoding the payload of the cloud event into a binary format, so you don't really need to worry about that like so, for example, there, like with data you are including a json payload in there, but those that's basically codified into like a binary format when it's sent through the wire. So that's something that you need to do to avoid issues with encoding.

B

Basically, so you can send the same kind like a string to a different platform. If you're sending from linux, to mac or to windows, they should all be able to get that binary thing that it's compressed and decompress that and then just get the same text. That's why you're doing that? Okay, if that's kind of like what the documentation said, you just need to do it and it should work like that. That's fine.

E

Okay, okay- and this is just then um using that same um encoding to read that is it. Yes, that's correct!.

F

E

Okay, you are not sending. Are you sending there like the the message? No like currently just like um it's from the um example basic https from cloud events, so it's just like catching the local. um So in order to send it through https connection, should I need to serialize it with json, and then I need to send it and then converting it back into cloud events? Is it.

B

I think that's correct right like if you want to send it via http, you need to create so basically the cloud events sdk.

B

It's going to give you some helpers to create uh like the http representation for that, because some of these attributes, for example, with source or the id of the cloud event, is going to go into the http headers and the data it's going to be into the body of the request.

B

So as far as I remember the cloud events java sdk, they will give you these helpers to create an http request that then, basically, you just need to send using a library.

E

Okay, so is it like so it's like kind of I'm using the jackson that they are showing me to see deserialize and then um with their helper classes. Yes, they were.

B

E

Are going to probably use jackson for doing that, so and and just then doing a post request and just catching it on the another, maybe localhost um 1990 from 88, and just to then um test it to sending a post and right um yeah. That's correct, okay, okay and then, where this is using like after creating it into binary like some encoding is done into this object right.

B

Yes, that's correct uh so probably for for json, if you're sending json data, you don't really need to do the right to binary, but let's check the documentation. Let me check that because it really depends on on the format that you want to use to send the payload of the cloud event if it's binary, if it's just json.

F

E

Sdk there it is um so here is the basic https example. They are showing sending in this cloud. Events um yep yeah.

B

So if you yeah a standard client, let's take a look at that, like http client with http url connection at the bottom of the page yeah one of these things.

E

That's the same file that I showed you.

B

Oh okay, that's the same one: okay, perfect yeah, so the first one is basically just encoding it and just showing that you can just read, send and read the same thing right and if you, if you scroll down there, is nothing else in there. No right! No! That's.

F

B

E

B

Let me see if I can find it.

B

I know that I've seen some examples that just shows uh more advanced usage. So, for example, this one uh is there any like I'm not entirely sure about jenkins, but I'm pretty sure you cannot use like a spring boot in there right or the spring library.

B

I also don't know.

C

I don't think so.

D

But it does yeah, there's some quite yet like restrictions on the libraries that can be used inside jenkins for sending this, but there will be something there to do it.

B

E

Yeah one in conference, they also said you can't. I don't know um if I heard wrong, but I'm just confirming they said. You can't subscribe to a cloud events in basic studio, but you can do on a spring using spring.

B

No, no, I think that you can call that. Definitely right, like you can definitely subscribe to not subscribe. You can listen to cloud events right.

F

B

That that's again, that's just exposing a normal rest endpoint! It's like it's nothing specific to the cloud event, because at the end of the day, you're going to get an http request that have a cloud event inside it right. So the only thing.

C

B

You need to do from the http request. You need to parse it and put it kind of like inside the cloud event class yeah, okay recorded. I I think that this, for example this example here, let me put it in the chat- is something that you might want to look into. uh It's there as well, and basically it's just sending the the request to another server using http exchange, and that's basically what I was mentioning before: it's just basically getting the cloud event and creating kind of like creating an http request for it, but yeah.

B

Definitely the examples are not the best. To be honest,.

F

B

And this is because it's very kind of like low-level java, it's like java, with no libraries at all right.

E

Yeah, that's why they look more.

B

E

Yeah they are using like sun libraries like yeah.

F

E

Something, okay, so got it like ah now. I will just make a um https request: um serialize, I'm just trying to pass and just make a demo of it. That would be great. Yes,.

F

Yeah thanks, um I'm gonna enjoy it.

B

F

E

um You can take the um um sharing access, um I'm just figuring out how to get one.

A

Okay, overriding yeah: that's fine!.

C

Okay, this, you are, are you part of the uh cloud event say, get our channel by any chance the cloud event. Sorry, what the cloud is the cloud native say, get our channel by any chance uh for jenkins.

A

um Probably not, I will send you.

C

There yeah it'll be it'll, be nice if you could join because I I have a feeling. You're gonna get a lot more questions about.

B

It yeah yeah that sounds good.

B

E

And if there is any slack channel or group community for the cloud events who are actually using it in their project, like integrating.

B

um That's a good question. So yes, so there is like a channel for cloud events themselves and let me figure out: where was that? That's that's! Definitely in the cncf slack uh organization.

E

But that's quite currently.

C

E

C

Specific channel for cloud java cloud events, sdk.

B

I think that no, I think that cloud events sdk it's the group, it's the main channel, where you can ask questions and like the maintainers for the cloud events sdks are quite like at least the java ones. They are quite responsive. So if you have any problems with the sdk itself, we can definitely send a pull request and engage in conversations there.

B

B

Oh, I can see you sagar there yeah, you are there.

F

B

Is that you yeah yeah.

C

Yeah yeah uh sagar. You posted some questions yesterday. No in a cloud event.

E

Yeah yeah, it's just like regarding listening.

B

Yeah, that's, I think that you're not getting any any any answers there, because the question itself is a little bit tricky. You don't really need to do anything besides, exposing a rest, endpoint or opening a message queue or whatever. You need to do to listen, that it's not cloud event specific right, so you can listen to cloud events in any way you want, and then you need to transform whatever you're getting into a cloud event if that makes sense. Hopefully that makes.

E

B

I totally understand if it doesn't at the beginning.

C

Okay, yeah, it's just like parsing that again uh cloud events is a format. It's not the thing like you can take data and like put in a cloud events format and pass it around. It's like a river of cloud events, data where you're just like pouring your juice into. So it's just going as a cloud event. So yeah it it can. It can be tricky to understand. That's a standard standardization bit initially. I think.

E

I have seen one json format like that's what exactly what you are saying. I guess go to just uh some new attributes to specify the cloud event.

B

Folks, I know that you are in guitar and I would join the youtube channel at some point, but I'm definitely on slack. So if you don't see me there, just ping me there in slack, I'm definitely in the cncf and in the cdf slack channels uh that might be the fastest way to contact me or via email right like if you send me an email, I'm I'm going to answer there for sure.

B

I have too many chats already, but.

A

B

To change them.

A

There's also the cdf um g sucks channel. That's always I mean if you want to ask your questions more publicly like that, can be helpful to other people. That's a good one or I guess the cdf events channel um can.

B

You invite me to that channel car care.

A

B

Invite me to the.

A

You should, I think, it's open if you're in the cdf um I'll send.

B

You yeah yeah. I will try to join now.

A

Okay, are you you're in this yeah you're in the cdf okay? I.

B

D

B

Yeah yeah I'm there.

B

A

Awesome meeting we're basically our time. Thank you all so much for being here today. This is really interesting and informative. So thank you.

B

Thank you very much. Take care.

A

Everyone, let's.

B