keptn Community, 19 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Community & Developer Meeting - APAC/EMEA - Jan 19, 2022

Description

On Jan 19 we had the inaugural APAC-friendly community meeting. We discussed the 0.12.0 release, Keptn representation at FOSDEM on Feb 05-06, GitOps for Keptn (KEP-65), Keptn operator, RBAC Support status (KEP-60), Google Summer of Code, and growing the APAC community.

Meeting notes: https://docs.google.com/document/d/1y7a6uaN8fwFJ7IRnvtxSfgz-OGFq6u7bKN6F7NDxKPg/edit

Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews

A

Hello uh welcome to the captain community meeting. Today we have the first ever edition of the a park meeting, uh so the intention was to have a meeting that would be suitable for asian and pacific region because we have many contributors and mentors to their users, but before that, all the meetings used to happen at 4pm utc and it's not a comfortable time. So we ran a poll and agreed that we were trying meeting at this time and it's 9 a.m utc.

A

So europe can join as well and the most of captain contributors are based in europe, so let's see and how it goes, and thanks a lot to adam brett and pawan for joining. So we have uh some people who have never joined the meetings before and it's already a great start.

A

So uh yeah I'll share my screen just to show the agenda.

A

So the topics we have in our agenda for today, um so I would like to just have quick introductions before we start, then we can discuss the news, uh the recent ones. um Then we can discuss specifics about captain in the apac region. So what we can do what you would like to see happening in terms of meetings and whatever then there was proposal from your house to cap 65 to the discussion.

A

I also want to discuss cap 60 briefly to see what we can do about that, and then we have a google summer of code up coming. So again, it's good to discuss the ideas. So this is the items we have on the agenda. Would you like to add something?

A

It else good to me and yes, then, the next uh topic is just introductions. uh So usually we do it at.

A

Community meetings so for people who just join, if you would like to do a quick intro, it would be nice so brett. Would you like to start.

B

Yeah um my name's brad, I'm originally from new zealand but living in australia. Now I've worked with adam before in the past, with an old company that I work for and, and we just actually got a contract for donald trucks today as well, which is quite exciting. We've been trying to get it for quite a while, so I'll be um getting really active and kept in the next week on.

A

Thank you so adam. Would you like to introduce yourself.

C

Yeah adam as brad says: we've we've worked together in the past. uh Merry christmas. By the way I haven't spoken to you since then um yeah good. I'm just really happy that this isn't a suitable time for uh aipac. It's uh yeah, looking looking forward to more adoption of captain in apac, so this is good. A good start.

A

How do you use captain.

A

Sorry, how do you use captain adam.

C

Oh um yeah, so mainly um obviously, I work for dinotrace mainly by work, but also um I've been putting together a service catalog, so I'm part of the services team, I'm using captain as a middleware layer to orchestrate some workflows to build demo apps to build kind of a tool, agnostic delivery chain for our services team.

C

So that's my that's. My next project.

A

D

I want to learn captain so.

D

Recently and I was able to get a hands-on.

D

Experience on that, so I want to learn more about it.

A

So yeah indian produced himself in the chat, so I'll probably do a quick introduction. My name is alek minaj. If I joined the community in july here, I currently work on various open source programs and I've been following captain since 2009, and I think it's a great project for various kinds of orchestration and automation. So my intention is to participate in community building and leveraging any opportunities we have, including running epac meetings and growing the epoch community, because from contributor and user perspective it's one of the beaches biggest and fastest regions.

A

So happy to do that and happy to see this meeting happening.

A

E

Then I go next uh one sec.

E

Can you hear me now: okay, uh hi, I'm johannes, I'm with you guys, captain project uh since day, one or day zero uh yeah, I'm working with the project for three years now I I'm on the journey of how everything started and how we are as of today and right now, I'm in the role of the product manager, taking a look or taking a picture of what we are currently planning to develop.

E

