keptn Community, 13 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Community Meeting - August 13th, 2020

Description

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

August 13, 2020
Keptn will have a virtual booth at KubeCon 2020 - Aug. 17. - 20.
Keptn community guidelines: https://github.com/keptn/community/blob/master/COMMUNITY_MEMBERSHIP.md
CNCF Slack Channel: Join here
Good first issues: https://goodfirstissue.dev/ or start here
Keptn mailing list / google group: https://groups.google.com/forum/#!forum/keptn
Noteworthy Issues & PRs (Review)
For each PR, please tell us if you updated the docs, or in case it was not necessary please say so.
Ermin:
https://github.com/keptn/keptn/pull/2206
Provide better indication and workflow for artifacts waiting for approval
Andreas:
Allow to set prefix in path: https://github.com/keptn/keptn/issues/2124
Florian:
Fixed error in GET Event endpoint: https://github.com/keptn/keptn/issues/1655
Shipyard Controller: Managing .started and .finished events:
https://github.com/keptn/keptn/issues/2159
HTTP Polling for distributor:
https://github.com/keptn/keptn/pull/2203
Gabriel:
keptn get event: Provide a implementation of this command that takes any event type: https://github.com/keptn/keptn/pull/2184
Johannes:
Formulate spec for Shipyard 0.2.0 and implement a dedicated type in the go-utils: https://github.com/keptn/keptn/issues/2106 (https://github.com/keptn/go-utils/blob/master/pkg/lib/v0_2_0/shipyard.go)
Christian:
Allow configuration of external Prometheus deployment: https://github.com/keptn-contrib/prometheus-service/issues/53
Roadmap → KEP / SPEC / Issues
KEP 06: The next generation of Shipyard: https://github.com/keptn/enhancement-proposals/pull/6
Keptn CLI: keptn delete service xyz --project=abc
Work in progress:
https://github.com/keptn/keptn/projects/29
Backlog Refinement / Next Sprint:
https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Akeptn+user%3Akeptn-contrib+label%3A%22next-sprint%22
Planning Board: https://github.com/keptn/keptn/projects/29

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

A

Okay, hey everyone. Welcome uh to this uh captain community meeting today, it's august 13th uh we're just a couple of days away from uh our cube con and cloud native conference starting next week. uh It will be a virtual experience and if you happen to be at this cubecon and cloudnativecon make sure to also visit our captain booth. We have our own booth. It will be open each day from monday to thursday and yeah. We are happy to have discussions there.

A

uh If you don't have time for the cube con and cannot attend, then we also have our slack channel either in the cncf slack workspace or on slack.captain.spa, where you can also join us.

A

If you want to contribute to captain it's the same way as always, we have a list of good first issues that you can find here in our github or if you want to explore them on goodfirstissue.dev, please go ahead and do so and one last kind of announcement. If you want to get weekly updates directly into your inbox in your mail inbox, then please go ahead and join us in our captain mailing list.

A

It's on a google group and with this link you can join us and get weekly updates on the captain project directly to your inbox.

A

uh Since we have a couple of new folks uh joining, I would suggest um that we already discussed a little bit before the recording and uh we had some questions uh and we we know that we have some people joining around uh how to integrate with captain and also uh how to do uh auto remediation with captain.

A

um I think um so. I'm not sure how long the list for the noteworthy issues and prs will be um johannes. Do you have an overview? Should we first go through the list of noteworthy issues, npr's and then discuss a little bit around uh the capabilities of captain when it comes to tool integrations, like gabriel, has worked in asphalt tower, and then we have a couple of folks um interested in the capabilities of um auto remediation with captain. Then, probably after the noteworthy issues and prs, we can uh have a little bit of a discussion.

A

B

I would uh suggest going this way talking about the the things that happened this week and then uh do follow-up questions uh when there are some.

A

Perfect so then I will hand it over to airmen and, uh as johannes already suggested, uh please um put your questions or in the q a so we can have follow-up questions uh if anything uh comes to your mind already. That is also not related to uh the issues that will be presented here feel free to also post them here, uh and we will keep them for later. So we can address all the questions that you have, so I will stop my sharing and thank.

C

You very much um I'm going to present a poor request uh regarding uh assisted delivery.

C

