Jenkins Google Summer of Code Office Hours, 2 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CDF GSoC 2021 Final Presentations

Description

CDF GSoC 2021 Final Student Presentations

Recorded on Aug 24 and Sept 2, 2021.

Intro: 0:00
Presenting the CDF: 1:13
Jenkins intro: 4:13
Spinnaker intro: 6:02
Demo list: 6:27
Git credentials binding for sh, bat and powershell: 7:08
Conventional Commits Plugin for Jenkins: 17:18
try.spinnaker.io: 31:04
CloudEvents Plugin for Jenkins: 43:13
Security Validator for Jenkins Kubernetes Operator: 1:04:07
Jenkins Remoting Monitoring: 1:18:37

A

Hello and welcome to the continuous delivery foundation presentation on google summer of code 2021.

A

My name is mahdi danju and in this presentation the students will present the work that they did during google summer of code 2021 combining phase one and phase two of their work, and this presentation is actually a montage of part, one and part two which took place on two different days and were combining the two into a single presentation for this recording.

A

Today, we're going to be talking about the projects our student worked on, but first we're going to have an introduction to the continuous delivery foundation. Then our students are going to present their work. This will be followed by question and answers links to the phase 1 demo, slides and phase 2 demo slides are provided here.

A

I would like to invite tara to present the continuous delivery foundation.

B

So continuous delivery foundation uh was founded by uh google, netflix uh and cloudbees uh back in 20. I want to say 2018 2019, uh it's a little early in the morning. For me, sorry, I don't remember the exact dates um with the purposes. It's a it's a it's a sub organization, a linux foundation with the purposes of furthering the development tool stack as it relates to, in particular, continuous delivery and helping drive industry standards.

B

um We became a sponsor for google summer of code last year for the first time um and uh jenkins. It has a long-standing jenkins project, has a long-standing uh history with google summer of code, so the foundation joined in along as well and we've had uh students also contribute to their projects. So it continues to be an area where we love to see investment next slide.

B

Next slide yeah, so it's our second year, as I said, we had 22 project proposals. uh We were able to accept six projects. This year um we had uh three to four mentors per project. It's really great. The the various projects get really excited to support the students in their efforts.

B

This year we had good project proposals for jenkins and spinnaker.

B

Additional projects that can be considered would include jenkins, x, techton and screwdriver, as well as ortelius, and then next year we will have another new project that will be online for students to take a look at which is shipwright, so we're expanding the number of projects that are available, and so hopefully you can spread the word amidst your friends. They want to apply for student proposals next year. We will hopefully have a plethora of opportunities.

B

I am pleased to report all the students past their midterm evaluations. I haven't seen the latest results yet for the final, but uh it has been a very successful summer of code season. Next slide.

B

Yes, so I want to extend a thank you to our students and mentors. I also want to extend an invitation.

B

Hopefully, all of you are made aware that you have the ability to record a lightning talk, could be a talk that you recorded for this. It could be another variation to submit to devops world. We have reserved time there, so you have a chance to see your project at an industry event which we hope that you will choose to join.

B

As a reminder, we have a very firm code of conduct and I hope that your experience as a student with one of the continuous delivery foundation projects was a positive one. So, thanks again back to you, martin.

A

Thank you, tara. Before we get started with the presentations, I would like to invite mentors or org admins to say a few words.

C

I would say a few things if you don't mind, of course, yeah. First of all, thanks to all six students working on the continuous foundation, g-sub projects and thanks to everyone who was uh working on jenkins, we had five great projects.

C

Four of them are focused on jenkins in the cloud and on cloud deployments, and even if you uh take a look at these presentations so cloud events, uh remote monitoring with open telemetry and parameters and um security detectors for jinx kubernetes separator. All of them are strengthened junkies position in cloud environments, and this is exactly what we need for the project and all of these projects are important part of the jenkins roadmap.

C

So thanks a lot to mentors students- and we are looking forward to seeing this project adopted by jenkins end users.

A

Thank you. Oleg two organizations participated as part of the continuous delivery foundation in the google summer of code this year, the jenkins organization.

A

You can find the jenkins organization, google, summer of code channels from their main page on jenkins.io. They also use a githere chat. You can also find them on specific channels of the cdf slack. They also use a discourse site on community.jenkins.org and there's the mailing list.

A

The second organization that participated under the umbrella of the cdf is spinnaker. You can find spinnaker at spinnaker.io and you can also find them in the slackwarspay slack workspace spinnakerteam.slack.org under the gsoc-2021 channel.

A

The first three demos are going to be get credentials binding for shpath and powershell.

A

This will be followed by conventional commits plugin for jenkins and, lastly, try.spinnaker.io.

A

In the second part of the demo by our students, there will be three presentations cloud events plugin for jenkins security, validator for jenkins kubernetes operator and jenkins, remote monitoring.

A

Git credentials binding for sh, pat and power, shell.

D

Today, I'm going to talk you through my presentation for good credentials, binding and we'll discuss the results that me and the mentors have achieved so far so far during the g-strip 2021 program. So let's get started.

D

So, under the project overview, the project involves extending the credentials binding plugin to create custom bindings for two types of credentials which are username password and as such, private key. These bindings are then used to automate the authentication task when performing any git operation using command line git through back or powershell in a pipeline job.

D

Now why these bindings were required or what was the motivation behind them? Firstly, when it comes on performing a git operation using a pipeline script, there is not much support provided and the user had to depend on various workarounds to the credentials, binding plugin or environment directive.

D

So the solution was to use with credentials wrapper, followed by credentials, binding plugin, which would take the user's credential and supply them automatically. When git operations ask for them during a user's authentication.

D

Coming to the objectives of the project, so the first objective was to provide authentication support for https protocol and ssh protocol. Then comes the targeted audience which were pipeline job users.

D

Another requirement was that the binding should support command line, git version 1.8.3 and later also it should be. Will it should be available on different operating systems.

D

The last one was that it should support not only a jenkins controller, but also a jenkins agent.

D

Now the results for phase one.

D

So during this phase we were able to achieve with authentication support for https protocol and it was released as get username password binding in get plug-in version. 4.8.0.

D

Also these this binding support supported both freestyle project and pipeline jobs.

D

The results for phase two in this phase we were able to achieve with authentication support for ssh protocol and the support for private key formats include open, ssh, pem and pkcs8.

D

Also, uh four encryption algorithms were supported, namely rsa dsa, ecdsa and ed25519.

D

The support for prior private key formats and encryption algorithms are provided through the bouncy castle, api plugin and sshd plugin. This finding was also available for both freestyle projects and pipeline jobs.

D

