keptn Community, 3 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Community Meeting - September 3rd, 2020

Description

September 3, 2020
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/2268 - #2061 Make links in labels clickable
https://github.com/keptn/keptn/pull/2255 - #2112 Fix missleading message "service not deployed yet" in quality gates use-case
https://github.com/keptn/keptn/pull/2256 - #2197 Provide API token and keptn auth command in user menu
https://github.com/keptn/keptn/pull/2259 - #2087 Allow to filter services in environments screen by event type
Florian:
Delete Service from Project: https://github.com/keptn/keptn/issues/2199
Adapt Lighthouse Service Comparison Behavior https://github.com/keptn/keptn/issues/2224
Shipyard Controller https://github.com/keptn/keptn/issues/2193
Extend Distributor to send events to Keptn API https://github.com/keptn/keptn/issues/2220
Andreas:

Johannes:
Flaky integration tests: Integration tests fail (in unpredictable situations): https://github.com/keptn/keptn/issues/2149
Christian:

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

Recording is started okay, hi and welcome to this uh community meeting um before we get started. I have to apologize for last week where we quickly jumped from this community meeting uh to another one. The problem was that some zoom bombing happened, and so we had to move this chat, but today it looks good and I'm confident that we can use this chat today for doing the meeting.

A

Let me share the screen. First, just take a look on the agenda for today, yeah um or let's go through the the bullet points that we have here. First of all, when you wanna stay in touch with us, also check out the cncf slack channel click, this link to follow this channel and there you will get all the updates that are happening around the captain project.

A

Also, when you want to get started with implementing your first issue for and want to co, when you want to contribute, then please go to https, slash good first issues, dot dev there. You find a list of all issues that we consider as good starting points check them out and assign yourself, and we will then give you the chance, or we will welcome you to provide a contribution.

A

Then there's also a mailing list. We maintain uh when you want to get more information about the captain project. Then please subscribe there. It will be an email every monday that we send out just telling you what's coming up, which webinars or meetups are running during the week and where you can get in touch with us all right yeah. Then, let's jump directly to the issues and pull requests that have been um completed this week and then I will directly give the stage to airmen.

B

Thank you very much, johannes um yeah. I'm going to show you four poor requests uh regarding the bridge so enhancements in the bridge. uh The first one is make links in labels clip clickable. So uh in the bridge we show uh labels. So if there are labels provided on an event and some of those labels had as a value link and the idea was to make that those labels clickable.

B

So I will just do a short presentation in uh bridge I have here, so you can see this event. Here has labels like the build id number and owner and there is a label news which has a value. That is um a link so here on the left side down here you can see this is news, dot or f dot uh at so uh any link that is provided uh as a label.

B

uh The key will be used as the the title and it will be yeah linked. So when you click on it, it will open in a new tab and that can be used to, for example, link to a dynatrace dashboard back.

B

If there is a problem even erased, for example, or any other link that could uh yeah enhance the usability here in the bridge, uh the next pull request, I'm showing is a fix, misleading message, service not deployed yet in quality gates, use case so um yeah uh that the thing was uh when we had the quality gates only use case.

B

The bridge was uh showing uh the information service not deployed yet use captain sent new artifact to trigger deployment, since the deployment was not done by or through captain, but just the evaluation, and in this case now you can see that, since this is just evaluation started, so no configuration change happened here, so the deployment was not done by captain.

B

um We still show now the information last process. Artifact is carts0112, because here in the payload we have provided the image and the tag information. So now also the start. Evaluation is considered as a artifact and if image and tag information is provided, you will see it here or otherwise. We will just not show any details about that, but you won't get the confusing message, so it's not deployed yet. The same is also on the environment screen.

B

So when I have, for example, now in staging the cart service, you see the image- or in case this in this case, that image and the tag that is provided with this event.

B

um Yeah. The next pull request, I'm going to show is a pretty nice enhancement, also in the bridge. We now provide the api token and the captain auth comment in the user menu. So when you have access to a captain's bridge and you're not authenticated to that captain instance on the right top side in this user menu, you can now see the api token and the captain auth command, and you have also the possibility here to easily copy that one and use it for easy authentication to this.

B

Captain to this specific captain installation and the last one that I'm going to present is the filter uh functionality in the environment screen. So uh I showed last week already that we now have the problem and quality gates notifications, also in the environment screen.

