Cloud Native Computing Foundation App Delivery Special Interest Group, 27 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG App Delivery Operator Working Group 2021-01-27

Description

SIG App Delivery Operator Working Group 2021-01-27

A

A

A

B

Hi uh we'll wait few more minutes and then start hello.

C

Sorry for coming a bit too late, I wasn't allowed meeting.

B

C

Let's wait about three minutes.

C

C

Okay- and I think you are you- are new here- aren't you yes, I am, and where are you coming from.

A

uh From which company, so I worked for red hat just now, oh perfect, before that I spent four and a half years at heroku. So I have a lot of experience of describing applications to running containers, perfect.

B

C

Just a signal, I'm sure, I'm organizing my my desktop at the moment to find out which documents I need.

C

C

It's just this one.

C

I think we have too much document.

B

Yeah and we'll probably need to move some of them or all of them into the github ripple.

C

um Do you know if jennifer will challenge today.

B

Jennifer, I think she said she might not be able to join okay.

C

um Yes, then, let's start um hello, everyone um welcome to today's um operator working group meeting um yesterday. uh We want to discuss how we will proceed with our document, um how you can contribute to our working group and what are what the current topics are? um We uh we changed. We are about to change our um workflow a bit. Currently um in the last few months, we worked on a google doc document and found out that this is not always the perfect way to get such a document.

C

um So um to get such a document done I'm currently, we are about to change everything to a working-centric workflow.

C

So um yesterday we created a lot of issues um for uh which are currently to do in our document, and uh we also we have um tried to migrate everything to the c-app deliveries and github repository.

C

So if you look in the cncf github repository sorry, a new, a new one is joining.

D

Yeah, this is my first time joining.

C

Okay, perfect, um then I'll I'll, try to um I'll try to repeat what it. What I said before um welcome to today's operator working group meeting. um Yes, today, we will discuss how we want to proceed with our. We are currently creating our um operator white paper and uh we want to discuss how we proceed with with the white paper.

C

um Omar jennifer and me created a lot of github issues for for this white paper, so everyone is invited to take on issue what to say. He wants to deal with with the topic um and to work on this topic, and we are also trying to get our talk to edit our document in in the github repository of the cigarette delivery.

C

um So we can discuss, uh discuss changes on pull requests and so on, but not discuss many things um over and over again.

C

um Yes, current. Currently, there is no no fixed timeline for the for the white paper, but we are working on it at the moment. um If we see how many people will contribute now and how how our progress, how our document gets further, um yes- and that's, this was the introduction um at first. How can you contribute um just? Let me share my screen.

C

So just a second.

C

um So I think these are: do you see ms cleaner? I think I've shared the wrong screen.

A

Where is it this.

C

Is it this show? uh This should be my my browser window. um This is the github repository of the cigarette delivery, um and now there are a lot of issues um tagged with operator white paper, and we also wrote operator working group in front of them to make sure that um you see that these ones are from us and we try in some cases we try to.

C

Yes, we tried to um describe what what should what should happen there if something is insufficient or you need something, uh don't hesitate to contact uma, um jennifer um and also, if you, if you would like to work on an issue which is not already created, um you can also um open the issue open up the issue and we will address it um what's missing in our case at the moment is um we are we are we don't have really have um um articles about the different operator frameworks such as the operator framework itself, as cube builder as computer and so on?

C

So if you know people from these communities which want to join us and would like to contribute to the document- and you are a modern world um currently um so um if you want uh to do uh to contribute to one of these of these things, um you cannot only comment to it. If you want to take a responsibility about one or one or more sections, um just contact us, and we will, we will assign this issue to you.

C

um Yes- and this was this part, the second part, so this is the these are the open tasks at the moment. The second thing is: um we have an operator working group space in the music delivery repository um there. You find all of our meetings, the links to the link to the chart, the change and meeting notes and so on, but also to the current document of the operator white people um did any one of you uh read on already the current white people except of uma.

C

I think you read it more than enough.

C

Yes, I really okay um and were there any things unclear to you or was the target? The goal of the document unclear to you.

A

No, it's I mean it's a fairly limited document, but it seemed reasonably okay,.

C

um Yes, so um what you can? What you can see in the document at the moment is there are a lot lots of to do's um and we tried to migrate all of these studios to them to the uh issues um and um at first we followed an approach where we created um sections in the document and afterwards added this uh track.