Now I am going to showcase the demo.

D

In the demo, I am going to showcase both the bindings. First, I am going to show the working of git username password binding in a freestyle project.

D

So now we'll look in the configurations of this project. uh Here, I'm performing a simple lit check out on a remote repository hosted on gitlab, which is a private repository.

D

So, as you can see, this is the repository that I'm using to perform the git checkout.

D

Now I'm using the get user and password credentials to push a tag to the remote repository so.

D

Now we will build the project.

D

So, as we can see, the project was built successfully.

D

And if we see here there are three tags and now there are four, so the tag was successfully pushed.

D

Now I will be showcasing the get ssh private key binding, so I'm using a pipeline job for this.

D

If we look at the configurations, I am using an agent which is an ubuntu machine to to use this binding.

D

So here I am performing a simple get clone operation on a repository which is hosted on github, and this repository also is also a private repository.

D

So we will be building the job now.

D

As you can see, the build is being performed for different private keys, which are using formats such as openssh, pkcs8 and and all these keys are encrypted with passwords.

D

So the build was successful and this shows that we were able to successfully clone the repository using private key binding.

D

So this was the demo.

D

So now moving on to the road head, so here the we will be discussing the tasks that need some work even after the g-shock program. So that includes adding more automated unit tests and making minor bug fixes and code improvements. But apart from all that, the major task is of releasing the git ssh private key binding.

D

And that's all for the presentation. Thank you.

A

Are there any questions on uh the this project for for harshit? Who is online right now with us.

B

We have a comment from rishabh just pointing out. It was not possible to do get authenticated operations before this, so securing pipeline efforts is super important. This is this is very awesome.

A

A

I look forward actually using this in my own in my own, build files that sounds uh really useful.

A

All right, thank you very much. uh Harshit we're gonna move on to the next presenter.

A

Next presentation is conventional commits plugin for jenkins by aditya srivastava.

A

Aditya, are you online here.

E

A

Okay, so uh do you want to share share your screen, share your presentation and go at your own pace.

E

Okay, so I my presentation is a mixture of both ppt and a video, but I would like you to keep sharing because zoom behaves weirdly on my system. When I share the screen.

A

Okay, so you you want me to change slide when you tell me.

E

Yes, that would be really good.

A

Okay, the floor is yours, then, and just let me know when to switch to the next slide. Sure.

E

So I'll start with the conventional comments plugin for jenkins before starting. I would like to thank my mentors. I was lucky to have such an awesome, mentoring, team, garrett, kristen, olivier and alan. Thank you so much for mentoring me throughout the phase of dsoc next slide, please!

E

So this is me: I'm aditya, I'm a gsoc student over here, I'm a jenkins infrastructure enthusiast and I like open source in general.

E

We can move to the next slide phase so uh today I'll be talking about what are conventional comments: conventional plugins for plugin for jenkins, how to use the plugin I'll show you our demo, extending the plugin and next steps followed by q. A if there's any.

E

Okay, so what are conventional comments, conventional comments.

E

So mutton there would be some kind of an animation here in place, so if it it will be better if you can just bring out the whole slide.

E

Yep, that's it okay! Thank you. So much so conventional comments are a lightweight conventional convention. On top of our commit messages, they are made such that so that it is easier. uh The commits are human readable and it is easy to write automation, tool. uh Conventional comments dovetail with semantic versioning. So uh can we move to the next play.

E

There are some examples of conventional comments, uh the chorus used to uh so conventional. As I was talking about conventional comments, uh they are did update with semantic versioning, so they follow this pattern of uh major minor and fashion patch versions. So achor is a conventional commit which basically says not to bump any version of all the three versions.

E

Fix is incrementing. The patch version feat is a additional feature. It implements the minor version and breaking change in increments, the major version of the semantic versions. So there are multiple ways to write: a breaking change. That's been shown over here on this slide.

E

We can move to the next slide.

E

So now I'll be talking about. What's the what's this plugin, what does this plugin do in jenkins, environment.

E

Martin, you can bring in the whole slide again.

E

Yes, thank you so right, so this plugin determines the next semantic version it takes in the following things: the get comment, log of a repository, the latest tag and the current semantic version that it is at so sometimes that the latest ad in the current version mentioned in the configuration file, would be different. The plugin handles those situations as well. Currently, we support six project types that is maven help. Gradle python make an npm.

E

uh We are adding more uh project types and and and you'll see how you how easy it is to add a project type in upcoming, slides.

E

We can go to the next slide, so using the plugin plugin is available at uh plugins.jenkins.org conventional comments. You can also download it from the update center. uh We are using dev229 to release the plug-in on every feature. A recommended usage and you'll see this in demo as adding a step in the jenkins pipeline and it works on both uh declarative and separate pipelines.

E

We can go to the next slide. A demo.

E

Welcome to the demo of conventional comments, plugin for dentists, here we'll be looking at five major use cases, starting with minor version bump, followed by a major version bump then using build metadata, bumping up three release and write back the calculated version.

E

Let's get started, okay, so, let's see how minor version bump looks like so I have a sampling, even project I'll, show you all the source code, that's in github and as well. You can see there's just one tag at 0.1.0 and I recently pushed off comment, adding a feature that has had hello world action.

E

I have a sample pipeline, ready, I'll, show that configure and here's the pipeline. We are cloning, the project and calling the next version so save it and build so as it was.

E

As the tag was 0.1.0 and we had made a feature comment, adding a feature, so it will pump the miner version and it should ideally show 0.2.0. Now, let's see whether it does that I see the next version. So it's it correctly identified the tag and the next version.

E

So now, let's try bumping the major version. I have a sample repository here with me. It's a sample python repository as you can see, there are no tags present and I have made a breaking change comment. I will show you all the current version of the project. It's usually in a setup.pi or config file. I have it in the config file.

E

Let me open it and the version is 0.0.0.

E

So now let's go back, create a pipeline and from the version.

E

So it's a new item I'll have to give it a name sample python project pipeline.

E

Just the script, so we are just cloning, the project and calling the next version apply, save and I'll build it now. So what we are trying to see over here is, as the current version is 0.0.0 and the comment is a breaking change. It should bump the major version and give the next version as one point zero point: zero. Let's see the logs, so the next version, it says no tax found so as there were no tax and one point, zero point: zero.

E

So we saw a minor version from on the sample maven project, a major version bump on the python project. Now, let's go back to the maven project and see how we can use build metadata in the conventional comments. Plugin.

E

So here we are back at the sample name and project pipeline and I have modified the pipeline a bit to add build metadata to the conventional comments. Plugin I'll show you all the pipeline here. I have used environment variables to add built numbers using the optional parameter built metadata. The rest of the steps remain same. I am finally printing, the next version, so, let's run it.