B

So when there is a quality gate that failed, you will see this icon in red and if there is a problem, you will see this icon in red and also when you click on that stage, you will see next to the service the same icon again, where we have this failed quality gate. So in case that you have many services just to make it easier for you to find this specific problem event.

B

For example, you can click on this icon here or on one of these buttons up here to filter the services here on this side with regards to this specific type. So, for example, if you want only the services where you have the approval that the open approval or if you want only to see the failed deployments so where the quality gate failed, you can click either here on this icon or here on this button in this overview- and you will see only this list of services with those details.

B

For example, in this case, we can see the quality gate uh for the version zero. Eleven two failed with the score off here. You also see the evaluation score and some more details in this tooltip and because we have blue green deployment here you see also the information that I roll back to carts0111 was performed.

A

C

From my side, yeah.

A

C

A

Me go back and yeah.

C

A

Your screen does not only work for the delivery use case also for um the quality gates only use case.

B

Yeah, that's what I showed uh here. We had the quality gates only so, for example, we have here only evaluation, started events and, of course, um also if there is an evaluation that uh is broken. So it was not successful. You can see this result also in the environment screen here. You can also filter, for example, only for those services where the quality gets filled, and then you can see here um in this case yeah the image and the tag information that was provided um so zero.

B

Eleven two and quality gate of card zero, eleven two filled with a score off, and here you see again the result of the evaluation, but no information about a rollback, because the deployment was not done by captain and we don't know um yeah what a deployed artifact is here. What happened so um just information that the quality gate for this artifact filled.

A

Perfect, and can I ask you to go back to the services view.

B

Yeah, of course,.

A

Because I want to point out that, with this new feature of having the labels clip clickable, um we now also provide the possibility to forward from here to other tools, because we have rob on the call and rob also brought up the issue. That dynadress is actually sending a program problem url as part of the problem payload, and this url will then be converted into a label and will show up right here in this.

C

A

Section and uh yeah it provides the the link to the dynadress problem, and this helps us to bring uh or to to link captain with other tools more convenient in a more convenient.

B

Way, yeah. There is a huge uh usability uh for the user, a huge increase in usability here so.

A

Yeah and with the new dynadress service we implement this feature. Andy did that he is taking the problem ul and convert it into the label, and then it will be. It will show up right here: yeah, that's cool.

B

Okay, if there are no more questions, um that's from my side and then I'm handing over to florian.

D

All right, thank you. So let's get started.

D

Okay, you should see my screen now so today I have four pull requests that I wanted to show you so the first one is an addition to the cli, so we added the possibility to delete services from a project via the cli.

D

So let's have a short look at the issue, but I think it's very self-explanatory, and actually this was a very requested feature, because sometimes you only want to delete one service from a project instead of the complete project and yeah.

D

Let me just show you a short demonstration, so here I have my captain's bridge open and, as you can see, we have our good old sock shop with the cards and cards db service and now I'm going to enter the captain, delete service cards, minus minus project, sockshap command into the terminal, which I think you don't see here, but it's just entering the command and now it has been executed.

D

And now, if we reload the bridge.

D

We see that we only have the cards to be left and the card services has been removed, so the helm service and the shipyard service uh take care of both removing it from the hit repository where the configuration for the project is stored, as well as the database materialized view, that's being used by the bridge, for example, to to get all the information and also the helm service will take care of removing the helm releases for that service.

D

In all of the stages that you have configured in your shipyard, all right, then, let's continue with the second pull request, so the next one uh was an adaptation of the logic within the lighthouse service.

D

So let me just go to the issue, so let me explain.

D

As you all know, the lighthouse service or the slo file provides the possibility to compare the scores of certain cl slis with previous evaluations and, for example, we can specify that we want to compare with the last three evaluations and the way it has been handled uh up until now by the lighthouse service was that it took, for example, the last three evaluation done events, and then it selected the the target values based on an sli level or actually, let me pull up an example here.

D

So if you look at this heat map and, for example, if we wanted to uh compare the round trip service, uh p95 uh metric with the last three evaluations, the lightest service fetched those last three evaluation done events and then looked at the individual values for the previous evaluations of that sli, and it always fetched only the last three evaluation done events regardless if they were successful or not- and this has led to some confusion so now we have changed it that it will load the last three successful evaluation done. Events.

