 I'm Tomash and I'm product owner for Peket project and here we have Brian, the lead of the Centos project or like, actually Brian, can you introduce yourself? Sure. Yeah, my name is Brian Stinson. I'm the technical lead for the Centos stream team. We work in the community platform engineering group here at Red Hat. So Tomash, I think you're going to start us off with talking a little bit about containers and all that stuff and then we'll go back and forth. We'll have a few different interesting ways that you can consume Centos stream. Yeah. Okay, I'm going to share my screen and before I do that, so if you want to participate yourselves, Jen posted links to the content of the workshop and also to, like a two way how you can download your either PM images or container images and it would be great if you did it right now. For example, for me, it took me like five minutes to download the vagrant boxes. So if you want to participate, please download them now. Thank you, Jen. And I'm going to share my screen right now. And here you can see my terminal in the, to the, like, upper side, the I'll have my notes. And I hope that it's not too disrupting. And on the bottom side, that's where I'll be running my commands. So, one of the ways you can actually consume Centos stream is via container images. And I hope that I don't need to introduce what container images are, since we're in DevConf and this is a hot topic past five years, I would say. The container images for Centos stream I hosted at quay.io in the Centos namespace. You can see the link right over here. They're available in three architectures, the normal MD64, which is probably what your laptop has. And the additional ones are ARM64 and PowerPC64, a little MDN. And obviously I'm going to be using the one for Intel, because I don't have the other hardware. I have a Raspberry Pi, but it's still 32 bits, so. Okay, so let's, let's pull the image and I already did that. And so it will be very quick. Actually, if you're familiar with Podman, and this is something with Karl mentioned to me when we were preparing this workshop, there's a feature in Podman 3.0 called short names. So when you are in, when you are using Podman 3, you can actually just do full Centos stream 8, and it will work, it will figure out that the home for the Centos image is quay. So that's going to be even shorter. So now we have our image here, I have it on my laptop, and I can invoke it and try it out. So let's do that. I'm doing dash, dash, dash RM, so that it's just like a throwaway container that I don't want it to linger on my host and TI are so that we can actually run bash inside. And that's it. I'm running Centos stream right now on my federal laptop. And let's see if that's actually a reality. I'm going to scroll and look at what's inside, let's see, release, and you can see that this is in this, in this Centos stream 8. And for me, this is actually a really great way to try different like operating systems or versions, or I usually do this. So when I, when I want to see like what version of a package is in this certain like Centos stream or federated to. So for me this is super convenient way to do it. Also, it's a fresh environment. So if you need to like I know like test something or try something you can get fresh environment like this very easily and it's super productive for me. One thing you can do right now is you can install packages or you can just update it because like the images and the composites or like packages have different lives. So if I run the update there is possibility that there will be some updates. So you can do that if you want. You can see that metadata has been downloaded like the usual stuff. So one thing you could also notice is that I was using, okay, let's do this right now. I'm going to quit it. And one final thing I wanted to mention about container images and that is that I was using the stream 8 as like the tag of the image. And it's actually important to distinguish because you, I could have just done this, like without the eight, and I would still, it will still work. But since we'll have sent us to nine soon, like, I wouldn't know what exactly is inside so it's very good practice to actually, like, pick the actual version so that you are not surprised that suddenly there are different versions of things and your software breaks, like always into a specific version so that you know what's exactly inside. And that's actually how you can run center stream in containers. I'll hand it over to Brian. So you should have a cockpit window and a terminal here on your screen. Hopefully you can see that the, I think the next topic that we wanted to talk about is, what do you do if you have a sent us Linux 8 machine, but you want to try out sent us stream. I think one of the, one of the important goals that we had, you know, dealing with with all the things going on in the stream world right now was, we wanted to make it. We wanted to make it pretty simple to take an existing sent us Linux 8 machine and just migrated over to stream and start, you know, getting regular updates. And so, I think Jen posted in the chat there, a link to our GitHub, the, that's some of the materials that we're using for this workshop today. In that, in that folder there, you should find a vagrant sent us Linux upgrade. Directory, that's kind of vagrant file that will take you from it'll start you from a sent us Linux machine and then we can sort of walk through the steps here. Really, like I said, we wanted to make it as easy as possible. So right now it's, it's actually three steps. There's three commands to run to take a Linux machine upgraded to stream in the future. We're kind of moving around some of the packages and where they live in all of the different repos. We were hoping to get that down to just two steps at the end. So you can see here on the screen I've got my vagrant boxes up. So I just need to run in and SSH into it. So if you run into that, if you're doing this at on your workstation at home in that directory just hit vagrant up and you'll get to to this stage right here. So to talk a little bit about how this works. You know, every operating system has two different release packages. So there's one that specifies sent us Linux one that specifies sent us stream. And then there's a set of repositories that the basically tell your system, you know, which how to grab the content for each of those things. And that's what we're going to swap up here. In order to get access to some of these, these repo packages, we're going to run this command, we're going to sudo dnf install sent us release stream. And that's just the this is the step that we're, you know, trying to eliminate in the future we're trying to get some some things in place so you don't have to do this but this will get you access to the repos packages. And so if you do that, in the world of live demos where you know this always takes longer than you than it did when you practice, you should come up with, you know, just one package that gets added here downloaded. Yes, we accept the keys. And we're good. So even the in the GitHub as well the the second and third steps are there, we need to run a DNF swap. And what that's going to do is it's going to take the, like I said the repos package that points your system at CentOS Linux swaps it out for a repos package that points you at sent us stream content. So that is sudo DNF swap. And again, it's going to do a little bit of magic here to find all of those packages. And then it's going to tell us that we're, you know swapping these things out and doing a little bit of a work behind the scenes to get the right sent us release packages in place. So if you do that, basically what we did was just dropped a whole bunch of young repositories and you can look and see what we did in at see young dot repos dot D. That's where this stuff lives and you can see the listing here. Those are all repo files pointing directly at the sent us stream repositories. We haven't quite yet migrated because we just told our system where to look. So the migration is the final step here. So sudo DNF distro sync. And that does a couple of things. It does a lot of dependency solving and things to make sure that you have the right versions of the packages as they exist in all of those repos that we looked at. And if you look at this, once we actually grab the metadata and do the solving, there's a whole bunch of packages that it's going to download. And so it looks like we have, you know, eight new package, eight new packages 184 packages to upgrade. And then once he hit yes, it's going to download all those. And yeah, especially, especially while this stuff is running, like Tomas said in the chat, feel free to ask questions, post them in the chat and we'll we'll handle those, especially while we're looking at a little bit of install time here. Ask a question in the meantime. So you said that you're trying to trim it to just two commands. So I'm assuming you are eliminating the first one. That's right. That's right. So that first command. Basically what that does is it gets you access to both sent us Linux repos and sent us stream repos. It tells you where to get get those in both locations. We're trying to ship those repo files repo packages a little bit differently so that you don't need that that first step there. You know, if you're following along waiting for, for that to show up, we'll definitely be announcing that on the sent us develop mailing lists, updating our documentation and all that stuff whenever we're ready to drop that down to two steps instead of three. So while this is running actually will maybe come back to this. Because I think this may take a little bit, a little bit more time to run. I'm sure it's if you're following along at home it's still running on your system to what I want to talk a little bit about some of the other the other ways that you can consume sent us stream in various environments because you know we had talked about doing it in containers. We got a little peek right here at the vagrant boxes because that's you know we are publishing them for sent us Linux but I want to talk a little bit about some of the cloud properties that you might want to use sent us stream in and the first one we can talk a little bit here about AWS and there's a page out on the wiki. You can check it out it's wiki.santos.org slash cloud slash AWS and again all of these links are in our our GitHub repo there. This describes a little bit about you know all of the Amazon machine images that we produce as part of our build and deliver process and there's you know a lot of good documentation in here. If you've got your own EC2 namespace configured setup you've got you know all of your private connections and our private clouds and all that stuff. You can actually pull this this in we automatically keep this page up to date whenever we see new machine images into AWS. And so if you scroll down a little bit on that page you'll see again this is a whole bunch of stream eight images seated into each of the Amazon regions and so like let's you know if you do most of your work in US East one then you have a machine ID attached to that that will will be best to spin up in that in that zone. And even on you know down towards the towards the bottom of the list you can even see we have some Eric 64. If you want to use some of the fancy AWS hardware. So let's go back and check on our vagrant install looks like it's still running, which is fine. The other thing that we that we also like to show off a little bit is all of these artifacts that we work with you know whether we're seeing them into AWS. Or you know if you come up across you know another cloud that you know maybe we haven't put images in ourself. We don't have official images you know posted to to Google Compute Engine or you know any of those places, but you do have the ability to go out and look at our. Sorry, this is the wrong. We'll get to the right place here. So cloud that sent us.org is where you can go to see if you can get other images for other places. And we publish these on a on a regular basis. They do have a little bit of a different life cycle than you know some of the composers they don't get generated every day, but but they do come out fairly frequently. The under the eight stream directory, you can see some of the ones that we publish, and we've got images for air 64 power PC and x86 64. And so we're going to drill down into this directory a little bit. And you know, hint for what's coming again, you can see we've got vagrant boxes for a few different versions here. This is this one right here. The send us stream EC2 image is the one that we're going to take a look at here in just a minute about spinning that up, you know directly in in AWS. That's the one that gets translated into each of those am is for each of the regions. So then there's this generic cloud image. And that's pretty useful for a couple of different uses. I actually use it sometimes on my workstation when I want to bring up a VM really quick. It's also really useful if, you know, you have a fairly standard cloud provider, you can, you know, try uploading this image, do your thing with cloud in it and, you know, a lot of times at all. It'll just work in your, your cloud namespace there. So cloud.centos.org is a good is a really good place to go and check out if you want to end up getting some images to deploy in other places. So what we're waiting a little bit more before we move on to AWS. Is anyone following along at home anyone else have their, their vagrant setup migrated yet looks like we're just about finished. So Brian, in the meantime, we got several questions. Yeah, and the first ones from Steven Gallagher and he's asking for people who are not working for redhead how they can contribute new features to stream eight or stream nine. That's, yeah, that's a really good question. So, and I think we'll get, we'll get into some details here in just a minute. So we know for sure. And this is, you know, talking a little bit about build processes and, and how we get things done in the, in the project. We know sent us stream eight, you can think of it built, you know, sort of, we call it inside out. And what we mean by that is, if you know how sent us stream works in relation to rel, it's meant to be a development location that represents content that's coming in a, you know, upcoming minor release of redhead enterprise Linux. So stream eight, it's, it's consumable, you can see it, you know, here in the artifacts that you have really, this is not the contribution workflow that we're, we're stuck with. This is not the contribution workflow that we're doing that we're looking at long term, because really we get source code, build it, and then, you know, outcomes the, these different artifacts that we have. And I'll talk a little bit about the things that you can do. You know, here in just a few minutes we'll, we'll go over what you can, you know, some of the things you can do with your, your fancy sent us to me machine that you have either migrated to or, or upgraded from. But, again, to the, to the point there, the intention is for sent us stream nine, the, all the package sources, and even, you know, if the Thomas you can chime in here a little bit about source kit but those are going to be directly contributable by the public. So the intention is you'll have there will be a names facing get lab point at the sent us stream repose or the sent us stream get repositories, you can make merge requests against those. And the role maintainers consider them and, you know, make sure it's it's right for the next minor release of redhead enterprise Linux. But that's a big shift. You know, both in terms of the work that we have to do to get the workflow up and running but also making rel development happen out in the public. And so that's a, that's a big deal about what we're looking for. I personally can't wait for like when we open the gates with get lab and everyone will be able to contribute, especially when all these repose will be set like hooked up with CI, so that whatever you contribute to we will run all the tests on your contributions to make sure that they are not breaking like the rest of the distribution or that the change is actually working is going to be super awesome. Yeah, and I think that the key point there that you you mentioned to is, it is really nice to treat tests, just like we do other code, because that's a that's a really good contribution point to some. Did we have other questions in. Oh, yeah, we have a lot of work is very active with the questions. So, I'll have to read his question, because it's really complex. So, on this is asking sent a stream is assumed to be a real eight dot x right and are the builds revealed in the sentence info or are those real RPMs directly. Yeah, that's that's a really great question actually. So, those are they're built from the same sources, but they are built in different infrastructure so it's not. It's not directly the bits that you get if you're a red hat customer, you know, for consuming a rel. It is a two different builds and that's going to continue. You know, over industry nine, there's two separate build systems to separate compose systems, you know, they're separate that way, they do consume the same sources. So, you know, whether it's, you know, well first and then set a stream eight, or if it's sent a stream nine into rel nine in the future workflows separate build systems separate workflows. We can look at at one of those here real quick. So, co g dot inbox that sent us to work. This is our build system for sent us stream eight. And you can go out and sort of follow along about, you know what's coming through and look at the logs and and things like that. The, the rel build system is completely, you know, inside red hat and so it's not really necessarily consumable but that's what you can look at to follow along with sent us to me. And another question from honza is, if there is a way to see usage of sent to stream eight in comparison to sent to slinnux eight. Yeah, so the that's a that's a tricky question, especially because of the way that we actually deliver sent us stream and even sent us Linux and you know some of the previous releases. We've got a pretty complex mirror network, which means that anyone can go out and, you know, sync the content, put it on their mirror, and then make it available to, you know, 10s hundreds. So it's really hard to actually gather that sort of data I know there's, there's a little bit of work that that happened in recent versions of DNF that the Fedora project is using to help with, you know, some of that count, count metadata. But, you know, up up until this point we really haven't, like we don't keep that much in terms of logs on the mirror network and you know where you're actually downloading the content from so. Yeah, it's, it's a little bit hard to guess about about things like that. So, yeah, so we just finished up our, our vagrant install, and you can see here from the set house release file we've got set up stream eight, and we're all migrated. So, that is a great place to be let's take a look at AWS. So I'm going to copy in a snippet here and the snippet is in the notes on our GitHub repository, and then we'll talk through what's going on here. Maybe not that one. Got the wrong paste in here. Yeah. So I've got the, the AWS command line tools. And, you know, we just looked over at cloud.centus.org and saw the machine images that we did. And we looked at, if you remember we looked at this page right here that describes the AMI IDs. And we pulled the right one for the region that I'm working in. And it's really as simple as this, we're telling the AWS command line tools to use this image, give me one of them, a T2.micro sized instance and then I've got some extra variables that are set here in my environment to, to give my subnet ID, and we want to tell it to give us a public IP address. Simple as that. So once we run that, we've got a pending machine here. And I'm going to give you a peek into my AWS console. Let's reset this back to, it'll always take just a few minutes to spin up. So it looks like we might have another question while we're watching this on the screen. So, yeah, I was trying to answer it in chat in the meantime. So, the fourth question is from Richard Allway, and he's asking at which point we are removing the branding of Red Hat in the import process for stream or centers. Yeah, again, so this is going to be sort of a tale of two different workflows. So you've got the Stream 8 workflow and the Stream 9 workflow, and they're going to be, you know, just a little bit different. I'll talk a little bit about what we're doing for the Stream 8 workflow right now. And again, like I said, you know, builds happen in RHEL, we get the sources for them and then build, you know, then after that we build and send us Stream 8. And when I say build there, what I basically mean is we take the sources and if it's not already de-branded, we have some stuff that some packages that have rules that, you know, give you the commit that landed, the source code that landed in Red Hat Enterprise Linux, but then we layer on another commit that you make it a little bit easier for us to strip out branding and stuff like that. So, you know, there are some packages that do need a little bit of extra attention. And right now, folks on my team are handling that as they come in. So we just have a list of packages. One, you know, one really important one is Anaconda. We always put a few different patches in that that spec file and then build it for send us Stream 8. For send us Stream 9. And again, this is a sort of a preview of coming workflows. We're trying to get as much of that conditionalized as possible. So you could you have flags that you know if you're building in a sent us environment or if you're building in the Red Hat Enterprise Linux environment and I think there's a lot of work to be done on that side just to make sure that the branding flows in the right direction. I think there's there's always going to be some content that is, you know, never truly matched one to one between Red Hat Enterprise Linux and sent us stream on a on a branding level because we have things like our trademarks and logos and, you know, the index page if you visit Apache and all that stuff that's going to continue to be maintained, you know, separately from from the counterparts in in rel. So, yeah, back to EC2 I sort of stalled for a little bit because this always takes a little bit longer than you expect for machines to show up and be available. But so I've got a public IP address here. And the instance is running. So let's run back over here. And I'll give it my AWS SSH key. And you can look at sent us release we have sent us stream eight running in AWS. And then of course you can do all kinds of magic things with your own workflows and, and all of that stuff there's plenty to do here but the main thing that we wanted to show is it's super easy to get something running in EC2. And of course, anytime you do something with Amazon, you always want to make sure that you go back and terminate your instances because your credit card bill will thank you at the end of the month. So moving on a little bit. So we did. Let's see we've done container images. We talked a lot about the cloud images we talked about. So just on vagrant just a little bit. I want to show, you know, another thing if you don't want to go through that, that whole migration process, you know, even though it's three steps right now I think we can make it a little bit easier. So we've actually published a vagrant box for send us streaming directly. And we looked at that in cloud dot send us.org you saw the artifacts for that. There's a directory in our GitHub. Under vagrant send us stream. And it's a really, really simple vagrant file that, you know, it's basically the output of vagrant in it if you're familiar with that. So if we look at the, at the vagrant file here. This is the important part. We're looking at the sent us stream eight box and then I gave it a version of the most recent one that we just published but so if you do vagrant up in this directory, it's going to pull I already have this pulled but it'll pull that image. It does a pull through to that that exact thing that we looked at on cloud dot send us.org. And then it'll start one for you. So while we're waiting for this. And talk a little bit and focus on, you know, another thing that Tomachman mentioned I think we've seen it in a whole bunch of other places. If you have interesting hardware. Maybe something that's not x86 64. You know, if you have one of those fancy power workstations on your desk. Come talk to me because, you know, I'd like to say hi and all that stuff, but you've got options for all of this stuff to because over here in cloud dot send us. I need to go to up. If you have one of those fancy power workstations you can download and install download and use the generic cloud image, just with livered from from this location to same thing for air 64 same and air 64 even has, you know, as we saw, some things that you can spin up in the Amazon web services and all that stuff so definitely something to call attention to including the container images and that was a lot of fun to to sort of match what we had in terms of container manifests and stuff in quay makes it really nice to just be able to pull that for something on your architecture. Is this generic image be actually used to import to different clouds like Azure or GCP. Exactly. Yeah, so some, we know that some clouds require different different configs. And so, like I know Azure is one of them because you know they want you to have like a management agent or something on top of what already exists in other places in the distribution. There's so it's kind of we basically need some experts for each individual cloud to tell us what you know what needs to be on the image but the generic cloud images are a great start to getting there because a lot of in a lot of places they'll just, you know, boot and run. So, let's go back here and check on our vagrant install. Yeah, so this is our sent us stream image that has booted. And so you can include this in any of your projects, a vagrant file like this in any of your projects if you're wanting to target sent us stream. That's available to you as a box in and this is here's the page on vagrant cloud you can see the the versions that we have and then some suggestions about how to get this on your system to we do have both virtual box and live for providers available for each of these. So the the question now kind of becomes you've got all these options right you've got containers you've got cloud images you can we didn't even really touch on the the traditional installs you know like download a dbd and put it on a on a system somewhere but that's that that's completely available to you to make sure that stuff is out on the on the mirror network where you would normally find these things. So you've got this sent us stream machine installed or you've got a container image running. What can you do with it. You can do a lot of things like you can put it on your laptop I'm actually running stream aid on my laptop right here. I've been you know my daily driver since we we started the project. You can run a home server on it. You know I've got my file server on it that has like, I don't know, maybe two or three containers for random services that I use. You can use it to start playing with containers. Like Tomas mentioned earlier, one of the nice things is you get one of the nice things about stream is you get features a little bit faster than you might expect for sent us Linux. And so podman 3.0 being delivered in sent us stream right now. That's, that's a pretty cool thing and you know I've been playing around with it, you know ever since it. Composes there. But the main thing is install it, run it, put your workloads on it. But the, you know, kind of an illusion to, to I think Steven's question from earlier, look forward to being able to contribute in a meaningful way. We're starting pretty soon. We're, you know, Tomas and I are working together on some of those workflows and what that means for sent us stream nine. This is going to be a really important place to, you know, collaborate with people that are working on rel in a way that gets you features that are useful to you. We can propose patches, hang out with us on the mailing list. But even right now, if you head over to bugzilla. We're treating because of the relationship there between sent us stream and rel. We're evaluating bugs against the sent us stream version you can see that here it's there's actually a version against red hat enterprise Linux eight called sent us stream. We're evaluating bugs that come in under this version as if they were rel bugs. That doesn't mean necessarily that, you know, if you're asking for, you know, something new or, you know, pretty big or something like that, like, it's entirely possible that the maintainers may say no. Meaning this isn't really a good candidate for the next minor release of red hat enterprise Linux, but it's a conversation that you can have, and it's a whole lot easier to have that conversation here in sent us stream than it ever was in any of the previous sent us distribution so you can think of sent us Linux if you found a bug at point release day. It could have been another six month cycle before you know you even get an answer on a bug because the send us Linux was so disconnected from where development was happening for rel. And that's why that's why stream sits where it is that's why it's important to participate here but also important to use it. So, I think those are the demos that we have. Do we have other questions or anything else coming up. I think we have one more guys from computer kid whoever that is asks, is there any good reasons to use sent to a stream over something like fedora on a laptop. Yeah, so the, and I think it all depends on your kind of your point of view and your workload. Yeah, I'm pretty used to running enterprise Linux. And, you know fedora is is one of those things where it's a, you know, it's moving pretty fast, it gets a lot of features and, and that's that's actually a really good thing. I always ended up running enterprise Linux on my laptops because I've ran them on my servers and I've just matched them up together. You know, I think the, the, what you're, what you're going to get out of the feel of running send us stream on a laptop is more, more like a workstation than say like a desktop environment or something like that. So I come from the world of academics are ran a bunch of stuff for a mathematics department and you know we loved running enterprise Linux on the desktop and on our laptops because that matched with our the software workloads that we were running there too. So it's a, it's a personal preference to be honest. But, you know, send us stream is definitely usable in a workstation environment. So I can try a different answer. I mean, I would love to run center stream on my laptop but my use case usually is I want to have the latest software possible, like I want to have the latest container run time or libraries. So I often ended up running federal Rohit on my laptops. And right now I even have multiple machines with Rohit and it's just because that's what I want. But yeah, I love to stress what Brian said that it really depends what you want to achieve and if you want stability, definitely go for stream and if you want latest greatest federal or even federal Rohit might be the answer.