C

Wallet tracker add this to a pr and merge this in the uh delivery um repository, but we found out that this is a bit of a weird um process and therefore we will try to get anything to keep and afterwards um only leave a comment at the white paper that everything is indeed um yes, so to the document itself.

C

um We as a cncf project want to create the white paper which um targets on operators, um obviously um but more from uh from a bit of a higher level, so not not only for kubernetes and not only for one framework, because um we think uh that operators can only exist outside of kubernetes.

C

So um this was. This was the the thing why oma created a section about an operator design pattern, because when you think about operators or how an operator is structured, you could also think of terrafor about terraform as an operator, because it also has a controller which is terror from itself.

C

It has a custom resource definition or a desired state. Let's say this way, which would be the description of the tariff, uh which would be the telephone script itself, and it has um an infrastructure where it is applied to and which it can reconcile. um So in a very basic and abstract way. You can think of think about that there are operators outside of a kubernetes landscape.

C

So what we? What we tried to do at the moment was we. We were describing how operators work and trying to describe these on the basis of an offer company of humanities operators, because these are the only operators that people know at the moment.

C

um So this was a thing where we said. Yes, we have kubernetes operator components as a controller, desired state and um objects to be watched.

C

And um yes, we described, we are trying to describe a lot um and afterwards we thought about what which capabilities could an operator have? So I know that there is currently a operator maturity, mode model um which says in this phase and operator supports these, and this in the next phase and operator supports this and this, and we tried to break this up a bit and say that we don't have a maturity model in this uh um in this way as it as it is in the redder document.

C

But we have capabilities and um we could say that an operator has the capability to install an application. Okay, that's a bit obvious, um but it can also have the capability to manage the backup of an application which is not as obvious as I think, or it could um deal with autoremediation of the of the underlying service and so on.

C

So the idea was to um just describe what uh how an operator could um help and then could helping user okay could help a user and which features could be interesting for an operator developer to to implement and what we what we are, and afterwards we try to describe what we think about this or how this should be. So um one of our known goals is to set standards in the form as an operator which supports observer, which supports, which has monitoring and matrix, and this good good observer.

C

I must use this endpoint and you and make it uh and expose it for this software, so we want to keep this a bit more open so that the people know um what they can use uh or how how such, how such things could be dealt with some things we also thought about- and I think um this has also been- uh can also be discussed a lot.

C

um We had the capability of scaling so that that that the operator supports the scaling of the application, let's think about master elections or other things, but an operator could also um support the auto scaling of an application in the form that it manages the scaling of the scaling.

C

But um what we found out that uh at a later later point um that scaling the operator itself could only be a could also be a very interesting topic um exactly uh if you are exactly if you think about watching and uh remediating um or reconciling the the um deployment supports or whatever it is operate this manager.

C

um Yes, so um we have, we, we defined a lot of uh lots of capabilities. So if you find another another capability, please only feel free to to discuss things in the slave group or in a github show or whatever, um because I think, as as many capabilities we have as as clear it gets for customers or for also for developers what an operator could bring uh could do for them and afterwards um we thought about.

C

We thought that um it is fine to know uh to know what operators are for. um We will get some some best practices and so on, but we also think that the except that the security and um possible risks of operators are very, very um important.

C

So um especially, uh how can a customer ensure that the operator he wants to in-store um meets his security requirements? So, let's think think about um science.

C

Science contains signed images or the openness of the code and so on, um but also how can I, as an operator developer, I'm ensure that a customer trusts my operator so which information could I provide to him think about permissions of the api and so on, and therefore we also um try. We are also trying to get the thing security a bit more in the board and also also other other security related specialists.

C

So if you, uh if you are more from the security um you, you have a have a strong security background, you're more than welcome to contribute on this. um Yes and the third thing. The third thing insecurity, I forgot was the end user observation. So how can how can an end user ensure that everything the developers said is really true?

C

Okay, um yes, and now uh we have some operator framework such as: um let's, let's describe, let's call them the operator framework, let's call them kyodo beater and, however they um they are called, and um therefore we thought about that.

C

It would be very cool if we find some people from the respective communities to describe their approach, because I think not every operator framework has the similar approach, and I think this is also true and um to what we want to ensure is that every every uh every community fees represented in our fields correct that it's correctly represented in this document.

C