So since uh 0.70 we have the assistant delivery and you can configure manual approval in your deployment pipeline and therefore we allowed to trigger the deployment from the bridge as well as from the cli, and we got here um a request to provide uh yeah um another option to yeah. Do the manual approval.

C

Currently you have been able to do this only from the environments tab and now the request was to allow the user to provide approval also in the services view.

C

So, while you are watching at the trace uh the traces here, uh you of course have uh or had the approval triggered event here, but not the option to approve this one and another one was yet just better indication since, in the services view we haven't focused on the manual approval use case, um yeah just a better indication of that events and of course I will do a live preview.

C

So here on my demo environment, I have the latest bridge uh deployed and in sockshop2 I have the cart service with yeah the configuration for production with manual approval, and you can see in the services step now. Also, this stage is highlighted if you have an approval triggered here that hasn't been approved. Yet this event now also shows additional information.

C

So you see the currently deployed artifact, which is 0 11 2, and you see the deployable artifact, which is 0 11 1, and you have also the score of the evaluation that was executed here in the staging environment with this artifact.

C

Also, in regard of this improvements, we have the same improvement also here in the environments tab before we just uh show the information uh of the last. uh If the last evaluation passed or uh um if there was some error now, you also have here the score, and you also see the detailed information uh regarding this evaluation. So you see the evaluation time frame uh that that was a performance test in stitching.

C

You would see the score actually. I have here bad uh example data, but yeah. You would see the score here. You would see the evaluation result which could be pass warning or error and no evolution in this case.

C

I have here the message because yeah I have nothing configured, but you would see all the details here as well, and you can approve that from this view here or as I already shown have shown, you can also improve it, approve it from the services tab here and just watch how it is going to be deployed to production.

C

Yeah, that's from my side. If there are no questions, I'm handing over to andreas.

D

Cool. Thank you. Yemen really, nice feature.

D

So I've worked on an issue for our installer and this installer now allows to configure prefix in the path and few seconds ago, a few minutes ago, I used our help chart in order to install captain. So what I did is in hand, inc and helm upgrade with the option install and um as repository where I take the handshake from I used our latest image, and here you can now configure the uh prefix path, so a prefix for the captain path and, in my case I've chosen captain community meeting, which now annoys me.

D

Oh that's good now, which now allows me to access the captain bridge on the captain community minus meeting, slash bridge- and this is also true for the api of course, and by this you get more flexibilities how you can install captain using this set command here.

D

Okay, that's from my side, any questions.

B

And that's: what's actually the need of having this it's. I think it's also called root context.

D

Yeah all right, um it's called root context too, and the need for this is, for example, if you have an engine x which uh which is uh here for for handling the responses and the request for two applications, you could probably have um clashes if you just go, if you have your ads, which start with api or with bridge.

D

So um this now allows you to customize this prefix here.

B

Makes also a sense, cool.

D

Next one is me.

E

All right, uh can you see my screen.

A

E

Okay, perfect all right today, I have three pull requests. I wanted to show you so the first one is actually quite simple but important. Nonetheless, so andy gardner brought up this issue, which was uh the following. So when you queried the api or the event endpoint of the api for an event and no event has been found, um the api returned to 500 error, which obviously shouldn't be the case, so that was changed to return. 404 and yeah.

E

First uh imre did already some work and actually did most of the work, but there was just uh some minor change required in the go utils in order to return the correct status code that has been done and now this get event endpoint should work as intended.

E

Are there any questions about that right? If not, I will continue with a more uh interesting one, so to speak, uh so this one is a further extension of the shipyard controller.

E

So if you recall the last meeting, I already presented how the shipyard controller manages all the open frigate events for actions that should be executed by executors and obviously we also need to react to the started and the finished events that come back from those services and the way it works is uh the following. So when a started event is received by one of the executing services, the shipyard controller will check if there is a matching triggered event for that action.

E

With the with the triggered id of the started event, and if a matching event has been found, then obviously it received a valid uh started event. Then it will persist that event in a mongodb collection. Similarly, like it does with the triggered events and then another type of events that can be received by the service are the finished events and when the shipyard controller receives a finished event, it will then again check if there is a matching triggered event and then it will fetch all the existing started.

E

