Jenkins Cloud Native SIG, 26 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: ☀️ GSoC CloudEvents plugin mentor meeting 2021.7.26

Description

Discussion on architecture, including consideration of Knative eventing architecture, especially its use of brokers. Lots of discussion on the CDF SIG Events Protocol Proof of Concept: https://github.com/cdfoundation/sig-events/blob/main/poc/README.md

Super interesting work! ☀️

A

Would you prefer that I turned the recording off.

B

uh No, I thought you were gonna. Do the introduction.

A

Oh okay, welcome to today's um g stock mentor meeting for the jenkins cloud events plugin and we are speaking about shorty's work in the last week and moving the plugin towards a first release.

B

Version so I did uh review the pull requests and got it most and uh just one thing: one uh thing I want to say was uh the readme would uh be nicer with the toc table of content and that's it, and I think we can move on to doing the first release uh this week. We can catch up on wednesday or even tomorrow, or to do that and yeah. um So what are your next steps of the plugin? Then.

C

um We also what what's that about readme did you say doc, yeah.

B

Table of content.

C

Okay- okay, I'm sorry got it um yeah, so the the past week, so we talked with um the event sake team, just to get a better understanding of how they have been um developing their. Like events, um sync for the captain and tucked on sort of integration- um and I was able to clear some things uh in terms of how we can design a sink, which is agnostic and also it can deal with different kinds of events in different structure and coming in from different sources.

C

So I think that if we can talk a bit about that, so we have a better understanding of the infrastructure that can be in place for the um the the stage where jenkins as a sink, uh I think it'd be.

C

That will be a bit helpful and moving forward and just thinking about everything that's needed for jenkins and sync. um The last time we were also discussing when like cara- and I we were discussing about how we, how like designing the sync, which is you know in a naturally cloud native sync, which can deal with fault or just like network and transient failures and also can deal with retries.

C

But retries is also applicable to jenkins as a source, but that's something that can be accomplished in an easy manner. But for jenkins is a thing you know. So when we were talking with the unsight team, um they they specifically had sort of a a middleware I'd say, which is dealing with events coming in from tecton and captain. So they have like captain, inbound and tucked on inbound and like outbounds, for both of them and what they're doing is basically like transforming um the the cloud events which is going out and then they're.

C

They have a a middleware in between which is like a cloud events broker, which deals with receiving and sending of the events, and if our sync is totally like an http request response system only like if you're designing um or if we're, for example, like receiving events only in that manner. You know only like a post request to the end point where it's present.

C

uh I think that it's really going to tightly couple things with that infrastructure of jenkins server or jenkins node, whichever whatever is dealing with the events always being available, um and then it also leads to the possibility of losing events, um some of what might some of which might be crucial.

C

So I was thinking if maybe we can start out by eat, like maybe testing with k native, because that's sort of the whole you know like the the their the product is actually something that might help us, but also I'm not really sure.

C

If having k n like having k native integrated with this sink, how can this look like it's going to be two different tools, but also when someone is configuring jenkins and sync, we we want to spin up k natives, so we can, you know, configure like an infrastructure as code or something similar to that, but I was actually curious and hearing your guys's opinion on the jenkins as a sink infrastructure, specifically going on using a pop sub like infrastructure, going for a different uh like the different protocol for both the entrances and source.

C

Anything, for example, if we want to introduce kafka both for jenkins as a as a source and also as a sync. You know like because cloud events does support like the protocol um for using kafka and also if we want to go with like a killing infrastructure, so there's rabbit mq, which supports the the kind of system that we might want to work with in a fall, tolerant and um sort of like a full like transient failure, tolerant system.

C

Sorry, that's a very that's the question. That's everywhere, I was just if you guys have an opinion on that or what.

D

Do you think about that.

B

So I think we can try implementing retrieves, probably with http, but if you want to uh start playing around with the kafka protocols for the cloud events, what you could start doing is you could just set up like kafka.

B