um Yes, we also thought about uh some time about the operator framework for non-kubernetes platforms. Some called uh sunset, choo choo- that's um I think, um but that's uh we have. We have not too much about this at the moment. Another thing we also have is the operator life cycle management. So um how does that operate itself, get managed, and so on?

C

um Yes, and what also could be interesting for everyone would be the would be use cases for an operator, so um this could also be that the section will be a bit more more on the upper of the document, um but I think it is very important, especially for users who want to imp uh for developers who want to develop operators which use cases they can manage with this so um uh which is made, uh which can be um also covered in the capabilities.

C

But this would be special use cases.

C

And what we also want to achieve is to get some some best practices for operators, so I think we hear we hear and read a lot about operators, um but there is no white paper or anything which um collects all of this best practices and so on, and this is one of our one other part we want to achieve. So um often there are it's talk. uh There's a operator, an operator operator is mentioned.

C

um Some people talk about the placement of operators so that you won't um uh won't like to operate your workloads and your controller processes, operators on the same nodes or node ports, but I think this can be re uh can can be discussed and so on so um and also how can I publish and operate an operator and how can I find it and after that, we would like to outline a bit a bit of technical implementation details.

C

So um how can I write an operator or how can I start to write an operator in this case this, especially for kubernetes? That's true um so um find the framework find out how an operator works and so on, but also how can a testing operator or um yes, how could? How could a demo application implementation of an operator could look like?

C

So I'm I'm not sure if you, if you know it, but there is a demo application in the the seagap delivery which is used for um demonstration purposes of deployment mechanisms, and we also thought about describing a example operators, not only in the document, but also in the repository um from the seagate from our working group uh on top of what is for this application and only reference to this in our document, so that everyone who wants to build or use different capabilities has a blueprint on this repository.

C

Let's see it this way, so this this was only also more an idea. Then we would be in the situation that we can implement this at the moment.

C

um Yes, and afterwards we will run. We will sum this up and conclude. um Additionally, we know that there are a lot of of books and white papers about operators and we all we also want to mention them and to give credits to them, because I think for some things, we've written written there.

C

The source is, is from there, but we also want to ensure that everyone knows what, where our document differs from this it's an afterwards. We have people who are crazy, and after that we can publish it.

C

um Is there anything in terms of structure um missing on your in your opinion, so also especially not from omar, because he knows the document.

A

No structurally, I think it's fine. I.

C

A

Obviously there are some minor detail things missing from it like to me. One of the things you're probably gonna have to standardize on is logging and things like that, because clearly you don't want to have to have multiple log formats being parsed you all of anything that you can reduce your friction with is going to make it, but technically I think the document structurally fine, you know about a number of operators.

A

They could probably contribute to some parts of this.

C

Okay um and that's it this way, would anyone like of you, too sort of kevin or winnie, would like to contribute to the document or which parts would you like to.

C

A

That's a good question. um I I guess I could probably write about writing operators using the operator sdk, the the go helm slash.

A

I think I've written a number of goal-based operators, so I could probably I think I've actually written a tutorial for some bits of this, so I probably could expand on that or shrink it a little bit and get something out.

C

So as we as we currently have no issue for that, could you write an issue what you um what you would like to propose, um and I will um I will take it in this and assign it to you.

A

I mean, I think, the key the interesting things about it would be to look at it through the lens of the maturity model. You know and to consider what what basic parts of it get you to the first level, what you need to get to each of the other levels and and can build on top of the labels to get to.

C

Those positions.

A

And that's probably how it might because there are already documents about how to take operator sdk and build a really trivial um operator, but it's that maturity part, that's interesting. What does it mean to provide deep insights? What does it mean to provide and remember what the fifth label is like? What are those things and how do you actually implement those.

C

um Just to come back to them to the maturity versus capability model, um what we thought about is that an operator which supports um auto uh sorry, I'm not sure um yes, an application which supports horizontal or vertical scaling.

C

uh So an operator which supports horizontal vertical scaling does not have necessarily to support backup, failover recovery yeah- uh and this was this- was also the cause why we switched from the maturity model term, working ability based model, um but.

C

Yes, it could it could all uh it could have also make sense to to um have have have such levels to find out how much how mature the operator is. But in our terms, we we try to avoid such things.

B

I'll say that uh we might want both, so there is the capability model, that's the thing that uh operator can do, and some operators, for example, don't need to do backups because it's not relevant for them. So it's not maturity level.

B

