Cloud Native Computing Foundation GitOps Working Group Monthly, 10 Dec 2020

Previous Meeting

⏯

youtube image

►

From YouTube: GitOps Working Group - December 10, 2020

Description

GitOps Working Group first public meeting. Notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.e0ignly90e17. See https://github.com/gitops-working-group/gitops-working-group for more info

A

All right, we are recording, I'm going to share my screen.

A

All right, so, um thank you. Everybody of the the response to the announcement of this working group has been really terrific, and so one of the first things that we wanted to do here was, let me just see if I.

B

Can daniel you inadvertently got muted.

A

Thank you good catch cornelia, um so let me just get to the right tab here. Sorry.

A

All right so um again, thank you. Everyone for joining today. The the interest in this working group has been phenomenal.

A

I want to thank everyone for taking the time out of their day to join and contribute we're really looking forward to seeing where this get ops working group goes. I also want to thank the folks that have helped kick this off chris sanders from microsoft, patterson from github dan from code fresh and the team here at weave works as well, cornelia and scott and and brees. So this is.

A

This has really been a group effort as well as uh nate, I'm not sure if he's able to join from amazon, but this has really been a a group effort to help define what get ops is and really to help. Hopefully turn it into something that is a principle-led um has has some meaning behind it.

A

So we um last month published this blog post around the get ops working group so back right before thanksgiving here in the us in november, and I think everybody is familiar with with the text that's been put up here on github and what we really are aiming to do um is not have git ops um turn into something that that doesn't have a ton of meaning meaning, or maybe it means something different to every company.

A

That's involved, we'd really like to have gitops, have a meaning, that's agreed upon by the open source and the cncf community, specifically around the the kind of the core principles of how it should work. So the purpose of this working group is define and in, I guess, create the documentation and the principles that can at some point in the future, grow into solution, conformance and certification, around git ops and what a git ops pipeline looks like, so that that was the real purpose of starting.

A

This working group was to have involvement from all the different companies that are creating git ops solutions or using git ops out there in the community, and I see that there is quite a few different companies both on the solution creation, as well as the end user that are participating today. So it's it's great to see the turnout and it really demonstrates just how much traction get ops has gained in the marketplace, since uh it was kind of created back in 2017..

A

So today, a couple of things before we kick off what I, what we hope is a is an active discussion. So initially we put the working group into the flux which is a cncf project or under the flux project, and the reason for that was flux is part of the cncf.

A

Flux has a defined governance model, which we think is very much applicable to what we want to do with the working group. We're not actually looking to keep the get ops working group underneath flux again. This is something that we very much want to be a cncf open, community-led initiative and not something that's seen as steered by any of the companies that were involved in its founding. It was just much faster for us to put everything under flux.

A

Initially, the goal right now is to actually move the get ops working group underneath the application delivery sig. So let me see that that would be over here and we're we're in the process of making that happen. Now again. This would take it out from underneath the flux project and move it over to the sig app delivery project and and kind of working group, and we think that that is much more aligned with how it should work going forward.

A

We do hope to bring the governance from flux. Cornelia actually submitted a edited version of the flux governance which, strips out anything that's flux related. But I know that our developer experience team here with with scott specifically who's on the on the con has known known to some of you from the cncf community, has spent a lot of time, creating a nice um open governance model and we're hoping that that uh represents the spirit of the working group.

A

So I wanted to put that up front and get that out of the way, because I know that that's a topic of conversation for many many folks is where the get ops working group would live, whether it was going to be steered by this core group of companies or if it was truly going to be something open under the cncf, and I think that that's hopefully the direction is well understood by moving it under the app delivery.

A

Another kind of housekeeping thing since we've had a bunch more people join since we started. We are recording this. It will be linked to from um initially the google doc, but shortly from the github um repo, where we'll be keeping all the notes and the meetings and all that good stuff.

A

Everybody here is already practicing good zoom hygiene and then has their microphones muted. So thank you very much. What I'd like to do after kind of that brief introduction, is just see if anyone else who is on the um involved in the beginning of uh the get ops working group. So that's microsoft, github amazon code, fresh myself, anyone from any of those teams would like to add any color to what I just what I just said.

B

So this is cornelia, I'll jump in very quickly. I've been participating as a part of the app delivery sig um for some time, and um I know alois, who is one of the co-chairs- wasn't able to make it today. I was slacking with him earlier today. I don't know whether harry or um brian lyles, who are the other co-chairs.

B

I don't know whether any of them are on, um but I will tell you that about a month or a month and a half ago that it was brought up by harry, he was chairing that particular meeting that gitops had in in several people's opinion, achieved kind of a level of maturity and level of interest within the within the community, for it to be treated as as a first class citizen within the app delivery sig.

B