What's in progress with on the agenda um yeah, this is what I'm responsible for, so that we have all the features and the new enhancements aligned and to get out uh cool progress.

E

All right, yeah, then uh thomas, please.

F

Yes, so hello, my name is thomas, I'm a principal engineer at batteries and driving the internal adoption of cabinet atlanta trees, I'm also kind of a captain contributor. So some of you might know my efforts regarding the operator staff for captain or, let's say my trials um and yes, that's my role. So I give back to.

A

Thomas is also attacked in attack up delivery in the cncf, uh the attack, which is actually a sponsor for captain incubation application.

A

So thanks a lot thomas for this uh work and yeah, I guess that's it for his introduction, so nice to see everyone here again. Let's see how this meetings go. If they stick, I would be happy to host them on a regular basis. uh Maybe every two weeks we could discuss whether we would move some of the community meetings so for the. For today I decided to just follow the forum.

A

What we have for thursday meeting now more or less um and yeah, then we can revise the format to see how we actually could make it more efficient for participants.

A

um So, regarding recent news, we have uh in the capital community. Just uh yesterday we had a official 0.12 release, so key highlights, then johannes, would you like to speak about it? Let.

E

Me take that um yeah three key highlights of the 0.12 release. The first one is that the team is working on a so-called resource service. This will be a replacement of the current configuration service, because the current configuration service here is using an internal git repository and due to this reason we cannot scale this gentleman and um yeah.

E

The plan is now to have a new service that just relies on the the upstream repo will become mandatory, that you have an amp strip configured then, but then we also can scale uh this service and have a replica set bigger than one, and this is then also allowing us that captain itself can be scaled up and down depending on the demand.

E

Second feature is uh yeah improvements in the ui, uh where it's now easier for someone to configure a web book, because now we have here a data picker that allows you to select to select data from the event and then add it to the custom payload that you would send to your web book just some ux improvements and make it easier for configuring your web hook and last but not least, yeah zero down. Time is also another big item on zero downtime upgrades.

E

It's also a bigger item on our agenda right now, as we would like to aim for upgrading a captain installation while it's running so that there you don't have to shut it down for one minute or two, uh but you can um yeah progress with all your sequences that you have currently running and in the back uh the upgrade is happening and for achieving that goal.

E

um Team uh implemented, graceful shutdowns in all components, in other words their components when they get a sick term command, then they complete the current task, shut down and hand over to the other to the updated version, and this is now done in a in a nicely manner. So that upgrades are possible.

A

So they're also api for services so to implement graceful shutdown of a service, let's say like gmeter or whatever, which may also have run time.

E

uh Oh, like you're, asking if there's an api or.

A

uh Yes, oh no, zero downtime upgrade supported for services in general.

E

uh It's just for captain core, but not for uh in uh for for um services that are built by someone else. Therefore, we are not taking care of it's really just for capping core components.

A

Understood so maybe I'll uh submit a lob ticket but yeah it's a great addition. So thanks a lot to the team for that and yeah there were a lot of other changes bug fixes. So it's definitely a good time to upgrade.

A

Thanks a lot to the team um anything else regarding 0 to 12 upgrade.

E

Nothing from my end, uh the captain upgrade command works as expected. I just did it yesterday, you type in captain upgraded, upgraded, um no breaking change, no things to mention.

A

Great thank you came under a few caps implemented, including uh uh the cap uh for full-based access controller. I would like to discuss later, but.

E

Also right just just to make it clear, not the caps are not fully implemented, but parts of them are taken and yeah. Part of this release like, for example, cab 48, which is the bigger topic about high availability and zero downtime upgrades, and here, as I said, portions of that are implemented and part of the crease.

A

Understood so thank you and release um yeah, another news, so we had uh talk confirmations for fosdom. They have arrived quite late this month, so first of all, thomas will be talking about unifying infrastructure and application delivery with captain the cincy dev rom.

A

