 Okay, so I don't want to talk to the mic because I want this to be a discussion So we prepared some content for you and some topics to discuss And in the end I would love to if this was discussion, so I'm not sure how useful this will be for the recording Okay, so why we are here? so we have like containers for some time and They have they've been integrated into Fender infrastructure, so we have built system We have registry we have package review process or like container review process and they are all there and like the reason for this fork shop is How to improve it? What can we do better? Which parts of the infrastructure we can improve or change or swap or whatever? That's one thing But for that we need one person and that is Clement Verna But he's not here right now because they are having Infrastructure planning meeting or something like that, but he will join later so Clement is actually the person who is maintaining the Fedora build system for container midges and He's been working for on it for past six months and He put plenty of ideas into the etherpad like what can we discuss today or like what can we plan for and One of the most important things of those is the creation of the new container Sieg within Fedora So the way this worked in Fedora is that there was atomic working group and Atomic working group for discovering Fedora atomic host and also container build system and containers themselves But it was working like best efforts. So so some issues were left open for Long time some sorry not But recently So you heard there is this new thing Fedora coroS so so the current state is that we'll have new Sieg just for containers and we'll talk about Fedora build system and Like how to make it better and then there will be other Sieg for Fedora coroS So, yeah, we could definitely talk about or we will talk about it as Clements get here about the Sieg itself like who wants to be in it What we'll be working on which issues from the atomic working room will move to the container Sieg Okay, so that's one thing to discuss the other thing is that Probably one of the reasons I started this workshop was that our team was working on Automation of the container delivery process internally. So the thing is that internally we are using a lot of different tools to build and release container images than there in Fedora mainly the last part and Our team was working on like automating it as much as possible It's still not done But we already have some results and some tools and we would love to also use these tools within Fedora So we definitely want to discuss that The main issue is that not all of them are open source Because they are really closely tied to the internal infrastructure But it shouldn't be such a problem to add support for Fedora like Fed message or Bodhi and others But the core parts are open source. So we can definitely show those and talk about those This other part to discuss and obviously since we have much more people right now here We can also discuss things you are interested in. So this was just like this Interpet is this was just our ideas what we can talk about that what I'm assuming that you guys have much more So we can totally discuss those So I already do did in introduction. I'm not sure if we want to like introduce everyone If everyone want to introduce themselves since we already have quite a few people Okay So if you want to look at the text, maybe sit closer Okay, so it's control plus, right? Okay. Yeah, so so the URL is Okay, I'll copy it if you want to open it yourself This is the URL of the Interpet. Feel free to put anything inside. Please just don't erase it all That's the only source of the information in here. Okay, oh Come on. I have Mike in my hand Okay, so I already introduced the session our team. I'm not sure if we want to introduce each hour each Of us probably not really or if anyone wants to introduce themselves and have any idea what we can do here right now Now's the time Okay Pardon Yeah, he will come so they have the infrastructure planning and he said that he'll be late, but he'll definitely come Okay, so We covered that okay, so as soon as comment come we'll talk about the container sig So I guess that we can start talking about the automation. We've been working on So so we are actually working for Steph Walter and I'm assuming that you already seen Steph and I did some of his talks about automation and bots and other things so Since we are working on him We are trying to follow his philosophy and the way we approach the automation Newtonally is that we created bots and like Real bots so they have even names they have personalities and they have usually like one task to do and they try to do it well and Yes, I said right now they are mostly tied to the Internet infrastructure But we can definitely make it work with in Fedora So our team, which is actually in the first row. That's Dominica and Irka. So they already tried to do it But I guess that we can introduce the bots themselves Okay, so we already assigned tasks like who will be doing what So I can start like mine is first then Dominica Irka and Yeah, and mine is lost as well Okay, so internally What we decided like the thing is with the automation is that you can automate things But you still need humans to help you with the automation like Computers can't do anything. They are still they're still need for humans. So that's good for us And the thing is like how we'll both interact with humans. So usually that's email, right? But that's not interactive like usually you need to put some input So luckily Dominics team, which is OSCI they've been working on deploying pegger on top of this git internally as well So it works pretty much the same way as in Fedora And we decided that pull requests would be the centerpiece of the interaction between bots and humans So So our bots actually interact with pull requests. So for example, whenever Yeah, so whenever there is a new commit Like one bot can easily Initiate a scratch build of the container image and see like if the commit is sane And if it not it would report back to the pull request that hey Scratch build doesn't succeed or for example, the docker file has issues or whatever else So just to give you an example I created a pull request for one of my containers in Fedora and this is how it looks so So, yeah, the idea is that this this could be the centerpiece of Like of the collaboration between the automation system and and humans Yeah, so it's very simple. I just added one more package into the tools container image So any ideas here like is this good idea is this bad? Pardon, I don't fall Okay. Yeah, so Okay, so dusty agrees we are good Yeah, so this is the premise pretty much that We have modern workflow for development of software. So we have git we can take advantage of the multiple remotes We can do forks and we can do pull requests and this is how we can collaborate So this is what we actually start building from and Then we have next bot. His name is Dravo meal So for those of you who are who have Slavic ancestors, you probably know what the name means and for the others Sexually draw meal could be translated is like person who loves health in us and Draw meal is a bot which lins docker files and Dominica. Do you want to talk some more about it? Let me see Okay, so I'm ill as Stoner said is someone who likes health and he looks at all changes in In this kid. So when talking about Fedora, it's not implemented yet in Fedora as Thomas said but in the future It may be matter of weeks I think that we would be able to do it now So it could work in Fedora only thing we we have to do is link it to Fed message and listen for new I think New pull requests impact pressure on a new commits commits on Peugeot, so that can be trigger for drive a meal. It should be really easy to configure Then a driver mill runs linters using Colin Yes Okay, just look at it and don't listen to me that it's okay I'm glad. No. No, this is So we've we've created this rule sets or that it is sets of rule that are important for images including best practices and and also required labels and and stuff from OSBS and Colin that's actually hard of the rubber mill that's the rubber mill is just a just a wrapper above Colin Colin looks at the docker file and sees what is wrong and when he sees something wrong He actually sends email to a maintainer or or DD creator of the of the pull request so or now it is the Comet creator, but yes, well indeed in the future. It will be also possible to configure it so you can At any other persons on emails or RC channels where is that we all can send notifications about the results? And we were actually really successful with With the runs we had some thousands of run in a month. So I think that's quite great Okay, do you have it? Can I finish I have it in my in my notebook, but Okay My environment is broken. Sorry. I have here a docker file Or do I just just an empty file so we can see all the checks and for the for Fedora, I run Colin You can see that all failed because we have an empty file. So these are all the checks Show you for Fedora Just a quick demo, so that's it for me Okay, so any questions here, so I couldn't hear the question actually For historical reasons when we were first we started working on it internally We didn't have petr and we there were no pull requests. So we started to react to commits and actually In the next week, it will be react the erecting to new pull requests. Okay, so for The question was about rules like where they live and if you can add your own that's a really good question and So the answer like answer can be really long. So I'll try to Make each other. So what Colin is actually the project itself It's like the CLI tool plus API and then a bunch of checks Like for example checks for presence of labels presence of files presence of whatever else and you can easily add your own checks And then whenever you run Colin as Dominica showcased she she typed Colin and then used rule set Fedora and this is how we decided to like Make the connection between checks and like what you want to run So we call these things rule sets and rule sets contain list of rules And you can easily add your own rules. So for example, you can use existing code for checks and just like put different parameters to Check for presence of different files or labels Yeah, so this one thing and the other thing is you asked about like how can you add your own? So you can easily open a pull request against calling project and add your own checks but The thing is that internally, this is not good enough right now because we definitely want to have as much open source checks as possible But at the same time We have internal infrastructure and we also try to check for internal things which are like they don't have any value in In the open source project. So we want to have also like internal checks So in the end then we need to figure out how to take the open source thing then the internal thing and then glue it all together And this is what we've been working on like very recently And I'm planning to finish it like next week because we really need it actually from someone from your team So they can contribute checks to checks to it Yeah, Dennis Yeah, so do so please So I've been working to adapt the script we have to publish the base image On registry.fp.co and hopefully we will so do The current tool that we use to generate the manifest list doesn't support the authentication method of our registry so we have to Work on that I'll try to work on that next week and I hope by the end of this month we'll have at least the base image for multi-arch on the registry They are already on Docker Hub but it's using That's actually doesn't even depend from Fedora and Fra I think it's an other team that pushed us to to the Docker Hub. We just pinged them and they update them Yeah, but they ask from what I understood they ask someone else to do it I think also Moan did a change and we started to The plan is to start to push the raw ID image every every day the Raw ID base base image on the registry every day. So you'll have a fresh So the OSBS that is currently deployed in production support rebuild when the base image Change is not enabled yet. I can look at this also but Yeah, we have the latest OSBS in Fedora in production now, so we Atomic reactor is 311 I think now so I Think some of the nice thing I don't know if you if you went through the new features now quit The nice thing where I think we can use is the automatic release bump So we don't have to manage the release label in the Docker files When you trigger a build OSBS just take care of it. So that's quite nice And then automatically build when the base image is updated. I think that's Like the two main features that we we can we can try to enable Soon Yeah, I guess this I guess the second one really we will be really handy when rebuilding images You just push the new base image and all of the images will be revealed Yeah, then we can look at automating So we supposed to release new base image and Layered image every two weeks, but we haven't been really good at that Mostly because part of the time OSBS was broken and or we were busy with other things so the idea is to try to automate that as much as possible and use Fed message to trigger the rebuild the release We are we shouldn't be too far from having Container updates in body also so that will help making the release more More friendly So I would like to I know that Yakuza has been doing some work on poor PC 64 Ali But we'll be charting in boxes in the infra I Think the plan was to reuse some of the builder of poor PC 64 because they would be discount Yeah, they're going away in f29 But I would like also to have a h64 for IoT. I think it's the main is the main target so That will come last I guess I Think they well, I'm not supposed to have anything is just a matter of priority And I don't think we will be able to deploy them all together and and resources here. So Yeah Okay, so yeah, we might not have a lot of resources for S390 X Yeah, I think yeah Well in my head at least and if people have over over requests and things so another arch is more important Yeah, just please tell me and I'm happy to accommodate Another few things if we want to talk about do you do you have over? Over project to show Not also, I guess we can finish. Yeah, I think about automation and then we can talk about the container thing Okay, so So, yeah, that was the first boat for like checking healthiness of docker files or actually content images Then we have another boat which actually took a lot of time to do because it was not so trivial as we thought originally is that usually people have their like content image sources in the upstream and Then they just pull it to downstream to Fedora, for example, or internally to Red Hat And then try to build their content images from it But still they do all the hard work in the upstream in open source So for that we have both name betka and betka actually Sings the files from upstream to downstream. So you could we want to talk about it a little bit more I Said I don't have any demo I could just maybe show you read me from the private repository since you can't access it yourself Who wants to see the read me nobody? Okay, so Software collections SCL org has their repositories on github I think and Yeah, we use betka for that And so it checks the Betka configuration says what Like downstream repositories Wants to check or wants to be synced with upstream and so it periodically checks the upstream repositories and Once it found some new commits it makes poor request in Beggar and I think it also sends some notification email that there is this poor request opened And I think we are planning to change it to like using github to Fed message So it uses notifications and not checking periodically the upstreams and I think that's that's all Yes, so probably the more like the most tricky Tricky thing is to Is to actually like how do you configure this thing because Okay, so you have some boat running inside the infrastructure and then you want people to be easily able to Tell the boat that okay. This is my upstream repo. This is my downstream repo and for example this some configuration Which files should be copied? But how do you make the boat ever of this configuration without without restarting it or something like that? And I don't think we actually figure it out yet Could the configuration be Yes, yes, it could but still like the boat needs to discover that configuration first So it's like a chicken and neck problem Yeah It this is actually a really good idea. So okay, so there will be a message Like there's a new like new commit and a specific file But we will need to parse like every single message and like filter it somehow or I hear also sense You can configure webbooks. Mm-hmm. So we can just send the message only on commits. Mm-hmm. You can actually Trim down. Mm-hmm. I think that message you can't just like send But with webbooks you can choose But But but we but we need to probably enable it for all the like container Related repositories, but it's already good ideas. You could check with a pingoo if we can have some names-based Webbooks Yeah, sounds really good And if you realize like how powerful powerful this is like you can have your Maintainers work on the upstream repository and whenever they create a pull request upstream They can easily you can just sink it downstream and like try to integrate it into the distribution and see how it goes and Basically report the results back to upstream. So they get feedback right away as they are working on a new feature or something like that so yeah, so This is something very interesting and I'm really wondering if this is like also good for Fedora because for example, it's Talked about software collections. They actually have all of their images on their github repository Github organization and they even most of the repositories have Docker files for Fedora, so Yeah, this could be very interesting Yeah, so does this comment is Whether there is some like tooling or some like that to create Container images out of modules Is that correct? Like each SEL into a module So instead of having like Python like Postgres 9 5 9 6 9 7 Each one would be its own module and then you create containers based on those modules So I'll probably have like two answers for that. So So, yeah No So back in the day our team was actually working for modularity team So like all three of us and this was actually one of the cards We are trying to figure it out How could we automatically generate Docker files or even images from modules? But we are not able to finish it or like complete it because the issue is metadata You need to put all the metadata into module MD and then generate Docker file out of it Which sounds kind of okay, but then you would have specific metadata to the container images Which would not be relevant for other artifacts and we were not able to like Come to a conclusion like how this metadata would be stored inside. So So you already have files inside the module disk it which are related to flat packs. Yes Wow So we could directly We could directly create the containers from the module Yes, exactly Theoretically the people who maintain the RPN might not want to create a container But there's somebody else that wants to create a container out of it. So like a different But anyway We are definitely not like not planning to do this so Like dusty or others if you are interested in doing this You should probably reach out to modularity team and maybe discuss with them because this was already on the plate But we just were not able to execute So maybe this time around when Oven figured out how to do this for flat packs. We could do it similarly for Contain images as well Yeah, absolutely So I actually wrote a blog post about that on Fedora magazine that it's actually really beneficial to use Modules and specific versions inside content images and then we could easily solve the problem that hey We have this container image, but what is the version of my skill inside so we can easily tag it But we probably just need to do the final steps here Or maybe have the content actually the modules themselves version Okay, so what's next? Okay, so I won't spoil anything so we have another boat and I actually spoiled already So if you already have a pull request in pegger, you can easily create a scratch build out of it, right? So don't don't I want to talk about it a bit more Actually, it was kind of inspired by drama also, so yeah now can react on pull requests and changes in pull requests and creates scratch build We had some problem with it, and I think it will be Result soon because I don't know how it works in Fedora, but internally we couldn't Trigger trigger scratch builds on on forks because we don't have we didn't have branch that would be like Usable from from from building tools So so we were actually able to push the change Push people to make the change so we can make built on on on forks, and it will be Updating pull requests with flags that will Tell about the result of the build Since we have something similar for RPMs, there is some service listening and trying to do scratch builds in Koji I'm not sure if we would be able to like unify it to have like single code base to do both I don't know if any one of you know how this works for RPMs Because this is pretty much specific for our PM is using Fed package I Did I the loop have a look because I wanted to do it It wasn't very trivial, but we can we can take another look It's worth it's worth like getting the two code base and trying to The Koji Can't remember it's called it's called G Koji see Yeah, it was called something like that. Koji see eye or whatever. Yeah, it's pretty specific to Appians mm-hmm. Yeah, maybe in the end doesn't make sense to so merge them with just an idea Okay, so all right, okay, so we have Next item which is almost the last one for the automation part and that's Something how our boats are running actually so they are so I don't know Dominic. I will not talk about it or Yurko Okay So we have these boats travel Milbet, Cassolonia and we have also this uh-huh service which rules them all and so They they usually react on some event on some message bus and this who which is check word for Year listens on this message bus and submits a task for these boats and it's that The task it's we use salary for that So the boats listen on some queue and who submits the task since it's into the queue and once the boats gets takes it from the queue and performs it and That's basically it and Home for our boats. I don't know what you meant with that. So as you said they are mostly in our private repositories Okay, okay, so I didn't write it either Metaphorically I see it as as a home like everyone has there Yeah, okay, so that's it and finally we had also like body, but we already spoke about it a little bit I'm not sure if we covered it all. I know that Randy said that he would come but he then said that he needs to go to the infrastructure thing but what I was able to Ask him in the meantime was that like the support is already in both heat to be able to release container images So what we have so the code is in body The body server is configured to be able to push to the registry Moan created release in staging for F28 containers, I think for like so we have all the code g tags In place. We just need to try so I quickly tried last week, but Obviously didn't work first first tried it didn't work. So we need to investigate what's what's blocking there might be simple There's one thing we after it's more like Process, but we might want to Try to think how we use body do we want to use it the same way as rpm so For example Maybe we let we need to have lower requirements on karma or thing like that that might be Because most all our containers are using RPMs so It might make sense to have like a lower bit the gate for So and especially RPS from stable repository, right? Yeah. Yeah, that makes sense And how about the two weeks rebuilt like how would we handle that? so if we have this we've in combination with Automatic rebuild of the layer image. I would see that we would just rebuild the base image. Maybe Like every two weeks or weekly Then OSBS should Rebuild all the layer image and create the the body updates So some tooling would create the updates in both here, right and even attach the builds it would be Yeah, it would be it would be nice to have the 12 that Automated be able to use that message also here. Maybe to to see whenever we got like When we have a new build for a container image from from OSBS We could have like a service that just listen fed message and and create the body update Yeah, okay, so that's probably all for the automation. So if you have any questions can address them and if not We can talk about the sig but automation So currently the So the tools are open source, but the way to run them. Yeah. Yeah Yes Yes, so I think once we have them it's good opportunity to try to see how we can put them in in fedora infra open shift and that might be some good content for the sig and people to get involved to help us to like Deploy that in a infidora infra, I think yeah, that's a really great idea. I have one thing related to automation, I guess I Don't know whether you solve it already because I missed the beginning. So the Registry that is used for building is it's still a stable registry or I Believe that it should be possible to use the Can date register register for that because that would speed up the development a lot even without the outer boats and Stuff and we do it do it like internally. It's it's working We didn't talk about it. Okay, so maybe Open a ticket on the seag Yeah, oh, yeah, it's in atomic seag. Yeah, we can move it to the content. I think I It's just a configuration configuration change in in OSBS to do that. So Yeah, we can agree to To change that so do we talk about the sig like How would it work and It's probably not the good time. There's probably as many people in the room Yes, yeah, yeah, absolutely. Yeah, that's really great idea. That's the So there isn't much Yeah, cool, I just created pretty much the wiki page and I didn't want to put any kind of process or anything I think it's nicer if we decide together what we want to do We have also Category on the new discussion dot Fedora project dot org Well, I tried to put nothing there are like currently to Currently two topics there, but I think it would be nice to use this instead of mailing list Yeah, that's the discourse and you can log with your you can log in with your fast account So you don't need to have an extra account or anything It's just a bit more friendly for people to to use and like not buried as deep as mailing list and so So I started the Fred on ISC meeting I'm not a big fan of having 20,000 meetings per week, so I Wanted to see what people think about having a meeting and What if and if we should have a meeting What would be the The pace of it so monthly every two months or every week I Think we're like few comments about like having it maybe every every two weeks at the beginning so it's not like We just don't meet and say oh I didn't have time to do anything in one week So there's actually some progress to do After organization wise I think I I Created on on pagura group. So which I'm currently the only person in but I See I see this group as being the like or if you're interested to join that the sick just Join the group on Pagura and you have like access on the tickets and everything and that would be the No, we don't Group members is never So if people we can actually do this to now if people are interested to to join the CIG and I Can I can add you to to the group and Yeah, we can I think what the city said it's quite a good idea we can try to To least so I started on on Pagura. I started to put some tickets we can maybe feel more tickets also on on On what people actually want to want to try to do and maybe what they think the com to how they think the container effort in Fedora should should look like and That would be a good start I think No contest see yeah together So I actually have one question for dusty after he finishes writing like What's the future of atomic working group in Fedora? No, I really literally atomic working group like when it's gonna be like shut down and how and Like what's gonna happen? Okay, so it's probably now's the good time to start moving issues from atomic working group to the other working groups I know do we want to do it Okay Yeah, sounds like I mean this was actually my original intention to sit around the round table But there's just so many people that we wouldn't fit one Yeah, like yeah, so The question is about the atomic working group and kind of what's the future there I Think that's the sooner that we basically start the container CIG and obviously that's Kind of what we're here today for the better mainly because We're not having regular meetings for the atomic working group anymore because we've started kind of working on the Fedora Coro West stuff and Clamont showed up to the Fedora Coro West meetings and was like hey Are we interested in discussing containers here like we did in the atomic working group or should do we think it's worth having our own? You know special interest group for containers. I personally think is you know in the best interest of You know the container space being healthy for people to be able to show up to something that is focused Specifically on what they care about somebody might care about containers that Cares nothing about an immutable operating system, right? So that was one thing that we noticed in the atomic working group was people would show up We talk in a meeting for 45 minutes about something they didn't care about or we wouldn't get around to a topic at all That they cared about so you know they might not show up as much So the recommendation was you know, let's see if there's interest for a container CIG and he put out an email and obviously got a lot of Responses back, which I was like, you know super happy about So I you know I think obviously he's already made a repo not the one we're looking at right now But he's already made a repo where we can kind of organize a little bit and kind of choose You know if we want to do a weekly meeting or bi-weekly or something like that And actually have people sign up there and we can organize that way on the container CIG Group repo I Just started a new issue That is like hey, you know if you are interested in Like being a part of this, you know, just add a comment here that way It's really easy because like sometimes people come up to you and you're like, hey, I'd like to be involved in the group But like their name maps nothing to their fast ID or something like that And so if you just comment in here, you know exactly what their fast idea is if you mouse over their name It tells you what their name is or at least what they'd prefer to be called in fedora so if you go to the container CIG Slash container CIG Pagger repo and just add a comment to issue number three You know that lets Clamont know you're interested He knows your fast ID already if you want to add a comment saying why you're interested that might help, too But as far as migrating stuff away from like the atomic working group issue tracker I think he may have already had it up But there's a bunch of issues labeled containers Some of them are related to container run times. A lot of them are related to application containers some of them are related to like Governance like, you know guidelines and stuff like that Probably half of these things could be just not migrated. I I'd probably encourage you to use some judgment I'm not sure we could probably talk to Pingu and see if there's like an easy way to Migrate a bunch of issues over I'm there is okay It's a get repo right. Yeah, I didn't know if there'd be like some automated tooling or anything Yeah One pack of repo to another Look at that. Cool. Yeah, so something like that might be useful if you want to go through Individual tickets at some point We can do that. I mean like we could do that today theoretically I don't know if that's the best use of everybody's time here today or not So definitely open to ideas Right well, yeah Well, it also depends, you know if people are planning to stay here the whole time or go to another session Which I think oh actually Yeah, I've got another session or another thing at 3 30. Definitely. I'm not sure about this current time period But yeah, so Yeah, yeah that works Okay, cool. Is there anybody here today that's interested in the container sig? That you know Yeah, nice. Oh that like you know has a specific thing that they're looking to get out of it, right? He's like, you know, not many people do things in open source without wanting something out of it That's what makes it work. You are by nature selfish. You want to achieve a goal. This is why you were helping, right? You know, like I think everybody's you know doing it out of the goodness of their own heart But that doesn't last over time So like is there anybody here that like has a particular thing or a particular agenda they want to advance? We know Dennis wants multi-arch really hard. So we're happy about that But is there any Multi-arch for you to okay But is there anybody here like, you know from the community Chris? Gotcha So we've got Christian here and he wants to Learn how to Get some applications within fedora that he cares about packaged in containers so that he can use them as containers Which is awesome. That's a great reason This might be a wider community thing, but I Think currently if you want to package a container you have to be a package and oh currently yes Yeah, which is which is I think that was mostly because That was the easiest thing to implement Yeah, right, which is not necessarily good because like somebody might be a great container packager that never did are Yeah, for example, well if I take my case I But you prefer doing Dockerfiles and like that would be much more interesting in packaging containers than the RPMs But it's just like like personal interest. I think it's maybe so I know that now We can push to this gets using Fox and HTTPS so It might be also a good good time to can we actually do that. Yeah, it's been deployed last Week or so like if they do a fork and they make a commit locally and they want to push you can do a pull request now Yeah, you don't have to do it from like another remote pull request You can but it you said over HTTPS So it doesn't work with SSH key you have to like push and then like log in with your FAZ user name a user ID and password I haven't tried either way. That's awesome Because that's you know, we had the we have the pull request model now But if you're not a package or you can actually you can do pull request now. Yeah, so I'm not sure what's the user Experience, but you can you can do pull request as non-packager now. So nice That's maybe one thing we want to do or we want also to consider having Like container maintenance, right? Yeah, so the the take away from that is we may want to We may want to lower the barrier to entry for For people who want to do containers to not have to have them be in the package or group first So we make like a new Container or group. No, that's a bad name, but you know what I'm saying. Yeah Yeah But yeah, so I think that'd be a great You know thing for the working group to pick up and like consider as an agenda. They'd look they'd like to push Because I'm sure that's a barrier to entry for people It's like of course, I'd love to have this because like I already you know, maybe the Maintainer of said package that I want to use in a container You know is a great maintainer for the RPM But has no interest in running it as a container So they're not going to do the work to like, you know create a docker file or whatever else for it But I would love to but I'm not a package right so like that would that would be great I love that I Think this is more It would be good to have like wider like people that are not present there to have their input also so Yeah, that could probably easily be like a topic for for this I would say for a first meeting But that wouldn't make sense necessarily what hey We're gonna meet to talk about when we're gonna meet except when should we meet to do that? Yeah, yeah, we could do do we have a mailing list yet, or is it we just do we're just doing discourse or so we have a mailing list but I Personally don't like to have to look at two different places to get information, right? So I'm not opposed we have the mailing list so we can use it But if it would be nice to have just like at least there's a clear message. We already have like the tickets in Pager So it would be all you have to go and check in Pager you have to do in checking You're right here here would be my suggestion and more or less Create an issue in Pager. We have a sig Pager now and then draw attention to it from other places So like if you have a mailing list Send out a message on the mailing list that says hey, I want to draw your attention to you know Helping us decide our meeting time. Can you comment over in Pager? So I don't have the don't have the conversation on the mailing list. Let's have the conversation over here There's a single place for that And then like maybe even CC the bell list so people who haven't yet signed up for the container sig mailing list Also get that information Except both of those are funnels into the correct place to have the conversation So that would be my suggestion and you'll probably get a pretty good idea of when to have the first meeting And then people can show up at the first meeting and say this meeting time sucks. Let's change it So I think that should work pretty well Yeah, when is good. Yeah, that's true Yeah, yeah, that's something we're trying to work through in the Fedora core as working group Because like we have mailing lists. We have discourse We have Pager you know the kind of the guidelines that we are Floating towards over there is Discourse is kind of like a forum so like to me that you know a user says hey, I'm trying to do XYZ and I'm hitting a problem So like more user-facing stuff and the Pager Tracker is more like hey You know should we change the root file system to XYZ, right? So like more design type stuff or like governance type stuff and then the mailing list is like Announcements or drawing your attention to something else where we can't have discussions there, but you know obviously people aren't as Interested in following mailing lists as much as they used to be so like we're trying to explore different avenues for for different things I'm gonna stop talking now Bad I Have We want to discuss like the focus of the working group in detail So one thing actually I wanted to discuss is that we are probably the mayor of the repository which is Project Atomic Slash container image label something like very long repository name and it's the home of like definitions of labels like what labels should be put on images but unfortunately it's not maintained anymore pretty much. I mean I open an issue and sit there for months and no one responds. So as far as I remember originally or the last maintain was supposed to be R on the way to come but so yeah my question is like what do we do about it? Like do we still follow the repository with guidelines for labels or do we just like... I think we are in the key of the guidelines we have to expect that people have been on this list. The other option is hey what's the status of these labels? Is it still recommended that we... No, no, I'm not talking about... He's talking about the Project Atomic. Like basically we equaled some definitions from... There have been some labels about... Is this repository still maintained? Yeah, I agree. So it's definitely not up to date because for example this repository suggests to use some labels related to OpenShift but OpenShift doesn't consume them anymore so they are like deprecated or even should not be used because users might get like idea that OpenShift will consume it but it will not so it could be even harmful. So yeah, so I opened a bunch of issues and no one responded so I think that like this repository is no longer maintained and we should probably figure out what to do about it. Coming back to the quotes you have, there is one... The one with the link... Yes, yes, yes. I think that should be the atomic source of information of the labels and maybe even after they've been used on the guidelines just that this is maintained in the tool and maybe you have an easy access for people to just check which... If it can be in the tool, I think it's the best... My personal opinion is that it's the best place for... There are some... Some kind of rules and... Why not? That's the same question for those calling container. I think it's a very much template report. Is this up today? It seems almost... There is some container... I think it would just be the modularity of what happens to this... Yeah, that's a good question. So the organization is actually from our team and we developed EVGs when we were working for modularity and it was like proof of concept and it actually stayed as a proof of concept so there are not supposed to be like production ready or anything like that even so we have like tens of thousands of pools on Docker Hub so maybe it actually works. So it's probably up to us to figure out what we want to do with it. I think we should make sure where the template is and where the template is and just, you know, definitely keep this organization up to date or remove it. Yeah, okay. I think we have a big opportunity here with a lot of... Yeah, that's the thing. Like, do all of us have time to execute this? Maybe it's the whole main objective and because we are a whole shop of time so maybe we can focus this here. Yeah, I think I'd like to turn a little bit from the engineering goals that we had around and see some ways. So I'm not sure, for example, behind FISU or anything. I don't find it to be really a challenge because we're going to be like, it's crazy, we're going to be like months or something and we're going to be doing things. But if I could just pour it out because I don't think it's going to be easy because I haven't seen the progress of it. Because it has to be. I've been doing nicer visualizations than you might have. It's a question of... I don't know if I could... Just give me a second. What... Honestly, my personal opinion is that we should enable FISU tracking on the FISU network for miles or so. For example, there are still a lot of images that kind of work here. In this case, I use the atomic working tool and you go possibly other people and together they can achieve something. It kind of works. Some people will be good. A lot of people can open monitors that will probably... So I think we already have a leader of the SIG. So we have to comment whether he's fine with it. That's why you can do by best. So we are about 15 minutes till the coffee break. I'm sure it's your energy level right now whether we should go for coffee or... Any other topics? We will send them as possible if you somehow connect the forces in the same system. How do they use all this design? They have... It would be nice to share... Honza, what was the name of the crew? It's the CCCP. Oh, okay. They sent us containers... Yeah, they should have a whole system of their own to build images from GitHub then put to registry, validate them or whatever. They need to focus on more than just the extra images. It should be visible from the container. Alright, we actually met with Bama. Okay, so I guess that we can invite them for this meeting. Yeah, yeah. The focus is to have the same user experience for the images for Rails, and for S and F. Volunteer for that? Talking to Andrew, I'm not sure what are their plans. And especially whether these Git repositories will be combined would be an easy way. In this case, what is the plan for do this, like, is it already decided and it's matching for this case. Anything else before the coffee break? I guess let's go for coffee and after the break we can probably look at the issues in the atomic region and think about what we want to carry over to the container. Okay, thanks for coming so far.