um This was not not entirely coincidental, but it was at the same time that a few of us were starting to talk about this, the various companies that daniel has mentioned several times here, and so when we started to bring these conversations together. I think that was when we all realized that this was this was the moment. So I just wanted to share a bit of that context with you all.

A

All right any anyone else from the kind of charter working group, let's say.

A

All right, well so really to provide a little bit more background around the get ops working group is, as we've seen, the the market really start to adopt, get ops as a very kind of clean way to implement cloud native infrastructure and manage cloud native infrastructure, not to mention developer application pipelines.

A

There's been, you know, a push and a pull around. What exactly gitops means is gitops relevant if you're, storing your cluster config, let's say for kubernetes in git, but you're manually, pushing that config out right. Is that git ops or is that infrastructure as a code? And so what we really felt was necessary was to provide some core kind of steering principles around what git ops was and how it works, as opposed to whether it was just infrastructure as code stored in git right, and so that's where this grew out of.

A

We have seen that you know major companies have started to adopt, uh get ops as a principle for operating their infrastructure and with both microsoft as well as amazon, as well as many other very large companies, starting to really look at operations by pull request as the way to manage the kubernetes clusters. It made sense for us to align around these principles and so the principles as they're defined here I think most people are probably familiar with, but I'll run through them quickly and then open up the floor for discussions.

A

So the number one thing is declarative configuration right. Everything needs to be declared to be get ops, compliant or get ops conform. It then it needs to have that declaration stored in version controlled immutable storage, so it doesn't doesn't need to be stored in git per se, but I think almost all of us are using git in one way shape or form. But if you really wanted to use cvs, I guess you could automated delivery.

A

So this is something that we feel is is a key principle of get ops there we're taking the manual changes or the manual push out, and this is why, back in 2017, um when the term get ops was coined, it was operations by pull request, the idea being that the change is made in get there's a pull request that performs a merge. Only after that point is the config updated and that's done by a software agent.

A

That's pulling that change into the target clusters and then leading into number four, which is the change needs to be run by software agents not manually triggered, which is a key difference in. I think our view between infrastructure as code management or get ops, and then finally, there should be a closed loop. The monitoring, the alerting, should be written back into the same target, git repository so that the state of the cluster is understood without actually having to log into or manually touch that cluster.

A

So those are the principles that we align behind in terms of what would be necessary to deem a solution. Let's say get ops, conformant or or gitops certified, and so that we tried to make them high level. We tried to also make them not um they don't talk about any solution specifically except for except for get, but that could really be replaced by any source control.

A

So what I would like to do is first see if any of the other charter folks want to add anything about those principles and then, after that, we can open it up to questions commentary, but we'd like to try and keep it maybe to about 10 minutes of back and forth.

C

Hey this is joshua from morgan stanley. I have.

D

C

Last question: how, however, that's come coming across, as um is there going to be like a set standard of what all cube resources uh get monitored as part of your uh principles, because I mean you mentioned cluster config, or rather whatever is running on your cluster. But then is there going to be like a set guideline we are supposed to have, for uh you know all the things that you should monitor as part of k-tops or just some deployments and app specifications.

A

So I think the intent is for it not to be dogmatic in terms of this very, very specific things that gitops needs to monitor, as opposed.

E

A

um Specifying that to be deemed a get ops solution or a get ops pipeline, it needs to be everything that is being operated, needs to be operated through actions that happen in get as opposed to any manual intervention on the target infrastructure.

A

Right, because you know I've been using kubernetes, you know nomenclature, but there's no reason why get ops could not um apply to you know, standard or first generation infrastructure as a service type infrastructure like vms right, potentially, you could operate vms in this way too cornelia. Do you want to add something.

B

Yeah, so I know, there's there's no expectation that um get ops only applies to a certain set of resources, and I don't think that we want to, within the get ops working group, only constrain ourselves or put any kind of specific requirements on resource types. If I understand your correct your question.

A

B

Yes, you were saying: does it apply to infrastructure? Are we going to be specific about it? How it applies to infrastructure? I don't think so. I I think that my feeling is that within the get ops working group, we talk about get ops and we'll have lots of examples, and I think that's part of the thing that I'd like to see this working group do is show how examples of how it applies to infrastructure examples of how it applies to workloads examples of how it could apply to iam policies.

B

Or you know you know any other type of things, but the principles themselves have to be brought across the different resource types.

F

Understood right, may I quickly after that, um so I think in general my proposal would be the way we should frame it is um you don't necessarily be have to be conformed, but you need to be adopting these best practices to say that you are doing something good up.

F

So I think if, if, if we could adopt the terminology a bit differently, that would be awesome that we can encourage more folks into the umbrella of doing things in a more git ops way by adopting best practices, um because the moment we use the term confirm automatically some follow out of compliance, and we don't want to do that. In general, we try to get more people on the boat by recommending best practices them how they are doing it, and you know how those examples listed.