So thomas, would you like to summarize this talk.

F

So um often as operations or application develop deployment guys, we have the problem that we depend on infrastructure for the deployment of our application, such as, let's, let's call them um ingress classes or storage classes in kibonitas, and they have to deploy by the infrastructure team and in the most most of the time- and sometimes you do exactly this.

F

This changes in the first stage in a development stage and after some time you want to promote this to the next stage and at some point in some cases, this infrastructure might not be there, and this um is the thing I will deal with in the in this talk so mainly deploying infrastructure and application hand in hand and also find out how you can deal with exactly these deltas and how you can find out if the infrastructure you want is already there.

F

um Yes- and this will be kind of an integrated captain and cross plane um approach.

A

Okay, thank you. I also got a confirmation for my captain application about slos and sli observability with parameters and captain, so it will also happen uh on sunday uh a bit earlier, so maybe more suitable for a park region. uh I just got confirmation about this. Talk this night, so yeah there is still no link, but the talk will be there and yeah. Also I'm giving a keynote about the revolution of open source ci cd, and it will be also including captain.

A

So yeah, if you want to participate in fosdem this year, it's online, so everyone is welcome to participate. uh Well, it's one of the biggest open source events in europe and currently it's accessible to all time zones. So yeah welcome.

A

Anything else regarding foster.

A

Do we have any other news you would like to share.

A

And it says that captain on k3s is also updated for captain 12.

A

Any other news we missed.

E

No, um I'm not aware of kenyatta.

A

Okay, thank you and yeah. So the next item for us is actually captain community in their park region. So it's uh maybe a question to brett, adam and pawan. What you would like to see or what is your current experience so regarding communications, community channels, etc, so, basically any feedback. You would like to provide about how it currently works for you. It would be appreciated.

B

I think having this meeting is a really great start, and just just raising awareness of open source in general and cloud native in the region is a challenge. We're trying to solve um some end user stories would be really cool to see as well to show the business value of what it brings so just yeah. I think we're making a good start today in that drive for adoption here.

A

Nice um and for slack channels for user groups, uh how does it work for you now, or would you like to see some of these events in their packed amazon too?.

B

um What do you? What do you think? What are your thoughts adam? um I think it works pretty well with slack asynchronously talking, you know chatting to people and um seeing updates you know we're all busy people as well. So I, I think that's been really good.

C

Yeah, absolutely slack slack works for me, um but of course the more we can do, um the better so yeah. That's why I was so happy with with this meeting being put in um it's it's like anything. We start we start and then we build from there. So yeah all right.

A

So for user group meeting I think we can host it also in the same time frame. Maybe we could try use one of the next meetings, so if you know about any big user of captain uh in uh about two gym, maybe you are my or your bread. If you would like to present your experiences as a separate meeting, I think it would be also great so.

A

If you're interested, we can just follow up and get it scheduled, we don't have to schedule even for particular time slot, because if you have people to host it, I'm happy to host it. Maybe andy would be available and we can just choose a time that would be suitable for everyone sounds good.

A

So for these meetings I was thinking about doing them, maybe every two weeks or so so doing them on a weekly basis is likely too time consuming for everyone. Maybe we could even consider moving one thursday meeting to this time slot, because again, the most of captain developers are based in europe. This time is generally suitable for them.

A

So maybe we could just uh move one meeting call together so that we don't increase the meeting load in the community but yeah if you're fine with the time slot. We could tentatively schedule another meeting, maybe in two weeks at the same time and when, if it sticks, you keep doing them.

B

Yeah, it sounds good yeah in my experiencing other um like, for example, the tag security um they move to a big time zone as well, and it's good to start really slow and just have you know, really meetings, not all the time, because it's hard for to get people coming all the time and sometimes people lose interest. If there's too many, so I think that's a good case.

A

