 So in this talk, I will talk about the Fedora Core OS, which is kind of sister-brother, whatever you say, of the silver blue. And we'll see why the Fedora Core OS is best for running your containers. Before talking more, I'd like to know who all are using Fedora, or at least no or never used Fedora. OK, that's nice. And who know what Fedora atomic host? OK, that's nice. And about container networks? OK, that's actually good. It's not like we don't have anyone here who knows about it, so it's like good audience. OK, so we'll see what Fedora Core OS is and which all features it provides to you and why it's best host for our containers and where exactly we stand today in Fedora Core OS and how you can get involved if you're interested or if you want to try out. OK, so Fedora Core OS, it's a minimal operating system, optimized for running containers, and its goal is to automatically update your system. So there are three things. And let me tell you, it's for server, just in case you are confused why we have both Silver, Blue, and Fedora Core OS. So this Fedora Core OS is mainly focused for running on the server, which is targeting basically containers and containers workflow. So the main importance here is that you'd like to run clusters of containers. So that's where you should use it. Or if you want to run a single load container, that's also you can use this system for. And it's basically mainly designed to do your container workflow in clusters of clusters. And if you can run on top of it, it's optimized to run the Kubernetes cluster, Kubernetes on top of it, or maybe without Kubernetes also, it will just run fine. Also, the project is under Fedora Umbrella. So you can think that it's what you get in the regular Fedora, like whatever RPMs you have. We build in Fedora, which gets signed and all like from the cluster space. So this Fedora Core OS also make use of all the packages which we have in Fedora. It's just that the packages, it does not directly consume. It uses RPM OS tree, which creates a tree of the whole packages into an object format. The format is OS tree, which uses it internally. And that's how you have the operating system. We'll see more in later on. Also, the Fedora Core OS is up to four RH Core OS. So if you haven't really used RH Core OS, then maybe you can try this and get a fill. But it has some broader scope than what we have for RH Core OS. OK. I think by looking at this picture, you can get some idea about what Fedora Core OS is. So it's just like it's the combination of what we have from Fedora Atomic Host and what we have in Container Linux. So I will tell you, we want here in the Fedora Core OS that we want to keep the community which we have in the Fedora Atomic Host. And from the community from Container Linux. So we want to keep the community, grow the community, keep our users so that everyone is happy and we have good Fedora Core OS for all the users. So we'll see how exactly these features from Fedora Atomic Host and Fedora and the Container Linux fits in together in Fedora Core OS. Let's see for the features of the operating system itself. So this operating system is based on OS tree and RQM OS tree as we talked before. And it's an Invitable Host, which means that the SlashVesal, which is majorly the main part of your operating system, it's a read-only file system for the not read-only file system for the entire operating system. It's the read-only file system for SlashVesal. So all the binders which is created from the general RQMs or anything, it's SlashVesal bin or it will be SlashVesal has been on anything else. Basically all are in read mode so that this is to help you to not do any accidental damage to your system. And because we want to run in an automated fashion and in the container workflow, we basically want to create our infrastructure once and we want to keep it running without much intervention, without breaking it so that our clusters and everything keeps running smoothly, like forever. We'll see why I'm saying forever. OK, so it uses Ignition. So if you are from a container in X-Wild, you already know the Ignition. This is being used during the boot time. So when the first time the system gets booted, during the drama phase, it has the Ignition and it checks the Ignition config and it will do the configuration like disk partitioning or user creation, all the stuff will be done at when the system first boots. So that's the advantage of this Ignition is that if you have a good configuration of Ignition, then everything will happen before the system boots because this is running at the in-it-ram phase where system has not really got transferred to the user space. So if something goes wrong, basically your system won't come up. So either you have a running system or you don't have a system. So it's not like in stale state, like when you use Cloud in it, you may have a running system, but it may not be configured properly if something in the Cloud in it doesn't go well. So these kind of stuff get like, you don't have to worry about those. Either you get a good system or you don't get a system that really helps. Also, another feature of this is rolling release. This is from the motivation from the container Linux. In container Linux, as I think you said that we have three channels, like Alpha, Beta and Stable. So these channels you get different, the Alpha is like the fix which is about to come and then Beta is like a bit more bagged in than Stable is what is like even more well tested. So you have different approach of getting how stable you can get. So similarly, in Fedora or CoreOS, there will be three streams. It will be next and there will be a testing and there will be a stable. So it's a bit different meaning. Stable is what you have, very stable. Testing is what which is going to come next in your step in moving to Stable. So a bit better, maybe less tested you can say which is may you can find some bugs during testing then it won't go into Stable, so it will get fixed before that. So and the next is that what's going to come next, like right now is Fedora 29 and we are going to have Fedora 30. So if suppose we have Fedora CoreOS today, the stable will be from Fedora 29 and the next will have the packages from Fedora 30. So you will know that what's going to come next. So you will give the feedback to us in advance and all will have the CEI and all will be well tested. So these all three streams will be released mostly like two in two weeks. So you keep giving us good feedback from the beginning. And if there is some security issues or something comes then we will apply all those fixes on all the three branches. So we'll try to keep everything stable. So your users can run some wherever they want like they can have some notes on Stable, some notes on testing and some notes on next so that you know how the next is going to look and what you should be having in the stable. So that this helps to keep your system always stable and without breaking and yeah. And yeah, one feature I just mentioned is the no Python because really Python is like everywhere but in chorus we are trying to keep things minimal. So we don't really need Python there and the main reason is that Python makes things it's just reduces the image size also and you don't have to worry about the Python whole stack. So this really reduces the bit risk. You don't have to care about the security issues which came to Python and it keeps things minimal and we are trying to work on that to have no Python. Okay, so we are all it should be available. We are targeting mostly from running you can run in your bare meta system by installing ISO or through PXE and it can also on any virtualize environment like QMU or live work QMU and virtual works and also to the various different cloud providers like GCE and AWS Azure and OpenStack et cetera, et cetera. And we are also targeting the x86 architecture and other two are like arts 64 bit and RPC 64 bit L. So currently the mode work is towards x64 but people are currently heavily also trying to do the things on x64 and RPC. So they are also going really well. It will take some time and let's see how and when we get all the three architectures in one place but exit is the six 64 is like first we want to get in that architecture. Okay, so we have seen all the features which this operating system provides to you. So why this is really best host you should consider to run your containers. This is because this is minimal. As I told, we don't have any extra packages other than what you required for running the containers. It also provides you the, it also provides you the all the container run times which is required to run the container like Docker, also Fodman and RunC. So you don't need to really install anything else. And in simple blue, we have seen that we also support package layering but here we really don't encourage people to do package layering. If we need to do some package layering it may be some case by case basis. But we don't do that. The reason is that we want to run it in a place where you don't have to keep intervening your system. It should be like running every time without any problem. So if you have more package layer, it can create issues like because you are adding more layer and layer. So, and those are not tested by us. We are only testing and the base of which we are given and the package layering which you are doing is it can have some issues. So really in the service server workflow we are not really recommend to do the package layering. And yeah, it has multiple strains. So whatever you want to try out whether testing next or stable you can try the feature early or if you want to be unstable you can be unstable. So it really allows you to stay where you want to go. Yeah, and the current status. So this is a new operating system which we are designing based on container Linux and Fedora Atomic host. So this is not really currently released. We have Fedora Atomic host in 29. If you want to try it and if we have container Linux also if you want to try it, container Linux. So you can go ahead and try those and get a feel of that. And this Fedora Core OS is like currently in the development phase and the target is to have it after Fedora 30. So when the Fedora 30 release we'll take the package from Fedora 30 and updates are available in Fedora 30 and use that and bake that into the, as a preview form. So that will help us to get some feedback from users from container Linux and Atomic host to know where we are, which features we are missing. So that we don't really want to make it stable now and break your system later on. It's better to keep it in preview, get the feedback and have most likely we'll have the stable release where we can rely on after Fedora 31 which will be based on Fedora 31 content. And the advanced, okay. I forgot to tell the advantages of different streams. So like in container Linux, I think once you install the system on, I think if you're in beta or any stable channel you always get rolling releases. Like never have to switch to any other or upgrade or anything like that if you keep updating. Similarly here, once we move to the stable release you can be on stable. And once you have installed it will keep updating the system. Every time it have releases like it will have two weeks releases mostly unless there is some security, security fixes so we can have some out of cycle releases also. So you just install once and keep running keep getting update for the system. So you don't have to worry about your system and you can have your own cluster running Kubernetes or OKT or anything else whatever you want to try the container stuff. So you don't really need to worry about your host. Just keep running and it will keep getting updated there is a new release of Fedora then we'll update our content based on the new releases and we always want the same system and we'll be focusing on making it automatic updated so that it really don't have to do anything. And we are also purchasing the artifact currently which is really currently mostly developers are creating it is not really like very tested or something but if you want to try out you can go and try these from it's in currently built in the service centers CIA pipeline and they are available I will show the link later on which all artifacts are currently there and also we are very close to shipping no Python in the host. I am personally working on that mainly and we have like six or seven packages of Python currently available in the host and mostly we have tried to remove whatever the Python things are there and some of the packages really are Python but we are trying to see if it's you can use those utilities from the containers. So really on the host no Python so it really reduces so mostly we will be able to achieve its own and we have a tracker here for the two doors on what things are completed. So if you want to look ahead and get some idea and feel you can see there we have already finished lots of design making decision what we really want to keep in Fedora Core is because we have learned from container Linux and we learned from Fedora atomic use so we want to be better than we take better things and just exclude whatever was not really maybe pain points or something so keep the good things and proceed there and make the Fedora Core seven better so we made a lot of design decisions already and then we are working on a lot of features already and getting implemented and aggregated and give you a good Fedora Core S. And that's all and if you want to get involved there are various ways go to the issue tracker or join our mailing list and yeah there are forum also if you want to ask question go to the community and I asked a meeting also we have an APAC friendly meeting which we do every two week in around five UTC so it will work it is friendly for APAC also we have a regular IAC meeting on every Wednesday around 4.30 UTC so whatever time works for you you can come join the meeting ask questions or maybe just ask on mailing list or anywhere whatever is comfortable and you can help us. That's all and yeah so these are the artists that you can see we are now creating a database where it's Kikoto and ISO and the EOSI non EOSI mode of that images and yeah OpenStack image so all are all everything is we are using the CoreOS assembly to build everything so this is a tool so really if you want to try out this is the best way all the instructions are mentioned here it's really very easy to try I'm sorry I'm a wrong place these are the links so basically you it's a coreOS assembly itself is in a container image so it pulls in and then it does just to coreOS assembly fetch build and run it creates the compose of OSI on your local system and then you have the artifacts whatever you want you can give the parameters and try it out and if something is not there you can make a request or talk to us on mailing list or as a channel and we can may include something which we have not yet planned because we don't know if that's a use case but we are open for everything that's pretty much any questions? That's on the that's for managing the managing that of that containers right that's not part of the container Linux itself Tectonic is part of on top of on top of the container Linux right? It's a platform yeah it's like branched a little bit of branched I know about that but I think it's like OpenShift it's what would you like? I guess I actually want to be what would I do on the website if there's a company to be able to do that yeah so you're going to go inside of what's the problem with you? Anything else maybe silver blue or in general if there was any question like not coro s maybe we can ask us So we are keeping both at this for now, and mostly the plan is to do both, and we focused more on part-man because it's an OCI based and it's more open to take the feedback and have the PRs ready, and it's really, because for Docker as far as I know, for some patches people were having hard time to get it merged into Docker, and also there may be some licensing issue, but here it's like multiple companies are involved, and it's more kind of open space, so it feels better to move forward. Yes, you can, but for now we don't have any image running because a lot of stuff are coming from container Linux and some stuff are like, and we are still working on porting and porting stuff, which is fixing bugs and all. So it's really in, we are trying our best to have that included, so once we have Arc64 support available, we can obviously try on Raspberry Pi, but the main target is for server side, but yeah, it's always good, because in atomic host we were trying also to run it on Raspberry Pi because it's easier that people can try, in general people can try, everyone don't have the server. Any more? So far we don't have any CI, we are right now working on designing the streams, we just plan which all streams we want and how we want, so the CI part is still needs to be done, but definitely we are going to have, and also we have the Mantel which have Polar, which does already a lot of testing, like launching images in a virtual lib world or anything or in the AWS or something like that, I think it's, they have very nice testing coverage, Blackbook testing and all, so we will make use of Polar a lot, other than that we'll see at package level, we will try like if there is a new package which we want to in, so we will have a new artifact and then we'll try to run the CI on that, still in like not like everything is planned at that area. New version of Docker? Yeah, so if there is a new version of Docker, it first gets built into Fedora, correct? So once it's built into Fedora, we have a new package, so we'll take in and we'll use it in the, use it in the content, the Fedora Core S, it will be available. Yeah, so just in my mind, you will update the Fedora Core S when it's ready or when it's ready. This is part of the operating system itself, so the Fedora Core S, when there is a new version update, you don't have to do anything, the operating system itself will pick up that update, it will build a new OS tree update from that and it will apply. Yeah, if, yes, so that's the cost you have to pay if you want to keep the system stable and running for like forever, like if it's not well tested, then there is chances that your system may not boot or something like that, right? So we want to make sure that everything is tested, we don't want to ship everything to stable, it's go through testing, users if they're using they can know and they can give us feedback that it's not working for their environment in the testing itself rather than running it on the production servers. Unless it's a security fix, security, if there is a critical security, it will be applied to all the streams altogether after testing. Okay, thank you Suneen for your great talk. Thank you. It's a great question. Thanks everyone for joining.