E

As it's getting built uh if you'll remember, this is the same uh project that I used to demonstrate the minor version bump. So we know that the next version should be 0.2.0, along with the build number so yeah. So here's the print message and it is 0.2.0, along with the build number 6..

E

Let's see another interesting feature of the conventional comments: plugin, that is adding 3ds information, we'll have to modify the pipeline script a bit I'll, be adding the optional parameter, prerelease and name it alpha, apply and save.

E

Now, let's build the plugin.

E

Okay, it's built so the plugin calculated the next semantic version and appended the prerelease information. We gave it.

E

What I recommend you all is to go to the github repository of the conventional commits plugin and look at all the options that are available to manipulate the pre-release feature. So we have three that is pre-release naming the pre-release. Second is preserve pre-release. That is, keep the existing pre-release. The default value is false and finally, we have increment pre-release where we increment the prerelease option and the default is voice. So last two are boolean.

E

I won't demo these in the interest of time, but we can see how it will work using this table thanks to philip.

E

So if our current version is 0.1.0 alpha and we have a fix that is incrementing the patch version, we have preserved, pre-release and increment free release, then our final version would be 0.1.0 uh 0.1.1. This is because of the patch version alpha, because we have preserved the prerelease and that one because we have incremented the prerelease.

E

So the final feature for today's demo is the write version feature the user. A user can use this feature to write back the calculated semantic version into the configuration file of the project.

E

Adding a right words and optional parameter as true would do the job so I'll, apply and save and build now.

E

It takes a couple of seconds to build.

E

It's done I'll, see the logs and it says that the next version was written to the configuration file. It would be interesting to go and check where has this been written, so I have already changed my directory to the project and I will just perform the text summary.

E

E

So here's the version that's been created. uh I think we can go back to the slides.

E

So extending the plug-in, uh as you can see, we had only six projectiles that we supported. Suppose you want to add a new one. That is, uh let's take an example of grow project type. You just have to create a public class and implement the following three methods that is check. The check method just uh is a it returns, a boolean, true or false. It's a check whether the project is at the given repository is of that particular project type.

E

So we usually check for the configuration file, for example, if it's some even project we'll check whether the form.xml exists or not in the given directory. uh Second, is the get current version. It is reading the current version from the configuration file of the project and finally is right version. So uh right writing back the calculated version to the file and thanks to kristin. This was super easy.

E

She suggested the factory pattern for this so yeah. Thank you. So much and oh, don't forget to add your class to the project uh factory.

E

Moving on next steps, uh so, yes, the next steps, would be to write back uh in various configuration files. So right now, maven and npm are done. Gradle, python, helm and make our left so that that would be my next steps and we would love to hear your feedbacks and suggestions for the plugin uh on github and also fundraiser.

E

Thank you so much.

A

Are there any questions for aditya on his work.

B

No questions in channel, though this is very cool.

A

Yes well, thank you very much aditya for your work on the conventional commits plugin and thank you to the mentors as well. Let's move on to the next presentation.

A

Try.Spinnaker.Io by danielle cole, this is also a recording.

F

Hi, my name is daniel, and today I'll be presenting my google summer of code 2021 project tridot spinnaker.io, explore spinnaker in a sandbox environment.

F

I like to start off my presentation, giving a little um primer on what spinnaker is so spinnaker describes itself on its website as an open source and multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence.

F

As you can tell, it is quite a mouthful and I like to break down these buzzwords one by one. A simplified, high level. Explanation of what spinnaker is is a tool that allows you to deploy applications in a very fast and safe way.

F

Spinnaker supports deployments on all major cloud providers such as aws, azure, google cloud provider and oracle spinnaker's biggest selling point is its continuous delivery features. It supports advanced deployment strategies such as red black rollouts, which deploy a new version of your application with the existing version, and it destroys the old version once the new version is ready to go.

F

It also supports automated canary analysis, which rolls out a change to an application to a small subset of users, and then metrics are collected to see if everything is running properly.

F

You can also define your own deployment process to your heart's content. Spinnaker also supports rollbacks, which allows you to revert to an older version of an application if the new version has gone catastrophically wrong.

F

There is also a manual judgment feature which makes all updates require human approval, and you can restrict updates to a certain time period.

F

There are tons of other features that are available in spinnaker and I recommend you to read them. If you're interested on our website, spinnaker was originally developed by netflix to serve as their own private deployment platform, but it was released to the public in 2015 and since then many other companies such as google and airbnb, have also adopted it as their own primary deployment platform and in 2019 spinnaker was donated to the cd foundation.

F

The motivation for this project actually comes from my personal experience.

F

I clearly remember the first time when I tried to install spinnaker and it was extremely difficult to say the least, and I spent countless hours searching through random, get up issues and looking through stack overflow and digging up random messages from slack just to get the main ui of spinnaker to appear on my computer, and I think, probably one of the biggest reasons why it's so difficult is because there's so many dependencies required to actually get spinnaker running. So you need a external storage provider like an s3 bucket.

F

You need to have a kubernetes cluster that has at least 16 gigs of ram and four cores. You also need to set up cloud providers that you want to deploy to, and you do a lot of networking to expose the ui, the api and whatever services you're. Providing.

F

If you compare this to like a project like jenkins, all you need to do to run jenkins on your computers to have java installed and double-click the jar file having a sandbox environment where users can go in and deploy some pipelines and test out. The spinnaker ui is something that I really wish. I had when I first heard about this project.

F

I think other open source projects are the importance of lowering the barrier to entry to having some kind of hands-on experience with their own project, which is why we see services like the go playground and play with docker being available to the public.

F

Regarding the infrastructure of our project, I decided to go with a multi-tenant solution on an aws eks cluster. This means that all the users will be sharing a single spinnaker instance on the cloud.

F

All the infrastructure is codified, using terraform and as simple as running one command to get tridot spinnaker.io running on aws spinnaker and its associated configurations are installed using armory's, open source spinnaker operator.

F

So here are some of the key features relating to environment. From our project, we mainly decided to focus on supporting kubernetes deployments, as the most common use case for spinnaker is deployed to a kubernetes cluster.

F

We support the aws load, balance controllers that users have an easy way of accessing their deployments on their web browser. We also have a private image registry hosted on aws so that we can get around any rate. Limiting issues, and also so that we can verify the authenticity of each image that we allow users to deploy.

F

We have also installed a special admissions controller to block any images that are not from our private registry for user deployments. We have a couple of default pipelines that users can deploy. We also have an auto resource cleanup pipeline that deletes any unused resources after a certain period of time.