One of the questions is topics deduplication because yeah. When we have two different community meetings, uh we should assume that uh even more content would be asynchronous, so what it means uh making less decisions at meetings, more decisions. Let's say in issues on discussions uh but yeah for these meetings. It will become essential to track to have good meeting nodes so that everyone can take a look and see I'm making meeting notes for this meeting and also, of course, posting recordings. But we leverage the baby platform for that.

A

So I think it will be important and also for some topics like cap 65 we have below. So it will be. It's a good question how we organize that between two meetings, but for now. I think that if we assume that this meeting, mostly for discussions sharing feedback, but the decisions would happen, uh synchronously in the cap pull request, I think that it would be defined for now.

A

So, johannes, are you fine with that, because we already discussed some decision-making problems we have with the current.

B

E

Yeah definitely, I think uh discussions should happen on the issues and the items itself and not that much in the in the meetings and the meeting should then be used to kind of broadcast the decisions and to make everyone aware what um has been discussed and agreed on. uh Definitely just one question back. um Does this then now mean that we take the community meeting on a thursday evening every second week and move it to.

A

So my suggestion is that um we definitely keep the tomorrow's meeting and at the tomorrow's meeting we can discuss how we approach it. Okay, um because yeah then we will have people who participate that meeting and then we can agree, what's their preference yep, so I'll go ahead and agenda, but yeah. I think that this is how we approach it yeah for the time being, I'm ready to host all meetings so without changes to thursday. But if people want to change right away, we can do it as well.

A

A

So I'm pitching up on limited notes, so anything else about the park region. You know uh question uh to you pawan. uh So what would you be interested to see at these meetings? uh What would be beneficial for you, as you just started with captain.

F

A

Okay, I can follow up later, so I think um then we can press it to the next topic and it's cap 65. So thomas, would you like to take it over and drive the discussion.

F

Okay, so as I introduced before in the in the introductory round, um I'm playing around with several keytops approaches in the last few uh in the last year. To be honest, um so I think brad we we talked about it.

F

I think, half a year ago, um in the mean in the meanwhile, we found out that this might not be enough keytops for captain, and it might be a good good idea to have all of the all of the captain configuration things in custom resources in kubernetes, which also makes the whole keytops approach by itself easier, because we only have to take the custom. uh The manifests for the custom resources from a deep repository applied among the community, discussed and captained, and the controller who, with the custom resources, does the race this.

F

So uh we created a prototype. um You know on an innovation day and resulting from this we created this um captain enhancement proposal.

F

So, um as orlick shows now, uh oleg shows the uh repository for the for the keytops operator. Now um and currently this resides in the branch in the keytops operator repository.

F

So this is in a new githubs operator branch. um There is kind of a documentation in there. um I think I also created a chart for that, and it should be so.

F

The the captain operator itself should be running if you install the rail job, but at the moment the kit approach itself does not work, um because the kit operator by itself is not runnable at the moment, and this is the thing I will do in the next week, so um there will also be a talk regarding the captain, github's approach and githubs in general, in our devops night in kiev, and for that I will. uh I plan also to to show the current approach of doing uh captain keeps operating.

A

You could put a link to the website key if it would be great.

A

So currently still doesn't fully work right.

F

um It worked uh the the management of captain resources works, so you can create services. You can create projects, it could also create stages, but at the moment you cannot deliver artifacts with that.

F

And this is the thing which which I'm dealing with at the moment.

A

So you cannot manage projects.

F

You can you can manage project, you can manage almost everything, but you can not uh add artifacts to captain, because this is part of the github's operator in this case and you can not deliver artifacts in so you cannot upload artifacts to the captain upstream reaper. Let's call it this way. You could also trigger trigger sequences.

E

And thomas this brings me to a question I mean uh we discussed it offline, but I think it should also be mentioned here in in this meeting that would it make sense to break the cap 65 into two components.

E

The one component dealing with or kind of implementing the captain operator for doing all the management of entities, projects, stages and so on, and the other components are focused on the githubs approach.