F

um Other improve our best practices.

G

H

Thought of conformance as something that applies to tooling and not necessarily to users like I, I don't think my intention. I don't know if anybody disagrees, but my intention wouldn't be that, like, oh, your bank is going to be get ops. Well we're going to send in our committee of investigators to make sure you're compliant and then you can put this pci compliant get ops. You know thing up, I don't think that's the intention. I think it's more like what are get ops compliant tools.

H

Oh well, you've got uh you've got flex, you've got argo, um you've got uh weave, works, has a compliant offering code fresh, has a compliant offering you know things that support that range. It's more of a tool for the consumer than it is a constraint on the consumer.

A

Yeah and to add to that, I know that a number of the companies that are building solutions are uh will absolutely publish reference architectures that demonstrate how their solution can be implemented in get ops.

A

Maybe we use compliant fashion right and how it demonstrates get ops principles in its implementation, and that's one of the goals is that everyone here is aligned around the principles of what makes something um a git ops system. Then it's pretty easy for folks to demonstrate a reference implementation.

I

uh Yes, along those lines, um uh probably there's gonna, be layers of uh definitions or principles right and I don't think the goal of the working group should be to say this is a get off solution and this is not a gate out solution, but more kind of describe what those layers possible principles and so on are.

J

And I have a question and thanks to all for organizing the the first meeting group, um I'm really happy to see this. um My questions around the term declarative and if we use the word decorative, does it mean that tools like polumi, for example, are excluded from the whole detox approach, all the the cdks coming up and the strong movement to say? Okay, we define deployment and all the stuff now in imperative language.

J

How does it work.

G

That's a good concern.

A

Absolutely and and technically I think, I'm not um I'm not well versed enough to answer. uh You know, because that gets below the the the kubernetes level right now we're starting to talk about the creation of the infrastructure underneath it, um but that is a it's a good question that we can. We can certainly ask.

B

Yeah, so I mean going back to the we want to be resource type agnostics. So fine, if it's you know, regardless of what you're using pollumi to uh to manage.

B

um I think that you're right in that so I'll put on my propeller hat and and say that um my personal opinion is that we have to embrace that shouldn't be language specific and it shouldn't be. You know constrained to yaml or something like that. um I think that's something that this working group should look at.

B

My feeling is, I want cdks, I want pollumi to be included in this um and when we do maybe when we define declarative it isn't that it isn't expressed in a typescript like language or a python-like language which could be imperative. It's that it's expressed in such a way that reconcilers can then respond to that declaration of the intended state, even if the the declaration of the intended state is done in a language that can do more imperative things.

B

It's that we want this ability to have a cloud native approach to this, because git ops, to a large extent, the way that it in my mind the way it differentiates from infrastructure as a infrastructure as code, is that it's the cloud native way, which means we're constantly reconciling we're constantly adjusting to changes that are going on around us.

B

So my my knee-jerk reaction is no, let's not off the top exclude languages that are imperative, but we do need to maybe at least put some education in there on what we mean by okay. If we're going to use polumi or we're going to use, um you know typescript or something like that.

B

How does it fit into this? Get op cycle.

H

Essentially generates a declaration right yep, um it's just a way of describing it and so like, ultimately like what we're talking about is. um You are expressing a declaration and it needs to be item potent so that a reconciler.

A

H

Work with it, so, whether you like, like those people that are using like sheet ops, where they're using like google sheets to generate all their yamls, like I kind of think that that fits in right because they're like even though it's a there's a procedure, it's a procedure, that's generating the decorated thing that a reconciler is going to work on yep.

K

There may also be layers here.

E

Sorry, I I think what you're trying to state is that what we need is the reason. Some of these things are in the principles like you're, explaining the. Why so for declarative? It's so that you can actually reason about the state of the end environment because you can uh inspect it. You can then say this is what I expect to happen and the reconcilers make it so and at this point you have a declarative statement, because then you can reason about it.

E

You have version control so that you can actually uh go back in time and and go to other states. You can reason about. um I was a little disturbed when you know, if you don't have automated delivery, because that last step is a button press. um You know you're out of the club and you're an infrastructure's code person when I heard that, but I think I I think maybe we could.

E

uh We could talk about that at another time, because if you do everything right, except that last step, isn't a button pre or an automated destination, um you know puller and you have to do something else to get that to happen. You're most of the way there you're just you're just deciding where the button press is different, whether you merged it I'll get it. That was your button versus you merged it. Someone else had to press it somewhere else. So I I don't, have the I'm not trying to start a discussion about.

E

You know where the line is to be honest, but I want to be inclusive about if you're 90 there, but then you got kicked out into the infrastructures code club because that's the old school way of doing it and now you're you're. You should be doing jobs. I think that's a that's a bad way to start so.

E