F

So here's a demo of the highliner pipeline, where we deploy version one and version two of a certain application. So after you hit the manual execution button, you can see spinnaker going through its various stages for this pipeline.

F

So after everything needed for version, one is deployed here is a manual judgment stage which directs users to go to the load balancer section and take a look at the deployment using the url.

F

So after a few moments, you can see version 1 of the application being deployed and then the user can go back to the spinnaker ui and continue to the next stage where we deploy version. Two of this application.

F

Once it's finished, deploying the user can go back to the same url and refresh the page, and you will be able to see version 2 of the application being deployed, and then the user can confirm that they did indeed see version 2, and that concludes the um pipeline.

F

So here's a quick demo of the cleanup pipeline, so here's another um pipeline that has stuff deployed to a cluster and if we go back to this cleanup pipeline, this usually runs um automatically every 30 minutes or so, but we can just run it manually. For this example,.

F

And after a minute, or so we can go back to the pipeline that has stuff deployed to it, and if we refresh, we can see that everything is gone.

F

Try.Spinnaker.Io also supports authentication and authorization for authentication we're using google's oauth 2.0.

F

This allows anyone with a google account to sign in and get started with, spinnaker right away on the authorization side, I created a custom plugin for spinnaker.

F

This plugin extends the authorization server for spinnaker, which is called fiat and gives everyone a default role called public.

F

The reason why we need to do this is because every application has a corresponding role and we need to give each user a specific rule so that they can access the public pipelines and applications that we have pre-defined for them.

F

The detailed auth flow for spinnaker can be seen in the diagram below so here's the offload from the user's perspective. So once they go to um the try, dot submit the io website, it redirects them to google oauth and they can select which account they want to log in with, and after that, um they are authenticated, so they can see the pipelines and applications that we have set up.

F

If we query the api for more specific information about our account, we can see the roles listed here. So this account has the role public and it also shows um the email and the name that is associated with this particular account.

F

So here are the areas for future improvement. I think it would be nice if there are more default pipelines or more interesting containers to deploy, as there are only really three examples that we offer to users. At this time I originally planned for supporting user created pipelines so that it would be a little more interactive, but due to time constraints and security concerns, we were unable to add this to our final project. For the summer, however, the groundwork is already set for limiting which specific containers that users are allowed to deploy.

F

So with a little bit of testing. I think this could be added.

F

Additionally, we only support users deploying to a standard kubernetes cluster, but I think it would be a lot more interesting if users can deploy cloud specific services such as google's app engine or amazon's ec2 instances for the long-term viability of this project. I think it'd be worthwhile if we pursued a hybrid tenant solution.

F

Currently, users all share the same spinnaker instance and the same kubernetes provider, but in a hyper tenant model. Users would still share the same spinnaker instance, but you would provision a separate kubernetes cluster for each user.

F

This will allow users to have less restrictions on what they can deploy, as well as less security concerns, as users will only have access to their own cluster and not anyone else's.

F

If I wrap up my presentation, I would like to give a couple of announcements, so the alpha release for a live hosted version will be released very soon. Unfortunately, there was a delay due to infrastructure setup, but the link to the live hosted version will be posted on the cd foundation slack and the spinnaker slack. So keep your eyes out for that.

F

Additionally, we're working on transferring this repo to the spinnaker organization's github account and once that's complete. I would love to hear your feedback through issues that you can file through github or submitting any prs that you might have.

F

Finally, the single source of truth for this project can be found in the link below. This is a link to the spinnaker, docs and I'll, be up updating this site frequently with um the live link once that shows up and the slack channel that we can use to discuss um any concerns that you might have about this project or any feedback.

F

I would like to thank the cd foundation for selecting me as a student for this year and for scheduling all the event meetings and things of that nature throughout the summer. I would also like to thank google for hosting google summer of code. This.

A

F

And lastly, I would like to give my thanks to my mentors dan, fernando and cameron, who've been really helpful throughout this entire summer.

F

Thank you for coming to my presentation and feel free to email me or to reach out to me on the cdf slack channel or the spinnaker slack channel.

A

Cloud events plugin by shruti, chaturvedi shruti, is unable to be with us today. I believe, however, we do have a recording, which I am going to play right now,.

G

Hello: everyone, my name, is shruti chatharovi and in this session we are looking at the cloud events plugin for jenkins, and this has been developed as a google summer of code project under cdf, um and the idea behind this project, or this plugin for jenkins, has been to enhance interoperability between jenkins and other ci cd tools.

G

How we are doing that is by integrating jenkins with cloudvents, so cloudvents is an industry adopted a standard specification for describing how events should look like so without using cloud events any of the tools and there's no common format for how events should be emitted.

G

So you know each of the tools can have their own different and specific way. How they're describing events which makes it very very hard to design systems or design systems around events or an event-driven architecture, because there's no common way in each way. Each way is going to look different for a particular tool by using cloud events, we're basically standardizing and we're saying that all of the events shouldn't have this particular structure and does it makes it very, very easy to just define and design event-driven architectures.

G

And we wanted to bring that standard um specification and that common way of consuming and emitting events inside jenkins and that's the cloud events plugin.

G

So um during phase one demos, we talked quite a bit about indirect interoperability about cloud events, and why do we want to use this particular idea of interoperability? And here is the link? It's a youtube video. If this is something you'd want to watch, and if you want to read more about interoperability, um about cloud events and how is jenkins interoperating and how is jenkins using cloud events and also, why did we want to implement it in the first place? Here is a medium article.

G

So the cloud events plugin for jenkins. It allows users to configure jenkins as a source and or a sync emitting and consuming cloud events. So, as we said earlier, using cloud events is going to standardize um the way that events are both emitted and consumed, because it is just giving us a a simple architecture or a simple design of what an event should look like. So with jenkins as a source.

G

We are defining um that all of the events which jenkins will be emitting should be cloud events and when jenkins is a sync, we are defining or we are, we are defining how jenkins will be consuming those cloud events.

G

So why would you want to use the cloud events plugin for jenkins? So obviously the first thing is because it is standardizes communication between jenkins and other ci cd tools and not just other ci cd tools, but also tools apart from ci cd, which is using those cloud events, and this is going to allow indirect interoperability and and we we talked a bit about interoperability in phase 1 demos.

G

But to give you an idea about indirect interoperability, it's just an idea that we do not want to have a direct one-to-one relationship between our systems, which are interoperating. So there is this common language which each of the tool understands, and all we are going to do is make our system interoperate with other systems using cloud events so using this common language.

G

