 Keep containers up to date. So the guidelines are continuing to evolve. One of the things that we request of container maintainers is to kind of keep up to date periodically with what's going on with the container guidelines. Maybe read the atomic working group meeting minutes, because any time we're going to do container guideline changes, they go through the working group. We do a consensus-based change set and address bugs. I mean, we do have a container entry place in Bugzilla. So wire that up to your email if you want to get nag emails about it, or check it periodically just for the sake of doing that. This isn't the same as package management in the sense that you're patching software constantly and that kind of thing. So the idea of having bugs flowing in is maybe not necessarily intuitive and at the forefront of what you think about as a maintainer responsibility. So please try to keep that in mind. We do have a review process. So when you contribute a new container, it does go through review. If anybody has been a Fiora RPM maintainer, this workflow is going to feel very familiar. A lot of what we tried to do when initially creating the containerized workflow in the build system, as well as the guidelines, and then in the review process is try to make it feel as much like the process of getting an RPM in so that contributors who are used to going through that workflow will feel right at home working on the container stuff. So I have a link here to the container review process. We'll make all the slides available. There's not a lot of slides for this. This is mostly going to be a work in the show. So container guidelines. This is what Josh is going to go through. And we'll hook up his laptop in a second and let him run through and go through the guidelines. And then, oh, I'm sorry, goofed. I doubled up the information on this one. But yeah, so we have the review guidelines out there. And then Josh can go and run through his examples and kind of show you guys what we're talking about. When we say guidelines, how to take something that is not in compliance into compliance, that kind of thing. So you're going to solve them up. Yep. So it's going to be a lot easier for you to follow along here. Sorry. No. It's not very easy to follow. No, it's going to be very easy to follow at all. But it's going to be a lot easier for you to follow along if you actually look at the container guidelines yourself on the Fedora wiki. Just because I'm going to display stuff for you here, there is a lot of text, though. And it will be easier to read on your own computer. So fedoraproject.org slash wiki container colon guidelines. So you can go ahead and bring that out. It'll also be useful to bring that up during exercises. Well, you are navigating there. I do want to mention that because this is one of the things that I do, since I'm part of the OSES department, there is swag here. So for everybody who actually came to this, we've got a couple of things. We've got patches so that you can actually put project atomic on your clothing or bag or something somewhere. I apologize. These were supposed to be iron-on patches. So you could take them back to your room and use the iron in your room to attach them to stuff immediately. And the vendors screwed up. So they are sew-on patches. But please take some. And if that's so much effort for you, we have pins as well. For everybody who sticks around for the exercises, I'm from Portland, and we have lots of gourmet stuff there. So I brought some fancy gourmet handmade caramel to supply you with a little bit of sugar during exercises. And then when we get done with the exercises, we are going to pick two containers that are in submitable, container definitions that are in submitable shape. And the team who worked on them, one of them will get a fleece, and the other one of them will get a bottle of project atomic hot sauce, and they can kind of fight that out between themselves. So just to give you a little incentive to stick around and actually work on stuff. So if you've got those up now. So we have a lot of text for this. And we talk a lot about the build system. We talk even more about the build system for those of you who were in the last session. How many people here were in the last session? OK, a lot. For that matter, how many people here have built a Docker or other Linux container before? Great. Oh, we're in terrific shape there. So our first part of the container guideline is basic Linux. We maintain a set of base images in the Fedora repository. And any container that is going to be submitted to the Fedora repository should be based on one of those base images. You can go elsewhere in the Wiki. If you go to Wiki, if you go to Wiki slash atomic slash flits underscore catalog. Sorry, I don't have any way to enlarge the text in the URL. Hold on. There we go. That's that URL. So if you go to that URL, you can actually see a list of base images, which are right here. We've got a bunch of base images based on the different versions of Fedora from 25 onwards. We also have the minimal base image. And this is a much smaller, what are we in it, 80 megabytes or something like that? I don't remember. I should know that, but I don't. It's a much smaller base image with very little stuff. There's no Python. There's no DNF. There's a whole bunch of other things. Micro DNF. Oh, there's a micro DNF. You can install things. Yes, there's a micro DNF. It's actually really, really useful if you're going to be using Builda, where you could install things into the container using tools outside the container and keep it small, but for a lot of stuff. And so your first thing is that the container that your definition you're submitting needs to be based on one of these. Because as much as we love the folks over at Debian, we're just not going to be building their containers for them. There's a whole bunch of information here about registry layout and that sort of thing, which, fortunately, you don't really need to know because the system handles that for you. And then a big part of your requirements. So in terms of actually developing and submitting a container to the layered image build system, what you are submitting is a Docker file for building the container combined with some other supporting files that it may, well, maybe other supporting files. A lot of containers will have only a Docker file. So the Docker file is your submission, just like an RPM definition file would be for an RPM. And the biggest part of our requirements that are a set of what are known as labels, which are a whole bunch of metadata that we need, partly to build the container and a lot of them are so that downstream users of the container will know what the container is for, how to use it, and what it does. And you can see here, we go through all this. But we're going to go through this sort of interactively with all of the required ones. And actually, I think, from their version. So before we actually go, so let's actually look at a Docker file. And I'm actually going to pick up one. Now, when we initially submitted this workshop, we actually had a bunch of containers awaiting review in the review queue. And so we're going to review some of the stuff that was already in the queue. Since then, we've kind of cleared out the queue. And honestly, what we actually need is more people to build, submit new container definitions. And so we're going to focus on that. Because you can see from this, we have only a handful of things in the queue to look at. This is actually coming from, if you go to the container review process page in the wiki, you can go to the package review tracker for Fedora. Because containers are packages, yeah? So that was interesting. One of those containers in the review queue was for a sorted library implementation in Python. Is that really something we want to be encouraging people to create a container for? It's not actually a container there. So the problem is, right now when we're discussing this this morning, we don't have a separate product for Fedora containers. And so I'm actually filtering by full text search. So if the word container is in the name or summary, it's coming up. We will get that fixed so that you can actually filter out package review to only containers. But right now, you kind of have to look for this beginning right here. You can see that where it says container review request. And we will have a better way to filter on that later. So I'm actually going to pick one that's been in the system for demo purposes for a while. Basically, right after we created the system we could submit stuff, Matt helpfully submitted a container definition for CALC, the command line calculator. I don't know why this would be useful to anybody, but there it is. Yeah. The reason it's very useful for these purposes, the reason why it's very useful for these purposes particularly is that Matt submitted it before we had the container guidelines. And so the submission is completely non-compliant. Welcome. And so for that reason, we can actually go through and make it compliant. But like if you were reviewing somebody else's container, you would be looking at bugzilla like this. And you would see actually the container review and that sort of thing. And go through the bugzilla and feedback. And Matt and Adam will talk a little bit more about the submission process once we go through the container definition. So here's the definition. I mean, actually, if we look here, you can see I've got this right here. Wait, where's the link from bugzilla? Here we go. So in the submission, there's going to be a link to a dockerfile, end, or additional files. In this case, there's only a dockerfile. And if you actually click through the dockerfile, you get this dockerfile right here, which I'm going to put in a text editor so that we can actually mess around with that. So now, people in the audience here, you should have the container guidelines in front of you. So what's the first thing that we need to fix about this? Yeah, what's wrong with that front line? It says the full registry. Yep. So and for people who aren't familiar with this, the reason why we need that particular front line is that otherwise, if we're using standard upstream docker, we'll try to pull from docker hub first, and we'll not find Fedora registry. And actually, for that matter, I don't think that we've modified the docker that we distributed to pull from. We have? Yeah. OK. But a lot of people might be pulling from other places. And so we want to actually make sure that we really define what's coming for them. Yeah, so for Fedora systems, that would have worked. And in the build system, it will work. But we want these things to be reusable to anyone. So we want to make sure to specify that appropriately. Yeah. And also, let's go ahead, because we know this package is available at Fedora 26, so let's actually bring it up to date with the current production version of Fedora. So we've got a couple of other things. We've got this main Hiener value, which is a standard part of docker files. But we also like to have maintainers a label. Now, there's one other correction you wouldn't know about, because it was something that we actually did after we published the initial guidelines and then revised it when we realized something. We found out something early on, which is that the labels are case sensitive. And so after a lot of back and forth in this, because of course naming things is hard, we just had to meet the labels of a lower case. So let's see. Other stuff that we need here. One of the other things that's going to be a little peculiar here. We have plans to automate the version number. Is anybody going to guess why we want to automate the version number instead of putting it in up here? Yes. For automated rebuilds. Because one of the things that will happen is, like there's another G-Lib C security exploit or something like that, we're going to automatically rebuild all of the containers. And at that point, we want stuff to version automatically. So unless you have a specific reason to use a version number that's different from the version number of the first RPM that you're installing, then just put a zero right there. There are cases where, for example, you're installing something from, say, well, right now we don't allow you to install stuff from PIP, et cetera. But in the future, we might. And in that case, you might be putting in a manual version number. Right now, you're going to be putting in zero most of the time. So question. So technically, you install some RPM, and let's say I'm going to be working on an E-Max, which right now, and Fedora 26 is 25.3, doesn't matter. That means that would be the version that would be supplied there automatically. What if I wanted to supply both? Technically, I wanted to create a container image, but it's going to be any version of E-Max 25, not necessarily 25.2. I want that stream. Whatever is the latest version of E-Max 25 in whatever Fedora, that's my container, latest E-Max 25. I don't want the version to include the micro or minor version. We can't do that in Fedora. That's going to be a modularity thing. We will be able to do that. We just can't yet. Because as soon as 26 lands, it's going to show up in your next container rebuild. I forgot it's actually going to be within the space of a single Fedora release anyway. But we'll get there. That's on the road map. OK. Josh, I think you need to change BZ component to com.redhat.component. That's correct. That was another revision to the guidelines by the atomic working group. And so this label, by the way, says what would I look up in Buxilla for this? Now, in the case of CALC, which is an RPM that we have in Fedora, that's going to be the name. In other cases, you may actually need to supply a name here because the Buxilla name is something different from the package name. Most of the time, it's going to be package name. And so here, we can just use these environment variables that we've defined, which, by the way, are also available inside the container for anything in the container that needs to look at those things. Yes? So the release is not automatically maintained when the version number is? That's the idea, yeah. What if the rebuild uses the same version and just bumps the release? The rebuild bumps the release and commits it to get it. Yeah. Yeah, the release means a change in the get file, whether it's a change done by you, the maintainer, or a change done by the build system. So this is actually important because if you are the maintainer, you need to remember to do a pull before you do a push because the build system may have incremented the release number. So question because OSB actually supports the auto bump or release. Yeah. If you omit release, it will automatically increment it. Right. So why not use that? You're doing it for a version. Well, no, we're not bumping version. Well, I know. But your automatic is brought to the line. At some point, yeah. At some point, we're going to introspect. So basically what we're going to have is we're going to have either a label or an environment variable that defines the primary component that you want to inherit the version of, and then we'll introspect into Koji what that version is. Right. But apart from the version, the release that was omitted OSBS would just rebuild as many times as you wanted. And if you have a newer version of RPM, you would pull it in, and the build would actually succeed. Yeah. So two reasons. One, when we wrote the guidelines that didn't exist. And two, that version of OSBS isn't actually in production yet, because that plug-in, as I understand, is relatively recent within the last six or eight weeks. But I would say this sounds like a good question to come to the atomic working group meeting on Wednesdays. I'm totally, I mean, all of that is open to change. Yeah. Absolutely. And one of the things like which RPM we pull the version from is still undefined, because we don't actually have a way to do that yet. So when we have a way to do that, then it may require modifying the container definitions. With Fedora, with RPM now for us, we reset the release down to one all the time when the version goes up. Is AD here that releases? We'll just keep incrementing forever. Well, I mean, I don't understand the question. Sorry. If the version gets bumped, will the release get reset back to one? So if we go to a version 26 of a container, will the release get bumped back down to one? Or will it go to keep on two? I don't really care. It just could be different from how we do it. Yeah, hold on. So are you talking about for the automatic, so if we're automatically setting the version from a primary component somewhere that we're inheriting the version number from, are you saying when that version number increases, are you asking if that version, are you asking in the event of that version increases, will we then reset the release? We have not defined the requirements for the criteria of the plugin that will perform this yet, so we don't know. But that is absolutely something that we will probably address there. So giving a simple idea is we are actually missing an environment label. What environment label are we missing here? Yes? Also I'm leaving because I feel as though I have been pushed by the FPL. FPL left your session as a badge. Yeah. This is a wonderful session. I love you all. Uh-huh. So we've entered in the architecture. So that's our sort of basic metadata right there. And then we need a bunch of other information, a bunch of other, there's a whole set of additional labels that we need that have to do with being able to run the container. Now some of these are labels for informing the user interactively how to run the container. And some of these are labels for supporting things like the atomic CLI, which will run the container. So some of these are already in here. So usage, for example, is if we look here at our list of container guidelines, there we go. Required labels. We have to give either a run line or a usage line. So what's the difference between those two? Well, a usage line is designed to inform a human how they would run the container. So it's meant to be human readable and over the label. And they say, OK, here's how we run the container. A run line specifically supports atomic run. Now you can actually do both of these if you want to. That's really messed up. Wow. That's interesting. Well, this is a bit open. Yeah, so that means we're ready to run the container. OK, well, wait. Let's stop now. Yeah. I don't know what happened there. I've seen that done in various editors. There's a preference for multiple labels in the same line just because it's one instruction to Docker build rather than having multiple instructions, which each label instruction is. I don't know that actually makes a real difference, to be honest. Because the labels don't create a layer, as far as I know. And it wouldn't matter for Fedora anyways, because we squash the layers to end the build. Now there's a problem with this example Docker run line. And that's because we namespace the Fedora versions. So even if we're doing this on Fedora, we need to actually give it a Fedora version namespace rather than just calling it by the name of the container. Wouldn't it be better to use the Xs? Oh, we could. Yes, probably would be better. Well, so no, this is it, except? Yeah. Well, will that actually, OK, so it will. It will as replaced during the build. OK. Yeah. Well, it won't replace it in the build. I think it will replace during the execution. So I guess we might as well go ahead and do dollar names, too. Yeah, we're getting fancy, y'all. Yep. And it only does that because they're environment variables. It won't do that for labels. So now one of the other things that you need to supply is information, a little bit more detailed human readable information about how to run and how to use the container. And there are a number of ways to do this, depending on what's appropriate for the kind of container that you are running. And for what utility you're running inside it. In this particular example, the Calc command line program has its own help output that's part of the package. So in this case, we can actually supply a help command that will be called by atomic help if using the atomic COI. And we can supply a help command that actually outputs help for the command. This, frankly. In other cases, the program may not have a help command. To give you an example, one of the ones that I've actually been packaging up is Ascibinder. And Ascibinder is a Ruby gem, et cetera. So no built-in help. So in that case, what we do to allow you to use atomic help is you create a file called help.one. And that file, do do do, stop scrolling, please, do. And that file gets dropped in the root of the container. So this is where another one generates, I believe. Where would the, where would its text come from? You don't have those. We should. I mean, we've talked about how we would handle that, but it's just. That way it would be automatically Right. Okay, that'll be nice. We'll probably have that sometime in the future. That's a markdown file? Yeah. Okay. I thought we'd fit that. It'd be in diskit. Yeah. You would just add a plain text file or whatever. Next. Give it a Docker file. Yeah. And then your help, that one file will have a number of things. And what it should cover is, it should cover sort of general explanation of it. If you are going to need any volumes of the container, that is storage for the container, then you should explain what the volumes are and something about them. Like in this particular case, in this particular case, for this ASCII binder thing, it's expecting you to mount your source repo for your ASCII binder project to a directory called Atomicostex. Well, it's actually now just docs. We've been changing it. The, if it has any ports, a usage example, and then a whole bunch of notes, whatever notes that you have about it that are special, such as alternate ways of running it, such as any issues that you might have with permissions or required SE Linux flag or other things that people need to know in order to run the container. However, for Calc, we don't need any of these things, which means we can get by with a much simpler usage, bit of usage information that is namely access to this help file and then, and then a summary. But there's actually one more thing that we could supply users with that would be nice. Does anybody know what it is? And there's, it's actually in there as an optional tag to do with container dialogs. Yes, because we can actually give people a URL. See, ta-da. Here it is, the home for the project. So this URL can be anything that's appropriate for the user to find more information, right? If this might be the GitHub repo for the container, et cetera, if it's a complicated container, like for my Postgres containers and that sort of thing, there's a GitHub repo for it. It might be the homepage of the upstream project. It might be the Fedora apps page of the actual application, depending on what's going to be most appropriate for where can I go to find out more information about this? The, so, are we missing anything else? Actually I have an example completed one but I haven't looked at it yet. Anybody? No, it's like that was all I had. Okay. So now the actual build for this is really pretty simple. So, you know, we might be passing some environment variables in this case to change pagination behavior because you don't, to make it compatible with the calculator. And then we're going to install some packages. And you always want to end your packet installation if you're using the full image with full DNF, with DNF clean all. And the reason for that is, you don't want to be adding the DNF cache to the size of the container. It doesn't seem to be part of the dialog. Yeah. Oh, okay. We should add that. We're going to file an issue on atomic WG. I'm going to file an issue on atomic WG. I'm going to file an issue on atomic WG. Is that on preserve? Mm-hmm. Yeah, I figure. Yeah. Yeah. Preserve. I don't know how to pronounce that. I don't know how to pronounce that. So, Dan was suggesting that actually the run command should be first so that you can readily change the labels without needing to rebuild. The, we need to discuss that in the working group because my experience has been opposite, which is that the labels are relatively static, whereas I'm constantly tinkering with how to install stuff. Yeah. If you're editing an old one. Or doing, yeah. So, the guidelines currently don't say that because, Yeah, because it depends. And then the last thing you need is a command or entry point. And how this works is going to, again, depend on what kind of container you're doing. The basic sort of guideline is if this is going to be a container that runs utility that the user is going to want to send extra commands or something to, that you probably want an entry point. Like in this case with Caliphate, we can be using as a command line utility. Whereas if the container is gonna be running something like a demon that's going to run in the background or something, you probably want a command. And then the user will swap out the command depending on what they want to do. So for example, in the Postgres container, we have a command that actually starts up Postgres. But the idea is that if the user wants to use a Postgres as backup utility, they override that command to actually use base backup. But in this case, we want an entry point because we're going to be sending calculations to this Caliph command. So I'm not going to build this again. I just had a question about the run line. Under what circumstances is that cached? Is that layer cached? Because I've seen a case where like the yum repo changes and I try to rebuild a container, but it just says it's already run that. You know, it uses that layer for the cache and it does not actually install the package I want to install. It doesn't in the build system because it's not cached. The pod's torn down so there's no local cache. Well, I think he's talking about the Docker's cache. Yeah, I mean, locally, basically anything up to your current layer. Right, anything up to the last layer that you change will be cached. But if you change the Docker file, but if I like resubmit a build. Right, but I have to double check this, but I don't think OpenShift builds like cached the layer by default. Because otherwise- I don't know whether or not the build got allocated to the same node, but just like if you don't change the labels, they'll reuse those layers. Well, no, but you can tell it not to, and I think by default it tells it not to, because otherwise, because you can like Docker build dash dash no cache or something, and I think by default it doesn't cache, otherwise it would miss certain changes. I just double checked it, but that was my impression. Well, I guess we did some weird behavior notes, but yeah, so maybe that's a, maybe it's a note. Okay, so- But I'm actually curious, I want to follow up. Yeah, okay. So, and then of course, there's a last step for this, which is obviously that you need to test the container. Right, you need to actually build and test the container yourself. Now, I'm not going to demonstrate building it because we're in conference Wi-Fi here, and it would probably conk out, but we can go ahead and test running it. So, go ahead and consider the calculation. There we go. So, running it in passing a parameter mode, we can also run it in interactive mode, and then we actually get a calculator. Oh, and see, we've already found a bug here, which is that when I actually disconnect from the calculator, I get an error. So, we need to actually figure out how to fix that. The, and that actually probably involves messing with Docker's TTY settings, which would go in the usage example. So, that is your sort of build a container sort of thing and what the requirements are. Now, the one other kind of file that you might be supplying with a container is that many containers, particularly for server services, for things like databases, web servers, application servers, et cetera, will have a custom entry point script, either as if it's a system D container or as a system D definition file, service definition file, or if you're running it in an ad-hoc way as some kind of a shell script to start things up. And so, that might be the one other kind of file that you're attaching to your submission. So, if you wanna actually grab this back, once you've actually put all this together, you wanna take it up with the submission process? Sure. You're gonna do it on my computer, you're gonna do it on yours. Yeah, that's fine. Okay. Josh, you wanna copy that finished example somewhere so we can use it as a starting point? Sure. But I mean, wait, that's already submitted review. Yeah, but you just fixed a bunch of stuff. Yup. I don't wanna redo all that. Yeah, but that's Matt's problem. I wanna take his stencil, copy it, and then I'll create my own container. Oh, okay. I'll paste it in new. You don't have to do it right now. I'll paste it in new. I'll start in just a second. Okay. I'm losing you guys, sorry. Okay. I'll mention any known trivial container build is gonna take a while on this one. Yeah, that's a fair point. Which is right, which is why we're gonna have you, which is why we're gonna have you write files but not actually build the containers. Okay, just quick show of hands. Who here is a Fedora Packager? All right, almost everyone. So the process you go through to, I mean, I'm just gonna like kind of short line some of it. Well, I won't complete it because there are a few people in here who are not. The process you're gonna go to is pretty much identical to what you do for a Fedora Packager review. So to begin with, you will actually go into Bugzilla and, well actually to begin with, you need a sponsor to become a Packager. So you can submit things without being a Packager before it is approved. You will need a sponsor and it's basically somebody who will kind of show you the ropes and they will be your point of contact when you need help or assistance or have questions about any of the environment, any of the guidelines, that kind of stuff. So we have a mentorship program set up and the atomic working group is the point of contact for that. So if you're gonna submit your first ever or if you're already a Packager, you can kind of skip the potential mentorship process but you have to submit a package for a RIP or SO request or a review review. Oh geez, oh that's a function. Okay, so we have a URL in the wiki on the review guidelines page that will allow you your mouse orientation backwards. Oh, sorry. That's okay, I'm pretty confused. So if you go to our review process page, it kind of dialogues this in the written word. It's relatively verbose because I shamelessly borrowed a lot of the information from the RPM page but we did actually update a handful of things. We have our sponsor ticket system and then we fill out a request in bugzilla that URL sets you up directly into the container review component namespace and sets you up with our template and you'll fill in your template information, the main component name that you're using, a short summary of what that is, the container built info URL and that should be a URL to a directory containing your Docker file and the scripts that you need to go along with your Docker file or simply URL to your Docker file if you're specifically just, you're not adding anything, it's just all self-contained there. Your full description there and then your fast user name for adding that in the admin blank BCS. So yeah, and then what you'll do is you will go ahead and add the Fedora review flag just like you normally do in RPM space. You'll go ahead and set it to, somebody will come along and set it to a question mark saying that they are in the process of reviewing it. You'll get updates and feedback and that kind of thing, recommendations for altering it if it's necessary. Then once it's approved, you'll get a little plus symbol, get approved, you can go through into the builds and the big thing, the big difference, oh, we lost the pointer. The big difference is Fed Package Container Builds. So once you have it available in diskit and you are actually pushing this into diskit, into the container namespace, you are going to do a Fed Package Container Dash Build instead of a Fed Package Build because that tells Koji what to do, because instead of having Koji just kind of like figure it out, we actually talked about that a little bit and we were like, what if we just, but we're kind of worried that somebody might like try to troll us and put both a Docker file and a spec file in diskit just to see how that went down. I guess realistically we would just, one of them would win and then it would do the wrong thing. Yeah, so anyways, so you're going to go through the view process very much so like you did and I mentioned this in the previous session, but I'll mention it now and a big goal with this was to have the review process and the workflow be very similar to how RPM maintainers in Fedora already interact and already work with the project because we wanted, wanted there to not be something that was very alien to people already well established with the project and wanted to build on some of that range. So for the reviewer, for those of us who are already container reviewers and those in the group today are going to go through some of this as well as you will effectively do the mental exercise that Josh has went through except you're not going to edit for them explicitly so much as provide feedback in the sense of offering suggestions or pointing out areas in the guidelines that need to be addressed. So let's get going. So for step number one, everybody should pick a partner because you know, it's containers we're agile so we're going to be doing some pair programming here. So everybody should pick a partner to work on a container definition one. So we're creating new ones? Are we reviewing it? You're creating new ones. We should probably. If that makes a difference, which partner are you getting? Because you've done it. Yeah, but it's probably better here. Yeah, also feel free to take a go and make sure I'm not. Because you know, people make sure most people here are at least in some degrees. No, I'm not perfect at this point. So we're going to hire a container and a partner. Okay. Also, what are you doing up here? Since he's like, doing the reporting stuff. Well, I just have to press a buzz in there. Also on Josh? Yeah, but like, you can't see the screen at all. I tried like shifting it a little bit. It's like, the lighting is too bad. It's too bright compared to the. That's why I put the video recording the other way. Okay. So having chosen a partner, you and your partner need to pick a container definition to work on. Because like I said, what we need most right now is people to package things as containers. For those of you who are already fedora packages, one of the easiest things for you to do would be to take one of the packages you maintain as an RPM and containerize it. You know, for those of you who aren't or for others, maybe. That assumes it makes sense to containerize it. It assumes it makes sense to containerize it. The, you might want to, you know, there might be an application that you use a lot that you care a lot about and you know a lot about and you want to containerize that. So maybe some of you already have some stuff that leaps to mind if you want to containerize something. If you don't, I have a bunch of suggestions here. And some of this stuff might be a, well, why do I want to containerize that but consider that on atomic host and atomic work station, we no longer necessarily install these things as packages. And so there's a pretty good reason to containerize them. So I have one set of suggestions here. There's a thing in the back of the room that's better for what you're running. Ever been fine. I have a bunch of containers for things here that are relatively simple command line utilities, simple in terms of that they may be taken input and an output or need to bind against a single volume as opposed to needing some sort of complicated security allocation. And that includes things like Pandoc, SQLite and client server mode, alternate editors, which I would really love to have on atomic host as containers. Yeah. Can I start with the room because I really kind of stopped the anti-pattern of what atomic host is. You want to install packages in containers, right? Right. I guess there's a question for a lot of stuff like, do you actually want a separate container? My work station, I'm sure, is like, it has chunks of that stuff. So it gets, and in that case, we do want to be RPMs because you're building, you're making packages. There's no one answer to this, but I guess I just, yeah, anytime someone says that. Yeah, but it's just a thing like, I'm taking for example, Pandoc, right? I think Pandoc's a good example. If I want Pandoc to be part of the build process, then I actually want to put it in a container so that I can orchestrate it. You follow me? Aggregate it into a build group. Well, I guess this actually gets in the whole topic of, there's no, like in R, oh, yes, I can't do that. Yeah, I think the consolidate versus specify is probably not a good discussion if it's worked out. Yeah, probably. And we should take it up later on when we have beer. The, because that discussion has never been satisfactorily answered for any... It's called the editor, for example. Yeah. Right. Yeah. So for those of you who are more familiar with building containers and with a lot of the requirements and that sort of thing and have specific stuff, here are more sophisticated containers that we could really use because a lot of these are server utilities. So for example, we actually don't have a canonical Ansible container, which would be nice to have. That's complicated though, because you have to deal with like, how do I mount in the SSH keys and that sort of thing. You know, and I've got a suggestion of a bunch of other utilities that are server utilities, you know, and services that we should have canonical containers for. Yes? I'm looking at the door of Docker files. Yeah. Before this layer in the build system existed, we had basically a PlayGrid and Docker file example. Yes, and if you wanna start based on the Fedora Docker files, that would be a good starting place. Oh, up on. Yeah. Okay, forever that thing. Yep. So what? So anyway, with your partner, pick something. We're gonna take about 40 minutes to work on an example Docker file for whatever that thing is that you're trying to containerize. And then you're going to swap with another team who will review that. So go ahead and go now. I'd like to review for Pmax, I'll show you something. My battery's dying. So I'm gonna go and I'll work on the container. There's a power strip up here from the front, right? Yep. I'm hanging a bunch of things in the CD plan. Yeah, I'm gonna bomb her down. At least she's wondering if I need to do this here. So, let's go ahead and say it. Oh, no, wait. Oh, you mean just... So I guess, in a sense... This is one. Can I unplug it and I'll bring it back? No, I mean, that's actually the video recording left. No, no, no, I mean, this is not plugged. I don't know who this is. Oh, okay, well then, go ahead. Is this yours? No, it's not mine. Well, I'm gonna give it back to whoever... I don't even know what you guys are talking about. I mean, I can see why it's moved on here. I don't know. I probably don't want to do that. I don't know, it's okay. We probably don't want to do it. It's awesome if you really want to do it. Was there any update on the store to see that? Maybe, maybe that. Yeah. But I think that the other thing that you guys need to know is why it's the wrong thing to do. Okay. All right. I want to do it. All right, so there's a couple of these. Are already being worked on. Yeah, I should say. Well, I'm really not a fan of it. Really, people are. Are there any things? Yeah. Well, I know it doesn't matter if I have to do it or not. Well, what? Okay, okay, okay. There's nothing there. Not you, oh, you're getting paced. Because I think you're already... No, wait a minute, there's a lot of backwards. All right, well then. AJ probably said he said they're being worked on. Yeah. Should we just start off? Okay. I'm gonna mention that. Is there anything you guys are saying? Yeah. Oh, he did. I thought anybody was gonna pick that up. Well, we will answer that. Yeah, he. I'll have him on my phone. He's gonna answer that. So he's possibly gonna go. So. What's an entry point for Scicoth? Hm? The open study. What? I don't know. What's the entry point for the Python back? The Python back. Look at the Python three container and see what the entry point is. Yeah, I don't know. That's. Yeah. So if you pick one of these from this list, then maybe we should coordinate so we don't all work on the same thing. So if you pick one from the list, maybe you come up here and we'll like write it. Oh actually no, we've got a nice way to put it here. So if you want to go, what are you guys working on? Panda. Panda. Okay, what are you two guys working on? What are you guys working on? So there's this major eye. Yeah? Okay. You know, I was actually going to ask the audience if they actually need it. I asked it in the poll. I think it's a little funny. Yeah, it's not really a news. You're going to ask them to work? No, dance it theoretically. Actually, just have to write it. It's a process. What are you guys working on? Brass. Brass? Brass. Brass So basically if you guys brought this, one post that you're going to have the certification, it's not recommended. Obviously. But it's the more active, it's the more active. It's the best version. Awesome. And it's actually what we're trying to do. Yes. Actually, I'm pretty sure we can take our label on this. Oh, no. Hey, Josh, do you have the marker? Oh, no, no. So what are you going to do? We can, uh, um, um, um, so just to make Oh, yeah, so the other pad is either pad.osuosl.org, uh, calc underscore container. Yeah. Um, just have a little case. Yeah. And we're going to label it here. Yes. It does the, uh, uppercase all of the containers that you're officially opening. I'm actually happy about that. You guys know what we're going to do. I can't blow up the URL and the right now it's not responding. So hold on. Hold on. There we go. Okay. I don't know what to do. I don't know what to do. So. Is it, is it? Just wait a minute. Yeah. Yes. All of these, um, STL... So nothing natural with the other two. You know, it's just anything in it. I don't need to install this. I just didn't want to, I don't really want to install it. Let's say you just run Docker, What do I find the source for? The important ones after that was I either have a user or I see I just admit it's a new answer So there's just like a brand or a user that uses just a label but run will be used by like, for example, a comic book author when you run a comic book it'll run that way So if you wanted to have like a you can actually have a question first so it's up to you if you want to have a user Yeah the bit, I mean if you try to gem install something, the build will fail Oh that's where it was If I can get the back button then I need to look at the stuff You can have the back button but that's wet a little bit Let's pass one, it was very strange because we kept having heat waves in the road Yeah this year it went back and forth a few times So there's a question See and I usually just like Yeah you want me to write it down Yeah I just realized that we actually need something here Yeah Alright never mind They're doing engine X already Yeah So Which Actually I actually would not do that Yeah That is up to you Let me actually see if I can fix it Does anybody working on a container that's not written down on the worksheet? I know you probably can't read it This is really simple Now right now you actually have to put it in there That's optional So installing an installer for Atomic CLI So So 263 We basically needed to install an installer So Alright so it should work And like So Now here's the thing Even though you have that That's still It's already not for run So actually run a commander So the run is what the actual commander will be How do you make sure about that? It does So like It's like a complicated Say you have a complicated container You need to provide this rocket And that's what you would do What kind of like Yeah It depends If you wanted to do something special Every end you would probably have this But if you're building on top of another It doesn't have an entry point So if it has an empty Directive in the container itself Then you would run it And it will actually call this command Directive on top of Whatever other options you give it Not there So Feel free to do it though Just try to go Yeah, but we don't need to do that So basically for Cal So the label In this case Run and help That is what I'm going to do The left I believe so I'm going to do that from time There are many different This is the main update I want to get right into it So Basically You know you have to At least you have the front There's no That's actually a good Good Is it right? Yeah It's an exact thing Okay Like obviously A user If they work at all This is your This is the actual format Maybe you just put it in Okay so you have Specifically it's not like You just pick something and read it Yeah So So So Right So So So So So So So So So So So So So So So So So So So basically it would just be one that's down here is actually from registry.org part of the Let's go. I'm going to just run dnf in this box. You know what we're thinking? We might as well just drop right down here. They could fill it all the way. So that's probably an optional malware. Okay. That's it. Now agree. Right. The good thing about this is the color. And then like the other thing that would probably bind them is for example is Right. But then it would also be for make sure. Right. That's the build that's probably going to help. Ah. Yeah. That was for view. Yeah. So you can technically include. I agree that another issue in the working room. The guidelines don't have an example. Basically they don't have to copy, read me or help me. Shush. Yes. Oh, no, no, no, no. It's like this. Sorry. I forgot what I was going to say. So in the internal name space it doesn't say. And then you probably have to find the version. And then this. So this. So the version of this is not the version of. The version of. Yeah. So that would be released. It would be anything. Okay. I thought one thing that we. One thing that we would want to do. Because that basically say this is how you. And then you just run. So they're all going to have to do. They're all going to have to find your own. Because. Probably. Okay. So. So what would it be. Just like. So I just create like any of. Like. Wow. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. And they would take that one for an AED. And again, sorry, I was thinking about that. So, um, okay. So, let's read this before this FTC session. It's probably, like, whatever you're talking about. So that says to remove the container when you stop filming. That's probably not what you're going to see here. This is going to be a long run. So we'll probably do Dr. Ron that on the team. He says demonize. Well, there's, uh, there's not. Okay, right. So just run by the image ID. See if that works. Yep. In this case, we'll actually, you know, like, we'll let's say that it's not slash maybe dot com. So, like, for example, we're indicating that this is actually... So what happens is, uh, if you run the container, I think... This is a file that the user's going to create. So, like, do, like, slash half slash two, at the name be dot com. So this is more or less... No, you're going to swamp with another container. But you still want... Yes. But we still want name be dot five. This is a half to two. Right. So that's, like, this is our name that we provide. Right. And we're overriding. So does this sometimes have this work? So now... There's oil and brush disease. And we also need the other one, too, right? You know, we're going to be... Mike, if you're outside, try to do slash zone fires. Right. Assuming that was provided. I'll put it. They have to... They don't have to. Right. So if you ask them, if they're creating a zone, they have to do it. Right. So when you get a container, it's a nice container. It doesn't actually... Right. So for example, I'm running this in an environment that it doesn't actually... Right. So we have to do zone fires. Right. So it's a directory. So you have to... Um, basically... Yeah. And if it were basically... Okay. It's a zone fire. Okay. So... It's... Because basically what it's saying... It could be noted that people couldn't actually... So like... Well, exactly. Yeah. So... Anyway. So... Um, it's... It's getting time to swap for a review. So if you can take whatever you have... Um, and put it on, say, F-Paste. So you can take whatever you have and put it on, um, a text sharing site. Right. Then... You're going to... Switch with another team who's going to review your container thing as if it was a container review submit. And you'll review theirs. So I guess this team and that team... Yeah. Right. Yeah. You know, long-distance team. Because it's so used to working remote. They can actually... So if you guys... Yeah, I think we did. Okay. What? I think we did. Thanks to you. Thanks. Um... Because, yeah, you two, but then we're... We're actually short-run parents. I already did. So... Three teams are going to get a little bit more complicated. You're going to review their container. Well, we were not together. We were not the same thing. Okay. So you're reviewing... Okay. Okay. Ha! That's fine. That worked out quite well. Yeah. Okay. So anyway, so... Upload or paste your stuff and then... Do reviews. So we're not quite ready for, like, a full container review. Yeah. But you can review whatever, you know... You're not submitting it to Bugzilla yet. You're not submitting it to Bug... You know what I'm not telling you to submit it to Bugzilla? Too late. Yeah? I mean, you can. Well, if you think it's ready to submit to Bugzilla, then do that and have them review the Bugzilla fan. The fact that we can't really go on. Yes. So do we want to trade computers? Okay. Yeah, just... So go... Share it on FFACES or something and just pass the link around. All right. So go ahead and start revealing. And we will review for another seven minutes. I know. I was gonna update... Give... It's not you. He's... If you're doing it to FFACES or something, it's actually an 8-0 point. I don't have the file. Or the main guy. You gotta still get it. Are you having fun with it? I'm not gonna have fun with it. Telling the team... And the question is, like, what... There's, like, running this for a while, and you don't have to be on your vlog, right? Yeah. So we're gonna... So... When there's more coming to human, and there's more to allows, you're gonna have to be on your vlog. They see you as passionate. What? Yeah. So it's, like... Normally, yeah. You're gonna get a key part. Yeah. So you see a message going on, which kind of makes the workload jump around. Yeah. Yeah. DM's. It's a particular workflow. You're like, hey... I'm supposed to find a CPU limit, and I would like that limit to come on. I mean, that's a... That way I can have cash with one thing or another. And... Because it knows it's going to run. Right. For which set, of course. So you use CPU sets to, basically, take the pod, bind it to... and then push other pods off of the CPU. I have a winner. It's... And that's, like, a cube with low CPU. Yeah. Yeah. Because it's kind of, you can't put the user passes down by using an inter-CPU value. So, I guess my window... So it's a lot of... quality of service. And so, it's like... It's not explicit. Exactly. Because you can't have anything explicit. Yeah. We don't want to say, you know, hey, if I need to... Yeah. Yeah. So... Yeah, it's just so... You don't drive me crazy. It's like... Crazy. And then, like... Well, I'm not... I'm not... I can't notice any of this. Ah! Okay. Just... Oh, don't worry. I'm furthering by it. Yeah. Yeah. Thank you. It's okay. Oh. Thank you. It will basically print those labels in, and then we're going to wait for it to pass that. There's actually an S2I base. I use Pandoc like this S2I base. I would actually suggest, like, so what I use it for is I use it to, like, actually mount it, like, and then I'll run Pandoc, Dash, whatever it is. So, if you add, like, a readme to it along with the stocking file, that would be great. Because otherwise, in this case, you're running Pandoc inside the container and you're not bringing it in positive from the outside. Which we shouldn't mount it in. But you don't necessarily, like, in your example, the usage example, you could say, like, pass two more files. And there is, um, you could use it in a more complicated way, or you could just say, like, it's common. But there's just an ancient mention that actually comes from some of these people. Say what? The combat run that can be done in IOS. So what? For example, so let's look at our S2I stuff. Where does that end up with designation? So, check it out. Yeah, I don't know. It's a pretty cool thing. And you could actually do, like, a bunch of stuff. Yeah, but I don't remember, like, why this is current work, or what, why we can find that way. But it was something, like, I, of the team, or something like that. Right. Well, among the other things, I don't know. I think we're doing the same thing. Yeah, it does. And then I have my own. Yeah, because the idea is that they want to have a way to get Dr. Hub based on unique labels. So, yeah. Well, I don't like it. I thought it was a run. I don't like it. It was the run, like, I think it's the word. And my favorite example of this is, if you go and you find a new way of doing it, you're not going to be able to publish it. And you're not going to be able to see what you are right now. Oh, that's a double. Yeah, I added that. So that's basically the build system. What do you actually want to test? I think it's much better. Yeah, there was an article published about this recently. It might not even have something on it. So, how would you do that? We have to introduce the environment. I'll show you here. What? Which is that? In the build system, if what you see is going to be automated, it's a lot better than the build system. No. It's a Paran image. Oh, why? Jesus, why? It comes from the Paran image. Okay, got it. So the answer is it comes from the Paran image. Yeah, I didn't know it was Paran. Oops, that is not the one to have it. Yeah. From your presentation. From? There we are. I don't play to know all the ramifications, but running the multiple clusters. Okay, so that's your answer. Okay. Okay. So, hold on. So are people pretty much finished with the reviews? Mostly. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So are people pretty much finished with the reviews? Mostly. Okay. All right, now we're good. What up? Because we're finishing up soon. Okay. So. So if you guys could finish with the reviews in the next minute. Okay. Okay. Okay. Okay. Okay. So are we done? With the reviews? Yeah. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So are you guys finished with the reviews, or any questions that you have? I haven't answered any of those, but it's all right. So, So basically, I stop a run, I say remove this, and I say outline, I'm like into the first year of my day and I also make that work. I'm more of a man of arms than a man of arms. I'm more of a man of arms than a man of arms. Either way, and then, I hear what needs to go in this place. So, and basically at that point, what I can do is I can run tandoff, dash, this, and then I can actually convert it into a spark. With this directory, this can be our home directory. Now we can access the game control. Tandoff will run some food items from the local directory. Anyway, then the master can fit in all files. So it's just like running. Okay, so if we are done with the reviews. So I want a couple of things to happen now. One is, I set up an etherpad. The URL is here. Containers from Workshop. I, except for the person who submitted something to Bugzilla, if the rest of you could put a link in that etherpad to wherever you have your sort of container source material, the F paste or wherever, so we can find it after this workshop. And so then, well people are doing that have a question for each reviewer team, right? So how many people got as far as having a container definition in submitable or pretty close to submitable? I mean like, you would feel reasonably okay with opening a Bugzilla ticket for, here's my container with my Docker file. I think we were good on the Docker file, but what we were doing needed like, a very extensive review. Right, so we would probably need to add a reviewer. Okay, showing people how to use it. Yeah, but like for initial, like Bugzilla page, and you're kicking off on your computer. Right, so okay, so, and here I'm asking the reviewers who reviewed somebody else's stuff. So how many people feel the thing you're reviewing is in pretty close to submitable shape? Okay, a lot fewer hands went up. So wait, there and, there and there, okay. Well, given that you couldn't actually test that. Okay, no, no, so keep your hand up. Keep it up, if, okay. So if the other team, was there anybody else pretty close to submitable shape? Yeah, okay. So there's a fair number of people here. So what was your container? What was the container you were reviewing? Sorry, fine. We're reviewing Panda. We're reviewing Panda. And you guys are reviewing... Reviewing what? Sci-Fi. And what were you reviewing? Spider. People got a lot further along with this. Is there any team without a member of Red Hat? Yeah, who in this room does not work for Red Hat? Winners. Okay, it's promising, yeah. This room does not work for Red Hat. Oh, I can't answer that anymore. Please, I might quit right now. Wait a minute, you have one of these. I perhaps have one. Yes, okay. Yes, outside contributors. Yeah, that's awesome. Okay, so please, yeah, please everybody get yours up here. I mean, obviously what we really want you to do is take this home, finish it up, and submit it through Bugzilla, so that we can review it and we can actually get it into the Fedora library. Yep. So this is... There we go. Containers from Workshop. Yeah. That's exactly what you do on the system. That's exactly what... I mean, you can do hands-on, I don't even want to. Yeah, so now we can have you on this list and we're going to get... I'm just saying, like, you can... At this point, you don't have to... Yeah, the only thing that you can do is that you can't access any problems. That's not cool. That's the only thing that makes this different. I don't know. More specifically, it's open. That's amazing. I don't know what you're talking about. Well, I mean... So if you have to do hand-on, and I think you can actually pull this... What's funny is, I actually have one PDFTK. It's actually not a problem, but PDFTK is actually to stop me and make sure I'll have the door. So like, I still have a container. That is... Fedora 220. This is a container on Docker Hub. That's Fedora 20. And I actually devised a way to run this, but I'm not using Docker. It's been so long since I've played it. PDFTK, I did the same thing. Same model. Because there's... There's no PDFTK. So I'm like... It takes space in the container, but what it means is that... These little... You know... Okay. Great. Well, thank you, everybody. Please submit those when you get a chance. And take patches and pins and other things.