 Great, welcome to today's Jingen's GSOC meeting for the cloud events plugin. Still community bonding, so you know we're exploring the project and hasn't quite reached the coding phrase, but Shruti has been very engaged, so it's great. You can tell us, you were mentioning before to some of the work you've been doing this week, right? Yes. Yeah, so this week, you know, it was not a lot of coding, it was more like discovering the past plugins that we talked about. So it was the statistics gather plugin, so I had it on my system and I was just sort of playing around with it understanding the code. And then I also found similar plugin for listener implementations, one of which was the extreme notification plugin, which is a little different, but it has the the same sort of events that it's emitting. And then there was another plugin which I looked into two days earlier, and then I will also mention something which I had seen which is the GQS monitoring plugin. And it's a bit similar in the sense that it's also like publishing information that we need about, you know, Jenkins objects like about jobs about Q about the bills which are currently in the in the queue but it's also different because it's using stapler which I quite, I quite get it, you know, it's like the URL binding that I'm not exactly sure why I think how it can help us because the statistics gather a plug and I think it's a really good way just the the listener implementation is going to provide us all the information so. Um, but but you know that was something that I wanted to talk about with you guys was just understanding stapler implementation. And I also like lived into other listener implementations and I have like noted down all the possible, like implementations for the events that we can, you know, possibly admit. And yeah, it was it was mostly, you know, just understanding a lot of like Jenkins native things as well as just, you know, like Hudson in general and all the, you know, actions and and then there is the root action then there is you know, the what was that action that I kind of forgot the name of that. I think it's the anyway. So yeah, that has been the word for this week and you know, like the coding mostly involved. So I was white while I was trying this to just get a little bit of, you know, tweaking the code and then also running it and using have that as a source which is just sending events out to an issue to be saying. And then I grabbed one of that event into like a cloud event. So it would look like with, you know, cloud and headers and since that data is in cloud payload. So yeah, I think you know, the next step would be just really going into what the first obviously understanding stapler and how useful here. And, you know, just rolling on from the stats here we're plugging and just deciding on the sort of events that we need to be. If there's any, you know, more configuration that needs to be done. I know that the statistics gather plug in it's a little in the UI part, it's a little different because you kind of only say you can enter, right off the bat does not send each request that's into advanced configuration. So you have to click on advanced option and get the. Okay, send each particular class and that's when you guess about it. So just understanding those things and maybe perhaps also start talking a bit about Jenkins as like a sync. So for that I've been looking into the generic trigger which uses like we would actually it has a URL and where it gets minded to an object. And that's where it's like listening on to request which is being sent by another systems, but just getting a bit of understanding and how we can extend that and then one from just okay when a when an event comes in. The most, you know, the common thing is to trigger a build and have that connected to like a job or a project that gets triggered for the build, but there could be other things too, you know, maybe if, if, if, if something is in the queue and if it's an event comes in, maybe you want to push it out of the queue or something like that. So to what extent have you tried the jqv stuff so the jqv stuff that Oleg mentioned like I've never even heard of it because I don't have much experiences in, but a good way to go ahead with this would be to just kind of see which one, you know, suits you better in terms of like working and kind of just like compare which kind of like if listener is better or if like the jqv stuff is better. So with jqv what it basically was doing is I think I have it on my local system like online jqv system so I can do a little bit of So basically So here's what's going on. So all of these, like whatever it's pushing here, you know, or a few jobs are a cause of blockage and all of these. These basically are like the exported like stapler from it's stapler export engine to just is going to exist. I get I get jqss purpose and if we want to tie all of this information to a URL. And so someone was reading off of the URL they would have this information with them. But what I don't understand is, you know, you know, since we are trying to extract this information and wrap it into excellent purchase on and then send it over. I sort of don't understand why, but it'd be helpful to us because it's doing exactly like essentially the same thing, you know, it has the stapler export engine it just uses some of what those native Hudson Jenkins or classes and then extracts information about the build on a project and then puts information out is excluded being so that's whatever you have to be in just Excellent on document. So this is the So it's basically getting all of this information again from the executor or whatever is executed and then using all of this information on to the excellent. So, you know, I understand that if we want to tie this information to a URL and then put it there as excellent or even as juice on it, it works with juice on this. I haven't looked at it yet, but it works. So I think I, I'm not very clear on how we need to use or, you know, just just as sort of an alternative method, I don't understand how it's going to work. So, you know, if you guys have any ideas on this or just how information that like that, but it's not But for now, I think looking at the, there are also a lot of other plugins that I saw there was another, you know, the statistics gallery was a really good example and then the extramunification plugin, but then I was looking at extension points. And then I looked at all the sort of plugins which have extension points for the listener. And then there were quite a few and they have very similar implementations. You know, not all of them emit the similar events, but a lot of them are using the same implementation. And the JQS monitoring system, which is using stapler. It also is, you know, it is sort of pulling that information. It is putting that, that, that, that, that, that, that, that, that, that You know, it is sort of pulling that information and it is putting that out into like, you know, outside for people or other systems to access through a URL. That's what I think. So, you know, what, what maybe if we were using stapler, maybe it would be designing, you know, like something puts information into the URL and then there's another class of just pulling information out of it. And then wrapping it inside JSON or if it's in, you know, it's natively in JSON, then just having like putting extra information as a cloud event and then putting in headers and then sending it to the sync. About stapler. There's not a lot I know about stapler, but from what, whatever I know, it feels, it feels like it's something that is closely related to the descriptor model that Jenkins uses to kind of like map, you know, what you have on the URL and what you have like underneath inside Jenkins. So it kind of is like a thing which staples the front end and back in together to kind of have this, you know, URL to object class object field and like information flows through that way. So I'm not so sure if it's, it's the way to go. But what I would suggest in this case is what we should do is we should kind of make a pros and cons list, because we have two very distinct ways in which we can get information here. You have this listeners. And then on the other hand you have these this exported information of some sort. I feel like in this case we should like look at the pros and cons like for both of them and which fits best for our use case. I'm not, I'm not sure if the stapler information maybe works well in like headless scenario where Jenkins UI, I don't know. Can Jenkins UI be disabled? So I'm thinking okay, if there is, if there is Jenkins file running and if we have our plugin installed on Jenkins file run up, would it be possible to, you know, use the JQS stuff? I'm not sure about that, but I feel like if we have for the statistics gatherer maybe it would possibly be able to use that statistics other implementation through the Jenkins file run up. If you, so are you aware of Jenkins file run up project? About what? The Jenkins file run up project. So imagine you have like a headless Jenkins which just runs jobs like based on like you have, you have this docker, you have this image where you provide your Jenkins file and the plugins are pre-installed in that image of headless Jenkins and once you get the Jenkins file, it runs that Jenkins file based on whatever plugins are there in that. So it's like a closure of enrollment of Jenkins and it makes Jenkins kind of for, what do you call it? Wait, are you talking about like Jenkins file or are you talking about something related to Jenkins file? It's called Jenkins file run up. Oh yeah, I'm aware of Jenkins file. I thought that Jenkins file run up is like a different concept. I'm so sorry about that. No, Jenkins file runner is a different, it's a project which was created by Oleg and like some other guys and it basically makes Jenkins serverless and even if it might be a little heavy in terms of like as an image, it works very well. So if the plugin had to be, so I'm thinking this way, if the plugin had to be used in a headless mode where Jenkins is not using the UI anymore and is just taking a Jenkins file and running it as it has it, it should be able to do all these things like send out cloud events when a file runner runs. It should be able to send out these cloud events to the sync, whichever sync is given at that point. So I may be thinking too far ahead, but the thing is, that's why what we need to do is like make a pros and cons list if the listener is more viable for us or is the JQS implementation more viable for us. It's called JQS, right? Yeah, JQS. So we need to figure that out first. So if there are hard dependencies on any one of them on the UI, then I think we need to reconsider and like use the other tools which are available. So apart from these two, there was something else you mentioned as well, right? Yeah. Like the plugin? The plugin itself, but the way in which information is captured? I think like these two primarily, like the listener implementation which is used in several different ways because there are a lot of implementation examples or like just listener classes and then stapler. But again, I sort of don't understand how stapler is going to work, even if it's like, you know, if you're talking about headless system, essentially going to be connected to that UI, right? Yeah. If we are using Junction to stapler and it's also adding the overhead of just passing information from the UI. That information is going to exist. Are you sure it is passing information from the UI? Or is it kind of intercepting between like, you know, information getting to the UI? Like, is it like listening on certain like endpoints or something? No, no, not UI. You are like passing. It's going to exist somewhere. That's because whatever I've looked about stapler for now is just it like is going to be binding those objects at a particular URL. And then whatever we are passing in, you know, suppose we want custom field to exist at the URL slash API slash text and whatever it is, you have to mention it. Okay, this is the information that we want to export. And then out of that information, that's going to be another. Okay, can you check one thing for me? Can you check if there is a hard dependency on these URLs? Wait, on the what? On the URLs, the hard dependency on the plugin kind of knowing the URLs? I don't even know if that's a viable question because I'm not as good with Jenkins as Oleg or these other guys might be. But I just want you to check if there is such a thing of being a hard dependency on these URLs from the plugin. If so, then probably it's better to go with the listener implementation. Because from what you said, I feel like it's the monitoring, the JQS monitoring kind of revolves around URLs. Yeah, that's what even like my understanding is. And when it's, you know, reading information just to like present it to the UI as earlier. I think it's reading off of that. The plugin slash API slash XML. That's sort of the native. If our plugin is like cloud events, plugins, all of this information is going to exist at cloud lands, plugins, slash XML. And that's what the information that we export from our like Java class. That's where all of this information is going to exist. And suppose we had a similar system of presenting this information to, to the user interface. To be reading off of that API. But events would be something that just come and go right. They are going to be, they are not, they shouldn't stay. They should be, they should come and we should go. And having something like this is not helpful for us in any way because we don't need to persist this kind of information unless we have a queue in our play with us. And I'm guessing that Q would be very small because most of the brokering that we do, we do it outside Jenkins. So we, we shouldn't persist this kind of information. If something happens and event is sent. And if an event happens on outside and we are the sync. The event is red and that's about it. Like this won't be persisted anywhere. But except in the job, for example, where if an event, if an event cloud event triggers a certain job, because we've configured it to be so at that point, the job would just be say something like, okay, cloud job triggered because of cloud. So this, yeah, this information shouldn't be persisted in like, you know, a single source of truth kind of a this information shouldn't be persisted. Yeah, I'm like, another thing is just actually going to be again, just reading off of the that one. And whenever you know we're sending like we're reading information and then you're sending it out, like you can see, oh, can also sort of alter the current space of just the current, like that's what I think. Again, I'm not sure if something is right. I think this is just me sort of putting words out in my head, which I think I just saw the plugin repo and I just wanted to check when was the last comment made and I checked. Okay, let's let's try to. Okay, maybe something that was released seven or eight years ago with, you know, the change in email addresses like the last comment made. It's pretty old school stapler. We should move with like some discussion and like, maybe, maybe understand like, you know, like this, this, this maybe like a good opportunity to learn to like understand how the stuff works, but like really think if we can work with this and like see some like newer implementations that are being done and kind of like work in that way because there is a reason why maybe this same method this method isn't used in the current implementations of any kind of monitoring or like eventing that is being done. Yeah, seven or eight years ago, does this work very promising? I think I would actually make a closing on this just to understand how this works better. You know, I'm kind of curious about this understanding statement and how it works. And I also Well, while you're for the next thing, let me just jump in and say I'm not for your, you know, there's an events meeting events, a meeting with the continues to the very foundation this afternoon, in about an hour and a half time. So if you're at all, you know, able or inclined, I don't know if today's discussion is necessarily pertinent to you but just in general, I would think that you find will find the conversation interesting. I can send you the link or I'll put it in our channel for this. So we will be talking about how to get cloud events. So we are making a new controller for tecton and for cloud events and kind of getting cloud events out of tecton through the new control and we'll be working on, you know, making those events into CDF events. So at some point, we'll do the same thing in Jenkins. So tecton is like our testing down right now. So like this stuff. So it should be interesting if you want to join. Nice. Yeah. First. And the second is, you know, just thinking about the events itself. What sort of things that we wanted to do. And then what things about. So, you know, there's the information about the bill. The bill has started. It's finished. Then there's like the steps of course, you know, change from one step to another. And then there's, you know, the Jenkins computer if something is online, if something changed or something failed. And then there's information about Jenkins. Shut down. Those are the two which I kind of found interesting. Jenkins shut down. How is that different from. Maybe just, okay, maybe it's like, you know, there's like, there's a cluster and when you say Jenkins computer offline, so that's just talking about one of those like one of the nodes, which is often when we just say like Jenkins shut down, that just means everything. And then there's information about like item and Jenkins item copied, item deleted, renamed, updated, those kind of things. And then job, job started, job finished. So do we, I know like we were talking a bit on Slack about starting off with what's the most sort of used. And that can have priority. Is there anything that we can add to it or something that we can delete or something that we can just think about. I know that we have not talked about just Jenkins computer, that it's offline or it's online or it's unavailable or it is configured. But I think that's that can be a very important event. And you know, just out of like NCI CD systems, if you want to, if something has failed and if you want to, you know, trigger another action of adding a new node or something like that, maybe. I think to get started, focusing on like the actual jobs and bills is a good idea. Computers could be something we could do further once we are done with the entire build life cycle. So starting from like, you know, creating jobs or project to like, you know, starting bills and the life cycle of bills and then the steps between them. And then after, and then after that we can look at, you know, computers and the cloud stuff where nodes are provisioned. Did you find listeners for them as well. Yeah. It's in the other one like the extreme application plugin. So that is, so that also has quite a lot of documentation. And it was really interesting because they are pretty similar but they still have, you know, like different. It's computer listener. What is it called? The plugin or the listener. It's extreme application plugin. I appreciate the name of this plugin. Which I did not find out. It's like, this one is more related to Jim Jim's performance. So, you know, the threads. You utilization stuff. But this one was also interesting. New plugin which was recently released. Like it recently started. The work on it recently started. Put my finger on it. It's called open something. What's an open source monitoring software. Apart from Prometheus. Yeah. Open telemetry plugin. I don't know how relevant this is. Right now. Could be helpful. Open telemetry is very interesting, but. That's pretty interesting. Because my. My impression on open telemetry was really for more observability. Once your application is deployed. Whereas we're looking for, I guess, in many ways. Greater observability or even tracing. When the pipeline is running and capturing all the events that are happening. Yeah, that is definitely what we are going for. I was thinking of this plugin and the. In a way that we could, you know, just see like what. How it is implemented. And maybe if there are some. You know, a few things if you can find. I don't know. I'm just. I'm just trying to understand the. Landscape here and if there are like, any kind of monitoring plugins in Jenkins. If it is a monitoring plugin or like an eventing plugin, it's then a good example for us to just dive into, see how it's implemented. And then see what's the best possible solution we can come up with. Based on these different examples. Something that's work. Maybe there's something we need to figure out. So like in, yeah, like here there is the computer listener being used. I think it's more around the, you know, understanding. Performance of Jenkins itself. The Jenkins monitoring plugin. I haven't looked at it, but. Yeah, that's right. I actually found a really cool. Another cool plugin. Jeff. Art. As we're done it. And it uses. The same implementation. You'd have all the status. It's pretty. This monitoring plugin made me think about. Four keys for some reason. The four key project. Where you can see all the events going in and out. Probably from Jenkins. Kind of sees like a graph. Could be something. No, most of these. And like the, the latest ones or the, some of them are pretty old, but you can use them. And they're using this implementation, even if it's on the pipeline. You can get the status. And this is also using this implementation. And like the listener. All of these plugins are using the listeners. It's interesting because when. Dina presented the four keys project just a couple weeks ago, maybe a month or so ago. I don't think there was a limitation for Jenkins yet, but they've done. Neither was there for like. Technically because she did it every, she did everything to through BigQuery. And there's not like one, I don't think there's a single singular thing, like a place where cloud events can be monitored as such. But she, so she basically implemented it. Implemented the four keys with that. Now, here we can think of, you know, doing that through Jenkins. You know, instead of taking in. Tech on cloud events in BigQuery, we are taking in Jenkins Cloud events in BigQuery. Yeah, this, this could be your contribution, Shruti. And he Jeff has worked on get, get her water status. Yeah. Yeah, that's why I mentioned. I'm guessing these meetings might be a little, little too early for them. Yeah, I did approve it, but they are early. I think they're crazy early for him, like five in the morning or something. So we might have to try at the very least. We may not go to everyone, but we should, we should actually put it in the sack. We should make an APAC friendly meantime, because it is a shame to be missing out on his expertise. Do you guys think that if we shift this meeting to like two to three hours, it might work for you? It works for me generally, but two hours. Well, two hours forwards. There's, there almost every Monday there's a CDF sake that I think of above and I'm both both involved in either way, but there's a lot of practices or events, which you probably will might want to sit down too. But one hour before is early, it's fine for me. And one hour is fine. So one hour or three hours. Basically I'm probably the most flexible and less. And this is totally possible should we need to. We made a meeting time that was that worked. Yeah. I think it's just so hard for APAC and Pacific region, like where Jeff is on the West coast of the U.S. I think it's just so hard to span Europe, Pacific coast of the U.S. And then APAC through so like India time is like, it's just, it's just such a wide spread. It's like a teeny bandwidth and it's going to be painful for at least some people. Yeah. I think like the most, you know, optimal would be just like little late nights for India. You may slash like. Leave me for you. But not five am early. So if we did propose one hour later or three hours later. Three hours later is probably getting ready date for, for you all there. One hour later is fine. Three hours later. I've been a, I've been an old man lately and I've been sleeping at nine. In the at night and having dinner at 6.30. The evening. So I think one hour later. All right, I'll propose one hour later. So I hope they will do that from, from next week. Thank you so much. So anything else? Any other questions? Like that is a pretty big. There's. I think this meeting. I think we can keep about. And then I'll make a closing con. But I think I'm going to continue with a list of presentation. And then on the side also keep looking for other presentations. And possibly if, you know, there's, if there is a better way. That sounds great. Also keep in mind. Sorry, sorry. Also keep in mind just like how you're going to test this stuff. So. Like think as like a test. It should be as testable as possible. That's all. That's all I was going to say. Yeah. Yeah. Good. I was just going to. Sorry. I was just going to add. Please do ask questions on the Slack channel. Any questions you have, especially for Jeff in the run up to, to hopefully next week's meeting, which will be at a slightly better time for him. But because you're looking at this plugin that he worked on, you know, Answering Jeff has already worked with listeners. I think you can ask him about, you know, which one is better. So I feel like we already kind of know which one is more used. We can go with that because there is some faith in listeners and in people. So we can go with that. But I think it's a good idea to ask Jeff on the channel. About like JQS versus listeners. If he's considered something else before, apart from JQS, which he think might be a good idea to, you know, dive into. Yeah. I mean, I have things, but I don't think that the five minute time that we have left is going to be sufficient. So, so about, so your question with your burning desire to be answered right now. I mean, I don't have anything right now. I mean, I have things, but I don't think that the five minute time that we have left is going to be sufficient. So, so about, I think the question with your burning desire to be answered right now is about Jenkins being monitored itself. Like if Jenkins should be sending out events on its state. That's what you want to answer. Well, yeah, sort of it was, I think that's kind of like the conversation sort of answered. I think that the burning desire, the burning desire to be burning desire to be burning desire to be burning desire to be burning desire to be burning desire. Like not the burning desire, but the burning question that I have in mind is displayed Jenkins is the thing. It's also something that we need to be keeping in mind and preparing for as we are building. It has a source. what we said like on staff and then in the next week. Okay, let's do that then. With the meeting, the cloud is meeting, is it in the end of the week? It's at nine o'clock. All right, so I don't have anything to add. Neither great work this week. I feel like you are really getting to grips with all the different ways that this has been approached in the various Jenkins plugins and we seem to be kind of consolidating around the idea of listeners, but it's really good to do the exploratory work and I guess in that way I understand what a lot of the certainly more recent plugins are, why they're choosing what they're choosing. Yeah, definitely going to research and math. Thank you everyone. Thank you very much. Thanks for being here. And yes, communicate more on the Slack channel if you have any questions or anything like this is really for you. So we want to answer all your questions as much as possible. That's good. Go ahead. Were you saying something, Tara? No, that was it. That was it. Okay, bye. Bye.