D

If you want to compare only with past evaluations and then it will inspect the values and then again check if the value for that sli has been, uh it will be evaluated as uh yeah successful and then it will consider that value for the comparison.

D

So I think that was uh actually how it uh was understood by most of uh our users and how it should have been in the first place and now it's easier to understand.

D

Are there any questions about that.

C

Hi florian, can I jump in with a question on that yeah sure so will it do that backward?

C

um You know determining what what test run metric by metric or will it do it by like? What's the criteria? In other words, if I have three slis, is each sli going to look back to find it's the last three good one by that sli or is it going to say, let me find a good test run and then all the metrics are being pulled from that same good test run. uh That's a good question.

D

um The latter is the case, so it will get the last three successful test runs so overall evaluation done events and then consider the sli values within those if they have been successful. So, for example, if we take those three events and want to consider the rt svc p95 sli, it will take that one that one, but not this one, because obviously this this was a uh erroneous uh value.

C

Well, I guess that's what I'm asking so, if are you if it's looking at the last three good test runs, then it would be looking at that top row right for the last three greens, but then my question is there could be a metric in a past test run.

C

I don't know if any are in this example in your setup here, but you know like say it's just like your your cursor's on that one right there if, like that, if you were to go vertically up and down there could be a metric that failed, but the test run itself passed exactly so what it would it looked like? Would it still grab that bad value as part of that metric, specific metric? That.

D

Case, uh for example, if that value were to be red instead of green, it will not uh consider that value.

C

Okay, so it's so, it might just, for example, say if there was three historical runs. One of the three was bad for that one metric. It would only look at the two good metrics for that government: okay, okay, that's that that would be kind of what I would expect. So thank you perfect.

D

Okay, are there any further questions about that request?

D

Okay, then, let's continue with the next one. The next one was quite a big one, so this was the complete implementation of the shipyard controller.

D

So if you recall from the from the previous meetings, I've already shown the the part where the shipyard controller manages all open, triggered events and then, in the next meeting I showed how it handles all finished and started events and, as part of this issue, I've actually implemented the complete functionality of the shipyard controller, which is going through a task sequence defined in the shipyard.

D

As you see in this example, and now the shipyard controller is actually able to really go through.

D

One of those task sequences send out the appropriate uh triggered. Events, wait for all uh started and finished events to come in then proceed with the next task and uh when the end of the task sequence has been reached, it will send out a task sequence finished event and also, as you can see here, if we have a trigger defined for a certain task sequence that should be triggered by the completion of another task sequence.

D

It will also do that so, for example, if this one here has been finished in the dev stage, it will then automatically trigger the the sequence in the hardening stage.

D

Any questions about that.

D

All right, then, let's continue with the last one. I wanted to show you, so this is a extension of the distributor.

D

So now we have added a possibility within the distributor to actually forward events to the event broker or actually directly to the nuts server within the cluster.

D

If the distributor runs in the same cluster as the captain installation and another possibility is to make the distributor send events that it has received to the captain api, including the api token, and this allows us to use distributors outside of the cabin cluster and the idea behind that is that if the distributor runs as a sidecar of the of a cabin execution plane service, the execution plane service does not need to know the address of the event broker or the not server or the captain api itself, but it just can send the the event, for example, a finished event to a local host on a certain port.

D

In that case it will be 8081 and on that port the distributor will uh listen with a http server. Then it will accept that event and forward it to the captain api or the not server. So this will make implementations of execution plane services a little bit more easy and convenient.

D

Are there any questions about that.

D

All right, if not, I will hand over to.

A

Johannes, all right, uh I don't have to show you a feature or an implementation work. I was actually working on getting the integrations integration tests fixed.

A

There were a couple of problems with our driver's ci build, but I could um could fix them and now our master build is green again and every day we get a all we get all of we get all images built and that's yeah pretty neat, because then, every day, every second day, we then have a cli version and all the artifacts that are represented in the master so that we can test it out and can make sure that everything works.

A

Okay, then, let's jump over well we'll skip the roadmap part because um we we discussed their shipyard controller a couple weeks ago, and we are currently working on that and today, florian showed us the implementation of the captain cli command on delete service, which will be now available with the upcoming captain release 0.71.

A

And this brings me now to the working items that we were working on this week and are in progress uh in the ready for review column. I have one left that is um assigned to you florian uh it was about it was on. I think it was a minor fix in the lighthouse service right.

