 Okay, hi everyone. I think we're ready to get started. So come on in and welcome also to everybody who's joining this online We are going to do our best to try to get everybody's questions answered including the online questions So hi, I'm Lisa Marine Ampia. I'm a CNCF ambassador and I would like to Welcome you to the get-ups working group session. Please do not be shy There will be someone running around the room with a microphone to make sure we get all of you heard Please wait until the microphone comes to you before you start asking your question Otherwise somebody up here is going to have to repeat the question Anyway, welcome and I'll first introduce my dear friend Dan Garfield and you can kick it off from here. Awesome. Thank you, Lisa. Thanks, Lisa Awesome, so yeah, we're the we're the get-ups working group, which is a working group established underneath the CNCF last year in a partnership between Github, Azure, AWS, Red Hat, WeaveWorks, and CodeFresh And the goal of the get-ups working group was essentially to come together and work out a standard for how Get-ups should work what the principles should be So I'm Dan Garfield. I'm the chief open-source officer and a co-founder of CodeFresh Yeah, hi everyone. I'm Cornelia Davis I have spent the last ten years or so working on developer platforms worked on Cloud Foundry worked on some Kubernetes platforms with Pivotal and VMware as well, and then I was at WeaveWorks when we created the the get-ups working group and we'll talk about the open get-ups project as well to clarify that and Just recently moved over to Amazon All right, and well, thanks everybody for joining happy happy to see people again. My name is Leonardo Murillo I have it calls me Leo. I'm principal partner solutions architect at WeaveWorks and co-chair to the get-ups working group Hey folks, Chris Sanders. I'm a program manager in Microsoft Azure and in particular I work on The Azure get-ups service which you're very happy to talk about today Yes, and my name is Chris Hernandez. I'm a senior senior principal technical marketing manager I think I have the longest title over at Red Hat and My focus at Red Hat is actually get-ups practices and her open-shift get-ups product Fantastic. Thanks everybody. So the format of this is pretty open We basically wanted to have a discussion talking about the new principles We just released open get-ups 1.0 and we also want to invite people to ask questions And we'll have a kind of an open fields open format We were all able to commit to that because it required minimal preparation So, you know, we'll have to see how it goes and maybe Cornelia Since you mentioned it you could kick off the difference between open get-ups and the get-ups working group Yeah Sounds great, and I think this is a source of confusion at times In particular because of the way that we named things when we first got started so for those of you who might have been in the the keynotes this morning where we talked about the various projects so Constance and Jasmine gave updates on the projects So those were projects that had reached incubation and reached graduation where that was some of the projects that they talked about and then I talked about the technical advisory groups that support kind of that that overall agenda and when we started the get-ups working group we put it forth as a project and We were we made Sandbox So it was a Sandbox project But it was a bit confusing for everyone because they were like wait a working group is a project Working group aren't working groups made up of people and what happens with that And so one of the first things that we sorted out as the get-ups working group was we said no no no The project is actually called open get-ups and we we went through a very open source Project kind of way of selecting that name and so you can think of the open get-ups project as the project that houses all of the artifacts that we're creating and We'll talk about some of those artifacts Dan just alluded to the fact that there's these principles But there's other artifacts that will be creating so that's the home of all of the artifacts Just like other projects might have code artifacts and Documentation artifacts. It's the same thing here and we may generate some sample code and those types things as well So think of the open get-ups as the project. It's a sandbox project. That means it's a CNC of project and it has it has the the Governance practice around it and it's the get-ups working group that cares and feeds that project Yeah, perfect. I mean that I think I hope that clears up any confusion about it and like Cornelia mentioned we just released open get-ups 1.0 as a set of principles And as a set of standards, this isn't something that You know the the group here on the stage We all just said let's get together and we're gonna pass down from on high The correct principles and we'll expect the community embrace it actually was a very collaborative process We had I think over 80 or 90 different participants. We had 60 plus different companies represented in that process Leo, you've been super deep into that process Maybe you can share a little bit about how we came up with these principles how these standards came out how we refine them Right. So I think and this is also relevant to all the people that that's joining us today both here as well as virtually, right? The process has been fully driven through community collaboration, right? What we're looking to define is how this principles how get-ups is implemented how it's it's actionable and real, right? To the community and ecosystem. So in order for us to do that We we really needed to hear from the community. So we started by Creating committees. Okay, so anybody can join the working group. We have monthly meetings where anybody can participate and we started to Create committees where people could meet up and collaborate and share their ideas as to What really get-ups meant for them and for their organizations and it was a I think it was a very Enriching process, right? I think it was phenomenal the level of depth of The conversations and the commitment of everybody that participated kind of looking to to really extract the truth out of all these Concepts that that we have been looking to develop. So we meet every month There is of course as Cornelia mentioned it is an open source project There are repositories where there's discussions that are ongoing and we just released version 1.0, right? This is just to put the iceberg. There's all sorts of Debating discussion that still needs to happen as to how all the things are implemented with How it how is it actionable in the in the actual ecosystem? So I really encourage everybody to to participate right in this debates Keep track of what we're doing in our repository in github and and And be active because after all these artifacts that we're producing are really the reflection of What the the industry and with the ecosystem are looking to accomplish right through through this principles And through everything else that we're gonna have to be putting together So yes, it's it was fascinating that results very much Yeah, you said it was really you put it sounded so positive when you said it and I was thinking about all the painful discussions and debates and I was like is this gonna become a flame war where we're you know It's like things like what does synchronize mean? What does apply mean? What do you know like you know if you're gonna put these things down? It's gonna be in black and white It's gonna be hardcore If you if you haven't seen the principles up on the screen. It says open get ops dev That's the site so I would encourage you to pull it up and and check out the four principles that are there and and look through them because They might sound simple by themselves, but it actually represents a Lot of experience and thought and people people have been doing some of these things for 15 20 years, I think Cornelia you and I talked a little bit about how this is Not there. There are things that are new about this, but if there's also a lot of old stuff in this too Yeah, I mean no question Although there the one thing that I want to be careful is that you're you're right people have been doing this people have also been doing things that we that don't follow the get ops principles and Because they're using get they believe they're doing get ops And there are a couple of principles that are really crucial That if you will Kubernetes has afforded us and it's the notion that there's automation that's convergent And so if you take a look at the principles the principles talk about automation, but they also talk about declarative state And so that isn't to say that having automation that is triggered off having a script that is triggered off of a get commit or a get merge Is a bad thing It just doesn't take you all the way to a new way of managing your systems And that I think is one of the things that that's one of the things It's not as well understood about the whole get ops movement is that it does the principles do represent something very foundational That hasn't been Ubiquitous it's been used in some places. There have been convergent systems before but Kubernetes popularized that oh, yeah Chris her Christian feel free to jump in. I don't yeah, this isn't a yeah Well, it's it's funny that that Leo put it so so eloquently, but like it almost did feel like a lot of blitz went tears went into this because it There was a lot of you know, they do seem simple, but there was a lot of passion You know in defining these principles and making it open and vendor neutral. I think it was it was powerful that It was brought forth In that aspect, right like it wasn't you know, there there's there was members from from we've worked so was You know from Codefresh from Red Hat, right? So this wasn't like a Vim versus emacs sort of thing and like there was a completely opposite of like we actually came together and try to Make make those principles and it's now really something that I can refer to as Cornelia was saying You know a lot of people are saying well, you know I'm already doing some of this infrastructure as code thing is like well that's just one piece of actually doing get ops and And now it's it's great to be able to refer to something It's like no no if you really want to do get ops what you're doing goes against You know one and two or you know, you're doing one two and four But not three right like you you know, you can have a place of reference in in a Y behind a Y behind it Right and it's like this is why we you know why you're not doing gaps or why you are doing get ups You know, you know what comes to mind because I think One of the things that I learned through this process is that simple is really really hard Basically where we started like complex is where we started right we had this complex ideas And I think a lot of the purpose of the working group was to distill those ideas into concepts that were Relatable that were comprehensive, but that in their simplicity could communicate this complex context right that Redifferentiates get ops from existing patterns and to me This has actually been kind of the first time that I participated in the working group and it was It was fascinating to to see the dynamics of that interaction right because Particularly coming from from kind of more structured Decision-making processes right like within organizations. There's usually a hierarchy that Defines a lot of the decisions that need to be made, but with the working group it was such a process of Reconciliation Another joke Yeah, it was a kind of funny I think I mentioned it the other day, but one of my colleagues coast has kept along us to this great Webinar on get ops and he asked people at the beginning how many of you were doing get ups today and in the audience It was like 60 70% of people were like, yeah, we're doing get ups today Then he gave a talk on get ups and he said how many of you are doing get ups today and 5% of the audience was like We're doing get ups today so there's definitely a delta and I think we should actually talk maybe a little bit about like this delta of like what the Perception is I think sometimes people think it just is well, I make a commit and things happen. That's get ops and It's actually like well how the how that commit makes it from point A to point B is actually super important and How that commit is recorded and all of these things are super instrumental So maybe we can talk a little about some of like the most critical principles and differences that we view in it I'm the last one here So I would recommend everybody take a look at the principles because I think they really have been boiled down to simplicity Which I really love and so basically we're starting to put guard rails on the whole get ups discussion And it starts with these four principles but then You know that what I see as interesting about the open get ups project is Then the community comes in and starts giving Examples of how to apply these principles and there's going to be many many different scenarios out there You talk to customers and they're we're all over the place and how to do it They're looking for how do I do this? What's the best way to do it and that's where I see the open get ups project coming in as a way to Put this information in there so that folks know how to do it They know how to create tools that work together and all of that But as far as the principles go that are very interesting as far as a tool set for Kubernetes management, you know the fact that you of course declarative is is huge You know you're not putting your business logic into code anymore The business logic is in is in YAML files that anyone can look at they're starting to get repo that's versioned So you can see what change one version to the next and then your commit to your repo becomes basically That's your operation as an application developer as a Kubernetes manager And you don't worry about the actual CI into or the CD into the into the cluster itself Right you worry about your CI part and I think that's huge because it takes a big part of the loop out of Places where actually you and I can cause problems if we go in there and try to do the CP CD part ourselves so I see the whole Principles of how get-ups works as a very clean way to manage Kubernetes and that's one of the reasons why Azure was very interested in making you know being part of this and and seeing it go forward with the community and using the community tools Yeah, I think I think I think actually my my favorite I guess piece of Of the principles is the whole discussion we've had and you guys can see the discussion and get hub right we've Everything I think mostly was done asynchronously on the get hub is the it's essentially the kind of the concept of the control loop And I think that's like the defining thing about about get-ups versus Doing something like with web hooks or doing something with like CI is That reconciliation loop that that control loop Versus triggering something to happen there is the The the get-ups controller right whatever using flux or Argo is Constantly checking and that's that that that loop. That's the end. I think that's that's that's one of the one of my favorite principles because it kind of drives home the fact that We're leveraging the platform of Kubernetes. We're leveraging that that that that that control loop right from from each one of those domains and I think that is One of the finding factors of using get-ups versus what we Sometimes called CI ops, right? So it's I think that's like a big differentiator one of my favorite ones that is like no no something's always checking It's not they're not web hooks or any like that something's always checking. So that's that's my Favorite principle there. Yeah, this is this is a feature of control theory and by the way We're monitoring questions on the platform and we're gonna I think we're gonna come to those in a moment And if people have things from the audience you want to raise your hand and Lisa will run around and it looks like we have one over here, but what while you're running over The the control loop aspect we talked about some analogies in the classic analogy is a thermostat versus a radiator and In an open loop you have a radiator It's just on and it provides heat and a thermostat you set. This is the temperature I want and there's adjustments and there's feedback and it's checking to see what the temperature actually is as it turns the heater on and applies it and Get-ups is meant to operate in sort of the same way where we say this is a state that we want but there's also a Checking mechanism within the operator within the agent that's actually saying was this actually applied wait Did somebody come in and start changing things and we need to say no That's not that's not what my desired state is. I'm gonna adjust for that. Let's go to this question over here Thank you. I have a combination of practical philosophical question, right? So, I mean our org is adopting get-ups previous org as well We're happy that solves the obvious problems and so on so forth, right up to certain level right as our company grows And size and this may be applicable to subset of companies Sophistication of our tooling grows right eventually we're gonna have like an internal develop a platform with UIs API CLI's and so many different interfaces and things like that Now we can use get as a back end for that right there's obviously patterns right you check out you command to create pull requests, right? I mean, but at that point that we just not like Making get the database and like reinventing a database and get then is there not like a Contradiction at that point right like I mean currently we can all like hack it then right go then that does that but like at that point We just created the database essentially, right? So I'm curious Hear your thoughts on that. Yeah, I see what you're saying. That's a lot to unpack. I would love to chime in because I think you said something really important there because get plays if you will I like to think of it as a dual role in The whole get-ups agenda one is that it can be used as the user interface as The collaboration mechanism where everybody can come together You can have many different eyes sets of eyes that go on a commit You can validate that that's the right commit before you commit it and once you commit it Then we have this convergent automation that happens. That's one element The other element is exactly as you said it is if we think of it as the data store now. You're right At one level it's like wait a minute. Why would we use get as a database? Aren't there other database technologies? But get has some semantics baked into that database that are really crucial to the get-ups agenda Some of those things are it's distributed So part of the benefits of the get-ups agenda is that we you'll if you take a look at the principles We we do things like pull we pull from get rather than push out to endpoints. Well It turns out that what you can do is you because get is Inherently distributed all you need to do is do a get clone to some edge location And now you've got and you can have a convergent loop That's constantly updating that so that if you have a network outage no problem when the network comes back You've got a clone. So it's a distributed database if you will it also has important features around immutability and Versioning baked in that ability because one of the benefits of get-ups is that you can always get back to a state So it's it supports disaster recovery and a number of different cases use cases like that And so having versioning baked in where I can't as an operator go and change a single line in my a single space in my configuration and have it appear as the same version Versioning baked in is another semantic that is so critically important And so I'm not going to sit here and suggest that we might not come up with a different data store that supports the get-ups agenda But that's part of the reason we call it get ops is not only for the user interface But because of the get semantics that are baked in to get that support the goals of get ops Yeah, we were actually very careful in the principles. It does not say you have to use get In fact the principles don't It's I know it's called get-ups right, but but the principles actually don't names are hard names are hard The principles don't actually mention get They mention that you need to be using a versioned and immutable storage for your desired state now You could be doing that with Perforce You could be we actually debated if you could potentially implement it and be Conformant with Google Sheets and you could potentially do that and also you could be using get and not be conformant So for example like in in Kubernetes. Everybody knows don't use the latest tag, right? Well, if you were You're actually not using versioned immutable storage because this is an end-run around Versioning because now you can no longer say this is my desired state because the fact the artifact that you're using isn't versioned so I Mean to your to your fear of like am I implementing a database? Well technically if you can get a database to be versioned and immutable You could use it as your data store for for get-ups and that would be okay Distributed and yeah And I think that type of feedback is exactly what's gonna keep this Parent I'm evolving right because we were really focused on not Talking about implementation specifics right rather objectives that should be satisfied by a certain architecture tooling right so as as the Paranime evolves and it's adopted by larger scale and different type of use cases. I think we will start seeing new technologies that are going to be used for for for Storing state What we're trying to define is what are these fundamental Principle characteristics like the needle was pointing out right that should be satisfied and yes get is the one that Satisfies them at this point in time, but as as it evolves There likely will be other Repositories that will satisfy those those requirements Okay, we have a couple of questions from the room and also the questions are piling up online and some of them They're getting quite a few votes, so I want to make sure we get to a bunch of them So why don't you ask your question first and then we'll take it off Thank you So you mentioned the principles your work that you derived and that you started from complexity and Narrowed it down to more straightforward ones. I'm curious if you found some common anti patterns That you found in multiple places and that once they set the route it made it hard to move to Do the system that works at here's to your principle Yeah, what what anti-pattern is do we see that keep people from implementing these principles? There's there's a common confusion that I think you've mentioned then and that's the direction of the reconciliation process where a lot of people think about get-offs going Into the repository and not the way around right when when you think about the runtime state actually being These sorts of truth and then just reflected in the repository. I think that's a common misconception That at least what I talked to end users usually comes around and I also think there's This concept of that was actually mentioned in one of the kind of discussions in good of this idea of weak get-offs versus strong right Where and I think for example we've worked we've actually identified that as a public component of collecting maturity model when when you Like starting up. You are really not doing continuous reconciliation So that's kind of couple of ideas that come to mind. I'd love to hear what Well I've thought about this a lot too because get-offs at one point says single source of truth, right and I think there's going to be a spread that you're gonna have to decide on yourself, right you can The perfect would be the single source of truth Everything goes through get and you know exactly what's going on But I can just give an example from from Azure that is a managed service there We're also often the ability to bring in services from Azure that are delivered Through Azure in agents on the on the clusters, right suddenly. There's multiple sources of truth I don't know what to say to that except to say. Well, there is a benefit Perhaps to have multiple sources of truth instead of just a single one, but you can out you can decide so that I think that's an example of this sort of Conflict that that can happen. Yeah, it's Leo's You know just expanding a little bit what Leo was saying is that a lot of Lot of people do think that is like, oh, no, like I I have a backup in get Right in thinking they're doing it like no, it's not it's not a backup per se in that aspect Right, it can function as a backup. It's like, no, it's not a reflection is actually what's in was it your actual state? and that's kind of one of the You know one of the things we saw and In maybe not necessarily an anti pattern There's there's some things I think they're still left up in the air that that came up that we kind of just maybe just brushed aside a little bit For this first go around because it's like, wow, this is a really complex problem, right? Like one of the problems is like secret management You know there is the I think there's the concept of You know encrypting your secret and then storing that In get because you don't never want to you know store that in in encoded But then is that an actual is that the actual state like technically like philosophically is that the actual state? And then there's some people that don't want to do that and to use something like a management system like vault is probably like the most Popular one. It's like well, then that's not you're not even storing even the encrypted version. You're storing a reference So then what's the source of truth there? So there's a lot of things that I think are still left up to discussion and And not necessarily anti patterns But some of the things that you have to take in consideration and I guess that goes all over for the other Conversation that's on get up between like weak get ops. Yeah, that's strong get ops is that there's there's some of these some of these things that May or may not fit into the paradigm. They're still up for discussion. Yeah, I would say the two one or two biggest anti patterns I see are people Who are like, oh, I'm totally on board for get ops and then I'll apply the changes and you're like whoa, that's it What? You're not you can't be the software agent You can't be the reconciler. That's checking that the actual state So that doesn't work and often I've had people and even today I had several people ask me They said well, what if what if I want to put something in get and I don't want it deployed and I was like, well, no, you said that you wanted it deployed when you put it at get That was the statement of intention. So if you don't want it deployed You probably shouldn't have stuck it in your main branch or you know, the branch that's that you've declared as your desired state You need to have the checks on the pull request or before that So that you're not applying something as your desired state and desired state is is also a little bit of a meta Concept too because you can do something like say my desired state is to deploy this blue container and To check to see if it meets these metrics and if it doesn't meet these metrics I want the yellow container that was there before to be deployed and that's sort of if you think about it That is a desired state if you're doing that as a declaration It is your declared state But even though there is sort of this meta element to it of Essentially decision where you're checking a metric and checking back You have another one. Yeah, there's a death question has a whole bunch of votes on it now So I want to make sure we get to it a couple of years ago There were efforts to merge flux and Argo CD, but they were shelled Does the working group have any plans to revisit that and why or why not? So within the working group red hat and code fresh I think represent Argo as maintainers and Leo with from we've works is representing flux There actually hasn't been discussions within the working group of should there be a single tool I think as a standard we said a standard should be tool agnostic and it should be something that flux is Compliant with and Argo CD is compliant with and potentially infrastructure can be compliant with or other tools can be compliant with Yeah, I think I think as a working group and as an open source community There's there's a lot of value in diversity, right? And there's a lot of value in in different approaches to solving Similar problems, so we have not discussed I mean and really it's not our position We have nothing directly to do with other than then kind of representing our different tools To make that type of decisions within the working group But I think what we have discussed is by defining these principles and eventually working on on Programs that we can use to determine the level of conformance of different applications Matter of fact is support the ecosystem so that it's not just going to be two tools out there there's going to be numerous evolving over time and What we what we want to accomplish is provide a solid foundation that will Support those future development teams in understanding how to how to apply these principles which is which I'll agree Yeah, I think it's all about doing Something's conformant or not But Thank you, and I think it's It's more to do with You know having something be compliant, right? Like oh, yeah, Argo is compliant flux is is compliant or you the next great tool is compliant because they conform to the To the tools and we're less The reason I like the working group is we're more about the process and more about like the ideals Versus, you know the hammer right like we were more about you know building something versus focusing on the tool so Yeah, and you know what these are open source. So if you want to write a connector for the Argo CD UI to a flux agent You know the pride I don't think the projects have that on their roadmap And there's not really an intention that I've heard of to do that within either project, but Hey, it's open source. So you can go and do that and you could throw it up and Argo CD also has like an extensions library So you could add in a UI element for flagger and there are people that use flagger with Argo CD. So it's certainly I Would say like not something that I've I think the projects are taking up and it's not necessarily something that The get-ups working group is really take putting an intention around but as a community Not our code so, you know, you can do what you want Those are both CNCF projects, of course They're both incubating projects. So and remember we we're not king makers in the CNCF Let's see and then yeah, Lisa you want to take it. Yeah, shoot one more question so I work with a lot of mid-sized large-size enterprises and We can implement get-ups and it works great from a technology perspective But then there's always the like the old-school ITIL, you know, they want to do releases They want to know what's happening when it's happening all those things you have any recommendations on how to bridge the gap between this, you know very fast-paced You know excellent technology and then the business side of hey, they want to know what's going on Hmm, who wants to make money is what I heard No, but you know like I think if you think about ITIL right and you think about change management For example, I think get is a phenomenal interface to that has changed management mechanisms built in right? You have full traceability you have auditability you have pull requests that effectively are the interface for you to request the change And I think this very same conversation or similar conversation happened as organizations were adopting DevOps, right? Can DevOps and the organization of kind of fast feedback cycles and constant continuous improvement? live in a world of very kind of Predetermined processes as ITIL does right and and I think the it's it's it's it's been done right, it's a matter of understanding how these different patterns apply to satisfy those requirements, and and I think it's it's a matter of of education and kind of thinking a little bit outside of the usual realm of of Technology right you can use get as your interface and and you can satisfy all those different checklists with Yeah, pattern such as I'd love to just add one thing and it's a really kind of Pragmatic, I think tip that I would give you and it's not specific to get ops But when it comes to any of these major transformations that happened within an enterprise One technique that I've seen that works really well is you've established that get ops practice Invite your compliance and your security folks in say we are going to do a deploy today Clear your calendar. We are going to step we're gonna show you exactly what's going on and The cool thing is I've seen it happen in the past where you take an entire today Day to do the equivalent of a get commit right and you step them through and you show them everything that's gonna happen And then the next day you say we're gonna do another deploy and you have explained the whole thing and you do the get Commit and you show them that nobody can go in and muck with the version history And so it's that it's this brilliant like moment of oh my gosh We just spent a whole day doing something and you just showed me how all of these gates are all of these things are Implemented into the system and now we just did the same exercise we did yesterday in eight hours We're doing it in two minutes and you've shown me How my requirements are satisfied? That's a very it just invite them to the party. Don't fight him invite him to the party Can we get a Mike? Yeah battery change for a Christian so um I One of the things I always say is that automation doesn't have to be scary Right, so a lot a lot of people think that like automation equals insecure and that's like not at all not at all true and You know the the process is more important than how fast it happens, right? So if it's if it's secure if it's Thanks, and if it's If they know what the process is and like we're kind of just feeding off of cornelia was saying is Invite them to know to see that process and see that it's really not Scary right so automation doesn't have to be scary Yeah, this kind of reminds me of we had some people asking yesterday And I don't want to belittle this question But someone was saying well, how do you how can you adopt get ops if you know that get could potentially go down? And if your git availability isn't 100% but you needed to make a change when git wasn't available What would you do and I thought well, that's a good, you know, that's like a disaster recovery scenario that you should probably plan for but It was brought up as an impediment to adopting get ops and I thought okay, so let's let's play it the other way You're not doing get ops and your process is what? someone logging onto the server and applying it or And then if if it's in bounds to say what if git is down then it's in bounds to say what if that person is out sick What if this person is on vacation like? You're establishing this process and to Cornelius point when you actually see it in action and people are like Oh, is there really any visibility into this? It's like it's kid like there's like nothing but visibility into this like Like it's really clear like the chain of custody is clear and chain of custody. Oh My gosh is that ever important when it comes to delivering software and How many time there are so many places especially in the past where that chain of custody has not been clear And it leads companies into situations where they're shipping vulnerabilities Where there's code that they don't know what's running on production They have no idea and it's a very very scary place to be so giving that chain of custody with get with get ops Is super powerful and you know just kind of a side note That Cornelia was referring to right get cannot be down get this distributed and there's a bunch of copies get hub Maybe down get lab maybe down. So that's kind of also very important to understand as to why get ups is so Relevant and valuable right because the source of truth can live beyond The provider that has given access to it, right? So I think that's that's important. Yeah I think we have one more question here is the online is I think they want the next question We're running a little bit over but are we over time? Oh, I didn't realize I'm sorry online That's one isn't in this room until 430. So you're good But you still want to ask your question if you need to go to another session. We won't be offended But if you leave in two minutes, I will be I'm saying that was your chance Now that you have like version one What's your roadmap? What are you working on for version 1.1 version 2? Yeah, there's there's a lot of things Kind of in the works there are some additional updates to the principles and the glossary that are in discussion But one of the things we want to start working on our best practices Which we've envisioned sort of taking the form of like white papers or things like that where you can say what is an implementation of get ops look like using XYZ tools and we envisioned this Install it still in the works in discussion, but this idea that I want to go and look and see if I want to use AWS or if I want to use Azure and I want to use This tool or that tool the other tool has somebody made a reference architecture for this for how they've done get ops And and we can say you can submit it and you can basically say like this thing is get ops compliant it meets all these standards and You know allow the community to start contributing those and bringing those into the to the four so that as more and more people use it We have a flywheel effect where more and more people aren't able to go and use it practically There's some other things too, I don't Think I think you summarized it well I think there's there's a lot that we have to identify in terms So we have this big conversation as to how does incident management work with get up, right? I think there's a lot of opportunity to think about How do we do incident management management? What happens when things don't work as expected, right? The the tooling that's being built around get ups is evolving So we really matter of fact is at this point. We really want to reach out There's I don't know how many interested parties that kind of expressed interest in the working group We want to reach out to all of them keep working with the hyperscalers and kind of increase the adoption of Get ups By the cloud providers and there's there's a lot of work Like as I mentioned like this is where we always use the tip of the iceberg and and we really want to encourage community involvement To produce all this artifacts, right that that are gonna move move the paradigm forward Let's think we have another question ready Sure, thank you One of the differences between maybe continuous delivery and continuous deployment is Manual approval steps and oftentimes you need, you know a sophisticated amount of frog Need to be somewhat sophisticated to have that continuous deployment canary deployments things like sandbox environment So you can do UAT on Things before you merge them Is there a place for manual approval steps and get off? So I've done a little work around this There's definitely a place for it right and I think I think an early version of the principle said that We it's at something and I may be butchering us. I'm sorry We've done so many iterations that the the the versioning it can be mutated either by a human or a machine, right? Or something to that to that effect, right? And so this Something that's writing to get doesn't necessarily have to be a human, right? It can be part of the CI process right something as simple as Running a JQ right on or or YQ on on a YAML file that when you update, you know an image, right? I'm sure there's tools out there that I'll make up the image, but I'm choosing a simple example That can be and then that does a pull request for you, right? So like there's an automated process that That that's the stop gap, right that someone the human needs to actually go and click merge To actually happen, but what does the pull request doesn't necessarily have to be a human it can be a process it could be Some things like that. So there is there is ways of doing things right that that are so conformant to the To the principles themselves, so I don't know if anyone else had Yeah, there there are quite a few ways you could cut that mustard Doing an approval through like a get PR and that having your approval gates happen in that moment Doing if you have like a metastate like a canary release that's occurring Well, there it's open-ended what metrics you could put on there and you could potentially have a manual intervention saying oh No, we caught a problem. We want to we want to no longer have this move forward So there and there's maybe a little bit more Fuzziness within that, but I definitely think that there is and actually to take take it another way Get ops is a set as a set of principles to things to implement If you feel like you're 90% that's certainly better than being 50% so even if you implemented everything and then you had like a really hard stop approval process that Maybe was not in process was a stepping stone like We're not gonna get you in trouble, you know, if you have police is gonna come yeah We're gonna get up police won't come and be like hey that thing actually isn't there now. I think we should strive for it I mean we put these principles together because we strive for them, but I think that to your point I think there are lots of ways you could potentially implement approvals in a very get-ups friendly way There are some less get-ups friendly ways. You could implement approvals as well that fair Okay, I think that's probably all the time we have because we're gonna need to give the room to the next people There was some online questions that didn't get answered. And so will you do you mind jumping in the chat? Yeah, you bet. Okay. I saved the question. I'll let you know what they are Thank you everyone