E

So to have also that discussions uh split apart.

F

I think we could we could split the two caps, but the key tops the the key tops. Part of the story is highly dependent on the on the captain operator. Of course,.

E

Of course, yeah, uh the captain operator itself um is kind of uh the foundation and the first step, and then the github's operator builds on that. Yes, so this would.

F

A

I guess it's rather a matter of documentation, because if you have two separate caps, they could be documented independently. I'm not sure whether they will be actually shipped independently.

A

But if it's helpful for users, we could split it, and I don't have a strong opinion here.

A

uh Do you see use cases for a captain operator without uh full github's uh hearts? For now? I'm sorry! So if we split a captain operator um to a separate cab, does it provide uh much value as a standalone uh deliverable.

F

Yes, I think so because you could also um configure captain via custom resources without the support.

A

Mm-Hmm yeah sure.

E

In other words, we could get rid of all the imperative commands, but have a more declarative way of declaring what I want to have and not telling captain to create certain things.

F

What we have to what we have to think about what is not included in the prototype at the moment are that we might have some more custom resources as as as specified in the in the cap currently, because we might also have custom resource definitions, for is a lioness low definitions.

F

But yes, this this: these are all things we have to think about and talk about at some point in time, uh do you mean segmented metrics by crds or the requirements, um the configuration of the configurations of them, because.

D

F

There are, they are file in the upstream repository, but they are also armored and they also have some kind of a schema and therefore they could also be implemented. Customer those definitions, and this would would also make the the artifact uh the artifact part a bit easier, because we won't, we would not have to to deal with with slide definitions from the uh you know, in a different way than the configurations.

F

So it would also make its way on the upstream, but it would make its way in the upstream on the on the k on the captain operator side and not on the keytops operator side.

A

So in this case, I would rather agree with johanna's proposal that maybe splitting the cap would be nice, but again it can be potentially kept in the same pull request. I'm not sure. What's the policy for that, because yeah I'm still getting used to the format of captain enhancement proposals when they stay input, requests for long time until they're ready to be shipped.

A

So how would you see it.

E

I would see the way that we just opened two new ones and close this draft and and just to a reference back that reference to the origin but having it then split it into two separate ones.

A

Thomas, what do you think.

F

Yes, for me, it's perfectly fine, so we could. We could make the cap 65 a bit shorter and.

F

um And and uh move the keytops part out of this, this was that would be the first, the first approach. While we closed the cab 65 and created in 67, whatever number we have at the moment and yeah numbers.

B

Are not principle.

F

In this part, you want to see this.

A

So if maintained.

F

If we put out the keytops part and create a new one for that.

A

I agree with this approach because we already announced cap 65 in social media as guitars, so for me it would be nice if we could skip if we could keep this pull request as a baseline for.

A

Githubs so johannes, does it work for you yeah.

E

Yeah definitely uh and a good hint that it has already been referenced in social media and we should keep it but uh to keep the discussion focused and also to have smaller pieces to work on. um I would go for taking out the the captain operator.

A

Yeah, we also have a bunch of references, for example,.

A

We would want to discuss later how we organize caps, because yeah this using a pull request, has obvious downside that if you want to recreate the pull request, then everything goes south.

A

uh Maybe it's better to have issue as a foundation and then just do requests and another opportunity, for that would be to actually merge the changes and do them incrementally.

A

So, for example, how we do it in jenkins, sorry for referencing jenkins too often at these paintings, uh but the engineers we have jabs, uh but these jabs we actually have them uh merged. So there are, there is a bunch of jabs and you can see different statuses, so some jobs actually ancient uh not merged, but have actually appeared that we submit pull requests against the repository and we work on these jobs. So when you go to the documentation, you can see actual documentation for every branch.

A