I haven't worked much with kafka, but you could just set up the infrastructure for now and then start playing around with it and then along the way, uh you will see problems which come in some things which could be better, but uh in terms of implementing pub sub and everything from jenkins side directly, I'm not so sure about that.

B

We probably it probably would be good if all of that stuff, like uh even retries and all these things actually would be managed by.

B

You know some kind of middleware, some eventing middleware, like half car.

C

Yeah and that's what for k native that's what they're the like the broker is doing. So you know you have events coming in from um techton and that's using sort of like a techdon outbound and then sending a specific kind of event which k native is expecting over to the event broker and the event broker or the cloud events event broker is the one who is implementing the we tries and also implementing sort of an asynchronous way of handling all of the events and the messages which are coming over.

C

So with the jenkins saying, uh that's, like my only concern with you know, because they said uh I like remember them saying that you know, since all different sources have different data or different way that they have structured their cloud events.

C

um I don't I don't remember them saying that any specific solution for designing an agnostic thing specifically has worked, because everything is different, so we might want to think about just implementing when we're thinking of like implementing a genetic sink. uh Also just thinking about having that middleware, which can handle different kinds of both like protocol and also the different structure of data. That's coming in and then design it in a way that jenkins should receive it.

C

I don't. I am not really sure if that can work, though, but I feel that might be helpful.

A

Shitty from my understanding, but you can correct me if I'm wrong the way that they're using the broker this middleware, it is what enables the sync to be agnostic to the underlying technologies. So this is what provides essentially like a translation layer depending on whatever underlying, if you're doing, rabbit, mq or, if you're doing kafka or what whatever underneath.

C

Yeah, I think it's so for them. What I understood was that the the responsibility of creating sort of you know um uh both the events which are which are understood by the sender and the receiver. It's the responsibility of both the source and the sync, so I can actually go back and pull out their poc that they have and also there's a pub sub like plugin for jenkins, which is a light version of pops up, not necessarily something that uh can be helpful, but definitely like. I've looked into it, and this.

C

This definitely like looks like something that we can use.

B

If you think we can use the existing logic and the power sub plugin, which you're talking about, uh could you send the link to that plugin.

C

Yes, over on the the gsa.

C

B

If you can use uses, oh yeah, okay,.

B

So I was saying if you could use the existing logic in the pub sub light plugin without having to write something new. Then it's something.

B

Maybe it's a good idea to experiment with it. um So initially, why don't we try play like playing around with those k native brokers and see how that goes.

C

Yeah well sounds like a good idea and, um and also like another thing is: if we, if we do, want to support just k native um where or how should I inside, like as a part of the.

B

When we try that with canada, does it mean that we support only the nato, because I think cloud events are agnostic. That way, like anything, that reads, cloud natives uh cloud need cloud. Sorry, I'm saying cloud, I mean cloud event. So anything that reads cloud events will uh like read a cloud event like uh whether or not it is supported by k-net.

B

So even the broker, I think, is such that it will just help routing the events.

B

Doesn't have to be supporting only cloud events for.

C

um Yeah, so they gained it like the k native broker specifically works with cloud events, so this is like it. It can work with other structured event data, but I think, like the k, native brokers itself um is only with um cloud events, uh but if we like wanna substitute this with something so like, can you guys see my screen yeah so where um there, the poc that they had?

C

They had like that on cloud events which was sort of that theft on outbound, um which is like sending cloud events over and then it's receiving it, and then they have a trigger. So it's just like if any event is coming and looking like it's from techcon, so that triggered it's basically, you know how we were mentioning um setting filters, so ce type, c's, that's what the trigger is going to do is basically set filters.

C

So um the trigger is going to be like okay, if any event is coming off to type um c dot, techton or whatever, then send it over um to this captain inbound and the captain inbound is what sort of transforms it to be used by um captain.

C

So escar was saying that, in a way that cloudvents broker it is, it is like agnostic, because this is only actually dealing with um the triggers, which are you know, looking for a particular type of an event, but both of these services so tucked on and kept in here, have their inbounds and outbounds.

