keptn Community, 11 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Community Meeting - November 11th, 2019

Description

Explanation of workflow for the keptn/spec repository
keptn/spec: https://github.com/keptn/spec
Slides: https://docs.google.com/presentation/d/13MBixC7JS0qUQ9epVJ2FWJW0p7GYWIpIet6D3JL6orE/edit?usp=sharing
Discussion of PR to keptn/spec: Proposal: Extend shipyard with approval
PR: https://github.com/keptn/spec/pull/3
In the meeting we could not derive a solution for the proposed change.

A

Alright, let's get started hi everyone and welcome to the next community meeting of the captain project in the last community meetings. We had really great discussions around the standard quality gates, standalone use case. This use case will be available soon. Actually, we are boarding on a on a beta release of this use case and it's around the corner.

A

But in the last meeting we also discussed documents and specifications very extensively, and this is also the reason why we decided to specify a workflow around specification documents and in this community meeting we will propose this workflow. We will explain you how it works and how we will yeah continue working with specification files, and we will also take a look into a real example. Andreas will show us this example and explain how to propose a change of the specification and the end of today's community meeting looks as follows.

A

First, I will talk a little bit about the workflow for proposing a specification change. Then we will discuss nutrious for request and at the end we wanna invite everyone who is at Keuka to stop at our booth. We will be there, the captain crew, the captain team, is that cue card and feel free to stop by to ask for questions to get a demo and so on.

A

Well, as I said in the last meetings, we extensively discussed a couple of documents and we also got feedback from the community that the Warner have a clear understanding, for example, which events are currently implemented or when it went are supported or the support of events are changed, and this was the reason why we decided to fill the work for around working with specification files and to bring it to the point in the captain organization of github people now find repository the captain's back repository and within this report ori, we will maintain all specifications that are relevant for the captain project and also a relevant for ya, specifying the behavior behavior of capital and for proposing a change of the specification.

A

You as a contributor have now had a chance to create a pull request on this specification and within this community meetings we will then discuss those changes and we'll discuss the advantages or disadvantages advantages of the one or other change. So that everybody is on the same page and we also can better communicate how we will continue working on on various implementations and as soon as a pull request gets merged into the repository. We will then tack the specification and based on this tag.

A

We will then continue implementing the specification and there's also a correlation between capital release and specification. That's based on, and each change of, the specification is also correlated to github issues, so that everything is is tracked and you can see the progress of a configuration, change well yeah, and when we finally release a new captain version 10, you will see in the release notes which specification changes have been implemented or which tag is it related to.

A

Ok, let's switch to this repository.

A

Just have a look into it. Just show you what's currently in there.

A

Thanks a lot when you, when you now go to the kid to the captain organization, then you will see this spec repository and within this repository we already have the specification of the captain loud events, the specification of the shipyard, you I'm sure you know the specification very well and there is also specification of a uniform. Actually, we should remove this link because we have implementation of the uniform. Yet actually it's a draft, as you can see it here in the headline and on the bottom.

A

There is the specification for SL e files that are used for for captain or a needed for captain, and when you now want to have a configuration specification change, then you just file your PR, then are you create, or you put on a great appear, her against the repository and then we will discuss Devon, o Radha PR throughout the community meeting and, as you can see here, there are currently four PRS available, and today we are going to discuss the third one it it's the extension of the shipyard with a brutal strategy.

A

This PR was created by Andria's and it was proposed. This new feature with this change and well now and over trend rest to tell us more about the idea behind this specification change. Thank.

B

You for this kind introduction from my side, so what we are now doing is exactly following up in the new approach discussing this PR together and what I am proposing is that we extend to shape yet mrs. so called approval strategy. But first please let me give you a quick reminder: okay, ten bucks, so captain uses so-called lighthouse service or P 2 meter service for evaluate equality of deployment, and this pedometer or in the future.

B

It will be called lighter service then gives us an evaluation result which can either be pass warning or fail, and then using this result we can either decide to promote this artifact or to discard this artifact and um so that it not does not get promoted into the next stage and can now always uses a kind of automatic approval.

B

That means, as soon as we see that the quality gates are passed that we get the past or in the morning we say, yeah promote this artifact into the next stage, but what's actually needed now is and to also ask the users, the Katan users, whether this effect should really be promoted, and that's not the reason why I propose a new field and the shippi are filed and and, as you can see, I'm naming this new property in the Shepherd file.

B

Approval strategy, and here I identified six different ways or six and different strategies which I was able to think of and now I would like your feedback actually on this six different approval strategies and therefore I will explain each of these approval strategies. The first month is automatic, pass and automatic pass means, or let's say, and the first term always indicates method should be done by captain or whether a user should be asked or not so automatic means captain is doing it and manner is getting user is asked for action.