Events so for each uh executor, service that takes care of uh executing the related task will send out the start event and keep it in the collection and when a finished event is received, it will retrieve all the started events and check if, if it already received a finished event for each of those started, events that are currently open. So this is kind of a join synchronization mechanism and when all started events that we previously received received a finished event correlates to that.

E

It knows that the task has been finished and then the triggered event can be closed and yeah. So this is the synchronization mechanism for a single task, and during the next week we will implement the next functionality of the shipyard controller, which is the controlling of the workflow or of a complete task sequence, so chaining together multiple tasks and also triggering a task sequence within the next stage.

E

If, if a trigger has been defined, all right are there any questions about that.

E

D

But really impressive, because with this issue we then exactly know if a service is running or not so currently, as you probably know, we have the problem. If tests take 10 minutes or so we don't know, are the tests running or not, and what you implemented here really gives us insights whether the tests, for example, are running.

D

This is really nice.

E

Thank you yeah, so it makes uh makes it a little bit easier to keep track of what is currently going on in terms of which actions are being executed.

B

All right forward, we can also bring this information into the bridge, meaning when uh event gets triggered and we receive a start event. We can show an icon that is loading or or doing something to indicate that there is a process going on, and that is pretty neat. It gives us a lot of of more user um friendly or mixed. Then we can make the bridge more user friendly.

E

A

uh I I would have one question uh related to this: uh if there is the like, if there is a starting event and the service that sent the starting event is somehow crashing and won't sense, the finished event uh is then, like the this started. Event will be kind of an orphaned event, or it will just. uh You would have to restart the whole workflow right or start with the new start event exactly.

E

So currently do not have a mechanism to detect timeouts, but that will, of course be a good extension to this service in order to to handle those kind of scenarios.

D

Really nice question because um this is exactly the reason why we have introduced the status changed events. So then we enforce all our external services to send us a status change event, for example every one minute or something like this, and then we can prevent timeouts.

E

All right, so, let's continue with the third pr, so this is an extension to the distributors.

E

So, right now all the distributors, as they are in captain version 0.7, for example, are required to be run within the cluster. That captain is also installed because they connect to the cluster internal nuts instance and then receive the distributed events from there and in some scenarios it might also be a desirable to have the distributors be or any captain service we run outside of the cluster and having the new shipyard controller actually makes this possible.

E

Because now we have the collection of the open triggered events that indicate that the task should be executed, and this api is reachable via the public. If you configure it to be so, those events can be fetched from anywhere, and thus we have extended the distributor to include several new options to allow the distributor to fetch the events not only via nuts, but also via http, and the way it will be configured is. We now have this connection type.

E

It can be set as an environment variable of the distributor, and this can be sent set to http or nuts, so not just the default, and if nothing is set, it will also default back to nuts. But if it's set to http, it will do exactly as the variable suggests, which is pulling the events from from the shipyard controller api, and then it can be configured with the with those three environment variables, which is the http endpoint.

E

This is the endpoint of the of the captain api for the triggered events, so by default it uses the cluster internal domain for this api, then, of course, also the auth token, if you run within the cluster, it's not needed, but if you want to fetch the events from the outside, you will need to set that accordingly and then it's also possible to configure the http polling interval so per default. It's uh 10 seconds, but you can uh also tweak that and set it to a higher or lower value.

E

All right. uh One thing that's uh worth mentioning here is there is one known limitation.

E

So currently we do not support having not scopic wildcards for retrieving the events, but since usually the captain services that run outside of the cluster will be dedicated to one or maybe limited amounts of dedicated tasks.

E

It's possible to just pass a comma separated list of topics to the pub sub topic environment variable and then it will also be possible to subscribe to multiple topics.

E

All right, that's it from my side. Are there any questions about this http distributor.

A

I would have a question so that means it's it's a different option, so it won't break the already existing uh implementations. uh If you have the if you subscribe to all of the uh topics, but it's just a different way of doing it exactly so. If.

E

You leave the configuration of the distributors as they are right now in your current installation. uh This new version of the distributor will default to exactly the old behavior, so nothing will break here, got it all right and then I would like to hand over to gabrielle.

F

Okay, let me just share my screen.

F

Can you see it? Yes, perfect? Okay, yeah. I worked on a cli event to get event function which allows you to get events of any type. This was possible before with the api, but now it's in the cli and that's easy to use, because the cli already knows your endpoint and identification tokens. So you don't need to go into the api and specify that yourself and we had the cli features before, but only for two events so for the approval triggered and the evaluation done and now you can get any event type.