C

You know which are sort of dealing with that conversion of events into a format which can be used by each other. So if tecton has this outbound captain has this inbound and what this is going to do is basically transform the events coming from tecton into something that captain can use and understand, uh so that that was one of the thing which was I like thing.

C

The thing about canada, which is really interesting, is you know it is working with power events um as are so we are, we only like you know we can set uh or a person can set triggers for a k, native service which will be running inside of or maybe like as a part of our plugin.

C

um It's sort of that interoperability. Also between different operating. uh I mean open source tools uh operating together, so the user would have to set up these triggers, but those triggers won't be inside jenkins as a sync, but they would more be inside, like the k native service, which is running as part of this plugin, but the only thing again is about these inbounds and outbounds, or those are specific. You know how you mentioned the direct interoperability system so again having those uh agents and and that kind of system. So that is one thing.

B

So imagine extending this cloudless broker to like one more row. Sorry, one more copy. Okay, you extend this to the right. You copy paste, this captain thingy to the right and just replace captain with jenkins. Now.

D

It's easy, but.

B

I'll tell you what it will look like, so the captain bridge and tecton dashboard is the front end. The cli is there okay forget about the clr, uh but the that will be the jenkins front like that, will be the jenkins uh port 8080 from where we can check the jenkins ui. Okay, captain inbound so take down triggers are basically web hooks.

B

Okay- and these are these are event listeners which, with which we can use which technon can use, and then uh these are created on tecton site and then consumed by the broker, where a trigger object is made by the k native cloud events by the by k-nator, and this trigger object uh is created with the uh webhook url given by tecton. Okay. So that's what it's triggering same thing is with kept on inbound. Do not look at the so these two are technically the same because they are both web hooks.

B

Okay, now here, tecton cloud events is actually uh so I uh so andrea. I actually did most of the work on this, but I did work on this a little bit. The cloud events.

B

Controller for tecton, so what the cloud events controller for techtron does it? It just sends cloud events, so you configure a sync where you want to send cloud events and you send the cloud events uh and the cloud events are sent to that place. That's all is that's happening. So uh what is happening here that all the events are just sent to the cloud events broker over here from and the trigger is the one which is actually doing all the work here now to translate this into jenkins.

B

The captain inbound captain, outbound or tecton triggers tecton problem, so it looks like instead of if, instead of inbound, you would have, you would have so important. Outbound can be transferred to source and sync directly and which the cloud men's plugin will handle.

B

So um right now, uh right now, what we are done with is the outbound right.

B

You would say that we are done with the outbound and we are kind of uh working on the inbound inbound stuff so and we are trying to make the inbound stuff a little better, so in terms of the inbound, uh which is jenkins as a sink.

B

So this is that's, that's the inbound stuff that we still have to work on and like make it a little better. So that is our next step in this process, but for now what we can do is- and I think it will be a good exercise as well, but like just uh play with the same architecture and uh forget about this, I don't know what this cloud events player is. Very frankly, I think it might be a ui from which you can yes, this.

C

Is this is like similar to sockeye, but for.

B

Okay, so it's it's basically like a more sophisticated socket for so the cloud events player view monitor and measure without events. Okay, so uh what we can do as a good exercise is uh we'll just replicate this entire architecture for jenkins, and then uh we will remove captain out of the picture and then slide in jenkins, and then uh obviously we won't be able to or do any inbounds right now. But what we can do is we can do outbound.

B

So what will what what we will do is we will just start a job, a jenkins, job, simple job and then uh we'll do an outbound. You send an event.

B

You will have to configure a canadian trigger to say that, once the this uh jenkins type of event comes uh trigger a tecton pipeline which does something okay, so I think this this would be a, but this would be a really good experiment which you can do the next week and in this in this way you can probably gain an idea what the poc will look like and also you can uh showcase this to the events say that you have done a poc with jenkins interoperability with techton and obviously, if that works for tecton, it will obviously work with captain as well, because uh in the trigger you, probably you probably have to create a similar trigger.