The other ones as well, I think you could go through and and talk about why they're there in addition to what they do and then that's either doing by use cases or you know, sort of the rationale of why you, the software agent, why you need declarative? Why you read those things.

L

So, john, I think I think you brought up. um I know you said you don't want to discuss it, but actually I wanted to discuss that. That actual point, that actual point itself right, because I do think there are, um I think, they're like three different um pillars or I guess guiding principles right, like kind of like a crawl, walk, run, sort of thing and I think that all should be included as well right like infrastructure code and then fully automation. I believe the third one or second one.

L

I guess in the middle that um I think we should define it's not clear in my head, but I do think there's one there, but I do think we need to get a sort of a a crawl walk run and it should be under the umbrella of like get ops right.

E

So I'm with you, I sometimes say: look you don't have to learn a lot about this. The first principle is write it down boom. It's on the file somewhere. Second principle is automate the application of it right, duh right so write it down automate blah we're just using fancier, oh sorry, put in version control, so you don't lose it duh and then automate the deployment and that's sort of the baby steps. Then you get up to the fancy words about immutable and version controlled, and everyone can talk that way.

E

But you know what I mean like you. I think you want people to be able to get into it even with without the it's so scary. I have to do all.

M

These things, but can't people can't people do that today. Already, I guess one and I'm gonna play a little bit of devil's advocate here like um I would argue that what you just said, john people, do today already like that's status quo and if you're trying to define sort of a set of principles of a place, you want people to go to.

M

Why not make that bar a little bit higher like I, I and I'm happy for other people to have different feedback or different points of view, but I do think it's interesting to say you know, hey the there's, a principled setup approach we want to go to and that principle includes you know a versionable repeatable um set of of configuration that gets you that generates a desired state, that you then have some sort of desired state system to reconcile right and that that is done.

M

That process that takes you from your versioned artifact to that desired state is automated right. I mean that's essentially what's being said here and it's not you know sheet, it's not a it's, not a human in the middle. Yes, a human may press a button, but that bus button should kick an automated process. That's also consistently repeatable that, frankly, a robot could press so there's a couple of.

M

I got a couple questions right um number one, the closed loop part of this right, so I think when you were describing that initially um you said something about write back. um That kind of a a topic that I see burning in this kind of getup space. A little bit is when we say something is declarative.

M

We've got the declarative definition of this resource in git and we want to take it and deploy it somewhere and there's an automated process for doing that that declarative reference or that declarative uh expression should be complete in that no matter where I'm deploying it. It should deploy repeatedly the same way right. So I see lots of people that are that are writing and I'm going to go into the kubernetes piece of this a little bit, but lots of people that are writing yaml and then applying it and then writing back information.

M

That say an operator is enhancing that yaml right, so they're. Writing that information back into the git repo, um because there's no other way to recover it, but to me that that kind of that kind of loop um destroys the credibility of what git ups is trying to bring to the table the you know. I write into this immutable version system.

M

What I declare my system to be, and that's my human interaction and any anything that happens to take that yaml and deploy it wherever it needs to go, is an automated process, and that gives us that separation of concerns between what the automated system is doing and what humans are actually trying to intend to happen.

B

So tim, I think that's a that's a really good point. I think that not every every closed loop, not every right back and to get, would be welcome. But there are some interesting use cases because gitops is not just a delivery process, it does interface all the way out to operations. It is git ops. After all, it's not get cd and there are some use cases, for example around progressive delivery where you've got something happening in the cluster.

B

You've got some progressive delivery happening and, let's say, you're rolling out from version one to version two and the way that you kick that off is you say I want to roll out version two and during the progressive delivery, which is all fully automated by robots it. Something goes wrong and it says nope.

B

Actually, we aren't going to go to version 2 because there's a problem, it's arguable that it might be nice to come back to the git repository and say you know what you're still running on version one, because we pulled back during the progressive delivery process.

B

So I think that the closed loop is there more as a nod to. We want to make sure that we there is some connection to what's going on in the run time system tying that all the way back to the what's what's been declared in in git there. There is some relationship there and forum, and maybe this isn't expressed. Excuse me expressed the right way yet, but there is some something interesting there. Yeah.

M

I agree, I agree with you completely there's. Definitely some some interesting use cases around doing that. I guess I fear that that if it's not defined well it'll be a slippery slope where basically you're recreating kubernetes using git right, that's the slippery slope. I guess I would like to avoid.

N

Yep good important question about get ops. um Let me keep using the term get and and repo uh is there a requirement that the source of truth for get ups be a get repo, because we have use cases where we're using that model and the source of truth is not a get repo and I think, still many of the same principles apply.

A

It does not need to, and we said this up front, it does not need to be get. That's just the word that was picked for that's.

N

Right, that's wrong, yeah! As long as that's the case, I guess I'm just um from a working group point of view that I think yeah.