F

Let me just show you. I have no demo for that currently, so I will just show you the commands here.

F

So you specify cap and get event followed by your event type, and then you can specify the project which is mandatory, so stock shop, for example, and then you can specify more parameters like stage and service and your output type, which can either be json or yaml, and you can by default. This gives you the last event that was sent, but you can also get more than one if you specified with another parameter, which is called page size and yes, any question about this feature or why it is useful.

A

I think it's very useful feature and it's great to have another captain core developer now. So I really like this functionality.

F

Is there anything else, a question or.

B

um I'm just curious: uh did you provide the documentation for the for the parameters in the code so that we can automatically generate the documentation? Yes, I did. I didn't generate the documentation yet, but it's in the code yeah, okay, perfect. Now we will do that. When it comes to a new release of captain, then we will automatically generate the docs and then it will be part of of the documentation.

B

F

So then, I will give over to johannes yeah.

B

All right, yeah this week I was working on one issue. uh I finished one issue, uh which is the specification for the shipyard auto tube. Well, let's go directly to the outcome. The outcome is indigo, utils library.

B

When you go to package then to the lib folder and in the lib folder you find two subfolders which are pointing to a version and yeah. There should be a specification, is in odor 2 implemented, and when you open this shipyard.god.yaml go file, then you see the structure of the new shipyard. Well, it's not that um not it it! It's just this structure, but there was a lot of discussion going on uh how this should look like and let's go to have a look on an example here. It's documented right at the issue.

B

Again shipyard will have some metadata at the top. It's about the api version, the kind and then a block for the metadata. Then the name of the shipyard and then the specification of the shipyard itself consists of stages and each stage has a name and then, as a property called sequences, and this is actually it's actually actually the part that will then configure the shipyard controller, because this list of sequence of that's not secret. This list of tasks will then be executed by the shipyard controller one by one and uh yeah.

B

It's, I think, pretty cool when uh in the next week the shipyard controller will get the functionality to process this list so that we then have can have a real example. How all those finished and triggered and finished events look like all right yeah when you want to work with the new shipyard, please check out the new go utils library and there you find.

B

It then um yeah kristen heckleman cannot join today as he has another meeting, but you can. Can you give us an update on his issue because it's heavily related to promises and you have a lot of experience in uh in promises and also reached out to the community? Can you tell us the status.

A

You you can open it uh right here, so I don't have to share my screen because uh it's just the the documentation we still have so uh christian was uh updating. Also the issue uh today and I was in contact with him. uh So the actual question that is still kind of open is um there are two ways to deploy. Prometers. There is a let's say the traditional way uh that we also made use of um in.

A

uh Let me just mute my slack or just get rid of it for a second um uh that we also leveraged for uh the the the current implementation of the prometer service, and there is a new way about the pro to do it with the prometers operator and uh turns out. They have a little bit of different um ins configuration options. So, first of all, the prometheus operator uses um most of the configuration as secrets instead of config maps. So this is one change.

A

That's also written here in this issue, and then there is another change which was uh commented uh by christian uh a little bit later in the the next comment here that um it also makes use of uh customer resource definitions, and it's now using service, monitor and pot monitors, and that was it's.

A

It's a different behavior and a different um setup uh than uh the previous uh traditional installation and uh the question that still remains is: uh if, if the prometers operator is actually the new way to go and if the configurations uh will also kind of merge to the new way of deploying the deploying prometheus into a kubernetes cluster.

A

uh So what we did is um christian and I we reached out to the prometers community via um their slack channel and also via the mailing list, uh but we are still uh waiting for feedback from the prometers community. So if there's someone here in the call, uh we would be interested also in uh what uh you think or, uh like your opinion, on the default way, how to uh deploy it from ethos.

A

The background for us in uh in captain is that we don't want to be responsible for uh deploying promethos, uh because, usually it's a it's, it's a team or it's a yeah. It's a dedicated team or a dedicated folks that are managing the prometheus uh installation. So it should not be done by uh by captain, because maybe it's already deployed, but with captain we want to be able to configure a prometheus configuration, that's already running and we need to make sure that we are writing the correct configuration files.

A