B

The only thing you will have to change in that trigger is the web hook, which it's calling and the payload. That is there. So um I think that's the good next step you could take, but uh I I don't know if I'm just blabbering or I've answered any questions.

B

Is this something that I'm missing out or not haven't answered yet.

C

No, no, it does. It does make sense and, um like I am following, because you have more insights on this, since you have loved with this system, um it does make sense. uh The the only thing that I'm just like looking at right now is sort of understanding that, if we are because I remember them mentioning how the inbound and the outbound is all for both sort of like the tecton and captain is also doing a bit of manipulation to adjust the event in the way that's coming over.

C

So I think that it's yes, it's a very good step and we can try with both techton and captain. As you know, just having kept an impact on both has sort of like sending or like receiving events from well.

B

Now we can just have them as inbounds. We don't have need to take the outbound from them. We can just have them as inbounds.

B

And just the setup should be fairly simple, but the part where you will have to do some learning would be the techtron triggers bit and the crds and stuff that they are using there.

B

I can help you set it up if you want, um and we can kind of do like a poc with jenkins and techno.

C

Yeah, that sounds like a really good idea.

C

uh Yeah, oh yes, I was, I was going to say um that, oh so, if we do decide in the future to sort of move with this architecture, I also was wondering again going to the question of how can we enable this this thing in the middle? You know like the k native system, amis uh jenkins, like the cloud events plug-in for jenkins, so I'm just thinking a bit about that of how you know if there needs to be a script. That can also start this architecture, but that will also need, like a pod.

B

So this is, this is a fairly decoupled system, so you actually don't have to think about you know. Making this uh dependency is. Is that what you think of that this cloud events broker would become a dependency to the jenkins cloud native plugin without.

E

C

Not thinking necessarily as a dependency but uh more or less like, if we are, you know like if we need gain native as sort of a service from inside of jenkins plug-in as sort of like this always needs to do. This needs to be there's like yeah, maybe maybe we can say dependency, but also like it obviously can work without it.

C

We don't always like need k native, but if, if someone happens to do or happens to initiate this system running, he wouldn't want to go back and set this up on k native, but they like need a system which is you know, asynchronous and which can uh similar to like a native can handle. All of this like have that cloud events broker.

C

So if we end up using like kafka, you know some other pop sub mechanism, or some cue we still have to we would we might like have to make so any structure or any format of like uh supporting cloud events, because we we don't have the trigger inside of jenkins as a single source right. We only have that inside of k native so for that filtering and then sending it over, because the idea here we'll.

B

Do one more example after this, so once you are able to achieve this bit of exercise where you replace captain with jenkins and uh test switching against outbound and protect on inbound. We'll do one more exercise where we replace this middle bit of cloud events broker, and we replace it with something else, um and we could probably discuss that next time I'll try to figure something out, but maybe we replace this with apache.

B

You know and see how we can make that work, because uh the uh point of indirect interoperability is that you don't you it. It should all be fairly decoupled and you're just using uh like on data packets to tell each other. What's going on what is happening and.

A

B

Focus is that so um from what you're saying right now, it seems that uh you are considering this cloud. Events broker probably has a hard dependency at some point, but that won't be the case.

B

So you pro and at that point, when we do the second exercise, we also get a better idea of the event filtering or something. If you want to do in on our side, what that should look like, what's important, what's uh or just some simple filtering, even maybe use rejects or something we could do that on our side. But I think it's a good idea to do some like test architectures like in this case like this is actually a very good diagram.

B

um If we just replace captain with jenkins for our first first go and on the second go, we replace the middle uh bit the k-native bit with something else like apache or something.

A

Like a different broker,.

B

Okay, this, I just checked some documentation. They have their own kafka broker as well. Maybe you could just extend, or instead of completely replacing, to use the kafka broker, um to send things to kafka initially and then remove after that, remove it completely and then just connect uh jenkins to kafka, protect on or do something like that, I'm not sure how well that will work.