A

It needs to be immutable, immutably stored right, so usually version control is the way to do it, but you know you could do it on blockchain. If you wanted to right.

N

Well, um mostly, it's the case that we have use cases where we have um other things that are source of truth right I mean, and it could be even a sas service or but anyway, yeah. Okay sounds good.

B

I'll chime in a little bit on that topic, so the first example is that a lot of people are using githubs, where they're putting config and git and they're not putting their images because they're doing deployments to kubernetes, for example, that's one of the first use cases.

B

The images are not stored in git, the images are starting to get repository and that's the source of truth for the images there's. This really interesting element that now git acts as a bit of an index, because the image repositories are not always necessarily versioned or immutable, um and so I'm sorry, I'm rat, holding a little bit here. But this short answer is, of course, there's other sources of truth. I think there's an interesting pattern where git acts as a bit of an index and can help bring some of those semantics to the table.

B

So I'm sorry, I just realized.

H

That you can hold your index an additional definition off of immutable inversion.

B

Maybe I don't know I haven't gotten that far yet.

N

Well, we make our our images immutable, um even sign them. I mean those are all kind of more patterns. People want to pick in terms of how.

B

N

To manage the images but yeah.

K

Yeah and again daniel can, can you hear me hey? uh This? Is this is scott uh sorry, I turned my video off just because I think it may have been cutting out my connection for some reason. um I just I just wanted to speaking of reconciliation. I was just wondering a few very short housekeeping things. One is: could we begin to reconcile the text chat with the verbal chat?

K

I think there are a couple of points that have come up that seem relevant, that we might want to just make sure get on the get on the recording and- and secondly, um I just wanted to mention that I think there are some voices that might not really be heard, because we've got maybe 40 well right now, 45 people on the call at some point almost 50, uh though a few dropped- and um I wonder if we might want to consider, if not today, in the future implementing a hand raising.

A

K

A

That's a good that is uh both good suggestions: okay,.

H

Yeah and just uh for housekeeping the chat is not saved, so um keep in mind that whatever goes in the chat's, not going gonna be stored anywhere. We do have a slack channel right in the cncf that I think pretty much everybody that had put their name down on the invitation to that.

H

If they were, if you were in the cncf slack, um I am keeping notes in the github's working group here um and, uh and then I think, like you know, in future meetings yeah hand raising, is good and then trying to set agenda items beforehand and and having the page available so that people can go and add agenda items, and then we can try to address them together um because, like this is awesome like we have 45 people in here.

H

That's like how kick-ass is that that, like the first get ops working, because that many people who are that engaged, it's awesome.

A

Yeah and and the intent was to have a meeting agenda um in github, we were just having some challenges with uh pull requests under the flex org. So um once this is moved over, I think that those will be resolved. There will be a list of upcoming meetings, as well as a proposed agenda for those meetings too. So the the goal is to have a little bit better um housekeeping, so so scott and dan. Thank you for keeping us honest. We appreciate it um so just.

E

Going back to the point about sorry, just going.

A

Back to the chat, though, um and scott so I'll put it over to you, but maybe we can raise some of the discussion. That's been going on between uh chris patterson schubeck and an engine, and hopefully I didn't butcher your names too bad guys um just so that it gets into the recording. And then we can go back and and conclude the kind of discussion around the principles.

A

K

Oh great uh sure, um I'm not sure quite how far back we should go, but I can just quickly raise them a few short things. uh uh Omar omer is right that the the chat can be saved in newer versions of zoom and I've. I've I'll make sure to save it, so we can keep it too just so that anyone's you know for future.

K

um The very first thing was, uh I can't raise my hand as the co-host, but I um and I guess we haven't implemented it yet anyway, but one of my questions was, you know, should we do you think it's fair to say that for now the get in get ops is is a shorthand for something like versionable declarations of desired state for operations.

K

Maybe even we could say that could be reconciled. You know it seemed that people who responded to that uh in the chat felt positively about something like that, but maybe we can work on that um and then, secondly, in terms of versioning or excuse me in terms of qual qualification for get ops. uh One thing I suggested in the chat is that maybe, rather than a binary definition, we we kind of dog food a little bit and consider our definition progressive as well.

K

So uh perhaps, rather than is it or isn't, isn't it you know the will there won't they question it? Maybe it's more of a does. It does x, project or air b project specifically meet x, y or z, get off standards and to what degree um just wanted to put those forward as discussion topics, if not for now, then maybe for a future future.

A

Yeah and that's yeah, sorry I'll talk over that person very quickly and then just uh seed the floor. But one of the next topics that we're going to talk about is the development of the get ops and- and the word manifesto is in a little bit of discussion, but um a git ops. Let's call it definition right um or the reason why we all believe if we're uh believers in get ops, that it's the path for managing infrastructure forward right. So that's the the next topic.