So in this way we need to make sure that it's either uh the the service monitors or pot monitors and if it's secrets or config maps we just need to know which which direction we we are going.

A

uh I see that uh we had one uh probably one uh prometheus expert on the call earlier, but I know that he had to drop because he's on vacation starting tomorrow and uh he is busy getting his uh luggage packed.

A

But if there's someone else with knowledge on this, uh please reach out to us or just comment on this issue. uh It's in our captain country repository. You can see the link here and it's also linked in the um documentation in the meeting notes or in the on the project.

A

So this was chris, that's uh christian and is working on this and I'm just trying to to help a little bit, but that's our current. That's the current uh state. Okay, thanks for the.

B

Update perfect, then we can- or we come to the next uh bullet point, which is about the road map. Yes, still, uh the captain huntsman proposal number six is driving the roadmap, it's all about the shipyard format and the shipyard controller.

B

Please take a look at the proposal to get involved into the discussion and also to bring in your opinion and just a quick note. We also pulled in one additional feature.

B

The community was asking now for a while it's about deleting a service from a project via cli and and api, and this is also something that we want to achieve and and get implemented the next couple of weeks and going forward. You can then use the captain, cli command, captain delete service, you specify the service name and then from which project you want to delete it, but I will come to this later on all right yeah. Then, let's go over to the working items, let's see what has been demoed and what is still open.

B

All right ready for review here we have an issue that says research use of argo rollouts for blue green deployments in canary andreas. What's your status on this issue.

D

This issue is completed and the results are described in the cap. 33 now 23. I guess, but it's linked in the issue.

B

All right, okay and let's just take a brief look.

B

The result is in cap 23 perfect, and here you provide a link to a branch. I guess that shows an implementation of the help deploy service thanks a lot then I will move it over to the dance column because we will take on on that work. When we um get closer to get the cap 23 uh implemented, then uh yemen does one issue that says wrong version in environment overview.

C

uh This was a bug and can also be moved to the done section since it's already fixed the pull request is approved and merged, so yeah, but yeah. Since it was just a bug I haven't presented, it.

B

All right, let's move it over, then we have a new feature in the cli that allows to compile just a portion of the command and not all of them andreas. What was your approach? Yeah.

D

um I therefore use build flags, and now you can combine this in ia so that, for example, the install command is not part of the scene. I so um I don't need to present this yeah. Let's move it over to them.

B

Okay, thanks and here we have one that that brings more flexibility for the install process, because here we can then configure the storage class into the system volume uh while doing an up install captain install.

B

But there is still an open pr.

E

B

Thomas should review and we will wait until this is done and then one additional uh issue that was implemented by gabriel thanks a lot for that. um It's about fixing some error messages in the integration tests uh gabriel. What can you give us a just a brief.

F

Yeah sure there were some arab messages that had been thrown but weren't caught by the tests, so they were failing and the tests were still passing. So I changed that there were some wrong exit codes as well. So just some minor bug fixes in the integration test all right.

B

Yep then uh I will move it over to the done section.

F

B

Right thanks a lot, let's see what's in progress.

B

uh First of all, again it's it's uh issue that gabriel is working on, and this issue is about configuring, the namespace for a captain installation, because by default now captain is installed in the captain, namespace and going forward. We also want to provide the functionality to install captain in any other name space and gabriel.

B

You will implement this for the cli exactly.

D

It's not only dci, you also have to touch some other components, and this was the reason why I reduced the good first issue tag so yeah. This is a little bit more advanced.

B

Okay, uh gabriel, whenever you need help, please reach out to us.

B

Foreign controller.

E

Exactly this is quite a big one, so this is the functionality for the shipyard controller to control a complete task, sequence or multiple task, sequences actually yeah. But I'm making good progress and I'm optimistic that I can present it in the next community meeting.

B

B

Then here we have one that is a chore where, because when there is a remediation going on and during the remediation, a problem resolved event is received by captain, then the color of the root event does not turn into green and it's still red, and this is giving a kind of misleading impression for the user, and we discussed to change the color of the root event. Whenever a problem resolved is coming in or the remediation turned into a finished, with status.

B

C