You can create a pull request against that and we just keep the status separately so that when the job is ready to be accepted, we do that. But if not it's just a quote in the repository which you can update, which you can still reference, and hence there is no this many pending pull requests, so maybe something we could discuss later, how we actually organize it because for me it seemed to be rather an impediment for users that it's only in the pull request, but I'm not 100 sure about that.

E

I'm definitely open for improvement. uh We just took a a look at how open telemetry is doing that and then uh stole their approach and applied it to captain, but if there are better ways of handling enhancement proposals, I'm happy. Thank you.

A

So again, it's something! Maybe we could ask captain users about, uh because what works best for you in terms of search in terms of absorbability, of and transparency of these caps.

A

What's the resulting coming comment from india about slo slices, slos, crds, so uh yeah, johannes thomas? What do.

F

You think um I think it's it's a different. It's a different thing for the helm class, because the helm, charts should, uh to be honest, should not be in the captain upstream repo because they are the shooters either in the helm repository.

F

So therefore, therefore, I think we don't have to deal with them only with their configuration um paste files are different thing. That's that's true, but there's the last slos um are, in my opinion, a kind of a kind of invention of captain, so at least the configuration format and therefore, therefore they belong, and also to the operator.

E

Thomas, I don't see it as the captain core component slis or slos. They are coming in from integrations, whether it's lighter service or the promiso service, which are defining their own format of how they want to have configuration. But I don't see it as a core element.

F

Okay, so the slice is aligned. This low configurations are different ones for different um services behind them.

E

Right and then we um because we can also think of taking a look or we can take a look at the lighthouse service, which is actually part of captain core, as we have slos built in. But the lighter service just behaves like an any other integration.

B

E

B

E

A candidate to move out of the captain core repo, and then it has its own configuration its own slo configuration.

F

Okay, then, I think I agree a bit with andy so, as this estimate might be different.

A

We will add, notes later get something to just uh submit to the github issues, meeting notes, uh but yeah. Thanks for the feedback and discussion.

A

Kim well, I think that it's definitely a nice conversation on the project um and yeah. If you have any feedback, uh please just comment on the pull request and we can get it added incrementally.

A

uh One topic I have to this meeting is whether this proposal is actually ready to be added on the roadmap and whether it's feasible to edit on the roadmap, because for me it seems like a major improvement and in terms of captain operations, and I think it should be on the roadmap, but it would be nice to get other opinions.

E

Just might see it there's a very, very uh strong improvement of of captain, but to put it on the road map, I would like to have it split into smaller pieces, smaller chunks and also um already refined and um described in a way that we know what we want to do, but once this is um done once we have agreed on on pieces, we would like to head to captain denim open to put it on the roadmap.

A

So we don't have a specific uh process for adding items to the roadmap. I would assume that it's basically the same as before, further items having two captain containers sponsors but yeah. It's also something we could discuss later but yeah. If thomas agrees with what johannes proposed, I think we have a plan and yeah. Basically, it would go to the refinement phase and uh yeah. Then, uh regarding planning, I think it's a wide open topic when it gets delivered.

A

I think that it would be a great start if you have it.

A

A

And uh speaking of that, uh so there was brief discussion uh whether it could be done as a lfx, mentorship or gsoc project. So thomas, what do you think about it?.

F

So I I think that it would be a nice project for one who wants to get started with captain, because uh when you, when you create or when you deal with all of these custom resources- and you um define the logic harvest, how does effective captain?

F

You know how captain works and also this might be a good, a good first task to get a good first project to get into kubernetes operators, because there is a lot of operator logic inside of there of this and therefore yes, I think it would be a good idea for lfx projects.

A

And so and yeah the question for mentorship projects is about timeline and about uh the probability of it being delivered, because when you have a mentorship project, usually uh one who works on it is less experienced. There is no guarantee that it would be delivered and would be delivered within a time frame, but at the same time it's a good opportunity to experiment and to see how it goes.

A

So. I think that at least having kita's project idea would be useful for us.