A

So if we want to hold anything related to that, we can we'll be talking about that in just a couple minutes. So go ahead. I think dan, I cut you off.

H

Yeah, I was just going to say I noted uh those items down scott um in the document and get off working group doc, and then I also noted schuberth's um mutating emission hooks as being an item for discussion, because that does there's some stickiness with that. So that's something we want to have. Okay, I see leonardo, adding 12 factors is a good example. So I'm I'm just trying to note these things down um in the dock as we go, so we can.

H

uh We can save them for later and bring them into discussion next time or later today,.

A

Excellent so- and I will just note, one of the principles um specifically says: version controlled immutable storage right. It says, for example, git, but it's not being dogmatic about that. It has to be get right. It does need to be version controlled, immutable storage, though so that's that's something that is a key, a key principle and a driving um reason.

A

I think, behind the adoption that we're seeing is that there's a lot of very large and very small companies that have confidence in uh git, specifically for version control because of the fact it's so auditable and you can do rollbacks and all the other good stuff. So that's that's why the the get and get ops was put there all right.

A

Let's have maybe two more minutes of conversation around the principles, and then we can jump to the next topic, which will be around the definition and the manifesto and then after that, we'll just talk a bit a little bit more about how we see the working group rolling forward and what participation will hopefully look like for everybody before we before we wrap up. So any other things that people would like to discuss around the.

O

All principles so just a quick question daniel. How will this conversation like move forward into the future? You think that's going to happen like in a google doc is like how is this conversation around principles going to progress and what is the best way to so.

A

I expect, as long as github enables the appsig working group to have the discussions functionality within github activated. I think that this is probably that's probably a good place so that it's archived it's searchable. It's easy to find for everybody, that's what I would propose, I'm not sure if other people agree with me, but but I think that that's you know, specific functionality specifically meant for this type of discussion.

L

Yeah, I agree with that. I think that's the best place for it.

A

All right, but out out in the open, that's the kind of the driving um the driving force behind this all right.

H

So over brought up on the principles here um he's coming from the operator working group, he says he thinks it'd be interesting to combine good offs with the general case of operator, something like git ops is using version controlled storage with an operator um we use the word reconciler.

H

I think here and one of the concerns I had somebody asked me about this last week. They were like. Oh do I. Why do I have to have it on my cluster like? Why do I have to install something on the cluster and and that's the case of an operator right? It has to be on the cluster. I actually don't think it is that the software agent doesn't have to be on the cluster. The reconciler could be managing multiple clusters, which is different than an operator um omer.

H

Do you think I got that right or am I missing am I am I under selling operators.

D

So, in the general case of an operator we are not specifically, we are not uh talking about the implementation inside kubernetes.

D

So in the general case, an operator is a software that has the operational knowledge to implement a state from one side to another side and that's kind of the case in gitops.

D

If you take the get off with the closed loop, it's some kind of then operator in the general case.

N

It might be that operator specific to an a reconciler runs on kubernetes right. I don't know the term cluster, because we have use cases where the operator is running on another cluster. That's managing workloads on other, uh but.

E

The definition doesn't state where that reconciler is running, I'm not sure, there's a problem yeah and that's- and this is.

A

Because someone.

E

Keeps track of the state on the target and someone then makes sure it happens to be correct, doesn't matter where they are so I'm not sure regardless.

N

Running, I think the term operator is something that's running on kubernetes right. I don't know whether the question was that the agent could be running on a non kubernetes environment, in which case maybe the operator pattern might not.

A

Yeah I mean, if you read just to put this one to rest. I don't believe the principals talk about operators specifically and so a core. You know difference between I'd say that the two leading get ops pieces of open source software, which are flux and argo, is, you know I think dan was alluding to this.

A

Is argo doesn't run on every on every cluster, whereas flux does run on every cluster right, it's an operator, so those are those are differences, um and but this specifically doesn't say that a reconciler where it needs to run right now, of course, you know, as people develop solutions in the space there, there are differences right.

A

You run into availability, differences and failover differences and all sorts of different things right, but those are more architectural decisions, as opposed to the principles defining how it works right and that's why we wanted to keep these high level so that there was a diversity of solutions and problem solving and and not a description of how to solve the problem.

I

Right and totally, uh you know, support that. I think people might have been a little concerned that the term operator is often associated with kubernetes, but in general, probably using generic terms like reconcile. It might be better.

A

All right great, so let us jump over and talk about something, and hopefully um people are familiar with this google doc where it was announced. But what we would like to do, um and and really the the what we hope to kick off in this working group and talk about today and get people interested in is moving um towards this idea of creating a definition.

A