B

I don't have a great experience with kafka, but initially I think it's a good idea to go with the just the jenkins replacement, then extending the cloud events broker to have a kafka broker as well, so that you can trigger some kafka jobs and I'm not sure kafka topics.

B

um My lingua is not on point uh and then uh we can do an experiment where we remove the k native based kafka broker and describe with a normal kafka broker. We could.

D

C

Decide on in like giving users the ability to to choose the the protocol binding. So do you? Do you guys think that that, like that protocol, binding should sort of um like the user is entering it or if, like a person, is selecting a particular kind of broker it just automatically? Yes, I think that's the more easy way. I think. That's like the better idea.

B

Yeah, it should be fairly easy because, uh like you can you can, you can say something like uh protocol binding and then in a drop down they can select kafka or http or whatever, and then, when you're uh creating the um yeah, it should be fairly easy. I think just like when you're creating it you'll have a switch case. It should be simple enough.

C

Yeah and like the ui right now, it does like support sync type. You know it has that http sync and other sync, so you just need to go on to other sync and then implement the so.

C

My my like my computer battery, is sort of it's like it's not really super amazing right now. So I'm starting my idea on my intelligent in my crash, but I'm going to try and sort of like show.

C

B

That's what I'm doing.

C

um Yeah, so you know like, um like you, suggested, having an abstract like a sink and different kinds of sync are just extending from it and then like um developing over it. So I think that can be really helpful here, because we have an http sync, which is um extending from the abstract cloud vents sink and then we'll just have different kinds of sync, which is designing events. So we might. I think we might also not need actually.

B

uh Thinking if yeah abstract makes a lot of sense with my, uh but the final product is gonna, be a json right like like, like a json object like a cloud events object. The final product is a tower console right, so I'm just thinking instead of doing the abstract thing. Would it be better to have a sort of switch case which manages all this and because I I don't want you to waste too much time on the ui.

C

uh I think that this is going to um be like very, I think, in terms of just making different zinc classes, because in that way we can sort of just separate this the kind of things so the ui has sync type right, so a person can see the same type and what this can do is also just sort of separate the ui sync type, with the implementation sync type, so the things are kept separate and what this is.

C

This will really need if it it'll just look at the the place where we are sending events and see if the sync type is http then use the http sync class to send events. If it's a different format then use that format. So we can use switch case there and then just go into classes uh because um we still would have to do. The the design of the cloud event is going to look different.

C

I can try I can like try making either. Whichever would make more sense. We can go forward with that.

B

Yeah um there's, I am just. I just think that, right now I have a gap in knowledge because I'm not sure how the like I was just thinking. Do I really even know the protocol binding and what it means for kafka.

B

Even I would have to just check before I say anything really because uh yeah I I even have to figure it out to tell you the truth, but uh what we can do is we can sync sometime this week uh once we gain enough info on what that is, and on my side also I'll check it out what we can do, um but I think to start off with the kafka bits to start off with that, we can just use the kafka broker for which k native gives and we can start off with them before moving on directly to our patching.

B

C

C

um I'm really sorry this, like the whole thing with like the power issues and the fire cuts here, like that it just really derailed. What I had planned uh should have.

E

Been more flat.

B

That's all right! um It's fine! um Any time like uh when do power cuts happen.

B

They must be very erratic and I'm not sure if it's the same problem that is happening in punjab, that's happening in up, but.

C

People here are just lazy, like don't wanna like there were four people who were fired over this yesterday, like in the power slug department, because they weren't recording this yeah like we had a fall for 18 hours straight, like from it, went from like 12 p.m, and it finally came at like 5 a.m in the morning, and there was one day that was like one day and then kind of the same.

C

Things happened over because they weren't able to find what had happened in that 18 slash whatever armor got, so they had to fire four people. That's just this.

B

State firing people is not gonna happen.

B

