 All right, good morning, everyone. Hello, welcome. Welcome, welcome, welcome to GitOpsCon North America 2022. This is, I think, our third one, fourth one. Third one in person. Second one in North America. So the first one was in LA. So I'm glad to see this grow. It's always great to see all everyone's faces in 3D as Scott says. So we're going to kick things off just like a few of the logistical things. The breakout rooms for the second track. So there's two tracks. If you are either speaking or wanting to attend a track in the second track, it's actually down the hall in 251. There'll be someone there in the front in rooms ABC. So 251 ABC, it's literally down the hall a few steps down that way so you don't have to travel far. Restrooms, I don't know where they are. I believe they're back there. Yeah, anyone know? Yes, yes, so they're back there. And coffee, refreshments, all of that is just outside. If you didn't get a drink ticket or a food ticket, the lovely ladies outside will have that for you. They're the ones that give you the wristband. So if you didn't get one, make sure you grab that so that way you can get lunch. So I believe with that we can just kick it off, right? Yeah, absolutely. Let me advance these slides. So I'm Scott Rigby. I work at Weaveworks as a developer experience engineer. I am one of the co-chairs of the Get Ups working group and amongst a good group of maintainers from across multiple organizations for open Get Ups. And I'm also, I do other things in the CNC ecosystem. I co-maintain the flux community and I co-maintain the Helm project and a few other things. So that's me. Yes, my name's Christian Hernandez. I'm a product manager at Red Hat. I am a maintainer of open Get Ups in the Get Ups working group. I'm also involved in other things in the CNCF, but mainly in the Argo project, right, ecosystem contributor there. And yeah, all around Get Ups guy. As you see, I'm wearing the shirt today, so. Oh, shamed. Shamed, that's right. We should have coordinated. So, you go ahead, I'll do the next one. Oh yeah, so okay, so we're thanking our sponsors, right? So thank you, Red Hat, for being a diamond sponsor. Super awesome, or being the diamond sponsor for this. Super awesome, appreciate you. Yeah, and thank you to AWS, who's a platinum sponsor for this event. Okay, so about the Get Ups working group and Open Get Ups. A bunch of you may know, but I'll give just a brief intro for those that don't. The Get Ups working group is a working group, a CNCF working group under the App Delivery Technical Advisory Group. We've been doing this for some years now, and it's, there's a really good gang of folks. Actually, raise your hand if you've joined Get Ups working group meetings or a part of the Get Ups working group. Yeah, so we have a good representation of people here in person from the group. So, obviously, when we have coffee breaks and stuff, please feel free to connect with each other on that, and we'll also show you how to get involved. The working group has guided the Open Get Ups project, and still guides the Open Get Ups project, which is a CNCF sandbox project. I think as most people know, there's sandbox incubating and graduating projects within CNCF. Open Get Ups is that, and the Open Get Ups project is meant to be the place where we hold all persisting things that relate to Get Ups. Documents, any certifications that are forthcoming programs and events and stuff go through the Open Get Ups project. Yeah, so I actually just said some of this, but yeah, so right, the main premise of the working group is to clearly define a vendor-neutral, principle-led definition of Get Ups, and we'll go over the Get Ups principles in just a bit. And as I said about the Sandbox project, yes, it holds those things. It also, the documents right now contain the CNCF, sorry, contain the principles and the glossary specifically for Get Ups. Also giving a shout out to the general CNCF glossary that is at glossary.cncf.io. For folks that are interested in the definition of Get Ups there, we are still working on it. We have, it was a relatively recent invite, so if you are interested, there's an open pull request and we'll send that to you. We'll make sure that that's in the links and we'll make sure that's in the presentation when we upload this. But the point of that is it's supposed to be readable by someone who has really no domain knowledge about this whatsoever. So let's say someone in upper level management of a company that is a person that's not really in the weeds with the technical stuff. So yeah, if you're interested in that, please let us know. Which is difficult by the way. Yeah, which is kind of. To try to explain it to non-technical people. Yeah, yeah. So that pull request is still open and yeah, we invite everyone to chime in. Yep. And yeah, go to opengetups.dev please to see information about Get Ups. We've got the principles, the contributors, and then copies of all of the documents that I just mentioned. Events as well. So yeah, now we're gonna go over how Get Ups relate to other tech practices. By the way, thank you William, who's here. There he is. Yeah, shout out to William. Shout out to William, because he's the one that helped out with mapping the Get Ups principles, right, which we hope most of you are familiar with to practices in tech. So basically, moderating, mapping those practices to the Get Ups principles, so that try to resonate in more with you folks out there. So I guess I'll kick it off, right? So the first principle is that it's declarative. I'm actually just gonna do what I don't like to do and read off the slide, but it's a system managed by Get Ups must have his desired state expressed declaratively, right? And so this kind of matches things like configuration as code, we have infrastructure as code. This is like DevOps, DevSecOps, right? This is kind of like the cornerstone of these practices and also Get Ups, right? Get Ups also uses that declarative model for managing a system, so. Yeah, basically, soup to nuts is the ideal thing where you've got not only your infrastructure, but your networking and your policies and then also all the applications that run on that. Pretty much anything that's required to reproduce a system, your system exactly the way you want it or exactly the way it was if there was, say, a disaster or just for replication purposes, multi-cloud, et cetera. Yeah, so then do you wanna keep? Yeah, so the second one is version and immutable, right? So the desired, again, the desired state is stored in a way that enforces immutability, versioning, and retains a complete version history. And then I always like to point out that notice we didn't say Get even though it's called Get Ups, right? So we try to make these as generic as possible so that way it can be applied broadly. And so, for instance, like an S3 storage meets all those requirements, right? So you don't necessarily have to put it in Get. You know, we each may have our opinion, but it doesn't necessarily have to be there, right? And this really maps to the infrastructure as code aspect of it, you know, DevOps, DevSecOps, right? It uses that version and immutable aspect of it and get ops to those as well. OCI. Yeah, OCI, yes, yeah. Yeah. Yeah. Yes, and also notice that this is just a screenshot of our website with these little practices mapped stuck on under each principle. So please do go to the website for anyone who hasn't already, you know, gone into the principles and the glossary because these little yellow notes like say stored and so on, they link to glossary definitions. The glossary terms, yeah. Yeah, that gives like other important pieces of information about what is meant by that. Cool, so the next one is it's pulled automatically. So software agents automatically pull the desired state, decorations from the source. I always like to add here the word pulled kind of trips people up a little bit. We don't mean like as in pull and push as in like the configurations, right? Like we mean as in your declarations, right? The decorations are pulled from a source. How you apply them, whether it's in a push or pull method that's we don't have a strong opinion on that. But we do have a strong opinion on how you get those decorations and those declarations are pulled really. And it's really to differentiate them from like web hooks, right? So from you know, you know, classic CI CD sort of web hooks kind of, you know, I hit a web hook and then something happens. No, like this, it automatically pulls that information, right? And this is maps to like, you know, dev ops and desec ops and get ops as well. Practices where things are pulled from that decoration automatically and it's done via some sort of software agent. Yeah, this is a super important point here because, you know, like usually when you're going through the principles with folks that are already really involved in technical practices and dev ops practices and so on, we start describing that everything must be declared if they're like, okay, infrastructure is code, cool, cool, I'm doing that, right? It's version and immutable, okay, we've got our stuff and get, cool. And you know, pretty much after that is where it starts to diverge, I think, as a community because, or not as a community, but yeah, like with various practices and where traditional CI CD really, the point of this that Christian was mentioning, I think is that like event driven things are great. Things happen faster, it's awesome. With get, get ops, you can still have event events that make your reconciliation go faster, give a little message and say, hey, I did something and then get ops and we'll say, oh, cool, I'm gonna go and fetch that. But the reason that it needs to be pulled is because of this next principle, which, you know, you can't really have the system self-heal on you or self-heal for you when divergence happens that has nothing to do with something that you didn't get, you know? So like divergence can happen because there was a networking issue or there was a bad actor in your system or all kinds of things. And if your system is only relying on your developers to do something before CD happens, like deployment happens or the reconciliation for that deployment, then you will still have drift. Yeah, and like Scott said, they kind of like build on each other because then it leads to this next principle, right? And I'd like to actually mention the practice before the actual, so this is the one that kind of like differentiates a little bit, like I guess our crown jewel, I would imagine, what differentiates someone like doing get ops versus doing like traditional CICD is that it's continuously reconciled as Scott was mentioned, right? So software agents continuously observe the actual system state and then attempts to reconcile it with a desired state. And so that's kind of the main point of get ops, right? And that's kind of like that practice is like, okay, like if you're doing all of these, yes, you're doing DevSecOps, yes, you're doing DevOps, you're doing infrastructure as code, like all of this is all related. And at the very end, but is it continuously reconciled, right? Is it continuously going? Is continuously monitoring your system? It's also the aspect of observability as well. Is like, do I need to do something to the system? I think that also is an aspect of the continuously reconciled. I'm getting maybe a little bit too specific there, but just generically speaking, system managed by get ops is continuously reconciled. Yeah, I think that's right. Where we say like literally the software agents attempt to apply the desired state, that attempt can be, most of the time you want it to be a closed loop, it's not in the principles because that's not required. You can make a cron job that just does kubectl apply. While true do kubectl apply. Right, sure, sure. It wouldn't be a very intelligent one. It wouldn't really be able to respond to any feedback or previous attempts, but you could do that. So however, during that attempt, various actions are made by those software agents on behalf of you to like say alert undivergence to, do you think this is very similar to Kubernetes for let's say back off options and so on. There are different like ways to make your agents more intelligent and the main tools that are out there to do this, do that, yeah. Cool, yeah. And no, I think you put that out beautifully. Yes. Cool, yes, announcements, these are awesome. These are cool things are happening, right? So first, I'd like to say we have new maintainers, right? This is actually was a process, but we actually got a lot of people who have been attending regularly and helping out with the project. So we decided to expand the maintainer list to include more maintainers. So sorry if I butcher some of these names, Jamie Magera, who was actually here at KubeCon, but he's actually doing Openship Commons. He's from the University of Michigan. He's a new maintainer. Nicholas Metke, I think someone who's German can tell me how to pronounce that, who is actually, I believe he runs his own consulting firm. So he maintains actually a lot of the website stuff. He's doing a lot of automation with the website. So he's been helping out a lot. Robert Strand, who's been involved since the beginning. So it was only natural for him to become a maintainer. And William as well, as we mentioned, William Kaman from Red Hat, he's also been contributing a lot, especially around like sustainability and stuff like we'll talk about in a little bit. So, and then we have, yeah, that's for the new maintainers. Yeah, thanks to our previous maintainers that are no longer here, who are listed here. Chris Sanders, Chris Patterson, Jesse Butler, and Nate Tabor. Thank you very much. Thank you very much. For your service. Thank you for your service, yes. Yeah, maybe I'll mention the updated governance real quick. So another thing that- Which explains the graphic, by the way, so. Okay, yes. So the governance for open GitOps has changed from there being a top level maintainer status for co-chairs for the GitOps working group to the maintainers of open GitOps. So that's just a good new thing. If you don't know anything about that, then you'll be like, cool. But if you do, it's kind of nice because it helps things move a little bit more smoothly, procedurally. So essentially, the power now resides with the maintainers now, whereas before a lot of the power was with the co-chairs, I guess for bootstrapping purposes, but now that the governance has been updated, approved, that PR was approved, it was awesome. Now the top level is the maintainers, so. Yeah, just go to open-github.com, getups.org, projects repo, and then there's a governance file that explains basic voting things. And also how you can get involved too, and we'll explain that too. Yeah, and then yeah, so we're growing, as Scott mentioned, right? Like how you can get involved and do things. There is, we're growing to the point where folks from the working group are forming subgroups, right? That have to do with GitOps. So for example, as I mentioned earlier, sustainability, that's something I know that William and Nicholas has been really interested in it in starting that subgroup of sustainability around GitOps and how can GitOps help sustainability. Yeah, and there's a session for that coming up today. Yes, yes, and there's a session about that. And also like AIML, right? So like how does GitOps fit into AIML workloads, right? I believe that there's been a lot of work already done with that, but now like the subgroup has started for people who are interested in that as well. Also subgroups, there's, I guess, by the fact of my subgroup, right? For the events, for things like this, right? Where we're also talking about like other kind of more open forum type of events, right? Where we've been kind of toying with, right? So that way maybe we'll have some of these meetings maybe more often and more of a bird of a feather type of events, smaller, more frequent. But anyway, you know, that's... Yeah, and if any of you like marketing, there's a marketing of people that help with things like the social media, like Dan's doing right now. There's also a subgroup that should give a shout out or mention that is about fact-checking for GitOps because there's a lot of, as you probably all know, that's become kind of a buzzword, right? And it can be, there are very agreed upon principles now that are agreed upon by representatives from pretty much the entire community. However, there's still a lot of marketing out there that will say, we're doing something on GitOps but it really doesn't adhere to the GitOps principles at all. So this fact-checking group is really just a helper group. Not like to call people out, like policing them, but just a helper group to say, oh, you know, you all may not have known that these principles were released by CNCF and the Linux Foundation and agreed upon by all these other people, et cetera. And please join us, you know, and let's help you with getting that information out there so that you can spread accurate information. So if anyone wants to be part of that, that's a really important piece because this has to do with how CNCF relates to the wider tech community. Cool, yeah. Events, so we, there's been some events centered around GitOps, right? One of them being ArgoCon, ArgoCon 2022 happened. It happened in the Mountain Euphoria in the Computer Science Museum there. So if you've ever been in the Bay Area, you know where that is. And it was the second ArgoCon but the first time in person. So that was pretty cool. I was there. And it was a great event that happened, right? And that's members from the GitOps Working Group also did ArgoCon. And then also GitOps Day happened, right? Mm-hmm, yep. Yeah, GitOps Day's focusing on flux happened. It was really great. Yeah, check out the videos from both of those events, for sure. And I'm gonna try to speed us up a little bit because we just hit the 930 mark but we still have a few more minutes before the next talk, so. I just like the DJ desired state you guys had there. That was pretty cool. I like that name. And yeah, we're planning GitOpsCon for Amsterdam currently. So we're looking for sponsors, right? So we're always looking for sponsors. They help out a lot. They help out to put in this event. So either ask me or Scott if you're interested in sponsoring the next event. So, cool. So next one. So what's next, right? Looking at the horizon, right? As Scott said, fact-checking, right? We need kind of folks to help out, not only like to actually doing the fact-checking but like to develop a code of conduct or I'm trying to find the right phrasing but like kind of like a guidance of like how to approach certain people that are using it more like a marketing term versus an actual thing. And we have an issue to help guide folks to that as well. Conformance and certification, right? So we kind of, we need help around creating like certified open GitOps, right? Or like, for example, like Flux is certified for open GitOps, right? And so we kind of want to start doing that with the working group as well. And then also helping out with trying to do create issues from PRs and vice versa, right? So like if there's, there might be a lot of issues but not a lot of PRs and try to like fix that ratio a little bit. So things like, you know, best practices, white papers, green papers we even talked about, blogs, right? All of that is stuff that we invite all of you to contribute to as well, right? So don't feel that, you know, you have to be a maintainer or always presence, right? Like we can do things asynchronously. That's what Git's for. That's right, and the website's just, it's just pull request based. So we can discuss it in Slack, we can discuss it on the meetings, open an issue or a discussion topic if you have them and want to do that. Otherwise just set pen to paper, you know? Yes. Yeah, collaborate or do it solo. Also under the certification side, I just wanted to mention that we are working with the CD Foundation to basically Linux Foundation is offering a, or creating a course on GitOps. And so the GitOps Working Group and Open GitOps Project from CNCF is working with CD Foundation to do that. So if you're interested in finding out more about that, I mean, we'll be announcing it as it's coming closer, but if for anyone interested in getting involved with that even potentially, let us know. I believe it's it, yeah? The more, get involved, the more the merrier. Yeah, you know where to find us, right? We can join a meeting, join a subgroup, get involved with us. You can go to the website. It's probably the best place to start because that's where all our links are there. Yeah, there's a good group of folks that show up including the two of us and several people from the audience here. So yeah, really we've got a lot of great talks coming up greater than the one that we just gave. And you know, like we're excited in both rooms. So obviously feel free to go back and forth between the two, check out Sketch and we'll be just giving you like a little, we'll be coming up and announcing people as they go. One thing about if you're a speaker for anyone that's in the audience that's a speaker already or speakers that are already here, just please see Daniel in the back before you start speaking and he'll help to give you one of these little packs and wire you up. Thank you. Cool. All right.