D

Exactly yeah, so basically, what happened here is that if uh info sli, so sli with no pass or warning criteria has been evaluated, uh it's marked it as failed, for example, even though the actual result of the metric didn't have any effect on this core and that uh propagated through to the bridge and uh there they were displayed in a red color, and this uh failed flag has been removed for.

A

Photos: okay, perfect then I can. I think I can move it over to the uh done volume. Perfect. Then, uh on this issue I still need feedback from jung who will be back in the office by next week and then I hopefully can close that one.

A

Then, let's jump over to the in progress column, um yeah, I'm currently working on deploying captain openshift4.4.

A

Let me just open this issue because mark from red hat did a very, very great job on that ish on this issue, because he provided us a tutorial, a full tutorial to deploy a captain on an openshift 4.4 cluster when you wanna try it out.

A

Please take a look on this issue on captain openshift4.4 then follow the link to the tutorial or to the documentation and go through this doc step by step, and I can promise you that's working out pretty good, and this is what I'm currently validating and the outcome should be that captain 0.71 will run on openshift 4.4.

A

We will announce that when we can verify that and then we have also this support, but it will take me about uh one day to get this issue finished, because the documentation is missing and final pieces on the on the validation are also missing.

A

Then the team did a great job this week on releasing captain 0.71, um let's just scroll over over this check list, yeah step. One two and three are done also step four is completed. Then we released a bunch of captain contrib services, those services that have been changed in the past or from the previous version we also released.

A

I mean we created the release branch for captain 0.71, which we then used for testing.

A

This is the this. The phase we are currently working on on the test phase. um Yeah florian already completed the tests on gke and then what is missing is the tests on openshift, 3.11 and openshift 4.4. This piece on this piece, I'm working on and the tests on openshift 3.11 will be done by andreas yeah. I think that, with this two tasks can be completed by tomorrow, so that we, then we are ready to release 0.71.

A

All right yep, this is still in progress. Then andreas told me that he still needs some time to do this task. um Yeah the definition of the cloud events for the new shipjack controller.

A

He wants to leave it here in the in progress column, then florian you're, already building the shipyard controller.

D

Exactly so that one is pretty much done. I've already created a draft pull request, but I wanted to wait uh until after the release has been done to to merge it uh in order to not have too many merge conflicts potentially.

A

Perfect but will be cool to see the shipping control in action then and yeah. This is the first step for for this, then. The next issue is that we want to switch from cloud events in version 0.2 to the version. 1.0 and florin. Are you already working on that? One yeah.

D

I am so I've already. Actually it's quite a big issue actually, because we also discussed with andreas to.

D

Extend the distributor in order to take over the function of the event broker and then get rid of the events broker and yeah. It's I'm making good progress, but it will certainly uh take up a good part of the next sprint for me, because it's a lot of moving part and things to be considered and to retest it in order to make sure that we don't break anything.

A

Yeah, but it's an important one. We are moving this issue now, I think for more than half a year but cool that that we get it done next week and then back down. We have still one issue opened by christian, who wants to take a look at our implementation of the promuser service and he wants to get rid of the step of implementing promisers by the config monitoring command, but this is still in progress.

A

Then, let's jump over to the assigned issues, I mean I assigned you this one, it's an xfi, the captain's bridge. Can you tell us what the implementation is about.

B

um Yeah, it's basically a code structure um based on the nx standard, so there's uh um standard. I think the page is also linked there uh in the description, yeah and yeah. This is basically a.

B

Code refactoring task, so it will just um make it easier to to uh go ahead in the bridge, for example, um when we start introducing more views and yeah. Basically, it's a refactoring task that needs to be done or should be done as soon as possible. So now, after the release is the perfect time. Okay,.

A

Yep then, let's focus on that one so that we have clean code and are ready for implementing the next few.

A

Perfect and then let's go and take a look on the backlog here we have a couple of more issues in there. The first one is also a refactoring task for the bridge. It's about using an http inceptor to add default headers and implement generic error.

A

Handling, okay, uh yeah.

B

I reported that one and uh you can also assign it to me since it's in the bridge. I will.

A

Take that one thanks, I mean: what do you think how much um time it would take.

B

um Yeah estimate half a day.

A

Half a day.

B

