 So welcome to our talk our talk is called bring corruption releases to federal height in one step So very short and concise title And this is talk. This is a talk about the packet project So let me first introduce our team. We have four team members from our team here So the I'm Tomas. This is Frantha. There's Yirka and there's Rado So there's the four of us and our team has actually much more people and they are at home They are not here So if you ever open an issue or send a pull request to our projects Like you will probably see one of the faces commenting on the pull request or the issue So do you want to introduce yourself? Okay, so I guess let's start Let's start the why like why we are working on packet project or why we want to actually bring New up-term releases into our height like very very easily This is a very nice diagram which was drawn by Steph and we used it in redhead summit and It's it's like shows you what was the current flow of Or or like work of up team Developers and how the their work lands into the redhead ecosystem and by red ecosystem I mean all our operating systems Which means fed or stable federal is releases federal or oh height redhead enterprise Linux redhead Coro s and sent OS and all these different flavors As you can see on the left side, we have the engineers and contributors. They were on their code They create new features their fixed box and there's all of this code lands in different Like in different projects so you can see like Linux kernel on our python or different projects on github And then at some point the project Says like okay, it's time to do an upstream release And that's usually the time when the downstream maintainers pick up the upstream releases and bring them into federal or oh height and then at some point All these new upstream releases bubble to all the other different flavors So I'm pretty sure like all of you work in upstream so you know this very well So is there anything you are missing or are you okay with this workflow and like would like to change it or keep it? Yes, Mohan. Oh So a month says that Apple is missing. Yeah, it's not in intentionally But okay, so what's your comment actually? Oh Yeah, so yeah, we are missing apple on the on the slide. That's that's correct. We should fix it Okay, so I'll give you my answer what's missing here Like my problem here is that all the arrows are just pointing from left to right and There is no arrow which would point from right to left Which means that when something goes good or bad on the right side the people or the projects on the left side Would not realize it and with the packet project We are trying to do something like this that we would have a also a flow from the right side that for example There's a new upstream release. We get it to federal arrow height and the test would fail or the compost would fail And we want to inform the upstream project about this So this is one of our goals and you can also see that the color of the arrows Between the projects and federal height change and it's also another goal of us and it would be like automation Create automation to bring the upstream releases to federal height and that's what this talk is about So now it's up to franta to introduce the package tool. Yeah, so to help people with the Process described in the previous slide we Work on the two core packet. So packet is a package Python package with the Python API and Command line interface you can install it easily with your DNF It has a rich Command line interface with many sub commands For instance, you have sub command for proposing updates from upstream repository to downstream to this gate or To syncing changes back to upstream from this gate. You can run builds or create updates or creates SRPM files or run a copper built The main advantage to use packet Is you can use these sub commands Directly from the upstream repository. So you can here you can see the one of the sub commands the status and you can run this status from the Repository or you can place the URL and now you can get the all necessary info. So you are working on the real code not the patches not In the this gate, but you are using the real code So to automate more things we have also the service which is built on top of the packet the tool So it's not the vice versa By now we packet service works as a github app before you ask We have other gitforges in mind, but we has to start with something so github app only for now The packet service packet as a service as you can find it in the github uses packets tool to do the real thing and packet service uses its own tokens its own Users and authentication with the packet tool you are using your tokens and your user We have no API yet and no the no client for the API itself. So This is all the service and Tomasz will show some examples. So thank you for the interaction. So, yeah, let's not put many more Text on the slides and let's start with pictures like how does the packet service look actually? So as Franta said you can easily find it on github marketplace or you should just Google it I believe that Google would give you the right thing and if you install it into our github project It would look like this that now you'd be using packet service Which means that whatever you do in your github repo we would get all the events So for example, you push new commits to a pull request You created new release or there's a new issue or there's a new comment in an issue and you would start getting these events and This means that we are getting the events and then you can Like you can set what the packet service should do about these events Which means that for example when you create a new upstream release You could say that okay, so packet service, please Get this new upstream release and push it to federal height and that's actually what you can do and you'll see it in a bit so this is how it would you look in your github repo and Then when you start using it like one of the like Main features we have right now that we would do Copper builds for every change in a pull request. So which means that for example in here someone created a new pull request on a repo which is using packet service and All is set up and packet service actually took the change and Created source RPM and pushed it to copper for a build. So right now the build is pending and when the build is finished packet service would create a new comment in the pull request and would inform the user how you can actually Get get the change installed locally and play with the actually content of the pull request locally We actually did this for sake of redhead summit because I know that all of us here are engineers So and we are working on the federal project. So we know how to get things from copper But at redhead summit we have like redhead customers and they are not very familiar with federal copper So we wanted to give this nice comment today to them and The main thing we have a website. So if you want to know more about our principles or a Documentation or all these things. So please remember packet.dev. That's our website for everything links and you can learn more Any questions so far yes you go Do you have Yeah, so the question is whether we are using it for redhead specific projects and whether you need to have spec file in upstream and That's actually question on like slide Plus 10 so we'll get to it. But thank you for asking Okay, so let's move on Okay, so if you know something about our project you might remember that we had a bet and We did this bet with Dominic There's Dominic and it was done at Defcon and the bet was about that if we are able to get 500 projects on board of package service by flock Dominic would grow a beard and that was the bet and you can as you can see Dominic doesn't have any beard so You can guess how it ended up Yeah, right now we have like tens of projects on board It turned out that it's actually really tough to create a service Which is supposed to be like secure and scalable and has all the features and be bug-free and Like well-maintainable and it took us actually a lot of time to do this Especially the security part Because if you think about it well when we are creating source RPMs in our service It means that you can have like RMRF in your spec file and then you could actually trash our like our deployment or you could just do like Look in the files and send all the content to your server and probably try to access our certificates or tokens All these things so it took us actually a long time to figure out to do security, right and Since we actually robbed you of the thing of seeing Dominic with a beard so I decided actually to like our review of this and Hopefully in a year, maybe we could get this and It's actually a lesson for us to make like bets which we can actually win. So so good job Dominic that you win Okay, so let's continue with actually the Topic of our presentation and it is how you can actually use packet to bring an upstream release to Rohit And we'll show you in these two different flavors as you've seen so far with the tool or with the service So with the tool itself First thing as Franta said like when you are using the tool on your command line You're using your credentials and all these things. So you need to have the Fedora Kerberos ticket Then you need to be in your upstream project and then you need to have like tags Meaning the new upstream tech fetched from the upstream repo So that's that's the meaning of these three commands and then you can just call one command which is called propose update and This command actually takes the upstream release and update spec file in Fedora in this case It actually pushes directly to this gate That's the no PR command The thing is that you can't create pull requests via API in Fedora disk it right now There's an issue in peg your API and you are waiting for a new deployment to fix this and So the precise meaning of the command is that hey take the 0.5 upstream release and update spec file in Fedora and like and commit it and push it and Then you can build it with another command which is packet build and That's it So it's pretty simple But as the title of the presentation says like do it in one step and consider it's a bunch of steps here So let's try it make it even simpler and that's using the packet service. So as I said packet searcher So so in this case you need to have the right access to the disk it because Yeah, in this case it is yeah, so Actually like the packet build command is just a very thin wrapper on top of Fed package build like you do just Yeah Yeah, yes in this case it's everything running locally. Yeah, it's very similar concept as Fed package But in this case Yeah, in this case if you want packet service to update your packages in Fedora height You would need to give permissions to the packet user in Fedora to actually be able to Sorry commit commits to your this git repo And as soon as the pull request start working like you don't even need to do that and packet service would be able to Create pull requests for this this git repo Okay already this explain jobs, so we have different jobs in packet service and they have different triggers All right. Yeah, I say I even have an example So we have the job proposed downstream Which means like I get the upstream release for Fedora and get it to Fedora this git the trigger is release So it's obvious we have all we also support like different triggers for different jobs and this is all documented and All the jobs can have additional metadata and metadata in this case is also like to what branch you want to push So you can actually define three jobs for all the maintained Fedora branches and push new releases like this with packet service And okay, and it's like the title Okay, so we have the question if the spec fun is to be after me for again and It's second slide from now Okay, so let's Yeah, and just one comment to this to this slide that Package service doesn't support builds yet because we didn't have time to implement it But hopefully able to do it in coming weeks So that we would have it all and finally let's go to the question of okay I'll skip the first question and let's talk about the Do I really need to have a spec file in the upstream repo like this question? We was out this question like a hundred times and everyone was furious about the packet project like having spec files in Like do you really need to have it or do we need to have it? So the answer is no, you don't need to have it. You can actually do some like this In packet we support things called actions Which means that we have our own actions like default implementation of some actions and you can easily Completely swap the default implant implementation for your command So in our case we expected the spec file is in the upstream repo But you can actually easily download it from whatever place you want so you can put these three lines into your packet.yaml and It would download the spec file from in this case from Federati's kit Or Actually another another way how to do this you can actually have template of spec file in upstream and then you can have some action we just process it and Render it into the proper proper spec file syntax So the question is if we could do it the other way around and have a repo with spec file and pull the code instead So this is actually how this git works like that's literally how this git works that it's a repo with spec file and all the other files needed to Create the source RPM and the upstream archives are actually pulled So yeah, there's this git like you can keep using this git and don't care about peck it at all and you are good But that and actually thank you for the question because that's also other feedback we got so far Like I'm actually okay working in this git, but I would like to have like more automation Regarding like getting things from upstream So maybe that's also a area where we as a project could like look into and try to figure out some workflows Which could be better and automate something. So yeah, there's also a thing which we could explore. Yes, Alexandra I'm sorry. I probably don't understand So the comment from Alexandra is that With with the package CLI tool you can just clone the upstream repo and put the spec file inside and work from that Workplace, so yeah, that's that's exactly what we are trying to go for that You would work all the time from your upstream repo and you would not need to touch this git like that's what we are trying to do Yes, be sure We are using rebase hopper to determine the last version if you don't didn't set it so it's there are some sources in rebase of the for example any tia and Directly Okay, so the question is that on the previous command It was a very long command where we explicitly specified a lot of stuff and it could be actually discovered and yes And actually you can run the proposed command just by itself for the disk it branch the default is master and You can also see dot that means like working the current directory There's also the default and is front asset for the version that we can use the Upsimilaries monitoring to get the latest version of the software so yeah I was really trying to be like very explicit in this case so that it's clear what's happening because if I would just Print pick it propose update. It wouldn't be clear. What's what might be happening So the question is whether the version is Mandatory argument the answer is no it's as far as I said it Peckett is trying to figure it out on its own If you don't specify it and it's trying to like pick the latest upstream release via the upstream release monitoring or And we we definitely have also like some We can determine it from the spec file as well. Oh, yeah and bring the highest one Well, but we are still we still expect that you have spec file in the upstream repo and that the spec file is up to date So that's our expectation No, that's actually a special case to be honest like we expect that out the spec file is in the upstream repo And that it's up to date and the version in there is the one you want to bring to Federa And if not like it's up to you to figure it out or pretty much like that's That's when peckett is like not very Like this is a special case that's what I'm trying to say So the question is whether The peckett project could replace present functionality with Anity I naps from release monitoring where new bugs are being created with some additional Things so the answer is no actually The maintainer is from after this monitoring is working on exact features You just described that instead of creating bugs the last the The one of the services from after milling's monitoring would create pull requests in this gate, but sadly The maintainer got sidetracked or with the row height gating initiative So he was working on that and he didn't have time to work on the pull requests, so Okay question from Igor if if if it if it would use peckett. Yeah, we actually collaborate together and The new code he's developing Actually uses some parts of peckett like from peckett api. I'm not sure if like which parts exactly but like some parts are or anything So comment from Igor is that he's maintaining 900 trust packages and it's infeasible to To every upstream report to have peckett email and do all this So he's using upstream is monitoring and fed message to get notified Yeah, yeah, that's very I'm pretty sure there are more people like you it's the similar use case and Like in current case with peckett project like it's not one of our I mean, we don't have capacity to like support you hundred percent and create you like perfect solution Like right now we are trying to be more generic and like for everyone and hopefully at some point We would be able to start implementing workflows for people with special needs So that's my answer So the question is how many projects already have spec find the upstream which peckett is using all of them As I said, we have tens of projects who are using peckett right now and all of them have spec file in the upstream report But like on the other hand all of the people are I would say redhead employees Federa contributors and all these things Show the first All right first question Yeah, and the other question we are getting Ask a lot and was asked right now. Is that what if the upstream project doesn't care about Federa or peckett or whatever? Yeah, the answer is just create a mirror on github and like mirror Meered exactly the upstream project and put more commits with the Federa packaging and then you can start using peckett right away So but I agree like it's pain to maintain such a thing because you constantly need to pull new changes from the upstream repo And hopefully we'll be able to implement Automation into peckett. So for example when there is a new upstream release peckett would create pull request in your mirror So that you don't have to do it manually, but it's just just a thought right now We are getting out of time So the question is about mirroring, I believe you need to do it yourself Mirroring it's possible, but you you have to rebase the distribution specific About So the question is whether it's easier to have CI for upstream projects easier or packaging easier I would say both but the thing is that if when our goal is both we can do like one perfectly we can do like two maybe good Yeah, it would make sense to focus on one, but right now the goal is like both and maybe like the high operating has like is making CI for upstream projects easier and That's actually the theme of the next presentation and yeah, we are sorry. We're out of time Yeah, Dominic Or automatic Yeah, thank you. So we have a workshop tomorrow, so please come by and you'll see all of the Things in action you just heard about and thank you for coming These are the links to the project to slides and to our website and to our mailing list So feel free to get in touch with us. We are here till Sunday. Thank you for coming