Yeah, actually something that we haven't also considered uh as johannes described. It is if there is a problem open and in the after the remediation we get a problem resolved or even the remediation itself already says that the image is okay, now, um yeah, that the problem was still red on the left side uh and yeah. We discussed about this to make uh it after the problem is resolved. uh Green and uh yeah indicate that it was a problem open but yeah. Now it's fine again, I'm working on already on that one, um I'm already.

C

uh The second use case is already covered. uh Just one corner case that I haven't uh that I'm working on uh yeah, it's not yet completely finished because of that corner case, but yeah it's in progress. Let's see perfect.

B

All right, yeah, we discussed already this issue from christian who is working on on the promises service, and here we have one uh for andreas. It's about the cloud events yeah the specification of the new cloud events.

D

So um I implemented it in ghost drugs, but I did not formulate the specification yet- and this is not a pressing issue now, but I I will work on this.

B

All right and last but not least, here we have our placeholder for the fleeq integration test. Whenever you see a integration test, failing, please just leave a note here to get it then addressed all right. Then, let's jump over to the assigned and committed issues I reached out to suri and to imre suri still wants to work on this one on the yamal input, support for uris yeah, and I leave it where it is.

B

But imra told me that he wants to give this back to to the backlog, because he he can't find time to implement it, and this is the reason why I will now move it back to the backlog and whenever there is someone who wants to get started with a good first issue. Please also consider that one and just leave a comment there and we will assign you to the issue to get to start working on that.

B

Okay, then we go to the backlog itself and now uh yeah. It comes to the issues that are related to the captain delete service command. The first one is the handling of the the command itself in the core. This means, when captain delete service, for example, cards from project sockshop will be executed.

B

Then an internal delete event is sent out. This one is, is then received by the shipyard service, which will then call the delete endpoint from the configuration service.

B

And finally, the configuration service then deletes the resources and the entity from the repository.

B

The implementation of this should be aligned to deleting a project deleting approaching currently works the same way and it should go hand by hand, and the definition of done is that when the captain delete service, cli command is implemented that triggered. Then it successfully deletes a service from the repository, and there should be also integration tests that cover this functionality so that we have it all also tested during the the daily um daily integration test.

B

uh Who wants to work on that one? The next week, all right, synth.

B

B

Then the implementation of the command in the cli is explained in this issue.

B

The idea is yeah to get this command implemented by introducing a new cli command for deleting the service, then the only parameter or flag. No, it's flag that is are required. Is the project flag it's mandatory and the implementation should then check the number of arguments and flags, and when this is supposed to be, then the command just calls the end point the delete endpoint from the api service, which will then send out the internal delete event, and then the the process process goes on. I showed you in the previous issue.

B

Yeah, it's about implementing this command, creating unit tests and then also describing the flags and the comment itself so that it will then be part of the of the documentation. When we generate the the docs.

D

I can do it, but um I can not guarantee that I finish because next week, as you all know, there's also kubecon.

B

B

I will assign it to you and when you find time right.

B

B

All right, and then we have also the functionality that we will delete already deployed services while the helm service. This means when this command is triggered, then also the helm service receives this delete event, and whenever this event is received, then it executes a helm uninstall, which will then uninstall uninstall the the service and the service miners are generated, helm chart from the cluster.

D

I would like to also do this.

B

B

Let's lot it over cool, then here we have an issue, that's related to the bridge.

B

It's about a misleading message in the bridge, because uh yeah, when you did not ex, did not send um uh or when, when the bridge did not receive a deployment finished, you went, then it still shows the message service not deployed, but this must not be true when you are using or when you are using the bridge, for example, for um a quality gates only use case or for performance as a self-service use case, where you have deployed your service somewhere else and not by captain, but still want to use the bridge for doing the evaluation and yeah airmen.

B

And I we discussed how to handle that, because we now take a look whenever a deployment finished event or an evaluation started event is received, and this event contains the image and tag. Then we will display this here.

B

Otherwise we will uh we'll don't. We will not show any information there.

C

Yeah, I will take it as we discussed it already. um You can assign it to me. Okay,.

B

Then the next one is: this is a technical one and not user phasing issue for the bridge. Yeah.

C

I'm already also working on that one. Actually, since I um in contact with the barista components, team, perfect.

B

C

Yeah, that's something that needs to be fixed.

C

For the barista components actually.

B

