 Yeah, we are late. All right, cool. Give me one second. Can you see my screen? Not yet. Okay, one sec. Okay, this part. There we go. Okay, should be all set now. All right, so on the call we have Oleg, Joseph, Natasha, Slaydan, and myself. I think that's everyone. This is the office hours for 3rd of July. So, since the last office hours, we've had two releases, 1.21 and 1.22. I think 1.21, there was no user facing changes, but there was for anyone using the JMH benchmarks, support was added to people depending on the configuration as code plugin to configure JMH benchmarks using configuration as code. And in 1.22, there was a few fixes, so Oleg just added the blog to the meeting notes of how to do the JMH benchmarks. In 1.22, we added a debugging fix for to make it easier when there was bad configuration being sent through. It now shows the expected parameters. I'll just show a quick example. And here it now adds the, so available attributes are now in there. Here we go, expected names and parameters, expected type of parameters. And I think that's now being combined in line as well. So hopefully that makes it easier for users. We've also added some support for I think subclass fields that we had to on the descriptor. So Git plugin was doing this. You can add browsers to the Git plugin in some way. And that's now supported thanks to Oleg. We've had some demo fixes for the EC2 plugin, which is now compatible again. And we have the test now passed with Windows again. We're not testing every build on Windows because of the Jenkins infrastructure, the Windows tests. The Windows infrastructure is a lot slower and not as reliable. And we had a lot of issues with it, so we don't test continuously. So every now and then issues are introduced. We try not to. And the other thing is we're now blacklisting default properties on tools. So that's something that's used for the UI, which was being exported. And it was preventing you from being able to export your config and import it again without any modifications. So now in a lot of cases you should be able to export your configuration and then re-import it and it should work before this change. It wasn't possible. We've also added a blacklisting method inside of the plugin for now, which you can add to if you don't want certain fields to be exported. This is an example of the syntax. So the one that we have, the one that we have, blacklisting is currently default properties on Hudson Tools Tool Property. We're open to extending this to making it so plugins can contribute themselves. But we just need to see that there's a need and there wouldn't be too much of a change given that we're looking at the GEP 200 that has a similar sort of functionality. And we may move and we are looking into removing the we currently have a restricted annotation which isn't really meant for us to use but currently we ignore anything that's restricted and we're looking at removing that behavior as requested by a couple of users and then using the blacklist functionality instead but that's ongoing work that we'll look into soon, hopefully. I think that's all from the release updates unless anyone's got anything to add on that. Nothing specific. So maybe it was mentioned that we had a few plugin releases which added JCASC compatibility. For example, the EC2 plugin which has been already mentioned now it's compatible with JCASC. The bugs have been fixed today and released. Then in Git plugin we now have support of submodel definitions. We are still waiting for the final release but it should land soon. And yeah, there is a lot of other pull requests which are staged for example, a log parser plugin a pull request created by Joseph if I recall correctly. It's also staged for the release. So yeah, maybe for the next meeting it makes sense to just put a list of such new integrations. Yeah. But it makes sense. Yeah, another one I know of is the Build Fairly Analyzer plugin is now compatible in beta. It's an experimental version you can use. This needs to be sorted by recently updated. Well, it's not trivial. Basically it's sourced by artifact ID name so that we can group plugins. The other dashboard I think is sorted by recently updated. Yeah. Yeah. This is the only open dashboard. Open compatibility issues. This one is sorted by updated. Okay. So we'll go on to the next topic. We've got Oleg here's some Google Summer of Code updates. Yeah, it's just a quick update. So last meeting we had one student who joined the meeting to talk about his JSOC project. So the update that this project is not going to happen. So the student we have grown and it means we are not going to proceed on the scope we had in this project. But yeah, maybe there are other options which we will discuss in the next items. So yeah. Right now there is no JSOC project which strictly targets JCASC. But yeah, for example Abiodale already did some patches for performance testing because system and Natasha is interested in the data planning manager. So still we have a lot of activities related to JSOC JCASC and JSOC projects. All right, cool. Thanks for that update. So we have the Jenkins configuration as code community bridge projects discussion. Slaydan, do you want to do you want to Yeah, sure. As I discussed with Oleg, I think we thought about I actually read the community bridge kind of the application form that was there and Oleg said that you could apply there formally and they had a JISAC they had all of the configuration ready to actually start this project. So he told me to pick you guys on the channel and take some beginner pull request. So that's why I just picked some beginner pull request and actually wanted to discuss some of the things that we could do as a part of the community bridge project. So anything anything you guys can contribute. So maybe it makes sense to briefly introduce community integration. Actually this is JSOC as a service program being run by Linux foundation Jenkins project moves to continuous delivery foundation and continuous delivery foundation as a part of Linux foundation. So basically we get access to this platform and we can use it for our projects. And one month ago so there was a discussion about RISC meetings about using the platform. We have created a stop project there and basically there is an interest to try it out and to have a program running but it will be a low scale program so maybe a few students and few projects I think it's a lot for your interest. I think we can use it as an opportunity to run the program. Unfortunately I'm still waiting for the Vocational RISC meeting recordings to be published so I cannot refer anything specific and if you want I can just screen share and show this program but basically nothing is really settled there so we just have open way and yeah we don't have strictly defined process and strictly defined timelines. Okay it feels appropriate to show something there if you want or let us know what you need from us there is there anything you want to discuss now or I think it was a discussion now yeah if you have some ideas what you would like to work on or particular interests you would like to focus on? Yeah yeah I mean anything that you guys if you guys have any project in mind regarding Jinkask I would love to like maybe we could set up a maybe a Gita channel or something where we could just focus on this a particular project like this I'm just beginning to solve some issues I'm getting a feel of it so if you guys have any sort of a specific project that you want to undertake yeah there's definitely a few small features I'm not sure but larger projects because there's quite a few non trivial features that would be great to work on I think I should have a doc on the Gita channel regarding the project maybe I don't remember exactly where it is maybe we could add some points there regarding to what we discussed let me see if I can find it okay I'll see you on my screen again show it yeah I'm looking for the document in parallel so basically if your agenda items don't hesitate to just add links to the agenda so that we can quickly find them yeah so that's just like community grid project doc yeah just a brief description okay yeah I mean for us it's really what you're interested in working on the certainly certainly some nice missing features around the IDE and the the schema that would be quite nice to fix fix and enhance because the schema doesn't really work properly right now so you can't validate and you can't you can't use a JSON schema for IDE auto-completion would be quite nice could you could you could you add it to that doc yeah that would be I mean if you have a concrete kind of set of points yeah I didn't get to the meeting call straight now yeah we can move it to the google doc I think that's one of the main features the other one is the wrong configuration kills you can start that would be quite a nice one to look at yeah could we could we compile I think we could compile all of these issues and do a single problem statement where we could actually take it up as a full-face project then yeah yeah so if you want to have a bigger problem statement so what team was referencing it would be integration development tools and support of development tools so yeah it might be integrations it may be validation it might be for example Jenkins pipeline steps or whatever which would be able to verify that so that somebody could set up CI CD whatever so I guess it would be interesting for any project user yeah yeah and other possible problem statements are just whatever integrations would have new features for example ufi was interested in adding support of providing configurations not from file system but from s3 and in such case it would also require some architecture changes for example adding extension points adding additional providers so if you're interested in such work it could be also doable yeah yeah cool cool I think I would just have a look of all these points that you add and then I think maybe formulate a problem statement and propose it maybe that would be cool yeah yeah do you guys require any proposal of sort like since we're following the GSOC framework so just in case so that we document everything that we're going through yeah so my suggestion would be to have a proposal yeah I don't think that you need to spend too much time on the proposal because the main idea for that is just have top level guidance and understanding what you want to do yeah cool cool yeah and since you already reviewed it you already did some contributions we have an interchart so we can just discuss that there is no need in application just application but still having some proposal would be nice yeah cool I think that's nice so you can just update it I think that's a nice idea yeah right and you also had a question about the special guitar chat yeah I know I don't think that's needed right if we can just have the normal Gcast channel because because having too many channels would be difficult to like track yeah that's for sure and the convolutional scope channel is definitely a place where you will get feedback from potential stakeholders yeah regarding to Benters I think Tim and Joseph would be or are there any specific yeah would that be cool or sir okay cool yeah so we firstly need to understand the time frame for the project because what we can't put in a community bridge it's autumn because my approach was that JSOC finishes in August and after that we can start community bridge because we have more mentors around etc yeah cool basically we can start when you and mentors agree so I can adjust the program to get it running yeah I think I would be flexible yeah depends on my mentor yeah Tim thoughts on that right so one potential set of community bridge is financial side so we have for example JSOC students a better stipend and we had a discussion in our advocacy and outreach special interest group about having a kind of stipend for community bridge participants so right now it's not confirmed but I got initial for that so I would be just interested to know what is your expectation so that I can work on that I think I don't have any such expectation from the financial side it's just a learning kind of thing for me so anything anything from your side would be fine I think okay I don't have any such specific expectations no specific yeah right but if you dedicate significant time 30-40 hours of course we need to think about something if it's a relaxed mode just like other open source contributors to do it's other option but yeah I'm going to be a pretty much flexible there yeah cool so yeah let's see what we can do about it and yeah I'll circle back but Joseph Tim what would be your availability in terms so let's assume this project starts you can handle all formalities maybe in one or two weeks what is your preferred timeframe for starting the project like I'm available on chat during the day my time zone and I can have calls every now and then and definitely have a recurring call or ad hoc every now and then but not hugely frequently but I'm around that's fine same for me so yeah so basically you're fine to start when you're ready yep yep yeah and what about you John would you be interested sorry I wasn't really listening to the details but if it's in my time zone I'll be usually be available I've got obviously some information coming up but apart from that I'll be I'll be around so yeah my action item is to just get everything crying but yeah I can probably do it in a couple of weeks yeah I think yeah the formalities yeah yeah regarding the mail and stuff you could send a formal mail which could actually so that we have all the documents and stuff ready okay yeah that's fine thank you for that okay all right I think we'll go over to Natasha now for the plugin management GSOP project integration yeah so I just kind of wanted to see I guess like kind of how this would fit into configuration as code and try to better understand like how those two will fit together and then like yeah how I can configure my project to fit in what's existing and I guess how configuration as code would want to use the plugin library hello did you okay so I don't know if you caught that I guess so maybe just for like this is kind of just like really basic stuff but like so I guess like first question is like how would like configuration as code want to use my the plugin library and then I know that this was kind of done before but there were some issues so I just want to try to understand that better so I was wondering if you guys could explain that a little in a little bit more detail I can say what the problem with the previous implementation was those two problems with it one was that there was no guarantee that the plugin would be installed before the configuration was loaded that required it and the other one was that sometimes there needed to be a restart when plugins were installed and well and then there was two problems with that one was there was a bug somewhere that was causing a reboot loop when that happens and two that causes Jenkins to be restarted whereas the rest of the configuration can all be applied live so this complexity which left a lot of people not using the functionality and a few the reboot loop happened a few times to people which really scared them away and most people like myself didn't use it as soon as they hit the problem where they would put the plugin configuration in the config for the plugin and the configuration wouldn't the configuration would fail because the plugin wasn't installed yet there are multiple issues with that basically there are many ways to resolve the issue for installing a new plugin but the real problem starts with updating plugins because firstly you cannot update plugins without restart hence all issues are referenced by Tim and Joseph and if you restart there is no guarantee that the instance will start up at all after applying the update because jcasp doesn't verify that so unless you have whatever automatic disaster recovery integrated updating plugins via Jenkins configuration is pretty complicated and what we were talking about this issue for the tickets actually the consensus was that instead of doing it via plugin we would rather do it via a library because in Jenkins it's possible to inject a library which works on a very start up and does something for example we could inject it using custom work package and doing a civilization of plugins before Jenkins even starts a plugin loading loop does it make sense? yeah I think so and then so like right now I guess like my understanding of current functionality and core is like there's sort of two steps it's like A the plugins have to be downloaded and then B they have to be installed or they have so like I think right now basically what the library does is it just downloads them so is this something where like it would also have to install them or is that that would just be it would be the same thing where it would just like download and then it would just be injected before like the installation even happens I think there are a lot of options so you don't need to implement the existing code okay yeah what could we ideally do we could just make the library your can a part of Jenkins core so I'm not sure whether other contributors would agree with that but basically we could inject support of plugin loading directly into Jenkins or it's not a problem to do it for Docker images for example because for Docker images it's much more trivial so now install plugins which works only when you build the image but basically you can invoke the script or your tool when the image starts up and in such case you can also do some automatic initialization so for me the best way to get jcask integrated with plugin management is to not do any changes on the jcask plugin side but implement whatever library which can read from Jenkins YAML and which installs the plugin according to that when Jenkins starts up so basically you already support plugins TXT if you support Jenkins YAML as an input and if we can basically we can then use a single YAML definition so it will be read into places okay I see for me it would be probably the most optimal way to go because otherwise you will likely hit a lot of issues including Jenkins architecture once I haven't tried it yet so I cannot say what would be the downside okay thanks what do others think it would make sense to me the only thing I could see there was people thinking that the plugins would get reloaded when they changed them because the rest of the configuration can be reloaded on change whereas the plugin would require a reboot but there may be a way to make that clear but yeah I certainly agree that directly in the plugin is quite complicated and likely require some core changes to integrate it properly yeah right there was a pull request by Kosike at some point to have pluggable core components so basically the idea was that to be able to load core components like step 3 or Jenkins Remoting from a plugin so there was a prototype for that but this prototype has never been completed and integrated but if we put this prototype in the core we could have done something like that from plugin for base yeah basically it does exactly the same as just injecting library it just has some machinery to read plugins and extract these libraries before it really starts loading the plugins yeah it sounds odd but it's exactly what that pull request was doing yeah I think that answers most of my questions or at least kind of like it gives me an idea of like where to go from here so it sounds like the main thing is just making this work with like the Jenkins YAML file and then I guess also figuring out like how to inject that as well so there would be multiple things so supporting YAML input is definitely a thing then you would need to ensure that this input can coexist with jcasc plugin because if you just install plugins using this YAML and then jcasc refuses to load because it discovers a section which is not supported it's probably not the best experience so maybe it still presumes some integration with jcasc plugin just to ensure that the configuration doesn't bring down the instance or maybe some edit value features for example, integration with update center to show which plugins are pinned and which plugins are updateable maybe you just want to disable update plugins when they are configured for jcasc so there are multiple options for you if you want to improve integration between jcasc plugin and plugin management but yeah it's a really good question what you're interested to work on I think right now so my main focus at least for the most immediate features just getting things working with Docker but I'm just trying to figure out what's next in the pipeline I don't know maybe we can talk a little bit more about some of those options when I actually start trying to work on that okay yeah it sounds totally right and yeah so basically once you have something working for plugin manager too maybe it makes sense to create a sample demo repository where you use your configuration tool to manage plugins and jcasc plugins to manage configurations and then you can use this repository to increment the new changes and make them closer together so it will be a kind of reference implementation for using tools then all integrations can be just a showcase to them okay okay thank you for that Natasha does anyone have any other topics that they want to discuss I have some topics regarding well some topics I would rather prefer to discuss after the broadcast so if you Joseph and team can stay around for a while it would be great I can stay for about 5 minutes if we want to shut them down okay so people started dropping anyway so I think we can stop the broadcast thanks for watching okay