 Well, cool. My name is Major Hayden and I'm here to talk to you today about some new things in Fedora Cloud. If you're unfamiliar with Fedora Cloud and the value that it brings, we'll go through that too. Let me get things rolling. What I want to talk to you about today is first off, what is the Fedora Cloud Edition? A lot of people have never messed with it or they have an assumption about what it is. Then I'll talk about the new stuff that came in through Fedora 19 from lots of people in the community that contributed something, including some cloud vendors that came in and helped out with some things too. And then I have a little call to action if you want to get involved with the next Fedora release. And I'll try and leave lots of time for Q&A at the end if you have questions. All right. So a little bit about me. I live in Texas in the United States. I participate in Fesco and the Cloudsig. And my work at Red Hat is really focused on making RHEL the best it can be on public cloud platforms. I maintain way too many Fedora packages and I use far too many emojis. So you'll see plenty of those as we go through the slides. So first off, what I get asked a lot is, hey, what is Fedora Cloud Edition? What makes it different from a server? Or what makes it different from CoroS or something like that? So the Cloud Edition really is an opinionated installation of Fedora. And so it's an installation. It's not something where you're going to go and do a kick start or an initial installation in a cloud service. You're going to just go and deploy this thing as an image. We try to pack all that into the smallest possible image we can make. And we want to make these deployments really fast and really flexible. Because when you go into the cloud, everything is priced on a utility basis. You're paying for RAM, you're paying for CPU, you're paying for storage, networking, and you pay it all as a utility cost. So anything that takes too long or takes up more space than it should ends up costing people more money. So this is a super quick overview about what it is. But if you have more questions, I'll share the slides at the end. And there's a really good detailed deck from David Duncan that explains everything behind the Cloud Edition and how the influence works in the community. And so what makes it different? This is a question I get a lot. People are like, okay, we have Fedora Server. What the heck is the difference between Fedora Server and Cloud? So in Cloud, you never do an installation. You're going to get an image that has been prepared or one that you prepare on your own. You're going to deploy it and you're going to put configuration into it during the deployment. So if you've heard of Cloud in it, technologies like that, when you create the instance, you will put in metadata and say, hey, I want you to install some packages or I need a user created or maybe I want to configure something differently. All that's done on the first boot. And then after that, it pretty much operates like a server. And like I said before, time is money. So if it takes too long for you to get a Cloud instance to do the things that you want it to do, then it's going to cost you more time. That instance is going to be on doing system administration type tasks instead of posting the application that you want to host or the containers that you want to run. And so the lifespan is really unusual for Cloud as well. Some of these instances, people may boot them for 30 seconds and do like a batch job or take care of something that needs to be done. And then it's thrown away. Some people will go and deploy one Fedora Cloud instance and keep that online for years and upgrade it just like they would a server or a workstation. So we have a challenge there in that we have to make, this has to be something that's useful for someone that's going to keep it online for a very short period or a very long period of time. And the last part is that you can customize your images. This is pretty exciting. If you've heard about Image Builder or OS build, you can actually go in and say, hey, I know what I need in my Cloud image. I know the packages I need. I know the configuration. I know the users, services, whatever I want. And I want to ship that to the Cloud with everything that I want in it. I don't want to have to do any like configuration after the fact. And you could do this too. So if you want to get Fedora Cloud today, of course, you can go and download it from the website, which I'll get to that in a short while. But you can download the image and send it to your favorite Cloud provider. But I've listed some there. There are probably more that you can get to. But I know with AWS, those are pushed nightly via automation. So you get nightly builds of raw hide and all the stable releases that go up there every night. So if you don't want to have to update nightly, you can grab one of those nightly images. Now, those don't receive quite as much testing as the official images that go out, but you have that option to you. And some of these Cloud providers will prepare a Cloud image themselves and make it available, which is what many of these others do. And also, if you want to customize it yourself, you have that option to do with Image Builder. And I'll get to that in a minute. All right. So you're probably sitting there saying, all right, he's talking about all this stuff about like, what is Fedora Cloud? But let's get to the new stuff. And someone always told me if you had a cute animal in your slides, people like your slides better. So I want to make sure I got that little dog in there. All right. So the biggest thing is, we have a lot more public Cloud CLI tools. Now, when you work with a Cloud, they all have APIs. Everything is an API. You change networking via an API, you launch instances via an API. A lot of them, when you go in their web interface and you create an instance, on the back end, it's just hitting the API and telling the API to do things. So having lots of tools available is really good. And so when we put these into Fedora, the great thing about it is that then you can build automation on top of those. So one example is if you want to connect to a Cloud provider and deploy resources, you can write scripts and things that use these CLIs and take care of it. Or the CLIs can take actions for you, like run backups on an instance or something like that. And in some Clouds too, you can actually have these tools inside your instance and they can interact with the Cloud where your instance is running and do things for you. So we have a ton of new and updated tools for all kinds of Clouds. Our goal really is to make sure we have some of the most common SDKs so that you can write your own code and then import the code from the provider and do things. But we also want to make sure the CLI tools are there too. So that way you can run commands and launch instances and you'll be able to get these CLI tools from a trusted Fedora repo. And the biggest ones, the newest ones that changed was Hedzner, Vulture, Oracle Cloud. I think those three were brand new. I think the Digital Ocean one came in with the last release. But AWS CLI 2 is a really big one because we had version 1 before. Now we have 2 with a whole bunch of new features and things like that, but it was a little bit challenging to do. And so it takes a few minutes to do some of this work. AWS CLI 2 had some pretty heavy requirements. It had some extra things that need to be packaged. And we said, hey, wait a minute. If we're going to do all this work, why don't we make it as sustainable as possible? That was the challenge. So we had some folks from AWS. We had Fedora community members and members of the packet team. And several other people from Red Hat came together to get this into Fedora 39 and get it really, really usable. And so the sustainability challenge was how do we make sure that it's easy to do updates, easy to test, easy for someone to come in and find out what's going on. And so we started using packet. The great thing about packet, if you haven't used it before, is it will automate so many of your package maintenance workflows. Use specified packet in a YAML file in your, the diskit repository for your package, if you do packaging. And you basically say, hey, anytime there's a new version available, I want you to go and make a pull request and pag your with all the new versions. But I want you to only do it for raw hide or maybe do it for raw hide and all the other versions. And then when I merge it, I want you to build in Koji and I want you to do the update as well. So packet takes care of a lot of this for AWS CLI 2. And I think more packages are adding into their packages. We also added elastic file system support on AWS. If you haven't used this before, it's kind of like having an NFS server that's made available to you in AWS's infrastructure. So you can mount it to multiple instances at the same time, just like you would an NFS server anywhere else. The cool thing is it comes with a mount helper that will automatically create an external connection so that your NFS mount goes over a secure link all the way into AWS's backend infrastructure. So when you mount via the mount helper, all of this stuff is automatically set up for you and you don't even have to think about it. So that's something that we got added into Fedora 39. And it's pretty cool. It also monitors your NFS mounts for any problems or anything like that takes care of them. The next one is UEFI by default on AWS. And the nice change here is that it makes things more consistent because UEFI is more and more common on physical devices as well. But the cool thing that it gives you inside AWS is that you get some access to some of the security tools such as the TPM and there's some secure boot capabilities that are still being worked on in there. And so it just adds more capabilities inside AWS for Fedora. Users still do have the option of saying, no, I want the old BIOS because that's the way that I operate or have some compatibility issue I need to deal with, you have that option at boot time. And the next one was a lot of these are AWS related features, primarily because we have AWS engineers who work inside the Fedora Cloud SIG a lot. And so we get a lot done and have a call to action for other cloud providers a little bit later. So as I was talking before, when you provision cloud instances, you don't do a kickstart. You don't do an installation. There's no anaconda. You're provisioning via metadata. So you boot the instance and you say, I want this instance type with this image with this network, that kind of thing. And at the very end, you'll say, okay, and here's what I want the instance to do the moment it comes online. And all of this comes through a metadata service. Now the great thing is when you could trust everything in the cloud and you could trust the metadata service, everything is fine. Sometimes you can't or sometimes you want assurance that you can trust that service that's on the other end. And so that's what I'm DSP to gives you. And so this is turned on by default now for Fedora and AWS so that all the instances that you boot will use V2 by default. And really the only change here is the metadata is all the same, but there's a session-based token that's used when you pick up the metadata. And so the good thing about that is that you know the metadata is coming from a trusted source every time you receive it in the cloud. And so this metadata is made available via, I forget the IP address. It's like a 169 IP address. It's unusual. So that way you can only get to it from that VM. It's the cloud provider kind of offers it up on a back end interface. And so one other thing was automatic reboots on launch after you apply updates. This was something we didn't have before. And there's been a bug open for a long time. And we decided we would get it fixed. The cool thing about this is that let's say you launch today, you went and launched the Fedora 38 instance. Well, there's probably going to be some updates between where you are and what the latest of Fedora 38 is. So you have the option to say, hey, cloud on it, when you launch the instance, I want you to update all the packages. And then if any of those packages require a reboot, like maybe some D was updated or the kernel was updated or maybe something open SSL related was updated, it will automatically reboot that instance for you. So you launch the instance, you turn these two pieces of metadata on, the instance will update itself. And then the moment it's done updating it checks to say, hey, do I have anything that requires a reboot? I do cool. And then it reboots itself. So the great thing about that is is that you know by the time you log in, you have a fully updated, ready to go Fedora instance that you don't have to mess around with at all or wait for a reboot. Thanks to the Tracer team for helping us get that done. And then next, I know Emma was just on here and Emma helped us out a lot with the Fedora cloud website. It came in with the last release, but I'm still like so excited about it that I like to tell people about all the time. It's beautiful. It gets you to the information that you need as quickly as possible. So this is one of those places where I was telling you, you can go to the cloud website. If you hit download now, it gives you tons of options for deploying Fedora cloud. So some of the options are, hey, I want to go straight to AWS. You click there. It gives you the AMI IDs. You're on your way. You don't have to upload anything or import any images or anything like that. But then also you have other images for other platforms. For example, if you want to take an image to Azure, which we're going to have images in Azure soon from Fedora, not quite done yet, almost there. And you can pick these up and put them onto another system. If you have maybe like a VMware ESX server sitting around or you want to run one in KBM, you have all those options as well. You can just download the images here, load them up and go. And so, yes, the website is extremely helpful. And it's really nice that there's some automatic updating in there. It's fantastic. I love the way it looks. And then one last thing that I like to tell people about, it's not new to Fedora 39. It's been around for a while, but it keeps getting better as you can customize your own cloud images with Image Builder. If you haven't heard about Image Builder before, it's a really cool thing to check out. I've written some blog posts about it and the links will be in the slides if you want to read more or go try it out yourself. But the idea behind Image Builder is that if you know what you need in the cloud image, you know the packages and the configuration and users and this kind of thing, you could build that automatically. So you can build that entire image, package it up, and ship it with Image Builder. So you can provide your cloud credentials and Image Builder will build the image and then when it's done, it will ship it to that cloud and import it. And there's a few things happening behind the scenes that I like to remind people about is that every cloud is different with how you have to package up your image and then every cloud is different with what you do with that image to get it into the cloud. And then every cloud is different on how you import that image to be able to use it. So you have to know if you want to do this yourself, you have to know like all these little steps and know which parts take a long time. But Image Builder gets rid of all that. So for example, you can specify how you want your image built. And then right beside it, you can put your AWS account credentials past the commands or do it in cockpit. That's another option as well past those commands and basically just sit back and wait. You can just watch the system journal go or you can run a command to monitor the progress. And then usually, depending on your upload speed at home or wherever you're uploading from, usually like getting an image into AWS is maybe about a 10, 15 minute process usually on most machines. I think in Azure, maybe it's a little bit longer. But yeah, it's usually pretty fast. So yeah, this is extremely useful way to do this. Another way you can utilize Image Builder is if you make it part of your CI. So if you, like let's say you have a certain application that you want to deploy everywhere. You can package that in RPM or a container or however you'd like to do it. And then you can actually add Image Builder in your CI. So that way, your tests run, your packaging runs. And then all of a sudden you tell Image Builder, hey, build me a latest Fedora image with these packages and this config and then add my software and ship it. And so I have a proof of concept repo in GitHub that actually uses GitHub Actions to build an image builder and ship it to AWS. Now, of course, that's nice because at least the infrastructure in GitHub is totally free and it ships it on its own. And you can set that up on a nightly job or something like that if you want to. So there's some links here on how to do it on different clouds. I think two of these are Fedora and I think one might be REL, but the instructions are the same, no matter if you're using Fedora or CentOS or REL. And then kind of getting towards the end here, I want to make sure I have time for questions, a little bit of a call to action here to get more people involved. So I really want to get more people into the cloud SIG. We're always looking for more ways to reach people and more ways to deliver valuable things that people want in cloud. But one of the challenging things is, as I said before, everyone's demands for cloud are different. Some people may deploy something in cloud and keep it for years. Some people might deploy something and keep it for five minutes. Some might deploy just one or two instances and treat them as if it was their pet and they take care of them, things like that. And then other people will deploy a thousand instances and then scale down to 100 and then go back to a thousand. So it's all across the board. So one of the biggest things we love is hearing use cases from people when they tell us, hey, I use Fedora and cloud to do something. And then we're like, oh, how do we adapt to that use case? How do we find a way to make sure that we're fitting that use case as well? And some people also show up and say, hey, I deployed this cloud provider, but the image is not very good. Maybe we can work with that cloud provider to get improved or maybe we can ship the images directly to them so that way you'll get the best experience. We meet every Thursday at 3 p.m. UTC on IRC, although I think this week it may have been Matrix. We're still trying to figure that out like some of the other groups are. We have lots of open issues and our mailing list. If you have any questions or if you have use cases or maybe if you work for a cloud provider or you know somebody who does and you want to improve the experience there, we're always open for questions or anything like that. And that's it. I want to make sure there's plenty of time for Q and A because usually, I don't know, people always have strange questions about cloud versus server or anything like that. I don't know if there's any in the list. I may have put everyone to sleep. Who knows? But yeah, I mean, if there's not any questions, we could probably wrap up early unless my screen has frozen. That would be terrible. Okay, good. It's not frozen. That does happen from time to time. Oh, let's see. Contrast Cloud with Fedora CoroS. I should have put that in the slides. That would have been a good idea. Okay, so I write about CoroS a lot too. I like both. And I think there's good use cases for either. So I would say if you haven't used CoroS, I think there's about a million different ways you can explain what CoroS is. But my favorite thing to think about is CoroS is what you use when you have a workload that you want to deploy and you really don't want to think about the machine that's underneath it. So as an example, let's say you have an application that runs with like two or three containers that have to run together. You really care about those containers and you care about what's in the containers and you care about how those containers interact with each other. But you may not really care about the OS that's underneath it. So you may not really care if like them is installed underneath. Like maybe you don't, that just doesn't matter to you because you're like, I want to run my containers and I don't care about that. But I want to make sure the OS underneath is always updated. So I think that's what CoroS gives you is an automatically updating platform that sits underneath and supports everything that you want to do. And CoroS also has updates that if you have an Android phone, the updates are very similar, downloads the updates on the side and then reboots. And if everything is good with that update, you're good to go. Like no RPM updates or anything like that. And then if something goes wrong, it goes back to the previous release and then you're back online. And then later on, it can try that upgrade again to a later version that comes out. And so Fedora Cloud I think is more like a, it's more server oriented. So this would be more like if you need to run workloads that maybe care about the OS that's running underneath them. So maybe it's a workload that you can't containerize and you have to actually run on the host. Maybe it's a workload that needs to be installed via RPMs. Or maybe it's the system that you plan to keep online for a long time and have a lot of customization of the OS that's underneath. And I think that's where Fedora Cloud really shines. All right, let's see. And then Neil asked, any teasers for the future of Fedora Cloud? Ooh, that's a good question. I know that we're doing some work right now to figure out how to get the same automatic image updates for AWS that we have now. We'd really like to get that for Azure because we do have people ask us pretty often about getting images over there. We get asked occasionally for them in Google as well. And so we'd like to be able to do that. There's been some talk too about working with some of the cloud providers that build their own Fedora images now to try and see if maybe we can build images for them so that we can supply them directly from Fedora. So it's less work for them. And then we could do some of the CI work because we care a lot about testing those images before they go. And also too, it kind of it removes some of the things. So I don't want to say anything bad about the cloud providers because they've got support challenges and things like that too. But I would say some of the cloud providers will make changes to those instances. Instead of using Fedora as the user to log in by default, they'll change it to root because that's what a lot of people are just they're used to that. But we changed to Fedora for a reason because it was more secure to log in as just a regular user, keep the root account disabled and only accessible via sudo. So we'd like to see some of those changes be a little bit more consistent across the board. And then we're always looking for ways to integrate Fedora into more clouds. So just to find ways like where we can have more of these things that you would typically want to interact with on those clouds, make all those packages available to you so that those integrations like for example, the elastic file store at Amazon so she could just mount those just right off the bat and use them. Let's see. And in the chat, let's see. Mateo asked, what about OpenStack? Is it recommended to use this instance or recommended to use this instance to be used with Ironic as a base to deploy controller or compute node? Or is this image only recommended to host apps inside a tenant? That is a good question. I have not used Ironic in about five or six years. So I'm not really sure what has changed over there in a while. I would think that Fedora Cloud would be the image that you would run inside the instance on OpenStack. And that's where I've run it in the past. I forget the name of the OpenStack public cloud where we have Fedora available. Oh, Vex host. We did have it in there. And yeah, I would say definitely that was I would use that for a tenant instance on top of OpenStack. But yeah, I haven't touched Ironic in so long that I don't know if I could answer that question. If anybody else knows, put something in the chat.