Cool all right, then, we have a next one that is user facing it's um about showing the failed quality gate also in the environment screen. This means, when you have a quality gate that failed in any stage, and you see this in the in the services view, then you should also get a notification and an indication here in the environment screen, and this is done by the traffic light. Whenever the traffic light turns into red. It is an indication that there is something broken and a quality kit is broken.

B

The number next to it shows how many quality gates are currently not passed, and when you click on this stage, you get more informations about the actual service which artifact um was not passing the quality gate and finally, also the the outcome, meaning uh the number of or discord that has.

D

B

C

Okay, since it's already uh since it's again in the bridge, I will take that one here.

B

Okay, perfect, then very close to that one is the next one which is about showing open remediations in the environment screen, and I think I don't have to repeat myself- I'm just two sentences when there is a remediation that is ongoing and the services green is showing that then also the environment screen should present this information, and this is then done by the first icon, which is here the exclamation mark. When this one turns into red, then it a user should know that there is a problem that is currently going to be resolved.

B

Yeah- and here is the functionality when you click on on a stage.

C

Yeah, I will take care of that one as well.

B

Thank you very much, I'm in cool all right.

B

Then we have one left that has the next sprint assigned um yep. This one was pulled in by by jung. You can, can you give us a quick update, or can it explain what's need what need to be implemented here.

A

uh Sure um so, actually it's not. It's not intended to be an implementation task, but it's more uh probably a documentation task or just checklist, so um we are required to fulfill the uh continuous or the the core infrastructure best practices.

A

um So we are listed here uh on on this website and it's a requirement for being accepted as an incubating project for the cncf state for the cncf incubating stage, and we are quite good on the score already. So we are already have a core score of 95, but we still miss three requirements that are securely related and uh that doesn't mean that we are not yet um already satisfying these requirements, but we, when I went through this uh list, I was not sure if we are satisfying this.

A

So actually the task here on this item is to walk through these three items um and take a look if we are implementing the security requirements um for for these three requirements. So the first one talks about that, we are not allowed to uh use any broken uh cryptographic, algorithms, like md5 or older parts. uh So if we are not doing this, then it's fine and we can basically uh check the first requirement. uh The second one is that we should implement uh forward secrecy for key agreement protocols.

A

um I guess we're using these kind of things for um maybe for our web sockets, but I'm actually not sure, so this also has to be investigated uh if how we are using it and if we um fulfilling this requirement already and the third one is about uh storing of passwords for authentication for external users.

A

uh I think we are storing these passwords for either the captain bridge and the cli or for both uh and also here we have just to to satisfy how we are or to describe and uh and clarify how we are um um storing this and, as it says here, they must be stored as an iterated hash with a per use assault. Since we don't have this user, uh we we only have one user. That is using captain, it's only one password, so probably for us, it's a little bit different.

A

uh So we can argue that it's only one user and uh we we don't have a user management for captain. Yet so probably we already satisfying those requirements, uh but as I'm not as knowledgeable about the captain source code anymore, um I was opening this as an issue all right.

B

Just one question: is there a time pressure on this issue? Do we need it by next week.

A

No, we don't need it by next week, so if we have it by in two weeks, that's also fine. Okay, okay yeah, but I I know it it might need some uh some more detailed, uh analytic analysis of the source code um yeah. I I would need help here from the captain team. Okay,.

B

Yeah then, um I will assign this issue to myself, but since I'm out of office the next week, I will start working on that one. The week after.

B

All right, cool yeah thanks a lot to everyone who has committed to and who has uh yeah, who has shown commitment to an issue again, quick reminder when you won't get started with a good first issue here I have two in the backlog. um Just leave a note. There uh tell us that you want to work on that and then we assign you tradition. You can start implementing it.

A

All right can I jump in here sure, uh because uh you're already, sharing your screen and uh akil is on the call- and he indicated in the beginning that uh he would be interested in the auto remediation features of captain and since it's kind of a brand new feature- and you already explained it and presented it in one of the previous community meetings.

A

I would ask you just maybe give a very brief overview, uh how we are um uh yeah, basically tackling this, uh the the problem of um of automated remediations, and uh what what the, how how we are doing this in captain and then then also. Actually, you can ask your questions right right away here. uh We have a couple of minutes left and uh probably also one very short note. So we are in this community meetings.

A