um The second reason is because we can build complex, end-to-end pipelines, extending multiple ci cd tools and again not just ci cd, but also other tools which can which uses cloud events without needing any extra effort, and when I say, without needing any extra effects, what I mean is that we will not need to design specific translators to talk with other systems. We will only need this common language uh which we will be needing in order to design a system which which extends multiple tools and multiple systems.

G

All we will really going to need is for any sync which is consuming cloud events to basically define how it wants to use a particular kind of event which is coming from a particular kind of system. So that's that's the logic behind jenkins as a sink is jenkins, as the sink will understand this common format, which it is going to be consuming from different um systems.

G

You know three or four different kind of systems, um but the, but the logic here is: how do we want to use or how do we want to use those particular events which are coming from all of these different systems?

G

And the third reason is integrating other system but jenkins in a loosely coupled scalable and tool agnostic manner. Again this is too agnostic. So we are not designing this for any particular tool, but this can be extended to any tool which can con for jenkins as a source. um This can be for anything whatever is consuming cloud events so jenkins, as the source is going to be emitting cloud events, and it's just going to be out there.

G

So any of the tool which consumes cloud vents can use this particular event which has been emitted from jenkins, we're not. We are not designing it in a way, so this is going to be um specific to a tool, but this is tool. Agnostic and skillable.

G

In the sense that this can scale to several services, not just two or three but any service which understands and uses cloud events- and it is obviously loosely coupled because we are not creating that direct one-to-one coupling or one-to-one agent or adapter- which we will be needing to talk to that particular service and again it eliminates the need to maintain tool, specific adapters for communicating with systems. So, as you can imagine, it is a much simpler way of communicating.

G

So imagine if we have 10 different systems, 10 different systems in our pipeline and each want to talk with each other, and it would be quite hectic to define um to define essentially ways to communicate with these 10 different systems, because each of these systems would have a different way, but using cloud events, we just have a common link. Each of these tools is going to understand, is going to emit and consume so making all of our design very easy. So that's why um cloud events plug-in?

G

Is your go-to if you're designing um such an event-driven system, and some super great news- is that the cloud events plugin is now released. So from phase one, the one of the questions that came up was when it's going to be released and good news is it's not released and you can check it out right here, download it, and obviously, please do provide us with your feedback.

G

So during phase one demos we we saw um jenkins claudivan's plug-in ui for jenkins as a source, so how we can configure the cautions plug-in for using um jenkins as a source which is going to be emitting cloud events and other systems can consume these events. We also saw the types of events which are supported by jenkins cloud events plugin, um so going back down here we have q events, we have build events, we have job events and also node offline or online events.

G

Another thing we saw was the structure so how the metadata of the event can look like and how the event data can look like, and we saw this using sockeye service, which is a k native serving service and going to define how each of these event is going to look like. So with phase 2 starting.

G

We had some questions for ourselves and these questions made us think more broadly about the cloud events plug-in for jenkins, not just in an individual sense, but also how this is going to look like for when jenkins is interoperating, with many different uh ci cd tools and when a user is building a pipeline which has different ci cd tools which need to inter-operate.

G

So the first question we had was: how can we implement a transient fault, tolerant way of sending cloud events, especially important for an event-driven architecture, because we want to make sure that none of the event is is lost by any network failures and how can the plug-in handle asynchronous communication so very important for implementing an event-driven architecture through um the cloud events plug-in for jenkins inside of jenkins? um The second question was: if we were to implement a in asynchronous communication inside of the jenkins, how how should we do that?

G

Should we have a messaging queue system or a pub sub system?

G

um The flip question was: how can this plug-in work alongside other ci cd tools that use cloudvent so again very important to make sure that the cloud events plug-in for jenkins allows jenkins to achieve that initial goal of enhancing interoperability between different systems in a much easier way and without needing to maintain specific adapters for each different system?

G

So we wanted to see if our final goal of building a two agnostic and a scalable eventing system for jenkins has been achieved through the cloud events plug-in for jenkins.

G

um So all of these questions led us into designing a proof of concept using jenkins, cardone's plugin for jenkins, and also a tools which have been using um cloud events specifically cit tools, and this proof of concept has been inspired by the eventsic team at cd foundation, and so they have something very similar with tacton and captain where both of these systems act as a source in the same sending and consuming cloud events and how they are implementing that um that fault, tolerant and also that asynchronous communication is through k-native cloud events broker and cloud events containing a broker by default, uses cloud events and transfers.

G

It between different systems, so it access that middleware handling, asynchronous communication handling, all um retries and other, never failures which might occur, so it is taken away from both like tacton and captain and in our poc. That um handling of network failures is taken away from the cloud events plug-in, and it is it's sort of creating an abstraction at the cloud and some k native broker layer rather than inside of our plug-in.

G

So so what do we have inside of the jenkins poc for cloud events? Plugin is jenkins as a source, sending cloud events and tact on as a sync consuming cloud, and so we also tested this out with captain um and also did did a test with how this is going to look like for when we are using kafka.

G

um But in this particular poc we are only looking at jenkins and takton, where jenkins is sending a card events broker to a native cloud events um broker, so the caditive cloud events broker has an idea of a k native trigger and a cadaver trigger. You can think of it as a filter which filters on specific attributes of the cloudvent metadata.

G

For example, ce type, so looking here we have ce type, c, spec id and source, so we can specify any of that inside of our k native trigger and only any event, which has that attribute matching will be passed on further and all of the other events will um not go beyond that layer. uh So any of the events which pass the canadian trigger will all will move on to attack on trigger and the tactile trigger is will be receiving the cloud events, and this is where we can extract.

G

You know, event specific information from cloud events. uh For example, you know if we have, we can extract um number of executors or we can also extract event, data or event metadata. However, we, however, we like and pass that information and trigger a tasker on our pipeliner and, however, we have defined it inside of tecton definition. So now we will be moving on into the demonstration and taking a brief look at the yaml files behind for the poc all right.

G

So what we're looking here are brokers indicative eventing namespace, so we have two different kinds: we have the default broker and the kafka broker and the default broker is a very simple cloud events broker, which is going to be dealing with cloudwind events to transfer messages between subscribers and different things and sources. Essentially, so the default broker is the only one where we will be talking about in this psc.

G

This is the broker definition, a very simple default broker, and this is the trigger. So, as we were looking at the image for our poc, the kdata trigger is going to define a filter and it is going to filter events on that specific attribute that we have defined. So the event attribute which we have defined here is type or c type, because we are referring it to type because it is going to be c type or cloud event, specific attributes, so ce type to be um q and thread waiting.

G