It's a capability, but in terms of maturity uh we can say an operator has phases of maturity like security is one logging and tracing is one and and like the the building of the operator that writing the code has matured, but in terms of capabilities we have some examples that operators that only creates other objects, so they don't actually need to backup anything external or even not doesn't have to support the vertical scalers or things like.

A

That what do you think I mean a lot of it? Is I mean it's interesting to me right so, like I look at an operator, is how do you um automate away your problems right? What do you do on a day-to-day basis that you would like to not have to do in a fail-worthy way, and so, like I look at it as backups, some services don't require backups, but a huge amount of them do um so.

A

You know I would probably shy away from the things that don't need backups in favor of how do you make backups useful? How do you make that level of maturity useful to folks? It doesn't necessarily always mean literally writing a dump to a pbe or something like that. There's other ways to think about that problem.

C

So I I often thought about, I think, about operators I I was. I was working as an sre and uh infrastructure guy, a long long time of my career and what I'm thinking about is that operators are um replacing my work.

A

Yes, that's why I think.

C

um So that's also what makes them an operator another controller and um yes, and what what I am trying to be. uh What I or what we tried to be uh to describe in the capability model was exactly these these tasks we did from day to day so um ensure that our application is correctly scaled, that it its backups, are running and so on and.

A

So, for me, things it's seller, you know it's essentially, if you consider what git ops is right, so github's operations by get well, it's that operations part that's interesting to me of operations. Anybody who thinks that operations is just deployments, probably hasn't done, a lot of operations, work and there's a myriad of other things that need to be done by folks to to keep systems running, and you know operational.

B

Yeah, definitely that's that's the interesting part of operations.

A

Yeah, you get a lot of people who think it's just deploying things.

B

I think that we, we don't have it in the docs, but I think thomas you talked about a few times. There was the day one and the day two. I think this was mark yes mark yeah.

B

Day, one is installing, and wrapping app and day two is like keeping the application healthy.

A

Yeah ruling secrets on a regular basis is another key thing that those things of operations I mean I I don't have to go far back very far to think about, like the kind of operational tasks that were carried out on the services that I've operated.

C

So I think often when people talk about operators, they think about installing an application.

C

um But um to be honest, uh if I only want to install an application given in this, manifest would be enough and we want to describe which, which which features an operator could also provide to them. And what are the main.

C

Accept its accepted.

C

A

C

Okay, do you have something to add? um I.

B

Won't ask when kevin uh does everything until now makes sense? Do you do you have? Did you have any expectations other than the things we and me and thomas and me has talked about so far.

A

No, no I'm pretty happy with it, and you know I'm feeling familiar with the landscape.

A

There's a bit a lot of chilling to do some of these things already and so shifting it into into operators and and cube, isn't really much of a change.

C

So we need, um did you have some expectations of the operator working group.

D

uh No, so I've been writing operator using queue builder, and I just saw this. I uh I was just curious how other people are riding operator, and so this working group seems interesting, so I'll go and read the white paper.

C

E

C

Very interesting, all working group. um So um if I just understood this right you, you did not write right. uh uh Very much. Operators.

D

No in in my team we are, we are writing operators. We are actually writing many controllers using cube builder okay, I'm gonna understood.

C

This yeah and have you made any.

C

Any experiences with operators you would like to share with the community or are there any problems you are dealing with, which we should cover.

D

um I need to think about it.

C

So we uh we also want to to make this document for the for the community and not for us. So if someone of you finds problems um in the real world or makes findings which we should share with the community, um just just let's discuss it in the slack channel or also you can, uh you can always feel free to write an issue for that.

C

um I think you're, muted,.

D

Yeah yeah sound sounds great uh yeah. I think this is a it's a very interesting work, so you know me, let me go back and read the white paper and see where I can contribute.

D

This would be very, very.

C

Perfect, okay, um so anyone uh does anyone have something to aid?

C

Okay, um so then I'll give you some minutes back. um Thank you for joining the today's commun uh weapon group meeting. um I think the next working group meeting will be in about two weeks um if it's not in the cnc calendar. At the moment, I will let.

C

Sorry, um english is not my native language um and I think it would be really cool if you could join us and contribute to the document. And if you have any questions or.

C

Expectations of um proposals, or whatever just feel free to contact us.

A

Awesome. Thank you to us thank.

C

C

Thank you. Everyone.

D

C

C