B

So automatic pass now means when the gatekeeper service, who is responsible for designing when an artifact is promoted or not receives a pass of the Immigration Service of the quality gates. Then it will automatically promote this article and if you choose warning it's kind of similar instead also an artifact is passed. If, if the relation service, the lighter service reported us warning and the third automatic approval strategy, I found is fail, so it is always promoted, regardless of the emulation result.

B

So even if I get fail, I potentially would like to promote this into the next stage, because in the next stage, I do further analysis or it's a kind of emergency. The.

A

Third option is: is kind of should I say because do you really want or is there a scenario where you want to promote an artifact, even though the quality gates failed.

B

Probably yes, I can think of security vulnerabilities, for example. You really would like to have this artifact integral in production, because otherwise your users get harmed, but.

C

Does this mean connect just quickly interject, because I also struggled when I read it and trying to understand in the use case? Would you really then define this in the shipyard file or the also envision an option when you do a new artifact and you build basically that you Dan kind of override it, because by default I think every shipyard every pipeline should be as secure as possible, but you're right there might be individual bills.

C

When you know you have to go through quality gates, but then I would define it on a bill to build spaces on a new artifact, buy a new artifact basis kind of overriding the default. This is their possible.

B

Good point um we can implement it and this would make this obsolete.

B

This is really good, because what this is actually doing, is it disables our quality gates right and if you have quality gates in place, you probably want to use it. So I would now agree that we need a way to promote, to push an artifact, a new artifact and to tell captain always promote promoted, regardless of the of of the result of the quality gates, and this should overwrite or we don't really need it in the shipyard file in the central.

D

Place but just to add to that I don't see why we should hide the option from the user. I mean if.

C

D

User ever thinks that they have a valid use case. It's not for us to judge if it's valid or not I mean, as far as having the option doesn't need to be there. But.

B

It should not be at least best practice, and maybe we we should create clearly state discs in the specification not recommended, because disabling air quality I mean.

C

There's one use case, especially in the beginning of a new project when you have no clue about what your quality gates actually look like right. If you experiment around, and you want to get things through and then learn and actually fill up, your your historical data I think the an e-book makes sense, but still I would not by default.

C

I would not probably put this into the shipyard file, because what I want to put into the Chappell file is my ideal state of the pipeline and then every time I saying I send a new, artifact and I say: hey it's my first artifact I know the quality gates will fail anyway, but I want to get it through. Then I want to override it I think. That's what I propose. Okay.

B

What should we do now modesty saying? Should we completely remove it and provide an option to simply deploy a new, artifact and say yeah, always fast equality gates, because I probably don't know the buy quality yet and don't have it in the shipyard? I was.

C

Keep it in the shipyard to be honest with you, but make it clear in the documentation it's not best practice and provide an option with the new artifact event, where I can override the default behavior of my approval strategy. Not a question then, is how would that look like if you have multiple stages and if I say a new artifact and I push the new order effect from the beginning of the pipeline, and will that override mean I'm overriding all the stages, or can I define overrides for individual stages?

C

This is something I think we need to discuss, but definitely have it in there also for current completeness from a documentation perspective and that people know, but then I'll, let it all or let it be overwritten. Okay,.

B

Okay, perfect, so the last three are actually the same. Instead of an automatic approval, the user is asked so a manual past, for example, means the user is even asked. Man emulation, service, the lights or service returns.

B

Emulation result pass so then the user can say yeah promote this into the next stage or not, and here especially this manual fail totally makes sense to me because, as as you said, and when you don't know the criteria, yet maybe you want to to promote an artifact, even it politicans unmasked. Yet this option.

A

Allows an end-user to to over rule an evaluation results and when the person provides recommends a annotation, and we also can add this annotation to the information resource by for exact right exactly in this case, the person says that it's not a fail. It's a warning.

B

Okay and shape yet vile, this would be simply be added to each and every stage we can do a promotion. So in the last stage we don't need any approval strategy anymore, because we cannot promote and effect further. So this is the reason why here in the production, we don't have an improvement strategy but, for example, in def we can use an automatic strategy and before promoting the artefact into production, we can ask the user, for example, using an slike integration as well, but he really would like to have this feature into production or.

D

Not I would have one thing to add here: um what, if I want to combine it with strategies, for instance automatic paths? So if it's a pass, it should work. Obviously, but if it's a warning, I want to give my manual approval anyway,.

B

This is a good point. um How would you name this I I would actually comma-separated list.

D

For approval strategy, but somehow this this doesn't make sense aiming then or with the definition, because if I combine automatic pass with manual warning the two definitions, kind of overrule each other, either way so I, don't know like maybe a backup approval strategy or a secondary approval strategy. So we can give them an order or something like that. But yeah.