Let's call it or a manifesto around what get ops is, and we really like the idea of the the 12 factor um approach too, and so one of the goals of this working group is to take. You know the formation and align the community around what uh the guiding um it's. I I'm having a hard time thinking of another word besides manifesto, but what the id of get ops is and and creating that documentation for it right and and having the community create that document.

A

So um with with that, I know that there's been some debate in the document around the word manifesto. um I think that there's probably uh other terms that can be used, but it's probably best to have that discussion um in written form uh in in get when that's available. But what we do want to ensure is that anybody who is interested in participating in in helping to write those documents that this is going to be an open, um an open doc.

A

I think I just want to see the there is a a start to the the get ops definition that um alexis, who is a co-founder of weaveworks and and coined the term, get ops uh put together. But this is by no means um what the final output will be, or even the beginning output. It's just a place to look at.

A

So what I'd like to do here is first open it up to dan chris chris cornelia, anyone else who is behind the formation, the working group to see if they want to add anything to this idea of the get ops kind of definition or manifesto, and then we can open it up to the floor.

H

I don't mind the word manifesto. Is there an objection to that word.

A

There was some discussion in the chat, I guess some people are scarred by agile and the agile manifesto. I don't I don't have a problem with it either it.

B

Was I believe that the objection was more along the lines of inclusion inclusivity um that yeah somebody said? Well, you know that the agile manifesto young people won't even know what that is, although I would beg to differ on that. I think it's pretty well known, um but I think that there were some concerns around the inclusive inclusivity and um and that it can be a trigger word for folks, because it has some historical, some negative historical connotations.

M

Right, it definitely falls out sorry.

I

Sorry, I think hernia described it very well which yeah manifestos are often associated with opinionated.

I

You know I'm not sure about the right order, but.

A

Revolutionaries maybe.

I

Well, this could be considered revolutionary, so I think that's not.

B

A revolution isn't necessarily bad, but I think it's often been associated with people who are um maybe.

M

B

M

I would say it sounds authoritarian, like.

B

Authoritarian exactly.

M

That's really the word you're looking for it sounds very authoritarian, and I think that we should. I.

I

Think for the purpose of the working group, it would probably raise fewer concerns if we picked a more neutral word.

P

The word I've heard used before is playbook um is another word that I've I've seen kind of in that same space.

I

Right but playbook also implies a specific sequencer.

A

I

Does maybe a declaration we can call it a declaration, go to the founding fathers.

B

Yeah I mean we may just do I, like somebody brought up 12factor.net, you know he wasn't called the manifesto, it wasn't called, I mean what did they say at the top of it? What what words do they use at the top of that.

O

I think it's just factors. Sorry.

B

And daniel suggested we have this debate offline, but now we give.

A

B

A

More minutes, but I'm not.

B

A

I'm not sure it's the best uh best use of everybody's time to debate uh nomenclature, um but one of the things is, I think what we should. What we should do is boil it down. There's been some good suggestions, already uh declaration definition playbook, and I think we leave manifesto in there, and maybe we just put it to a good old-fashioned vote.

A

um I think the key thing that we're looking to boil it down to, though, is if and the reason why the word manifesto, although being authoritarian, um is applicable, is that again, if we go back to the reason this working group was put together, the goal of it is to put a definition around what a get out system is, and the reason why that we would like I, I hope, all everybody here would like there to be a definition around it, because we want to be able to build systems that are get ops compliant um that work in a git, ops fashion and hopefully build tools and components of those systems that are interoperable right.

A

So that's that's. The overarching goal is as an end user. My hope is, if I pick a bunch of tools that all say that they are, you know, get ops compliant or get ops whatever the term may be that I can put those tools together in a straightforward process to form a gitops compliant pipeline.

I

Yeah so daniel, I'm not sure if the main goal is to say what is or is not like what solution is. There is not give up whether something is compliant or not, compliant to a specific set of descriptions. I'm not sure if that is that.

M

I mean I would I would say that that the reason I'm so interested in this is because I spent years trying to to figure out what the actual definition of devops was. I don't, I think, git ops has a huge amount of merit and and capability in it already from what from what little has been described of it. If we can put some actual good description around it, I I think this could be. You know a very, very useful um process for, for so many different kinds of applications.

M

Right and yes, I don't think it's tooling specific. I would like to stay away from that at all possible, but I don't want to go down the rabbit hole of this is very general. It took years for somebody to come up with a devops definition that people even somewhat agreed on, and they still don't really agree on it.

A

Yeah, I will, I will just put it out there and say: the specific reason for being of this working group is so that the term get ops is not abstract is defined. So I will, you know, do my best as a participating member to steer us away from too much vagueness and catch and catch-allness of the term. We very much- and we kind of state that in the in this opening um post that really the goal is to define what makes something get ops and what doesn't make something get up.

A

So just just so that we're really clear on that. We don't want it to be abstracted away to be completely vague.

Q