So here is the event that we are looking at, and this is the only event which will be passed through to the subscriber of the um of this k-native broker so techton. This is the only qnted waiting is the only one which will pass through, and the next thing that we have is tact on trigger and the techno trigger is what is going to be receiving that entire event and then extract information.

G

So here is where we are extracting information, job name from the ce type, um and then this is the information that we can use in our classroom and our pipeline run. However, we want to use this information, and this is not only specific to our event metadata. We can also use event data um again. This is according to the need of a user. So where are you open to using?

G

However, you would want to use this, so what I'm going to do is I'm going to copy this particular url, and this is going to be the url for um sync of the cloud events broker or the cloud um plugin for jenkins right here.

G

So I'm going to paste this and when I paste this, all of the events of the the types which are checked here will be sent over to the sync, um but whatever will be sent from the broker to techton will be that one event which we are filtering, which is the q, entered waiting this particular event. So I'm going to save this information and what we're here is we're looking at task runs inside of tekton dashboard. So when I run this job, I should see one single task run, not two, not three.

G

So we're looking at this test- and this is the one I will be triggering here- and it will only trigger as soon as that event is received inside of k native clutterman's worker, that is going to be filter, and this is going to be sent over to tacdon and tecton will trigger a task on if the particular event of that type is received. So for now we're only seeing one events and that's good jenkins attacked on task run, and this is what um we have defined so so yeah.

G

So this is the only event that was uh that was received by tekken, because all other events were filtered and if, for example, there had to be, if my tactile was not available um or for some reason there were some other network failures, it would be the job of k, native inventing um broker or the canadian cloud events worker, which handles cloud events, and this is going to be um retrying all of those network and transient failures.

G

So that was it for the demonstration of the poc.

G

So that was the end of the presentation. Thank you so much everyone, a special thank you and shout out to the city, foundation, um gsoc and all mentors on this project for such an amazing summer. um This might be an end of cheese talk, but this is definitely not the end of me contributing to and being a member of an absolutely amazing community, um and if you have any questions and feedback, we would all love to hear them.

G

You can send me an email here, connect with me on linkedin or our github repository and please file an issue with us and we would love to take this further and develop this into a more robust system. Thank you.

A

Great, so I want to thank trudy for sending in this recording.

A

Do we have uh comments or questions from.

H

uh One please okay, so my name is siri and I was a mentor on the open ministry uh instrumentation of blinking through motion. I would be interested in understanding what are the semantic conventions that are used in the event. We can communicate events, we have a shared data structure, but what are the? What is the common known way to common attributes that are shared across all these cicd tools so that they can interpret together?

H

This would be something interesting to me.

A

uh All right um so shruti is not on the call like I guess. Those were comments right. This cyril.

H

Yes, this was something I would be interested in understanding I think, and I've seen the cd foundation has done some work to normalize the vocabulary across ci tools. So I guess it relates together.

I

We may want to have serial connect with the interop, the interoperability sig at cdf, to get more details on the cloud events plug cloud events semantics. I think it's a it's an excellent question. I'm just not sure that the group here has answers for it. Well, I do.

C

Have uh on the basic answers, but we can follow up later for this on the call, but actually cloud events is very pluggable.

C

It's structured event system, so you can add a lot of information in these messages, basically integrate as many systems as you need.

C

And uh yeah one thing which was mentioned that cloud events basically doesn't mean that events themselves are very much standardized.

C

So that's why there is a project started in the continuous delivery foundation about creating a standard for ci events. So there is a separate project started, basically, as a spin-off of the events seep. So there is interoperability, seek the interoperability seek created. Another special interest group in the cdf called events special interest group and this event seek, is actually working on open standard that would uh unify these events across multiple systems.

H

So a great time to contribute important to to be able to integrate things together, and if we can imagine some graphene dashboards things like this. If we have some common semantic inventions, then the community will be able to create a lot of tools that will integrate with all ci systems.

A

Okay and thanks I'd like to move on to the next presentation, if there's no other comments or questions.

A

Okay, I will start my share again.

A

The next oops next presentation is security validator for jenkins kubernetes operator. This is a presentation is by pulkit sharma.

A

And for this one I will play the recording as well.

J

Hi everyone I am today, I am going to demonstrate my work on adding a security validator to the jensen's kubernetes operator, uh so the security validator right so uh like what is the problem. It is solving right so uh in the jenkins custom resource that we are defining or we are defining it in a declarative manner right. So the the custom resources and the plugins are being declared in this fashion right.

J

So uh there are some security vulnerabilities that are present in the plugins and uh it is not visible to the end user so uh to solve this problem uh like the security validator is being added to the operator, so the security validator is nothing but a validation that that operates before the object is persisted to that city cluster right, so it operates before creating or updating or kubernetes or jenkins. Custom resource object right, so the web hook is different from the validation that we are doing in the reconciliation loop.

J

It is after the object is persisted to that 3d cluster, so it is low. In contrast to the you know that validation, the web hook is quite fast and uh yeah so on using the web book. It is completely optional for the user to use a level right and it can be easily installed via help or there are cube, cuddle manifests and that can be used to get the book up and running right.

J

Also, uh we are using a search manager as an external dependency right, because we have to manage tls certificates and uh that's why search manager is used. So let us move to the demonstration right demonstration so uh I'll be using the image that I have read locally to launch the operator along with the web. So this is the image that I have built locally. So this thing is operator security validator.

J

First of all, let me create a new name space or limit demo and then I'll be using helm, charts to get the operator up and running right. So so.

J

We provide the path to the charts.

J

So the name space we have to specify the namespace, so the namespace for the operator and then I am going to.

J

Set the image that I am going to use right, so this is the image.

J

Also, the web hook is completely optional and we can have it up and running you or via this web dot enable tag right so by setting it to true.

J

The web book can be installed right, so this stack will also install all the external dependencies like research manager and all those different dependencies will also be installed or when we will enable the webhook right. So also, it is advisable to not to launch the jenkins cr along with this helm. Charts because of the web hook actually takes some time to get up and running, and if I install the jenkins custom resource along with the web book, then I won't be able to validate the security warning so by default.

J

It is uh set to be true right. So by default we are launching the jenkins custom resource, so we should set it to false as well so yeah. That's it. I think I have specified all the flags. So, let's launch the operator.

J

So it's up so let us see.

J

J

Yeah, so actually it takes some time for the operator to get up and running right. So so it will first initialize the plug-in data cache and all those things. So it uh generally takes around a minute or two to get the operator up and running, and then we can launch the jenkins here right. So.

J

Yeah, so uh all the search manager, resources and all those resources will take some time to get up and running and oh, they will provide the tls certificates necessary necessary for the communication. So.