B

Yeah I also think your proof or your thoughts and valid, but maybe this would be the first implementation- would go for just six different kinds of approval strategies and then we can always extend more approval strategies so.

C

The quota question really is what, if nothing here matches well what if I said automatic pass and it's a failure? Failure do I ever get a chance to actually then override this mistake, or let's say, if I still want to do it, because I have an emergency. How would I be able, then, to promote this there's still some information that I can get the link? Maybe they approve a link in case I have to still approve it.

C

So I get feedback that the evaluation failed, no approval and then, if I still want to have it improve that would need to run the pipeline again and then override it. Basically right, that's what your it feels. Also a little counterproductive.

D

Yeah, maybe we actually need the seventh approval strategy, that kind of combines manual and automatic approval, but I think that's beyond the topic of discussion. You actually.

C

Think it's it's. You know, I mean basically there's two things right: you either have we reached a certain limit and we want to approve it and you can say automatic or manual for certain levels, players warning of fail or what else should happen in case I'm, not it's like with the objectives right. My objective is 100 milliseconds and if I succeed, then I want to do X, but if not I will do something else, and maybe that's the way we need to think about this right.

C

We want to approve it either automatically manually if we hit a certain stage, but if this criteria does not meet, then what you want to do nothing or do you still wanna, send a link, let's say through slick, so the people at least get the chance, because, basically that's what it is do we have to, but what's the state of reaching an approval, and if so, is it automatic or manual? And what, if you don't reach that state? What else we do.

A

This brings us to the point that we have two separate action and decretive at the passing criteria. We cannot combine those. We have to split them that we can come then individually, combined, but.

B

This will solve so map. Basically, this would solve Christians and proposal for having automatic pairs and if it is a warning to do manual review and what Andy needs is when we get a failure, so that it's not passed is that the user still gets a message so on events that the immigration is not passed and afterwards in he can always decide to promote it if it's needed so that we don't have to run the pipeline again mm-hmm.

B

It is correct. Yes,.

C

A

Every manual approval Gibbs gives you the chance to promote, regardless of.

D

A

D

Different approach: what if the approval strategy is automatic pass, comma manual? This means, if it passes, it's automatically promoted and if anything else happens, you have the chance to manually promote, so we don't specify that it needs to be manual, pass warning or fail. It's just as an extra step you can manually approve whatever happens, I.

C

Just feel a comma, not the best way of doing it, because if you look at it and I, don't know what's the first and what's this thing behind the comer but I get where you're getting to but should basically be. What's maybe my approval behavior and what's the default behavior, if, if I'm not approving mm-hmm, so I could say, my approval strategy is automatic if I have passed or it could be manually if I have pass and default would be just manual.

C

But if I'm outside of the range but and I, think that would be the default behavior anyway. I don't think I would ever override the default behavior to automatic.

C

C

And the thing, then, the only other question today for what the default behavior will probably almost always be manual unless I want to avoid spamming, because if I have 50 bills a day and 40 of them fail, then I don't want to get for the options to still promote and so I think. That's the reason where you want to actually have the particular specific option to say what do you want to do in case? We don't approve it.

C

Do you want to get an manual notification or not I think this depends then in in in high frequency deployment environments, where you may say no I just want to get it. I just wanna get notifications in case I am and I'm reaching the state of approved.

B

Your uniform how you configured Kevin, so you can register to events and if you decide not to register to them, you don't get these events, so this should not be part of the uniform of distributed.

C

Well, don't let me ask you another question: what happens what event is triggered in case I say automatic pairs? I'm, not passing what happens.

C

Do we have an option to receive that event that the approval stage failed or the approval strategy did not match.

C

Or will I just get an event in case I'm, actually passing.

B

C

B

But I guess: when you really are, we had a really good discussion huh so as a homework I would have proposed it. Everybody sits down and thinks how he or she would like to have captain. So the approval strategy, listen captain and please make comments on this on this PR and then we can have a short follow-up in the next community meeting and of course it would be also valid to go with this specification all and to have a first implementation and then extend specification and the implementation so to have an iterative approach. I like.

C

B

Then we have finance night all right here, which is we would like to invite you to visit us at the Q Khan. So you d, AK, allows and also me from the captain team will be at Q, Khan and San. Diego does Q come on Ren, it takes place next week and we will be located at the dynaTrace pools, which is p39. So please, step I, ask your questions. We are welcoming you and we have to answer all your questions.

B

Me to get in group get the nice cap like any okay. Dan, sorry for my no voice and have a nice day are. There are.

A

Further questions regarding today's meeting.

C

B

Go back that see you see you! Thank you.