um But yogi right I don't know um I I can't say much much about that, but I hope you just get uh light on a more regular basis. um Are there any kind? But when are you free this weekend or you can just actually just ping me, I'm pretty much free this entire week and you should just ping me when you're free and we can catch up on the release bits and then, after that, if you want to sync on the um the architecture bits, I can help you with that as well.

C

Yeah, that sounds really helpful. Thank you thanks. Everyone side note.

B

um You've already been able to deploy sockeye, so you're kind of halfway there with uh setting up the brokers.

B

I don't know what else might be needed, but uh for all the crds and all the crds that you need you were able to install and keynative is something you are able to install in mini cube. uh The only next thing, probably the next thing you can do is you: can you just have to figure out what triggers are, how to set up triggers and all those little bits? And then then, after that, you have to figure out uh running tecton locally, on your mini cube and um using the cloud events controller for it.

B

I don't know if you need that and uh setting up the triggers, uh which you will definitely need for the trigger template trigger bindings and whatever things are there in the triggers um controller, you have to learn a little about them and then just create the event listeners and then give it to the cloud event triggers and then once uh and set jenkins as a source on one of the broker. I think so we can talk about that sometime this week.

B

Just let me know whenever you're free and I'm pretty much free every week again, you can just bring me. Let me know.

E

C

um And have you also like worked with captain, so we can also sort of try that out just to make sure that if things are fairly similar for different systems,.

B

um Not exactly I did deploy, but I couldn't get to running things with it. um I I I was just. I just got a little confused with the abstractions and the wording they used for certain things, um but I will probably have to check it out at some point and we can just uh you know, have a hacking session and figuring out and figure out what captain is about because, as far as I know, they they are like. The.

B

Like they really embrace cloud events and try to work with them as much as possible and use that as their main, medium of communication uh kara, like do do, let me know if I'm going wrong here, because I feel you know a lot about captain compared to what I do.

B

I I don't have much of an idea about it.

A

Actually, I was thinking that mauricio would be. The person would be a really good uh go to first nascar. I thought I think in his new work. He will be working with it and focus on it. So I think I just I feel like he actually of all of us probably has the most um contacts in knowledge.

B

Yes, yes, so uh maybe in the next meeting what we could do is we could have like a captain session uh after after the hacking session, maybe and figuring out stuff, uh whatever questions or anything you might have about captain, uh we can ask them to um mauricio. When he comes in next meeting. We can make make it a point to call him for the next meeting for the captain discussion.

B

um I'm not sure, but do we have a event meeting today.

C

This is august 6. Let me check. Actually, yes, it's august 16th, the next one. Oh.

B

Have they changed to a monthly forward.

C

I don't think it's I don't know, but I'm just gonna go on, live and say that it's the summer, uh I'm probably, but I'm not sure kara you might have. You might know more about it. I.

A

Think that is exactly correct. It's due to the summer, um we did the same thing with the interoperability.

C

I also like I have like the started with jenkins as the sync and the one on again like the one thing is the setting of the sort of, maybe I would say triggers because we have been talking in terms of triggers for k native so triggers here and that's why, when I was, you know like mentioning um like that dependency with k native that one thing was leveraging triggers that k native has because, yes, it will, it will be easy to implement it inside of jenkins.

C

But if we are already working with another sort of system that that is natively made to trigger and filter based on a cloud events metadata. um I think my question here would be that.

C

What what should be our sort of dependence on using any form of or designing any form of triggers inside jenkins is a sync and what I mean triggers like more specifically like filters and just triggers both included.

B

Specifically cloud event triggers, though,.

B

Yeah, we uh that would be jenkins as a sync right.

B

Yeah, so probably in that one sink, what we can do is we can have a object called triggers which the user can set up and then certain um like. If you, if in the sync you say uh you want to create three triggers, let's do three different things and the first one would be something like you know, just start job.

B