We are mostly discussing about the captain core functionality, but uh we also know there is a lot of things going on in the captain community around integrations to captain. We have folks here on the captain community call uh that are working on integrations with other automation platforms like ansible tower to integrate this into the remediation workflow of captain.

A

So that's also a great starting point or a great interaction point with captain and external tools, and we know there's also folks out there in the captain community that are working on uh integrating captain into slack and writing slack bots. So we also really really appreciate this work, and but these captain community calls uh when we discuss the the issues and features we mostly discuss about captain core functionalities, but there is more out there. I just want to mention all.

B

Right, yeah and one uh one reference I would recommend to get started with the remediation use case is a blog post on medium, um just check out medium.com captain and there you find the blog post, which is called close room closed loop remediation with custom integrations, and let me use this blog post to explain this capability of captain, because um here we can skip this part. It's just the intro and some some explanation.

B

But the core principle of captain's capability for triggering remediation actions is about declaring your operations as code. I will show you, then, having automatic build blocks that take care of actions that are exe triggered as response to a problem.

B

And, finally, you can also use captain to do an evaluation of your remediation actions to figure out whether the result and the outcome is what you want to have and now let's get started. First of all, you configure your remediation for your service by providing this kind of space of remediation file.

B

This file has a version, a kind and then some metadata and the specification itself then consists of a list of remediations, and here you specify for which problem type. You wanna act on in this case. It's a response, time degradation and when this problem is received by captain, then captain takes care of executing those actions that are listed here and the action itself has a name uh user facing or a user a human human readable description and then here a unique name which will then be sent over to the action provider.

B

And this is kind of the declaration of what should be done in case of a problem and when this problem occurs, then let's jump over to the automatic build blocks, because when this problem occurs, then captain sends out an event, and this event will then be received by an action provider.

B

And here is explained how this action provider works and finally uh yeah. This one should take care of getting your problem resolved and also will respond with an action dot finished and when this event is received by cap, then captain will do the evaluation part and we'll try to figure out whether it solves the problem or not.

B

Yeah. This is a kind of starting point for getting more information about this capability, but we also have documentation at the official captain, page captain documentation page and when you go to the 0.7 release and when you go to automated operations here again, you find the documentation how to specify your remediation config, and here is the documentation how you set up an action provider.

B

We provide two types of action providers, which is the unleash and the helm action provider, but you can come up with any kind of provider when you want to implement it, and then you just hook it into captain, and then you, your provider, takes care of of doing the action.

B

Actually gabriel, is writing an action provider for for ansible power. This means, when um captain sends out an action-triggered event to gabriel's service, then gabriel, as an indentable tower service, will execute a remediation scenario in ansible.

B

We're looking forward to see this in action.

B

I know this was now very brief intro, but when, when you need more information about the remediation workflow, please reach out to me by slack and I'm more more than happy more than happy to give you more.

A

A

Great, thank you um akil. If you have any more questions, I also posted the slack url uh here, so you can join us in slack and also um yeah. I posted the link to the medium blog article. That johannes wrote.

A

Are there any more questions or uh general comments since we're already hitting the top of the hour? We are basically also hitting the end of this community meeting.

A

I think there are no more agenda items left if we scroll on the bottom of this here, uh so we are uh basically good for uh uh for uh for one week of cubecon and cloudnativecon next week uh we are pretty uh excited so, uh as said, we have the uh captain um booth. Also, it will be a virtual booth. um We have folks from the captain core team. We have folks from the captain community uh in this booth. uh Basically they are staffing, this booth and are happy to to answer the questions um yeah.

A

We will be happy to to see you there next week and also we are hosting another captain community meeting uh in uh next week. So if oh, we yeah, so there are no more questions. uh So uh yeah join us again. uh Next week and uh yeah, we are happy to see you there.

A

D

So uh next week advisor now christian is not here. Janus is not here myself, I'm not here and kubecon is, and so maybe we should think of postponing it.

A

uh Sure, um let us probably um have this discussion, also in slack. So if someone uh that is not joining here, but we can also cancel next week's sync and then sync up again uh on the 27th of uh of august.

A

I think that's a it's a valid option to to have an open discussion. It's like, but uh please andreas uh go ahead and suggest uh to cancel this so either way you will find out in in slack slack.captain.sh.

A

So uh yeah have a nice evening and see you during kubecon bye.

C

C