J

Yeah, I think all the resources are up. So finally, the operator will start.

J

So, as you can see, it takes some times time for the set manager resources to get uh so. That is why the operator was the pod was crashing initially. So.

J

Okay, so now the operator is up and running, so let us try to create a jenkins custom resource from here right, so I have defined some jenkins custom resources and uh in the first example uh I am uh creating a cr uh with some of the plugins containing security vulnerabilities, for example, in this vnc viewer plugin, uh we are using the 1.7 version right, so so this version will have security vulnerabilities right. So let us try to create a new cr from here.

J

Yeah, so it will throw an errors or specifying the plugins containing security vulnerabilities, for example. Oh, it will so like specify that these user defined plugins will have security vulnerabilities and uh we have these four plugins that have security or normalities right. So uh in the upcoming example, uh I have kept all of the plugins. Oh right, so I have updated their versions so to a version which does not have security vulnerabilities right.

J

So uh let us try to create a new cr from here, but, first of all uh let us, let me see the logs of the operator right so.

J

J

J

So, as you can see, oh there there are a lot of warnings in the logs right, so it is like for each version of the plugin. There will be multiple security vulnerabilities right, so in the logs we can like, we can see the all the security vulnerabilities detected for that particular version.

J

Also, we can see the warning message and the link to that advisory right. So there is a whole a lot of metadata that is included in the logs right. So let us try to create a new jenkins er right. So this time we should be able to succeed yeah, so it works.

J

So now let us see the logs yeah, so it wrote a response that allowed is like we are allowing on it to create a object right, so it sends a 200 response right. So yeah, that's pretty much it. Apart from that, uh we have to mention that whether we want to validate the security warnings or not, and if we set this flag to false so, for example, in this particular example, if we set it to false.

J

So here we have plugins containing security vulnerabilities, and if we set this to false, then it should fail to create the jenkins cr right. So let us try.

J

So yeah, so it is able to create the changes here, despite having or despite the plugins having security. What now it is, so we can oh yeah, so we can manipulate it, whether we want to detect vulnerabilities or not using this toggle switch. So, oh, that's all.

J

uh So there is always room for improvement right, so uh some of the areas on which we can like extend the project or add some features is like one of them is to have a post installed right. So, as you have seen, while uh installing the webhook right, so it takes some some time to get ready. So what can be done is to have a post install hook that checks whether uh the web hook is ready and when it is ready, then uh the help installation will be completed.

J

So the user knows that the now he can send like he can create a jenkins custom resource. uh Another uh things, another areas on which the book can be extended is we can move the validation logic that is being done in the controller to the book right and uh there is other sorts of validation that logic that can be implemented in the webhook right.

J

One. uh Another feature is uh like we right now. We are validating the plugins right, so for each plugin uh there is, uh there are dependencies for a particular plugin right. So what can we done? Is we can like traverse the whole dependency graph and check for uh validate all those plugins? All its depends dependencies as well, because uh that is uh those are. Those plugins are also being installed so uh like validating uh those before installation uh would make sense right. So this is another cool feature that can be implemented so yeah.

J

So that's all from my side. Thanks.

A

Thank you pulkit for this presentation. I will stop the share and open the floor for questions and comments.

A

Do we have questions or comments regarding a pull kit's presentation.

A

Okay, going once going twice, let's move on to our last presentation today.

A

Oops: okay: our last presentation is jenkins, remote monitoring by akihiro kyuchi, and I believe akihiro is here. So do you want to share your screen.

A

I

We're not hearing any sound from you akihiro, I can see. I can see it looks like you're speaking, but I'm not hearing any sound.

K

How about this? Yes, yes, okay, thanks so much! I I want to share my screen.

A

K

Yes, thank you.

K

So do I begin yes.

A

Yes, we can see your screen, you can.

K

Go ahead thanks so much I'll talk about my project, remoting mulching, bees, open telemetry and I'm a kiroku, and the purpose of this project is to support jenkins admins in troubleshooting and monitoring the remoting system.

K

And to achieve this purpose, we set the goals below one is to correct telemetry data, including matrix traces and logs of the remoting module with open telemetry, and the other is to set to send the data to an open, telemetry protocol endpoint and the open. Telemetry is our next standard. Next industry standard, observability framework for cloud native software and and it handles three type of geometry- data, rugs, metrics and traces at once, and thereby it enables the integration between the different type of telemetry data and but in this google swap record.

K

I didn't include the trace feature and either explain the details later, yes, and and which open telemetry and the point to use or how to visualize. The data are up to users and users need to set up these services on their own I'll. Show you a demo first.

K

K

And I will forward the getting started section in the redmi of this project and I've already crowned the repository in this demo and now change directory to the example directory and run docker containers using docker compose, and this will set up open, telemetry corrector and which is an open telemetry protocol, endpoint and the rookie for rug, aggregation and premises for matrix, backend and graphana for rogue and matrix visualization.

K

And in this demo I will also set up a junkies controller using the docker compose.

K

Yes, and next I will download a monitoring engine from jenkins maven repository.

K

This engine is a java file format, java format, file and this engine is the main deliverable of this project, and I will use the engine later as a java agent when launching agents.

K

Okay, and when you want to correct rugs of remoting, you need to create a login property file and use our rogue hundred. So I will create the login property file and copy this configuration file.

K

Yes, and here you need to set our.

K

Logging 100 here, okay.

K

Oh, so by now all the containers are running and the monitoring engine has been downloaded and then I will launch genghis agent and first I will download the mounting remoting agent from here.

K

Yes, agent, uh okay and set the set this environment variables. This specifies the location of the target open, telemetry protocol.

K

Then I will execute, execute the remoting agent, and here you need to use the remoting engine as a java agent. This uh use remoting engines as a java agent, and you need to also specify the logging property file and then agent is connected and rets explorer explores the telemetry data on grafana.

K

Okay. First, I will show you the agent logs from the loki data source.

K

Here you can filter the agent logs by service instance id and the merchant engine generate the service instance id for each agent automatically, but also you can set this value set this service instance id using an environment variables.

K

Now you can see the rows in graph on graphana, okay and each log. Entry has several attributes such as rogue reverse and the names of the class and the names or name of the class and method that issue the log and next.

K

And regarding the logs in in the error log, you can see the stack trace for the error. Okay, then next I will show the agent matrix from promises: data source you can filter the matrix by matrix type and service instance id or that other attributes, and yes, so far, I we correct only very general metrics like gb road, jvm, gvm memory, usage and etc.

K

Like like this, but in the future I want to add more jenkins, specific metrics, such as the number of the connection or the size of the working directory or etc.