One second would be like start job to start a top three, uh but you could do that like and I think before we reach that we have to kind of uh like uh redo the ui move. It move it to manage, manage jenkins and do all that sort of stuff, but yeah you can. You can start off with that. um Whenever we do it, we can.

B

uh While we configure sync, we can have like these boxes for triggers and each trigger will have you know a particular project endpoint or like a build job or run on jenkins pipeline.

B

Like do any any of those things.

C

um So, yes, the work on that I have been on it and I I would say that most of it is like sort of moved out. But it's not like very clean because, as like just rushing over and like writing it down so still like. I would move, probably like everything and then design the idea with jenkins as a sink specifically aligned with triggers and filters.

B

Yeah, I feel that there's a lot of stuff that we need to do with jenkins with us as a sink. um It's uh it's. Probably it's probably a better idea to do it in some time. As we understand you know, the architecture builds itself and how the sync would be used and getting started with the architecture with the cloud events broker and everything is a good place to start like once. We start understanding the one uh one flow which is jenkins to techcom.

B

Then we can start understanding the others technology rankings and what that would look like, and although we can, we can get some idea of. There was a plug-in. I think the events plug-in or something which was mentioned on the design document.

B

Initially design document draws and we can gain some. You know we can get some help from that key with how we can uh you know, design that part or if we can just use, uh use the implementation that they've already done and kind of uh re refactor it for cloud events.

B

I think that would be a good step ahead as well.

C

Yeah, um yes, that does sound good and most of triggers for this, like with the gainitive broker, they're, usually sat on the header fields or not the headers, I would say the metadata about the event. So if do we still wanna sort of have that structure specific, like probably like in this introductory, and the starting out phase wanna, keep the filtering option for the body or the data specifically of the event as well.

B

Yeah we should. We should allow the user to filter everything very quickly. The boy feels like we should allow them to filter each field individually with a different filter, each part of the header, each different header with a different filter and then the body itself with a different filter like the body contains this. Does this uh like? I think we should allow the user to do that.

B

um It'll be very um yeah.

C

I'm sorry, god.

B

Yeah, because if we just uh allow only a few kind of filters, like only the header or you know some parts of the body, I don't think we can do that, but just the header. I think it will be good for to start off, but we should allow them to do everything.

B

I I don't know, I don't think it'll be that hard even to just do the body also. So I don't know um yeah.

C

So if you guys can see my screen right now, we are looking at so we're still inside of the poc and we're looking at the um like how they're designing of the triggers for kept on uh so like depth on outbound.

C

Yes, um so like the events which are going out from tucked on- and so you know they have this- let's see so they have like the bindings they have like 100. maxi type. This is the c type that an artifact was published.

C

uh You know this they're doing like bits with expression replacing register whatever, um and then they have like these bindings where they have okay, um the name. This is the name like sh captain context and body dot. Sh captain context, so this is like this like this is the binding with like the the event data whatever is present inside of the event body so like obviously, here it's like that, they are aware of the kind of events which um gets triggered from decked and so like the entire body and the entire life.

C

I think that we can take reference- some like somewhat reference for this, but for us it's going to look very different because we obviously can't just like give them like findings like okay or just like filters like okay. This is going to be inside of the body and then body dot whatever, because we don't know where it's coming from.

C

So that's also one thing that we have to think about of how we can allow user to go very modular with whatever um filters they're setting on the body, because our sink is agnostic and it doesn't know how to park. It knows how to parse it, but but it doesn't know how to find that particular piece inside of the body.

C

ah That's like that's one thing that I've been thinking about.

B

Yeah, if you remember, we discussed this uh last time with the cell interceptor so discussed.

B

So if you can go back to the yaml for triggers and you go back to the filter that was there, I can show you so what is happening over there, that they are using an interceptor uh which is a common expression, language interceptor, which we saw last time and the language that they're using over there with the header dot, match something something um so that language is the common expression language, and I don't think we have a java library so that we could use which we could use.

B

