 Great, welcome to today's meeting for the cloud native sake. We have Gareth and Vibhav today with us, talking about the tecton. Yes, I'll introduce myself, I'm Gareth Evans. I've come from the Jenkins X project, where we used tecton quite a lot, we were sort of heavily, heavily, heavily, heavily used as a tecton really, and recently moved over to Jenkins community, mainly focusing on sort of infrastructural stuff at the moment, but one of my sort of your areas of interest is the tecton stuff, and I would love to know how that's going. Is it still in sort of active development or is it sort of, is it kind of done its proof of concept and then it's paused, or are you looking for contributors and where you see it going really? So, even I'll introduce myself before we start rambling on tecton plant plugin, so I work for Red Hat and I work as a maintainer for some open shift plugins, and as the Jenkins that we use on open shifts, so we package Jenkins for open shift and do some pre-skip, so we maintain that, along with that I also work on the Jenkins automation operator, so we basically were working on the Kubernetes operator under the Jenkins year, and then we forked from them because the development was a little too slow for us, so we forked from them into the Jenkins automation operator, and we are working on that now, and as a side thing, so that is the stuff I'm doing for Red Hat, as a side project, tecton plant plugin, I started as a side project to better understand the plugins themselves, and how to write one because at the end of the day I have to understand plugins better, and the plugins that I have in Red Hat have inherited them, I didn't write them myself, so it came about as that, so one thing that I wrote tecton plant plugin was also for, so that Jenkins users can basically start using tecton, and they can easily just go through, they wouldn't have to fiddle with the YAML, Jenkins users are okay with using the Jenkins UI, and they would rather do that, so they would rather just go to the Jenkins UI, do some stuff on the Jenkins UI and just say build, and that's what they're used to, so they should be able to do that on Jenkins, so that was the initial idea, and it is in development, active development, but it is also something that I do on the side, so it would be nice to have contributors, it would be faster, and where I see the plugin going is I wanted to be able to support all tecton api, and that also means that there needs to be some kind of contribution, so the thing is in the tecton plant plugin, we use the tecton extension for Kubernetes land, so the tecton extension for Kubernetes land doesn't support all APIs, but what would happen is that while we are working on tecton and trying to support all APIs, we will have to also start contribute a little bit to the Kubernetes land as time goes, so we have all the APIs supported in Jenkins, and as time goes on, it would be nice to have event listener support, and once that happens, and if the cloud events plugin works out, this is all in the future, this is what I was just thinking about, so if the cloud events plugin works out, the tecton client plugin could do a lot of stuff through the cloud events plugin, so there will be a hard dependency on the cloud events plugin at that point, but then that's what the cloud events plugin, I'm ideating the cloud events plugin for, because once the cloud events plugin is done, Jenkins can support cloud events and work with them, and there is a proper methodology for it, I think the tecton client can leverage it and then also work with tecton more easily, and once that is done, again, I'm just thinking out loud, not like this is just ideating, but once that is done, it would be nice to see in the Jenkins file, we should be able to have a DSL for it, and once it's in the Jenkins file, I see that that would be a good plato to reach, because then once it reaches that plato, then a lot of people can actually start incorporating it more into their Jenkins workflows, so yeah that is basically it, that is basically all I've thought about it, yeah it's nice to see some interest towards it, thank you for forking it, I was like who, who forked it, there's one more person who forked the project, wait who is it, oh it's Garrett, oh I'm meeting him, alright it's nice meeting you Garrett, okay nice to meet you too, now I was just, I mean I was looking at it from a, I suppose it's like a build density point of view, so we want to build on top of Kubernetes where we've got lots of jobs going, certainly for CI doc Jenkins.io, for all of the plugins, one of the kind of issues that we have in converting that to Kubernetes is that for every agent that we spin up, we also end up spinning up a GNLP container with a JVM on and that takes a considerable amount of memory and CPU costs and for the sort of 1500 plugins that we're building with, that's, that can be quite a lot, so we're looking at a way of sort of running those builds with, you know, in a, in a lighter way if possible and one of the things we found on the Jenkins X project was that as soon as we switched to Tecton, we got amazing build density straight out of the box just because the builds are so quick, they're so lightweight, we could do all those things, so something like that would be, that's kind of where I'm coming from really, possibly the UI, the ability to create or update a job from the UI isn't so much of an issue, I don't think that would be something that we would probably look at, I'm not sure how we would do it yet, but I think using something like, or how giving the ability to use like Tecton and Tecton catalog, those those sorts of resources, sort of as reusable components inside Jenkins and be able to view the log and handle correctly if the pipeline fails, that kind of stuff. Great, I've done a few prototypes using the TKN client to trigger a job and handle, and I'm basically just doing a, you know, Cube CTL apply inside a pipeline, but then I still have the overhead of trying to, I need to spin up an agent first to be able to do that, and that's problematic, or I take over an executor on the controller, and that's what I'm kind of trying to avoid. Yeah, I mean, one of the approaches we took on Jenkins X was to have, it's not actually Jenkins X that triggers a job, it's a component called Lighthouse, and that uses a .lighthouse folder where you can actually put your pipelines and resources and everything you need inside there, and they're kind of lightly manipulated and then applied so that you have full control. I was wondering whether that would be something we could look at to, you know, have a Doctecton folder or something like that inside your repo, and it would be able to handle those or at least create a job based on that, a pipeline or a pipeline run, whatever else. There is a project which is going on called a Tecton config, Tecton is called, or if Tecton config is called, which does something similar, I don't know if you've heard of it. I've seen it on the Tecton working group, yeah, I've seen it mentioned. I don't know much about it. Something similar, like you put a .tecton folder in the root of your git, and then it basically picks everything up from there. So I'm not very sure how it does it, but it's supposed to be similar to, like, you know, having a .pravis folder, or file, it's supposed to be similar to that. I'm actually not very well versed with Jenkins X, apart from the fact that it uses Tecton, and it's like an amalgamation of different components, like which work together. Yeah, but I understand, from what I understood, you try to run Jenkins jobs through Tecton, and you'd have to sometimes spin up agents by yourself, that's what you're avoiding to do. Yeah, so I suppose the initial kind of prototypes that I came up with, just they used the Tecton CLI, the TKN client really, and the way that that seems to work is if I put the control of that into a pipeline, then I end up with an agent being spawned. I suppose we can maybe run it directly from the master. When you say controller, what do you mean? I'm sorry, the master. Jenkins master? Yeah. Okay, okay, okay. So how are you, so are you, let me go back to another question, maybe which was repeated. So Kara asked a question about if we can run the client without a JNLP, like an environment which doesn't need a JNLP connection. So this is something you want to achieve, right? Ideally, yeah. I mean, that kind of thing, I suppose that would be like an optimization really. It doesn't, I suppose what I would, I'd like to be able to spin off create or manipulate or spin off a Tecton, you know, a Tecton pipeline. Yeah, and at least monitor it for failures. I'd like understand whether or not it passes and fails and the kind of like ending up status, it affects the Jenkins drop. And I suppose view the logs of that pipeline as I would through the UI. That's kind of where I'm thinking that would be kind of like a first step. Okay. And then is that currently the sorry, sorry for breaking, but currently the logs are supported. Like, I don't know. So last few times I prototyped it and checked it for like for CDCon. And a little bit after the log streaming work well, log streaming works well for task runs. I'm not sure about pipeline runs right now. I need to check. It's just been like a lot of times since our last I worked with the plugin was last week. And that was when I was reviewing it with one of my juniors. And you're trying to figure out like what we need to work on next. So it's actually a lot of cleanup first we love to do. And then after that it'll be most of, but yeah, it is possible to. So what I did was I basically just copied the logic that was there in the Acton CLI code of how they stream the logs. And I just like replicated that in Java. And like, and, and it's, it's, it's very possible to do it. And like, what would be nice to have is as you said, would be the catalog support. So catalog support a planted for V1 right now. Let me just share like a tentative V1. So you have the link. So link to the road, you do have the link to the road. I think I've seen that on the GitHub. Yeah. So for the, for the tentative V1 like catalog support is like, is supposed to be there. And I hope to start working properly on it by the end of, like at least by the end of this month. So there's, there's, there's a lot of stuff and like help would be appreciated like from wherever I could get. I am trying to see if this can, I don't know if it's possible. Maybe this can become a GSOC project. Maybe that would help because just because I actually have a lot of other response release and this was kind of like a side project I worked on. And I would actually just love to go ahead with this because we are kind of going to plateau soon with some of the features that we have for Jenkins automation operator. And I'll, I'll, I'll get time then to like work on tech on and all of this other stuff. So also contribute to tech on from time to time, especially to pipeline and currently I'm working on a debug feature for it. So I really want to be able to work closely with tech on as much as possible. So it'd be nice to have someone who can contribute as well. Are you planning on contributing by any chance? Yeah, yeah, definitely. Yeah. That would be amazing. So it was, I remember like, so I had the prototypes ready for a bit, but I applied the talk for CDCon like in the last hour I was thinking should I or should I not, but I'm going to edit and it was like it came through and I really want to see this project go forward. So where do you see and how do you see this being used like in the hands of users and is it so you said you work like primarily on Jenkins X, right? So I was, I was working on Jenkins X up until probably about midway through, no, maybe like September. I think it was. Yeah, I was primarily focused on Jenkins X. But working on like SAS style components for Jenkins X really, and that's where we were focusing on. And then since then we have been, I joined the Jenkins community team. So I've been looking at Jenkins sort of infrastructure. So the main, the instances of Jenkins that host I'll build all of the plugins, do what we do releases from. So it's more of the community side. And it's all Jenkins rather than Jenkins X. But what I'd quite like to see is to see, to bring it over some of the learnings from Jenkins X back into Jenkins. So certainly around the usage of Tecton and like, yeah, better ways of scheduling builds and pipelines on top of Kubernetes. That's where I think you're on. Yeah. Okay, that's good. That's actually, that's actually very nice to hear because like, I don't have much Jenkins experience as such. But like, we, if we are able to work together and work on something that will actually make Jenkins support Tecton, and maybe anything that supports cloud events, I'm just like looking forward to that. I think there would also be other people in the community interested in doing this. And I know that I've spoken to like a few X Club, these employees that are doing or running into the same sort of thing problems. And they really want to know how to get much better build density on top of Kubernetes and using things like Tecton and can they sort of work it all together. So maybe I'll throw other people in. Yeah, that should be good. The thing with Jenkins is I'm going to be extremely blunt here. People don't like the fact that it's a monolith. And it's really, they don't like the fact that, and it's not about even liking the performance issues are there. And we have a lot of peeps and Jenkins in OpenShift who like, just don't like it. That's why like we are kind of moving to Tecton in the first place as a primary CICD. But the thing is the matter, the fact of the matter is we can't just force people. And that's, I feel like we can't just force people to move to like a new tool. You've got to give them some kind of, tool to actually move and like some kind of, don't give the farmer fish, teach them fishing. I feel like you can do that with some integration like this. So I really feel it's possible to do it with some kind of plug-in integration or something. So I look forward to this. So have you run the plugin before and are there any kind of issues you see? No, I mean, I was trying to find out if there was an actual release, like a proper release of it yet. Like is it, do you know if it's downloadable? It's it's downloadable from the experimental channel. Okay, that's what I need to do. So there hasn't been an actual release for it. But it's, so if you go into the releases, you can see that you can pick up the from the. So this is the TechTong client plugin that's available on the experimental channel. Okay. Two things starting with the more important one. For, for moving this forward at a community level, I think it would, you know, if you mentioned having this as a GSAP project, I think this actually would be a fantastic GSAP project. And would either of you like to do a draft proposal and submit it on the mailing list for GSAP? I know you've, yeah, okay, awesome. And then we can get some feedback on it and, and put it up as a draft proposal on the website, which would be great. I think there will be a huge amount of interest from students. I think this will be a very popular topic. So it's nice. And I think it's great for Jenkins and for the community. So that's very good. My other question is more from for me. So when we talked about build density, Vivek, you mentioned Jenkins file runner. How, how do you want to speak more on that? Because I think I have some questions about how these things relate Jenkins file. Yeah, you I said we, we were looking for, well, I guess I didn't say build density so much. I said we wanted to spawn a pipeline without spinning up a JVM and you, you're actually Jenkins file runner likely does something similar or, or that work. So I actually worked on the Jenkins file runner. So I was just like very interested with the Jenkins file runner because the fact that you can run Jenkins files like Oleg is amazing to like, like make that I really like the Jenkins file runner. The fact that you can run Jenkins file is on a soulless fashion. This has a like Jenkins X uses Tecton. It really doesn't run Jenkins files as such. But Jenkins file runner actually runs Jenkins files in soulless fashion. So initially I taught that Jenkins X was, was doing something like that when I, when I just heard its name. But later on, I figured out that it's basically running Tecton. But Jenkins, so the, so with Jenkins file runner, if you can just give Jenkins files and the required resources in a fashion, which is replicable. And like, I was thinking if this is possible, then people can just use use this methodology to run their Jenkins files in a soulless fashion. To do this, I figured out this sounds like a great idea for an operator, because that's what operators do. That operators are used to like replicate, like replicate these kind of, you know, processes. And the, so what the operator does is it basically helps the user. So it's even that is like, you know, POC phase. It's not in the Jenkins here or the, so it's basically just POC, but it's basically just supposed to allow help users build their own Jenkins file runner image. And that image will contain all the plugins that they require. And then they can use this image against any Jenkins files, files they want, which requires these plugins. So it's a portable image, which they will be keep using for the same Jenkins files. They won't want to run in production. And there are a few things missing, like, you know, the ability to add RBAC to the Jenkins file runner pod. So once that RBAC is gone, the operator, the pod can actually spin up other pods and stuff, because when you're running Kubernetes client, the Kubernetes client require, in the Kubernetes client plugin, that plugin requires you to give certain permissions to the pod. So we did, we did a POC on this. So my teammate Akram, he had actually worked on the Jenkins file runner to do a POC on OpenShift. And he basically ideated that. And I built on top of whatever like Oleg and Akram built. So I turned that into idea into an operator. So this is also possible. And this is something that would also help users kind of just run their Jenkins files in Kubernetes. I don't know how this correlates to build density, because I'm not sure what you exactly mean by build density as well. So if you could help me out with that. So I suppose the build density is just, is referring to like that, the number of, the number of builds that you can process per, yeah, available CPU and memory. So on Kubernetes, if, if we say we're on GCP and we're running with, you know, a number of standard sized nodes or something like that, how many builds can that actually process. One of the issues that we had on Jenkins X when we used Jenkins file runner originally was that because it requires a JVM to do the initial launching, you're, if you're doing a Maven build, you're actually launching double, you're launching two virtual machines to be able to do that, or two JVMs anyway, to be able to do that. Rather than with Tecton, you're just launching the single one. Yeah. Yeah. So that we, we, we had to run with pretty much double the number of nodes to process the same amount of builds using Jenkins and Jenkins file runner. Yeah. The Jenkins file runner is, it does take a long, no images do take a long time to build, actually. For the Jenkins file, because they are quite heavy and like Tecton, even the core Tecton doesn't take that much time to even get deployed, but the Jenkins file runner is like performance heavy. I feel that way the build density that you could achieve with Tecton client plugin, even right now would be much higher than actually just running jobs, because at the end of the day it is using Tecton. And if you consider Tecton client plugin as the main engine for your jobs, through Jenkins, it would not engine engines the wrong word, but the interface for your like Tecton jobs through Jenkins, it would, it would be, you could achieve a higher build density than this. There needs to be like the, these are not real numbers. Like I'm just, I'm just thinking like it would definitely be much better because the Jenkins file runner is quite heavy, but in case like where customers like who don't want to move from like, like, like Jenkins in, in the, in that scenario, I think it'll be nice for them to suggest the Jenkins file runner, but it's, it's definitely, I would say it's definitely better to migrate, like migrate to Tecton. So currently I'm working with a guy like he, he's kind of a, he's, I've known him for a long time and they run Jenkins in their, like environment. And he, he's looking at moving to Tecton. So he's, he's taking my help to like understand how the covenity, like covenity side of things works and they're just saying that it just takes a lot of performance. They just need to keep like upgrading their AWS instances and more storage. So it is something that the, like he, he's thinking of that way, but I feel like you can achieve like high build density to Tecton. So yeah. Thanks. That was a very good explanation for me. Thank you. So, so my only thing is, like, it should be like, what would be nice is when, like when, once we reach the DSL stage in Tecton or client plugin, at that point, I feel users would be extremely comfortable to start using it because they, they, I feel a lot of them maybe don't care about, you know, some, some, some of them might not even care about the UI, but a lot of them might care about the Jenkins file itself, like, and doing everything through the Jenkins file. So it could be something to look forward to after the catalog feature. So that would be nice. In terms of what prioritizing work, you mentioned that cloud events would facilitate a lot of the Tecton plugin work and be like the Tecton plugin would have a hard dependency on the cloud events plugin. Is that, is that still the, the development like basically overall roadmap you're looking at for this? That's so what you're thinking. So the cloud events part will come much later on when. Would come later. Okay. So if you have much later on, like when you would want to kind of create a link between the Tecton cloud events and the Jenkins cloud events, like if you want to do something like that where if the, like you're listening on like a Tecton cloud event and hoping that once the, you know, task exits, you want to do something in a Jenkins job, which probably you couldn't do through Tecton because Tecton doesn't support it or doesn't do something. So cloud events would help in that case. Okay. So creating the sync for it. So the, and it's hard dependency, dependency, but only later on. Like you would Tecton might use some of the plugins capabilities to create for like event listeners and stuff. So to create an event listener, maybe like create a sync, like I still need to like dive deep into the cloud event stuff. I have tried a bit, but I still need to read up a lot more about it. So there's a lot of study that even I still need to do. So I think I put a link on your draft proposal for the cloud events plugin to a work stream group with the continuous delivery foundation. It's under the interoperability sake. Actually, it's going to become its own sake probably next week. But that might, yeah, that might be an interesting meeting or sake for you to go to. So work stream was part of interoperability, right? Yeah, but it's, it's gotten a lot of movement and interest and the idea is to make it its own sake. That's nice. So I guess Andrea Frittoli, I think he's part of the work streams, the work stream. He, he architected the cloud events stuff in Tecton. And I actually want to, I'm actually trying to study that the way he's done it in Tecton to understand how it could be maybe replicated for Jenkins because yeah, for me it's just a learning thing. I am not that great with like cloud events, like eventing in general, but I'm just trying to learn as well as time goes. So his model I feel is a good place to start in Tecton. Yeah, I think so. Good. So I'm just, so should I mention this in the, I didn't, I didn't, I didn't actually get the, get, so should I mention this doc to the interoperability guys or the work streams? Which doc, the cloud events proposal doc? Yeah, yeah. I mean, there's, you know, there's, there's no reason why not to. Okay, cool. That sounds good to me. Yeah. Okay, I'll do that. You can kind of get, you know, I'm sure it'll be a good discussion and you'll get feedback, so I wouldn't have to take. I'm sure Andrea will ask me a lot of questions which I wouldn't be able to answer. It's good. You can turn them around and ask them, them back. Yeah. I'll come back in a minute and it'll be like three days later. Awesome. So we're at 45 past. Are there any other topics to discuss for this evening? Not from my side. Nope. Nothing from me. That was, that was pretty good. Yeah. Yeah. Really good. I'm so happy you two met and had a discussion. I think it's really fruitful. Thank you for the proposal on the cloud events for GSOC and if you would like to make another one for the client, the Tecton client, that would be, that would be great. Yeah. I'll do that. I'll do that. Let me see. I think, I think I should have it by the end of next weekend at least. Okay, cool. We will look at moving this meeting two hours earlier and I'll just do it and announce it basically or maybe ask and then. I'm just thinking Maki and Oleg are not here. It would be nice to have them. Yeah. It would be really nice. Maybe, maybe we can get Oleg and he's super busy right now. He's been pulled into so many different things which is, but I know he likes to be involved in the community. So hopefully this is a meeting they'll interest him. Do you think this, this is a good meeting to continue these discussions on cloud events, on Tecton, catalog integration, things like that? Yeah, I do agree with this. I feel so, I was, so when I proposed the Tecton client plugin to Oleg, he suggested that the plugin be discussed in this meeting. Okay. I think it's a, makes sense. Yeah. Agreed. Okay. Great. Thank you all. Very good meeting. Have a good Friday. Thank you Bob. Thank you for showing up, even though it's so late. Good seeing you, Gareth. Thank you guys. Thanks.