WEBVTT 00:00.000 --> 00:10.480 So I hope you've just realized that I'm only one person here. 00:10.480 --> 00:16.560 So hello, I'm Frankie Shek, I am a product owner of the Peckitim in Riddet and I'm not 00:16.560 --> 00:21.040 joined here by Dana from Suze. 00:21.040 --> 00:26.520 And it's a pity because Dana has done all the hard work and you'll see my role in this whole 00:26.520 --> 00:27.520 thing. 00:27.520 --> 00:34.720 So, in the set, but I think there is still plenty of things to present and also I have 00:34.720 --> 00:41.080 nice excuse to say I don't know to all of your questions so I think we are on good spot 00:41.080 --> 00:42.080 here. 00:42.080 --> 00:51.000 Okay, so what's ahead of us, I'll shortly compare what's in the open Suze World and what 00:51.080 --> 00:57.560 Fedora, how there are the services connected so we are on a like somehow see the context 00:57.560 --> 01:03.200 where we are, what we are looking at, then I'll introduce the Peckit projects and his role 01:03.200 --> 01:11.680 in his in this thing and there will be like the story of how this all ended or went and 01:11.680 --> 01:19.320 then finally the current solution what you can use now, what's what's planned for the future. 01:19.320 --> 01:24.840 So, let's take a look at the basic structure of the distributions that should somehow 01:24.840 --> 01:34.200 fit to most of the distributions, we usually have some place where the Peckitis are defined, 01:34.200 --> 01:39.960 some kind of source control distribution gate or something like that, then we have some 01:39.960 --> 01:48.480 things, some tool or service to take care of the built, then if you have like all the Peckitis 01:48.560 --> 01:55.360 built, usually have something to like assemble that together, produce some artifacts and ideally 01:55.360 --> 02:01.760 for good distributions there is some kind of quality assurance or testing going on, ideally, 02:01.760 --> 02:07.600 not all, usually if you would like to get like the update and things to the user so there 02:07.600 --> 02:13.920 is some publishing going on and maybe some monitoring, so let's start with Fedora, how it looks 02:14.000 --> 02:20.640 on the Fedora side. So, the Fedora, we have a distribution gate, so it's a gate server, 02:22.240 --> 02:29.520 where we have a gate repository for all the Peckitis like each Peckitis, 02:29.520 --> 02:36.640 mostly each has a separate repository for each Fedora version that is a branch basically. 02:37.520 --> 02:44.480 We have that figure as a front end or like this gate forge for this, which might not be true 02:44.480 --> 02:51.680 and so soon, so this is going to be replaced by 4.0. For building Peckitis, we have Koji, 02:51.680 --> 03:03.200 which shows how Fedora is looking at the things compared to open susay, Koji is quite simple, 03:03.200 --> 03:09.680 let's say like it's a build system, so it does one thing and does it quite right, so it takes 03:09.680 --> 03:16.160 care of the building build task and these things. In Fedora space, we actually have two build 03:16.160 --> 03:23.680 system, there is also co-oper that has like a key part in the Peckit stuff and it covers 03:23.680 --> 03:29.840 like the user, slash community targeted build, so if you are from the Ubuntu space like 03:29.920 --> 03:35.200 Pepe, Pepe, and stuff, so that's like the thing that's going on here. 03:36.880 --> 03:44.720 Then we have Panji, that takes care of like the repository of some plants, creating images and other 03:44.720 --> 03:53.600 artifacts. Then there is an open QA used for the like discoloration and stuff and 03:53.840 --> 04:03.040 slide the related, there is also body, body is used here to like move the stuff between the 04:03.040 --> 04:09.840 Koji before it gets to the user, so if there is a build or a group of related builds, 04:11.520 --> 04:17.680 this doesn't go straight to the user, but usually there is this so-called body update created, 04:17.680 --> 04:24.400 which provides the way how to like try the stuff before it gets to the user, vote about that 04:25.200 --> 04:32.720 and maybe block the update if something goes wrong. And there is a Koji that takes care of like 04:35.120 --> 04:41.600 somehow like reverse the dependency issues can help us with this. 04:42.560 --> 04:50.160 Looking at the open source side, the structure would be much much easier. Most of the stuff 04:50.160 --> 04:58.960 is being taken care of by the Open Build service, OBS, so I'll try to if I mention one or the other 04:58.960 --> 05:06.400 does it the same thing, OBS takes care of everything. So it has some kind of source control, 05:07.040 --> 05:13.280 it's not a git, we'll get to that later, because there's not the simple stuff 05:13.280 --> 05:22.080 and regarding building, it's both Koji, both Kooperi's case, so it covers both and also like 05:22.080 --> 05:29.360 these other steps, everything is being covered and also automatic rebels when there is a 05:29.360 --> 05:38.880 dependency update, everything is in OBS. There is also Open Kuay actually that's the place where 05:38.880 --> 05:44.720 it was like for first time compared to Fedora, so it's easier something to share. 05:46.000 --> 05:50.160 If you are interested in more details about like these differences, 05:50.160 --> 05:55.440 done has had a total last year about this, so take a look at that, 05:56.400 --> 06:05.520 here's a lot of interesting ideas and compliance and yeah and it was probably clear about this 06:05.520 --> 06:15.440 because he ended the talk that Bob has some issues, so I won't properly shuffle the infrastructure 06:15.440 --> 06:23.440 nor in Fedora nor in Open Susen, so but maybe there is something we can do on top of that and that's 06:23.440 --> 06:28.960 actually what we try to do in general in the packet projects, our goal is to get 06:30.080 --> 06:36.000 upstream developers close to the distributions and by vice versa, like in Pope ways, 06:36.000 --> 06:41.360 so we are trying to like provide a downstream distribution feedback back to the developers 06:41.360 --> 06:46.000 and when there is an upstream release, we are trying to help maintain, let's get the 06:46.000 --> 06:53.840 get the release down to the distributions. So looking at the upstream workflow that's like this, 06:53.840 --> 06:59.680 first use case packet is like a single service, but still has supports these like two kinds of 06:59.680 --> 07:07.200 functionalities, so the first one is like acting as a GitHub or GitHub CI, so there is this 07:07.200 --> 07:17.040 GitHub and through packet you can do like various, various tasks. Usually we leverage an existing 07:17.040 --> 07:24.720 service, single purpose service to do the stuff, but build and use the facing workflow on top of that. 07:26.320 --> 07:32.800 So for building, we support learning, scratch build, so like the test build and also copper builds. 07:33.200 --> 07:37.200 With copper builds, we have a bunch of other stuff that you can do on top of that. 07:41.040 --> 07:48.640 Back to the copper, you can not only use it as a CI, so not only to check if your package can 07:48.640 --> 07:55.520 be built, but also to provide like persistent copper projects for your commits or releases, so 07:55.520 --> 08:01.360 you don't need to wait till the code gets, for example, to Fedora and, you know, like approval. 08:02.960 --> 08:08.720 Also, we are integrating testing farm, which is built on the TMT test format, which is like 08:08.720 --> 08:16.480 spreading in one of various places of like this RPM space, but also in another space, you can 08:16.480 --> 08:23.520 either run the test directly on the code or you can run it in a VMs that has the 08:23.760 --> 08:30.000 archni-a-marti-fax from copper available installed on the VM. 08:30.560 --> 08:40.960 Newly, there is also opens can have integrated, which is a static analysis service being open source 08:40.960 --> 08:46.400 from an internal redhead service, so you can also use that. If you are interested, 08:46.400 --> 08:51.840 we had to talk about that two days ago on CentosConnect, so that's a nice thing to take a look at. 08:51.920 --> 09:01.920 Well, and regarding VM images, there is an image builder integration as well. So, let's take a look 09:01.920 --> 09:07.920 at the Fedora automation of what we have in package, actually we need to move the stuff a bit 09:07.920 --> 09:14.880 to make a space, because we are starting in abstin, that's our role. So, we are starting on GitHub 09:14.880 --> 09:20.080 or GitHub, as I mentioned, but we can also use release monitoring called CentosConnect, 09:20.080 --> 09:27.600 Anita, related things, that release monitoring is like data-based service that starts together 09:27.600 --> 09:33.680 information about abstinence releases, and let's us know when there is a new abstinence. 09:34.880 --> 09:42.960 So, where we know there is an abstinence, we can prepare this git for this new release 09:43.280 --> 09:51.040 and upload an archive to the Lukasite cache. So, this job is results in a pull request in 09:51.040 --> 09:56.160 in this git. Once the pull request is reviewed, merged, we are running automatics, 09:56.160 --> 10:02.160 co-chip build, and when there is a successful co-chip build or a group of successful co-chip builds, 10:02.160 --> 10:08.640 we are creating what we have played. Okay, so, whatever will happen soon. 10:08.960 --> 10:18.960 Last year, I had a talk, we can get abstinence, close to together, and I prepared a bunch of 10:18.960 --> 10:23.760 questions we are getting, and one of such questions was like, yeah, you are supporting just a single 10:23.760 --> 10:29.360 distribution, we as an abstinence don't like that to debug that, and I've collected a bunch of 10:29.360 --> 10:36.880 ideas what you can do, and actually someone suggested to you. So, yes, because it supports more 10:37.760 --> 10:47.120 distributions, there is all nice, but it is not easy. Obviously, it has a custom versioning control 10:47.120 --> 10:53.120 bolsing completely different way of how we were used to, and that's part of the whole system. 10:54.640 --> 11:00.800 Okay, but by bother about this, it's not so easy. Yeah, it supports more distributions and 11:00.800 --> 11:09.840 package formats, and also it can provide more artifacts than copper, copper is very nice, we 11:09.840 --> 11:17.680 we love to work on that, but yeah, some limitations are there. So, we are starting the history. 11:18.400 --> 11:27.440 Then, actually, send the first PR, how, like, year and a half, I go trying to like, 11:28.480 --> 11:34.400 let's, let's introduce OBS into packet, because I have mentioned that, 11:34.400 --> 11:40.720 done is both, like, community member of Open Suzan Fedora, so he would like to see a single 11:40.720 --> 11:48.400 tool for all his packages and efforts. So, that's the date, yeah, please don't spend much time 11:48.400 --> 11:54.800 on that, we are reveriting like this wraparound top of OBS, and yeah, two years ago, 11:56.160 --> 12:03.920 yeah, and a lot of discussion, and yeah, but from the perspective of packet team, 12:03.920 --> 12:08.800 we need to be also sure that if we introduce something into our code base, we need to care about that, 12:08.880 --> 12:18.480 and so we need to be a bit cautious, so just a few comments. Yeah, so slowly, 12:19.280 --> 12:25.920 done stop, we had time for that, so it like slowed down, which I completely understand, 12:25.920 --> 12:30.880 because it's really complicated, and maybe it's also my fault, because I started packet, 12:30.880 --> 12:36.080 we've on the base that there are two repositories, one for OBS team, one for Dams team, 12:36.160 --> 12:42.560 and I wasn't aware that things can be different, otherwise elsewhere, so let's me on. 12:43.280 --> 12:48.560 But, yet, last year I was thinking, like, can we get some help on that, and like, yeah, there is a 12:48.560 --> 12:55.840 g-so going on, Fedora doesn't have, wasn't chosen at the time, but it opens a set date, so what 12:55.840 --> 13:02.160 about doing something about that? Yeah, and actually, together with Dams, we've provided a 13:02.480 --> 13:10.480 project, and we got Brian as a student working on that, so Brian took the code from Dan, 13:12.320 --> 13:20.800 and starting building on top of that and spent the whole summer on that, thanks for all his 13:20.800 --> 13:26.880 work, on that, but actually, some is quite short time to do something like that, so yeah, 13:26.880 --> 13:35.120 there was like a lot of stuff going on, and he has done some stuff even after the project was 13:36.480 --> 13:42.960 was finished, so, yeah, same story, it slowed down, it was like, we've done yeah, we would like to 13:42.960 --> 13:48.160 finish that, we would like to finish that, and nothing was happening, but yeah, and that's my 13:48.160 --> 13:54.080 cruise roll here, it was always like, yeah, Dan, what about submitting a talk to folks there, 13:54.080 --> 14:00.640 maybe it will, like, force us to finish that, so yeah, it's a good idea, and yeah, nice thing to do 14:00.640 --> 14:09.200 during Christmas, yeah, so yeah, two months ago, we are going back to the original public 14:09.200 --> 14:19.680 quest, and Dan revisited his work, and actually, with magic, and no worries, the time doesn't match, 14:19.760 --> 14:30.000 I've made a screenshot yesterday, so this is fine, just need that, okay, so how it works, yeah, 14:30.000 --> 14:37.040 so yeah, we have an abstinence here, or when we are working on locally, so get your repository, 14:38.880 --> 14:47.120 we create a OBS project, or set up like the stuff on the OBS site, if it's not already set up, 14:47.120 --> 14:54.960 and then we prepare SRBM, and do the committing, and adjusting, prepare a change file, and 14:54.960 --> 15:02.720 this stuff, because with OBS it's kind of like submitting an update to this given Fedora, and also, 15:02.720 --> 15:09.760 so it's like a combination between copper and this git, so we need to do both, and then if the 15:09.760 --> 15:17.680 build set set, we can report it to do use them, so currently it works only for command line, 15:17.680 --> 15:25.360 so we are missing the service part, but in the future, this should like, in the context of 15:25.360 --> 15:30.640 abstinence for for, it should result there, so another build service available for you, 15:32.080 --> 15:38.160 but that might not be the only place, so let's do the demo, actually rather not, we don't have 15:38.160 --> 15:46.480 done here, okay, so let's take a look at how you can use it, so you should install the great latest 15:46.480 --> 15:54.000 great display kit, I've got the release of Halvan Hour ago, so the build made it, so I think you can 15:54.560 --> 16:02.640 install it, and after like a few days you'll get it from Fedora, so that's the first thing, 16:03.040 --> 16:10.960 okay, then you should have the package set up, you can flow this guide, there is a lot of information, 16:10.960 --> 16:18.640 but usually when we are configuring the package, you just need to know what the name of your projects 16:18.640 --> 16:25.680 and all the stuff, since we are heavily built on top of RPMs, so you should have a spec file, 16:25.680 --> 16:30.080 not directly, you can also download it from somewhere, but you should have it, but we had 16:30.080 --> 16:34.960 the talk in the morning about Rastuar PM, and stuff, so I think there are tools to help you, 16:36.720 --> 16:44.080 people that you can have, then you should have, since we are talking about pick it command line, 16:44.880 --> 16:50.560 pick it command line requires your own identity to work on, so pick it command line and the core 16:51.760 --> 16:57.680 is like that it uses like your identity, the service part uses pick it's like own identity, 16:57.680 --> 17:06.800 so you should like set up the OBS credentials, and don't be confused, if you set up token on OBS site, 17:07.440 --> 17:14.640 it won't work, you really need to put their password, don't ask me, okay, so here's the command 17:14.640 --> 17:25.040 you can use, basically you think and just if you want to wait on not wait for the build to finish, 17:26.000 --> 17:36.480 so yeah, so what now, so what we would like to do, so the change of log might be improved, 17:37.520 --> 17:43.360 but that is like heckishness, I think, not so important, the 17:44.640 --> 17:49.840 another important, very important part is that the done is working on supporting submit request, 17:49.840 --> 17:57.680 which is a way how you can introduce updates on new packages to the OBS board, like OpenSusa, 17:58.720 --> 18:07.760 and so it will somehow match the way what we have, what I shown for Fedora, so you now, 18:07.760 --> 18:13.200 you would be able to like from one place set up like automatic updates to both these distributions, 18:13.840 --> 18:19.840 and the third one and the crucial one, you would like to have it in the service, 18:21.200 --> 18:27.520 so for that, we would really, really like to know if you are interested in that, if it makes sense 18:27.520 --> 18:33.440 for us to continue on that front, I'll mention how we can do that later on, but that's the crucial part, 18:33.440 --> 18:40.320 and also since OBS supports like other distributions, I might want to take a look at that as well, 18:41.040 --> 18:49.680 so, because you might not be sure, and after some tells you might be wondering, 18:49.680 --> 18:56.320 what does it mean for me, so I've prepared some cheat sheet for you, so I have a project 18:56.320 --> 19:01.760 developer care about my users on Linux distributions, yeah, please do set up package, 19:01.760 --> 19:09.680 I for your project, so you are sure right away on OBS team that, and that your project won't 19:09.680 --> 19:14.560 break, and it gets finally to the distribution of so you can, this is called like ship left 19:14.560 --> 19:20.720 angle, so like moving test and stuff and verification to OBS team, so it's like it can be fixed, 19:20.720 --> 19:27.200 right away when the things are developed, okay, so I want to have ArpNM repository for my project, 19:27.840 --> 19:32.480 I've already mentioned that that you can already use the corporate integration to 19:32.480 --> 19:39.200 provide you like the stable, stable, corporate repositories, the Yamrepositories for your projects, 19:39.200 --> 19:44.560 either for the comments, in what is for example a different, different repository for 19:44.560 --> 19:50.000 comets and main branch, different stable branch, and maybe different for OBSs, which for example 19:50.080 --> 19:57.760 do so, you can like quite easily without much hassle, like have this available, and if you are 19:57.760 --> 20:05.440 interested in like OBS, please do try locally, it can still help you save some time and creating 20:05.440 --> 20:12.480 the setting up the project, and ideally let us know, okay, so I'm a federal amendment owner, 20:12.480 --> 20:18.480 yeah you should set up a package in my automation for a project, simple, there is a dedicated, 20:18.480 --> 20:27.600 this good specific onboarding guide for you, and okay, I'm an open to the maintainer, 20:27.600 --> 20:37.040 yeah try this package OBS functionality locally, let us know, let us know, okay, and I'm 20:37.040 --> 20:42.480 maintaining an added distribution on or ideally I take care of the infrastructure here, 20:42.480 --> 20:49.200 getting touch with us, we are more than we more than welcome any like contribution, we usually, 20:49.200 --> 20:54.240 we've like managed to do a couple of like various collaboration and a way that like someone 20:54.240 --> 21:01.760 external, implementing the package core, as done it currently, and then maybe package team can 21:01.760 --> 21:06.480 like build a service bar on top of there because the package core slash command line is quite 21:06.480 --> 21:15.120 easy to work with, but the service is not so simple to like foreign newcomers, but we will 21:15.120 --> 21:21.920 be really like to have more distribution supported or at least some collaboration on that front. 21:22.880 --> 21:31.120 Okay, I've mentioned let us know, so either we are quite active and our primary communication 21:31.280 --> 21:38.160 or something matrix, I'll show you the next slide so, but I've just created a discussion for 21:39.200 --> 21:47.840 where we can like ask anything or mainly, either you stumps up or mention, I would like to 21:48.880 --> 21:57.040 see this happen or I would like to use it for my projects, our team is outing splints are heavily 21:57.520 --> 22:02.080 based on like the demand, so if we know that there are a couple of people interested in something 22:02.080 --> 22:08.480 or are worked by some of some of our work, we can therefore working on that, if we are not sure 22:08.480 --> 22:12.800 if there is anyone, we'll probably not spend the time on that, so if you want to influence what 22:12.800 --> 22:22.400 we'll work on, let us know, yeah and the huge thanks for done for finishing this and also Brian 22:22.480 --> 22:30.080 for spending the summer on that and also the team for reviewing that because you might not 22:30.080 --> 22:36.240 supported like how many lines it was, it was really easy at all, so thanks for those for that and 22:37.440 --> 22:43.840 that they were very willing to respond to my messages like I do this and I do that what about and 22:43.840 --> 22:53.440 okay, so that was all for me, I like the MasterDone accounts and most of the stuff should be on 22:53.440 --> 23:01.280 our webpage but the matrix channel is quite active and we try to be like, well come again 23:02.240 --> 23:15.680 I'll be just stuff, so thanks, do we have any questions? No worries, I'll forward right into 23:15.680 --> 23:33.280 down, it's fine. Hey, I know you have some kind of service that can run the bills but basically 23:33.280 --> 23:42.800 did you like experiment with the Gita Batchons for example? Yeah, we have Gita Batchons actually 23:42.800 --> 23:48.240 like that's the issue that Gita Batchons are not so fitted to the if you have like the existing 23:48.240 --> 23:54.880 services and it's same with like a Gita Batchons, that it's not those who did when you have like 23:54.880 --> 24:03.520 existing infrastructure and like this even based system that you need to like change the steps 24:03.520 --> 24:10.480 going outside of your control and you need to wait for something, yes, that's the that's the 24:10.480 --> 24:17.440 main issue, but yeah, there are some basic steps going on like having a packet, 24:17.440 --> 24:23.760 Gita loves setup or Gita have if you want to like to be dead, if Gita is a bit easier but 24:23.760 --> 24:29.520 but it it will basically be just a wraparone out command line and you will lose all the 24:30.320 --> 24:33.280 like vessels on top of it. Thank you. 24:40.480 --> 24:49.520 No more questions I guess. Thanks for the show.