But it is definitely some an idea with which we can go ahead. So, instead of cl, we could use something else for filtering and we can obviously start off with. uh We can obviously start off with something else like you know, just simple matching: we don't even need any kind of library, but uh in due time, what we can figure out is uh what we can use for. This sort of you know um data extraction from the cloud events which the users can use ahead in their whatever or triggers they're using.

B

So in this place, what is happening is that they are binding certain variables or to certain so they're binding certain values to certain variables.

A

B

Them uh to run in their pipelines, so what this allows the user to do is that the the dynamic nature of the pipelines, which is uh changing the variables and running them, the changing the variables part, is completely done by the triggers themselves, so they don't have to like the devops guy or the whoever it is. He doesn't have to think about it.

B

So this is definitely like some feature which we which we should have, and so, whenever we are done with the initial implementation of this thing, so once once we reach the trigger stage and we are able to do match we at that point, we should figure out when we like. What do we need to do for this value.

C

Yeah like because, as I I I don't know, if, like I'm understanding correctly but the the interceptor that they're using is more specifically for like the matching but like the bindings is what's like when we were, you know talking about extracting, maybe the job name from the event body. That's coming for jenkins, you know so pecton is like okay. I have completed this artifact and this is now what I want like.

C

I want to start a job with this name, so that's so something like maybe body, dot, um jenkins job name, and that would be that would have the nemo jenkins job name and then we would trigger a job like using using that particular variable, um so so the the interceptor it I'm not sure if, like using that inside of I mean yes, we can use that, obviously it'll be used inside of even body, um but that modularity of extracting specific values- and I think that's one thing- that the the system for the poc with um captain and tucked on yes, like the inbounds, is sort of helping with that they know what's coming over.

C

B

um So as we move forward, we will obviously have to give examples of how to use this plugin with different systems. So at that point, we'll have to give examples of like what it would look like.

B

You know to use it with tecton and there might be an examples directory where we can keep the stuff, and we should do that and if you notice here this is this part of the uh eventing is not that dynamic like they know where the certain things are like the trigger id the context and all so these things we need to be sure of these. These are some things. We need to be very sure. That's why and that's why. The format that we're using for the event in the cloud event also matters a lot.

B

So yeah, but I I think I think we can actually take this conversation ahead at a later date. As we, you know, okay, so right now we're just kind of getting acquainted with this. So I know like there's like ideas flowing and all, but slowly as this kind of uh you start getting used to these ideas, you will figure out that uh you'll figure out the right path to take.

B

So it's good that this is simmering in your head right now, um but once you start working with the architectures and stuff, I think you'll get a better idea of what stuff should look like what it should be because you you would have done enough for um like you, you would have seen enough things to know.

B

What needs to be done ahead like for like right now, you're looking at these uh tecton triggers like you'll work and work on setting them up at some point, you'll figure out: okay, captain inbound outbound: this is how it works.

B

Then you will get a better idea of like how the cloud event side cloud events plug-in side of things should look like, because uh users who are using uh these things uh once they switch over to something else, they'll they'll have a similar concept in their head and they'll also be able to work with the same concepts more easily, and it will be easier for us also in developing this.

C

Yeah, that's that's a good idea um all right well! Thank you.

E

Thank you. um Well, everyone had to go.

C

But also thank you, everyone and thank you cara uh forward with.

D

C

Stuff we've talked about.

E

B

Let me know, let me know if you're free this week and we'll discuss all the stuff and help others be certain some of the stuff which you need to go forward. Yeah and congratulations on uh getting first part of gsoc done.

A

Congratulations.

E

Thank you. It was again it was like hell from you guys so like thank you for for all the work you put it in for being amazing. Thank you.

B

Thank you for being amazing and working on all of this stuff. It's great.

A

Definitely yeah you've done fantastic work. Shooty. Thank you. So much.

E

Thank you and we will continue doing this.

E

B

A

All right, good meeting guys um I will we'll be in contact over the week and thank you very much for being here and thank you very much for your work.

A

Thank you. Everyone.

C