F

Fred, how you, how would you think about this? I.

B

Was just going to say that I would be interested in that yeah? I was just going to mention that.

B

Yeah, that would be really interesting for me.

A

Yeah, so speaking of that, maybe we could quickly discuss g-shock and lfx mentorship, then, since we're on the topic, um so google number of code applications open in a few weeks, and I had a proposal that we would participate in gsoc this year.

A

So basically, I already started assembling uh possible projects and uh based on feedback from thomas. I would also uh basic githubs for captain here.

A

And again, you would still need to refine the project idea, but I think that it would be nice to have it here.

A

So, uh regarding timeline, if you do google summer of code this year again the scope changes compared to previous years, but still it will happen during the summer and there will be two options: having a full-fledged project, something around 300 hours and a partial project around 140 hours, it's of coding, time dedicated by the student during the summer. So it's quite considerable amount of time and the project itself starts now so organizations already prepare their project ideas. They already prepare their charter.

A

For this event, they look for potential mentors and if our application succeeds, then we would be able to have a few projects. The number is to be determined sometime in april by google uh after the conversation, but I think for us it would be nice to participate.

A

I've been participating in google summer, of course, since 2016 as mentor and orca mean- and I find that this program really nice not only for finding new contributors but also for community bonding inside the project, because yeah doing science, mentorship programs is generally fun and it helps to get more engagement from mentors and maintainers of ecosystem companies like integration services to get them participating in core activities and maybe getting involved in community-wide topic.

A

So I think that it would be nice for us to participate and if anyone is interested in any particular project and would be willing to consider mentorship, it would be really nice.

A

So my question to everyone on this call whether you would be interested in something specific.

A

So one of usually for google summer, of course, the most of students come from uh india, sri lanka or china of pakistan. So everything is in the apac region. So heaven planters in this time zone would be really nice.

A

Would anyone be potentially open.

B

What's what sort of mentoring would you be looking at.

A

uh Yeah, so basically what it means: firstly, providing students with insights to technical area and getting them involved in the community, so getting them introduced to right contacts and, after that also providing technical expertise and advice during the implementation, so sometimes pull request, reviews, sometimes q, a and usually it amounts to something like several hours per week of mentors time.

A

So it's quite a time commitment, uh but at the same time it might be really interesting, especially if you like mentorship, because usually in google summer, of course you have top notch students who are very committed uh to the program and yeah. For me, it has been always a great experience in jsoc, so some projects may fail, but the overall success rate is quite high and if you're good at selecting applications, then yeah, it might be a really nice experience for you.

A

At the same time, it's still a time commitment. So in jenkins, we usually recommend that there are two or three mentors working on a single project. So there is some redundancy because well obviously, it's summertime not for australia, but yeah many mentors take vacations, especially in august in europe.

A

So having some redundancy for mentors also reduces uh the level of commitment for them, and it gives them an opportunity to take a break which is essential for everyone.

A

So I plan to document the charter for summer, of course, and other initiatives in the coming week and then bring up this topic again. So in general, you can find take a look at some information on jenkins website because we invested a lot in documentation and guidelines, including the level of commitment, etc.

A

So if you are interested, maybe taking a look at these guidelines, uh at least it would be my ballpark estimation when it comes to captain, because I was leading the jenkins g-shock since 2016 so yeah. These guideline lines are basically based on our experiences and we try to maintain them in actual state.

A

So if someone is potentially interested, I'm happy to work on that and come up with the proposal.

A

So then I'll probably do that again. There is no need to decide anything today or even in february. It's iterative program says, but for us uh one of the key decision points in february would be whether we apply or not, because if we apply then well, we still can get the role later, but it puts some commitment for us as an organization, and if we accept it, we will be guaranteed to get at least one project slot.

A

It might be more might be less but less, but yeah one projects what we are going to have. If we have a student application for that.

A

So any questions comments.

A