K

Yes and I will introduce other features and deliverables.

K

First, you can control which metrics to correct uh in in this uh in this merging engine you this motion engine can correct many kinds of matrix, but you may want to correct only gvm matrix because you already correct the other kinds of metrics with another two, so we offer the feature to fill the matrix by their name using regular expression.

K

So you can correct only gvm, matrix by setting environment variable like this.

K

And I prepare two types of demos so that you can try them out very quickly. One one uses docker compose like the demo I showed before and and the other uses kubernetes docker compose demo is- is the easiest way to try out our monitoring engine. It set up all services, you need and it services if service is pre-configured.

K

So what you need to do is to clone a repository and change directory to the example directory and do docker compose app, and then you can export data on the graphene, and I also prepared the kubernetes plug-in integration demo and and in this demo the service instance id will be not a name, so you can find out target drugs and metrics more quickly and I'll. Show you a quick demo for this criminal system.

K

Okay, I will set up a mini cube cluster.

K

Gotta skip okay and create a namespace jenkins.

K

And set up pods and I will create a jenkins controller and arrow key and open geometric corrector and promises and graphene.

K

So then I will skip until all parts to be created.

K

Okay and then I will access the jenkins controller and set up kubernetes plugin air skip.

K

Yes, okay, I will set kubernetes url and test connection and it's successfully connected to the kubernetes cluster and next I will create a sample pipeline.

K

Yes name sample pipeline and I will use a custom agent image in this demo and I will copy the pipeline scripts.

K

Yes and I will use a custom image and the image and its docker file are published on github and this pipeline are waiting for it back. So this this this pipeline just print arrow and slips 300 seconds, and I will start this pipeline twice.

K

And here uh two agents are correct allocated and these agents uh emit their telemetry data. So let's see graphana.

K

Okay, I'll join a log and you can filter the log by service instance id and its value is equal to the agent jenkins node name. So you can use these strings to fill those rocks.

K

So it's much more easy to access to the rugs and you can also see the see there uh metrics from promises dead cells.

K

Well, it's like this.

K

Okay, I'll next I'll go to the next slide.

K

Okay, and in the end, I'll mention my backlog and the biggest backlog is the tracing feature. I tried two approaches in to.

K

I: try two approaches to trace remoting behavior one is to use engine resonance and duration interface and the other is to create extension points on demoting to trace the remoting more precisely, and I try to generate the variable spans and I try to define a body of response for monitoring and troubleshooting the remoting system into phase one, and I and, as you can see in this figure, I actually created a system to trace to to trace monitoring behavior as a proof of concept.

K

But, finally, I couldn't find out a good way to instrument remoting module to produce variable and have for tracing data for monitoring and travel for monitoring and travel shooting. So I decided not to include the tracing feature in the google smart called deliverable.

K

And I mentioned the other another other backlogs in the current implementation. We correct only very general materials like gpu road, but we can help jenkins admins more by adding more jenkins specific metrics.

K

For example, the count of reconnection or the average offline time in a day may have junkies admins to check the connectivity, and I conducted a user survey in phase one, and I found that connectivity is one of the main factors for high availability agents. So so this is important and users should be able to configure the open, telemetry service name and service namespace and remoting our resource attributes.

K

So having more configuration, having more configuration option is already so the background backlog of backlog of this project.

K

Yes, uh this is all from my presentation and uh google sum up called in jenkins is a great experience for me and thank you so much mentors and anyone involved to organize this google search called. Thank you very much.

A

Thank you for this presentation. Nike hero. Are there any questions or comments.

C

I would like to just uh say thank you. Thank you for the contributions, because yeah it's a great project which is super available to the jenkins ecosystem, and you can see that there is so many projects happening around the observability space and the agent monitoring has been always a big issue for jenkins end users.

C

So, currently, with this update, we will be able to provide better diagnostics for users and I'm looking forward to adopting in the in sea agency as well, because today we would definitely benefit from some advanced monitoring features.

C

So thanks so much thanks a lot.

K

And yeah thanks, I'm.

C

Super happy about the project results and hopefully we will be able to continue with other open telemetry types so basically to clean up this backlog, because there is a lot of opportunities.

C

Maybe it's a subject for either another mentorship program or some, maybe a google summer of code next year, the person I would rather prefer to work on it earlier. Let's see. Thank you so much.

C

A

All right, um can you please, uh I think I can override your share so.

I

I'll stop your sharing. Thank you.

A

Okay, thanks for those uh the presentation and those comments, is there any other comments or questions.

J

I had power cut, so I have to drop off that's why? So if there are any questions so that the audience will take to us, I am happy.

E

J

Answer them now so.

A

Yes, so are there any questions for regarding.

J

Security validator.

C

For me, maybe one of the question questions would be about classic jenkins, helm charts. So have you discussed together with mentors whether some bits of this project could be all supplied to there or is it solely specific to the jinx kubernetes separator at the moment.

C

Okay, sorry, in addition for the jenkins to the jinx kubernetes, separator the results uh classic jenkins hand, charts and also there is a lot of security related questions today in terms of management and configuration, including yaml files. So I wonder whether the results of your projects could be potentially applied to there too.

C

What do you think.

A

Looks like we have a connectivity issues or leg with a pool kit. I he dropped off the call.

C

And maybe elba will ask in the chat and by the way all projects have chats. So you can just ask the is needed.

A

Oh he's back, you want to try to answer that bulky. If you heard the question.

J

Like the network is quite unstable, so that's why yeah so? uh Can you hear me now? Yes, hello, yeah yeah, so, uh regarding your question uh like what I have understood is like you are saying that the helm charts like we can uh use the charts to install the operator and uh we can uh like apply those results right. So uh the.

C

Hello! uh Yes, though, it's.

E

C

About using hound charge for the operator installation, this part is clear: it's rather about using the same validators for jenkins being installed with hound chart, but without operator, because the results are official junk sound chart which is not based on operator. uh It's standalone.

A

All right so may.

C

A

uh You can continue.

A

Yes, okay, so thank you for uh for for this, for, for for the time and uh for answering questions, they could continue answering questions in the chat. I believe that will be easier.

A

Okay, let's move on to the conclusion.

A

All right, let's move on to uh concluding the presentations today. So last couple of slides.

A

A

Just want to thank everyone again.

A

We have a feedback form that I invite everyone to visit and give us feedback regarding the summer of code program in this presentation, and actually this is the end, so we'll turn off the recording and and and then everybody can ask more questions, questions in a more open channel and speak freely to each other, all right and it's actually the last slide. So thanks everyone. Let me stop the recording.