Well, just else had one piece here um from discussions with hundreds of customers. Folks are looking for clarity in this space, so the more that we can provide clarity, it's going to be a good thing, and that's that's one of my big interests in this group.

A

Thanks chris, oh someone said engine I like that: the pillars of get ops there's another there's, there's another good one um in the in the chat there, all right.

A

um So one of the things that the working group and we'd like everybody to participate on is going to be the creation of um a document that becomes the definition of what of what git ops is right and again, I think already we have some consensus just by people participating on the call today that it does not. We don't want to name tools within this document right.

A

This is this is something that's principle-led that should be applicable not just to kubernetes, not just to something like a ci cd pipeline that we talked about today, but they are. They are principles that need to be demonstrated for a system to be git ops, and I don't want to there's no compliance board but for some a system to work in a git, ops, fashion right- and so that's that's the goal of this. um What I would like to do is have a place to start, and so we will.

A

um I I believe that we can get email addresses out of the slack registration, but we will also update the document that everybody used here just again in the notes, with a more explicit link. If people didn't see it to this working draft, we will also copy the working draft over into the new get repo so that there can be active discussions about the the document.

A

What I I think we want to hopefully aim to do is by the next meeting, which will be probably second or third week in january.

A

Have a document that's been put forth, not for approval per se, but that people have reviewed and that we can have a very active discussion around um and and I'd like to put that forth as kind of the first deliverable that hopefully, the working group um can can get behind.

A

So I want to see if- and I think we can do the hand raising, um but if people who are yeah who are on the call, wanna wanna aim that as a as an initial deliverable I'd love to for that to be the first thing we put out.

A

All right we gotta, we got a second from dan and a number of other hands too all right just to be conscious that we have so many people participating today. um I know there's a a lot of discussion in the chat. um What I'd like to do and is just open up the floor to any other questions comments, if you didn't, if you had a you had something to say, and you weren't able to push through um earlier, please, you know, feel free to unmute and uh and say hello over the last few minutes.

M

You mentioned a slack registration. I I don't see a slack channel described on any of the documents out in the git repo. Is it on the google doc.

A

We will put it there. I will also paste the link right here into the it's in the cncf. So let me just copy the link again and put it into the chat here.

A

So that is the wg get ops under the cncf slack channel that dan set up. Thank you very much feel free to join it. We will also make sure it's in the documentation. Thank you.

C

I think it's my first time joining.

A

C

Cloud native slack channel, could I get some pointers on? How do I register for that, or something like that?.

A

Sure thing I think, if you go to the cncf uh website and I'll paste it into uh and right here, there's gonna be a link to their slack down at the bottom and that's how you join the the slack channel. Let me just paste that into the chat.

A

All right other questions, comments.

R

A

R

um I think putting this together. This is really great. um I I want to double down or vote plus one on clarity. I think that is fantastic. I think in that vein, I think there's value in knowing what it's not so, um when I think ops, I think um the things that I think come to mind with git ops uh changes in the cluster rollbacks all that stuff, but I also think diagnostics, I also think uh debugging and management.

R

So I don't know if it's inclusive of that, I'm not trying to drive more conversation. I'm really just um I would like part of the topic and definition to be very explicit about things that it currently is not maybe it'll evolve over time, but I think that clarity is super valuable.

A

All right great feedback and I think, there's someone matt. I think you were about to see.

S

Yeah thanks yeah yeah, I was just gonna ask um I. I think that uh defining get ups is the the first thing and maybe the most important thing, but other other valuable things that follow from that are uh explaining why someone might want to uh to use git ops like what what's the value proposition there and then what are the?

S

What are the steps between where somebody is starting and where they're they're, using a full get ops uh get up set up right, uh you know, is it a is a whole hog transition from uh you know: non-declarative uh non-infrastructures code, uh lifestyle to a full, get ops workflow. I think the answer is no based on sort of like the crawl walk run uh comments earlier, but I think uh documenting stories for how to get uh how and why to adopt. uh Github should be valuable.

A

All right great feedback and yeah the first hand, especially the the folks on the line who are end users. You know documenting those use cases. uh I know myself from a solution standpoint. We love to read those use cases right. The success stories, the the why um the increases in um productivity and security that come out of get ops, adoption other any other. Last speakers here as we're at the top of the hour.

A

All right well, thank you. Everybody for participating in the inaugural get ops working group call. This has been terrific. It's been great discussion. I want to thank everybody for participating and for microsoft, amazon code, fresh weave works and github for sponsoring. So thank you very, very much for helping us get this going and as soon as we have the next meeting scheduled, we will add it to that existing working group doc, we'll also add it to the get repo and it'll be updated and pinned in the slack channel scott.

A

Please do keep us honest in terms of uh the governance stuff and uh we hope to see you in about a month happy holidays. Everybody.

C

Thank you. Everyone take care.

H

J