Sorry, if we confused everyone with this program,.

A

It's quite a big topic on its own.

A

So then, just moving forward, so I put a question about cap16. So maybe it's something uh johannes. If you could summarize the current need and the expectations for that, it would be awesome.

E

Okey doke, um therefore, uh thanks for screen sharing, can you go to the cap? Please yep, because what currently the progress on that topic, I progress is that the team is currently with the open id connect flow into the bridge and cli. uh I have here a screenshot a little bit down another screenshot. It's kind of.

C

E

Here, visualization of um yeah implementing the oi dc flow in cli bridge, as well as the distributor and um first pull requests are currently coming in. They are open and and ready for a review and will then also be part of 13, and this then allows you that you connect uh your captain installation to an open id provider like, for example, microsoft has one. There is key clock out there or um yeah google and all the other, all the big names.

E

They have open id up providers, and then you can uh connect your capped installation with those providers.

E

Currently, there's also an open pull request on the documentation. That explains how you do that with a microsoft account it's currently under review and yeah some might be updated and it would be really cool to see uh also an implementation with an open source uh provider on that end and a key clock, for example, would be a candidate so that I, as an open source user.

E

I use have my key clock, identity and access management system up and running and would like to connect this one with a captain, installation and technically the foundation is there, but now a tutorial or how to guide would be nice to also have something for their for their open source world.

A

Yeah, it totally supports uh having key clock, uh because key clock is open source project and it's already an aggregator. So once you have a kick lock, you can easily integrate with github google et cetera. So by doing this integration, you actually provide a layer for all other integrations if needed.

E

Correct justify the dynadris team is currently integrating uh captain insulation with dynadrif dandries um frame books, but it would be cool to see the same on the open source space.

C

Once this is done, I'll be more than happy to um walk it through and and document how uh um there's nothing worse than wanting something to work and the documentation isn't good enough. So I'm a big fan of good documentation.

E

A

uh Yeah, if I understand correctly, it covers only authentication right now, so it doesn't cover authorization.

E

Right now, it's authentication authorization is the next piece.

A

uh And there was a question uh in the stock, but uh there is a plan uh to use open authorization as engine. So basically oauth2 has a layer for that. Has it already been discussed.

E

No, not I'm aware of.

A

But yeah it's definitely something we would need to cover because, as for open id, having copper and authorization is really useful, because then we can connect. For example, github teams, whatever ldap.

A

And there are standard players for that, so it could help but authorization. One of the biggest problem is to actually have this permission layer in captain, because I guess it's going to be a huge change. So do you have approximate timeline for that.

E

No, uh no, I don't have a timeline um for that right now.

A

Is it on the scope for cap 60, or do you consider also splitting it out to another cap.

E

Capsid 60 has the goal of providing an a default admin default reader and write role, and uh for going further into more find grand um user permissions and configuration. I think it will be a follow-up. Okay.

A

Yeah, let's click. I think these roles would be managed uh through internal database so that there would be no external uh authorization engine.

A

A

I think it would be already a great start because we needed so many stories that gets brought up every week, so if it gets delivered, I think that it would be huge for us in terms of growing captain adoption.

A

So yeah we are running out of time. um So yeah, maybe one question before we wrap up. Is this meeting format useful for you and should we keep going kazi so should we do some adjustments.

B

For me, it's really good yeah. I think adam will probably save the time.

A

Let's try to keep doing that. Maybe limiting the next meetings uh to 45 minutes as target with the opportunity to overrun a bid.

A

I think thanks a lot for everyone who participated and provided feedback and yeah adam right, if you have any topics for it for the next meeting, if you have any uh challenges with captain, you would like to discuss or just to show, if you want to share your vision for captain, I think it would be a great opportunity for us for the next meeting sure yeah that sounds good.

A

Okay, yeah thanks everyone. uh Thank you. You introduced them.

B

Yeah sounds good. Thank you very much.

E