Yeah, that's not a huge one.

A

Then I have- or let's let's I think, let's move that one a little bit further down um yeah, since the shipyard controller will be available with the issue of building it with the cli network, with the driver ci.

A

We then have a component that is working and and then we need to touch all the services that are part of the continuous delivery and automating operations chain, and the first one we want to tackle is the geometer service.

A

This means that the geometer service should then be changed in a way that it acts on a test.triggered event. Then he immediately sends out the test. Dot started event and when the committed service is done, he sends out a test.finished event all right, yeah andreas explained here uh the payload that the test or that gmeter service is uh receiving it's actually at the test strategy, and then the test, the or digimeter service can also consume the payload. That is in the deployment part.

A

And here the response or the test finished event is explained.

A

um We're gonna, who wants to take this one.

D

I would like to do that, since it's um actually kind of related to the issue, I'm currently working on.

A

A

um Foreign, what do you think.

A

We also need to test this implementation, of course, and do we have we will, will we have a broken master for a certain amount of time, or is there a way that we can get rid of the old implementation and exchange it by then the new behavior of the geometer service?

A

D

A good question, but my.

A

D

Guess would be that uh we will have a broken master for.

A

Time: okay, yeah. I think we have to take it into account and that's that's the way it is.

D

Yeah but maybe we can come up with a solution to to avoid that or keep that time. As short as.

A

Possible great all right yeah when the test is finished. The next service that kicks in is the the lighthouse service, who does an evaluation, and he should also behave the same way as the geometry service does, because he listens on the evolution.triggered sends out an evaluation.started, and this service responds with an evaluation.finished event yeah.

A

There is also the payload explained in this issue and all the events that should, or the structure of the events is also laid out there um florian. What do you think? um Do you want, or do you have enough time to work on that? One as well.

D

uh I think so: yeah, okay.

D

A

Right then, the next one is: let's move that one up uh yeah? It's the change of the helm service, which should react or should drag the deployment triggered, should send our deployment started and should send out a deployment finished when it is done with his job very similar to the others.

A

I can squeeze that one in you think I mean. Let me assign you to that one. But when you don't find time, then it's fine.

A

A

A

Okay, yeah, then, in the backlog we have one issue that is uh regard or for the cli, because, with the change of the shipyard format, we also have to touch the cli in regard to creating a project.

A

The create project command should then accept the new format of the shipyard and corresponding or then create a project based on the new format.

A

I assume florent, you are.

A

You have enough tasks for the next week? Okay, but.

D

If I'm making faster progress than expected, I can of course then pick that up as well. If nobody else.

A

Okay, um I think we just leave it there where it is and when, uh let's see uh we have the progress of next week and then we can always decide whether to move it over or not, and also uh kristen is coming back next week, and maybe he wants to get started with a uh an issue.

A

And I think this is a good issue to get started all right and from my side I next we will focus on some planning uh tasks and some planning work, um especially for for the bridge and getting out cool new features in the bridge, and this I want to focus on next week.

A

But when someone wants to get started with a a good first issue, I always have a couple of them right here. I will today remove survey from this issue because he told me that he has not time to work on that, and the same is true for imre.

A

This means that they are free now and when you want to get started, please just assign yourself there or just leave a comment on on the issue, and I will assign you all right.

A

Then yeah, let's go back to the agenda. I think we recovered the work in progress items. We did a backlog, refinement and discuss this issues for the next print and also took a look on the planning board yep. This brings us to the end and we can still use this time to answer a couple of questions either currently or has someone a question for your team then feel free to to ask.

A

A

Okay, it's silent. I take it as a as I know and then I have to say stay tuned. We will announce the release of 0.7.1 soon, maybe tomorrow or then next week on monday, but it will be available and you will also see it in the captain's bridge with the feature of the banner that will show when the new version is available and then there you will also get the links, a link to upgrading to the new version, and I can promise you.

A

The upgrade mechanism is now pretty cool because you don't have to deploy a kubernetes job anymore. Now, upgrading is done with the cli, you can do captain upgrade and then the cri will do the upgrade for you and will um move your captain from an 0.7 zero to another.71 in 30 seconds, and that's pretty neat.

A

Okay, uh I don't have any more uh points to consider and then I will now close this meeting and say goodbye, see you next week.

B

A

C

Hi guys good job bye-bye thanks, bye.

C