 But it does sound to you. It is working. Okay, so I guess we can start. So hello to modularity workshop. So what we tried to do today, we tried to create some new modules. But before we start, I'll probably disappoint you, but that we probably won't build any modules. And the reason for that is there is a big dragon in our way named conference Wi-Fi. So because in order to build modules, you need to have packages local in your systems. And that's like hundreds of megabytes or even like several gigabytes. And it's not possible to... Yeah, yes? Probably one other issue that you would try to build is that in our picture it would still download in little time and I tried a few days ago because like some hard code it takes 76 something in the code. Oh, well that's a problem. So... Because I tried to re-replicate some bugs from the script and I tried to download 76 binary hardware and it didn't work for a bit. Problem? It worked. Yeah, it did. Yeah. Yeah. Okay, so I wasn't even ever... It's possible to have something out of that Intel. Okay, so... But what we try to do is to create modules and to have it like ready for trying to build it locally. So I assume that when you get home you'll be able to just get to your module and just run build and you should be able to build it yourself at home. Okay, so... Let's get started. So I don't have fancy slides. I have fancy github repo, I hope. It's available in here. It's federamanularity.workshop. I already used it a couple of times and all the content is here. So what I try to do is to get like real steps into our website, which is in here. And so usually I just link to those guides from this workshop. So this workshop is just like a big chunk of links. Okay, so let's start. By the way, Stewn Gallagher has created two very nice blog posts about building modules. So if you want to like hear it from different kind of perspective, you can read it. I fully suggest that. So this is the prerequisite I wrote down two days ago. So what we need or what you need to create modules or build modules is the module build service package which contains the whole build service as Ralph was talking about it earlier. And it also has ability to build modules locally. So also, and what the build service does is that it downloads your build requires for modules which are packages or modules and which are composite packages and it downloads them locally to your home directory. And so whenever you build a module it downloads all of them. So it's like a cache. And if you want to like trigger like get me up-to-date modules, I created a very simple module in this directory. And here it's like very easy steps how you can build it and force the modules to be downloaded so you can start working right away. Okay, agenda for our workshop is that okay, intro to modularity, I believe that we don't need to do that. Or we've been like three talks about it so I really hope that we don't need to do intro, right? But if anyone needs it just let me know and I can do it. So we can skip that. Also Adam Shamali was talking about module MD so he tried to explain it like in pictures and diagrams. I can show you like how it looks in real. And then he submitted like a section to this workshop about workflow, how he envisions to like create the modular distribution for FeatherAp 27. So I can describe it briefly and then we can finally start like go through a process of creating a new module. Okay, so let's skip the intro. So I already tried to practice this workshop in our office and I usually got stuck for like most of the session about describing module MD so I don't want to do the mistake again today. So I'll show you only the significant parts of module MD because module MD is like a pretty big specification and you can find it in here. And let's allocate only five minutes to module MD and then just let's move again. Okay, it's available in Pagger. It's specification. It's also a Python library so you can integrate it into your code into your infrastructure and it doesn't have like a formal specification like JSON schema or something like that. It's just this YAML file and it has very nice description like what all the fields do. So it's really long and you can read it at home if you feel like. Okay, let's get back. And what I'll do, I'll instead show you a real module and I describe what you can see in the module MD. So I'll open OJS module which we did for Voltron. It's pretty short so you can see in comparison to the real spec because there are no comments. So let's talk about the significant parts. Okay, it's all there kind of funcally. So in the root of the document there is like a type module MD and version. It's pretty boring. And interesting parts. So components, that's like probably the most important thing that's where you specify what RPMs you want to have in your module. So you have components. It's names based for RPMs which is like thinking for future because in future someone want to invent new packaging technology or other distributions might want to integrate modules into the infrastructure. So for example in future we could have also like a deep package here or like other packaging technologies. So as I said in here you define what packages you want to have in your module and I can see this is not a good example because as I said it's Node.js and Node.js is not in the list so let me just switch to different branch because I think this is master branch and I think we haven't updated it. Okay, so I'll use the branch from Boltzron release. Oh yeah, that's much better. Okay, back again to components. So as I said this is Node.js module so obviously there's Node.js package in the list. So what are these three things? So there's rationale which means that this is the reason why the package is included in the module. It's like I think it's pretty important to like write down that okay this is the main package and it should be included or for example you can include other packages which are just build dependencies of the main package so again it's like good to write it down. Ref, that's actually standard Git ref so you can reference to branch or specific commit. So for example in here we are referencing specific commit because by default Node.js requires some other Node.js packages which means that you can't easily build it in a modular way. So what we did that we created a new commit in this Git where we try to enable bootstrapping which means that in that commit Node.js doesn't require any Node.js packages so in like this we can easily build it so this is the bootstrapping process we chose and also there's built order and it was explained by Ralph earlier. I think this is zero so which is kind of redundant because I believe the default build order is zero so this line is useful actually I mean useless and we have other packaging here which enables packaging other Node.js module which contains RPM macros. Okay this component we don't defy filtering here so API, it was already mentioned so in API you list binary RPM packages which you support within this module so in here we support Node.js and NPM and NPM comes from Node.js which that's why there is no dedicated package in here also profiles we already discussed profiles so we defined two profiles in here so default that's when you do DNF install Node.js module it will install these two packages and we also defined another profile just for sake of clarity that you can install just Node.js you don't need NPM and yeah this is mainly for DNF profiles what else so you can also specify documentation for the module so where is your community where is documentation for the software and where is the issue tracker when you can file it upstream issues or specific issues to the module so in future hopefully this could be auto generated okay dependencies another very important field that's how you specify what modules or what repositories should be enabled for during the build or during runtime and I'll show it later in the build during the build like how important this is so again this just means that these modules or repositories are enabled during the build so when when DNF tries to install all build request of the packages which are part of your module then the packages will come from this module and you can build your package yeah there are build request and runtime request so this is build and this is runtime licensing when we did this workshop earlier licensing was very confusing to people so and I believe this because the license and because people thought that module in this context means like a license of the module and everyone thought that okay so this probably needs to be like all the software which is part of the module like where is this one just GPL so the reason why this is confusing is that this is the license of module and not the module itself and in here it's wrong because we agree upon that all module MD files these recipes will be licensed as MIT not GPL so we need to correct it and same thing is for spec files like spec files have MIT license as you can read in federal packaging guidelines and for content there is a specific field and you probably shouldn't field it I think the plan is to fill this automatically with an MBS I'm not sure when it's going to happen because it's written in the module in this pack so I was assuming it's planned yeah we just messed it up it has MBS okay and finally there are summary and description fields these are mandatory you need to fill them otherwise it will fail I believe and just like summary just one sentence what the module is about and description like a thorough description what's in the module and how to use it or something like that okay so this module MD as I said the spec is way bigger there is tons of other fields which are not used much so let's just not talk about those and let's move on okay this was module MD okay so the workflow Adam has said for developing the Fedora 27 modular release is that he created a bunch of I mean repository where there are scripts when he tries to iterate on like what packages needs to be modularized in order to have Fedora 27 server so the start is that we have platform and host modules and then there are requirements what software needs to be available in the Fedora 27 server so it's all written in the repository and I just need to find the link yeah it's in here okay and what Adam does that he like create he sets new modules and sets components of these modules which regenerates the way the packages are being distributed and it always outputs like a graph and just like expanding so this repository or like the content of this repository would be worth like another talk to describe it and what's in there and I believe we don't have time for that so if you are interested about the process Adam said or I don't know about it briefly I don't know it's basically if we are adding new modules to the 27 server right now we don't have anything in there it's pretty tricky to determine what's going to be in modules so they don't conflict and we have everything so this is just for coordination in the beginning but I guess we will be using the mock tools or something that will be much smarter so this is just for the coordination in the beginning so the thing is that in order to like build your for example on the list software which is to be available in the next modular release there is free IPA in PostgreSQL in order to build these modules you need to have all the build dependencies modularized and runtime dependencies modularized and there's like hundreds of packages so you need to figure out like where these packages are meant to be like should there be one module should there be ten modules and all that Adam does is that this work is trying to figure it out so there's like a bunch of reports in here and there is a bunch of modules like defined what packages are in there so feel free to look into it and I believe that we can finally move to the workshop part okay I'll skip this one and I'll skip to the like a real workshop part and let's create AutotoolsModule so so that's our task like create AutotoolsModule so let's start I already kind of said the name but the name is important like usually you didn't name the module probably by the most significant package in it so for example PostgreSQL module will be named PostgreSQL right but for Autotools like Autotools just like the virtual name but the packages in it will be Autoconf, Automate and libTool so hopefully that makes sense and I believe it was already said before so we need to create a stream for it so like so it's available and people can use the module so as Matt said on his talk about arbitrary branching usually you name the stream by the version but as you can see like these versions are completely out of sync so this is one version two, version one so how would we name the stream I already asked this question and I didn't receive any answer so maybe interesting idea could be the name of the stream like the date when the when it's created so for example today and then when we update the packages we can create new stream with the new date or something like that so this is just just for entertaining ok so let's create the module mb we don't need to write it by hand I created like a simple version of it so if you have it open you can feel free to copy it that's what I'll do let's try to build it so I'm in the workshop so in order to build it locally you need to be in github repo and the module mb file has to be named the same as the directory so I need to create auto tools directory I'll set it into it and I need to create auto tools notiaml which is the module mb sorry I hope it's visible it's a different color scheme than the one in the terminal so it's visible but it's really horrible I'm not sure if I have a different idea compared to black one because it's weak like around a little line ok so I'll try to switch to ok I'm using solarize but I hope I fear that it won't be visible oh yeah right oh great ok so this is our module md we can get through here are the packages we use we go directly from raw height we have the summary description references so as I said we need to be in github repo so we need to do githunit githout like this so we have the repository can I ask a question so in the amul file it was pointing to a github repo and I assume that's just because it's a demo one it would be living in diskit if this was a real thing yeah definitely yeah exactly so this is just for the demo ok so now since we installed module build service we're going to do mbs build local and here's the time when wi-fi will go mad and this one will fail so does anyone know why it fails so there's an issue in module md what? so there's something missing in here like something very important is it stream? it's not the idea of dependencies exactly we didn't set any dependencies so the build tool build service doesn't know how to build it actually because we didn't set any modules as build dependencies so here is the next iteration so we set dependencies to platform and host and we do the same for requires so let's try it like this ok so now we have dependencies we need to commit it so usually when you use mbs build local there's a bunch of output and so locally it uses mock as back end so there is usually one line with locks for mock so you should probably wait for it and once this appears like usually what I do I open new terminal window and I tail locks from so I can see what's actually happening because right now it looks like it's stuck especially building the packages in mock so I usually just search for lock it's starting a new connection with koji did you see that? is that pulling down content? yeah that's very possible yeah so it's downloading packages for yes Adam? this is really excuse me? you executed the command for I'm not curious what that was oh yeah I should probably say it in the beginning so I'm using a lot of shell aliases and vy is vm star dot yaml so I'll try to not do that sorry I'll give you a word excuse me ok yeah ok so when you put the dependencies in the yaml file what is the module build service getting those from? from koji so it's going out and just pulling down is koji module aware? no it's not the name platform master is where you put it there so it acts as the product definition so you can see what koji tag corresponds with that model stream and then it gets the content from koji ok how does it define there is at this point there are like 500 database tables with TEC and some other stuff is just in one of them but under these variants that's what we thought model is going to be so as I said there's already something happening in moq and so the build dependencies are being installed right now so if you are interested to see where the packages are being downloaded it's in home there's a directory called module build and there is like cache when that's where all these modules like your build dependencies are being downloaded and builds there that's where the builds are where you can find all the rpms which are being built from modules ok let's get back so if I can kill it I can show you the way this one will end so I don't waste I don't know wifi so this one will this one will fail like this so the build depth command from dnf will fail that it can't find auto conf how to make and help to mount because these are the those requires of of one of the components of our module so I'm not sure if you follow what's happening here but it means that we are trying to build auto make or auto conf we need actually how to make or auto conf to build it so we need to bootstrap it and so what are the ways to bootstrap it there are I try to write it down on our website and I can show you ok so this that's upstream repository for module build service and here in our website this guide how to build locally and that's that's and in this one there's like how to define the module mv and there's the build the bootstrap process is in here so can do two things you can either try to bootstrap the package itself so it doesn't require the build dependencies you don't have any available so that's what we are trying to do with boltron so for example for auto conf I was collaborating with the maintainer and he decided to me how can I bootstrap it so it doesn't require auto conf itself and I can build it without the need but that was like very so it took very long so for each package you had to spend like days working on it and if you look at the requirements if you need like hundreds of packages it's like so much work to bootstrap the whole distribution so in the end we started cheating and we started cheating by using actual packages from Koji from the regular distribution to ease the bootstrapping and that's what I would definitely suggest to you and the way this cheating works is that you don't use platform or host as your build dependencies but you use bootstrap module as your build dependencies and this bootstrap module contains 15,000 packages and there is auto conf how to make art there so you can easily build your modules like this so yeah it's cheating but for bootstrapping it's very useful and as you already bootstrapped your modules you can remove the cheating and start going like the module away and the bootstrap module is the reason why we probably can't build anything today because as I said there is 15,000 packages and it has 10 gigabytes and for example on fast internet connection it took me one hour to download it and since you want to build your module locally you need to download the whole module and I believe we built it on Tuesday so it's like you need to download the new version ok so just for bootstrapping like any questions ok so let's take a track in the module and see what you would do to depend on bootstrap oh right yeah that's a very good point so in order to depend on bootstrap you just something like this so we just said the dependency is to bootstrap master and I hope that's also ok so it's in here so yeah right now we depend on bootstrap and right now the build of auto tools module should pass so these are the last lines from Mocklog you can see that it finished building the packages so if we had good Wi-Fi and yes so that's the discrete branch of the rpm from rpm in space it's synonymous with stream too so that's the particular stream the module but the way streams needs to be created is that they're just the discrete branch so let's just get modules slash bootstrap yeah let's get a module that slash bootstrap but it's rpm in space oh sorry no let's just get modules slash bootstrap no rpm slash bootstrap ok so the the modules and the master there is the stream of the bootstrap module not of the rpm bootstrap module they contain some of your master's over there you look confused somebody said it was rpm in space and then it changed the module in space now it's the stream and the stream it's all those things it's everything you want to speak I don't want to I should do the wrong thing the master said it wrong and that led to the confusion he said rpm in module yeah you don't under that dependency section you're never pointing to rpm right? yes so I just wanted to correct myself so this is modules namespace and this is the name of the discrete repo and this is the name of the branch like stream dependencies and in components that's rpm's namespace so we should probably make it so ok so the dependencies is module namespace in components is rpm right? yes it's sort of clear in the component part of it so it's rpm but it doesn't say modules in the top yeah I started asking this question and he asked yeah dependencies are only specified in components in components are things that make it this much ok so if you probably wanted to say because I'm kind of looking at this from the perspective of like BERT which has a massive dependency chain you have to module all our i's everything like in the dependency chain in order to depend on it so qmu has depends on cluster which it does in her once features cluster would have to be a module before I even build old cluster because it needs to be thought to be module can you just put all of those rpm depths into the module yes but then what happens when you want a cluster module well you build a lot of them you build different components that you want now it would probably be more sense to make a cluster module ok so if you have a let's say you just have a BERT module qmu all their dependencies which is a lot a lot of storage things so we push that and it's literally listing every single you know set cluster whatever both and then someone comes along wants to make a cluster module are those going to conflict in any way they will at present so what so they need to call you up and say hey I'm going to make a cluster module depending on mine right so we would like it to be prettier than that but we are not there yes sir is there any way to search and find out if you can call somebody out that's the tools we're working on right now so yes we have one and actually we also in a related way we actually want to infrastructure test that verifies it all the time and it doesn't commit but it will actually check across everything to make sure it doesn't there's no problems is there a recommended way to scale this in terms of say like I've got a bunch of dependencies and how many of those need to be combined in certain ways so one of the tools that we have in progress that we're using to do free update it's kind of that so basically it tries to make a recommendation so it does try to you know it's still I imagine that you have guidelines around it that's kind of what I'm looking for but there's a tool that will help me so that's actually my next section okay sorry no more questions is there a way to do either or like you don't care what stream you get you just have to have one of them in fact there is of course so y'all mentioned that if we were to make the Buster module it would then cover the Gurt module how does that well you have an RPM count right no no how do you then satisfy not have a module I just have a question okay so so back to the tooling which Adam is working on and then the dependency report so for example here is the AutoTools module in the repository and he's running dependency checks for all the modules specified in here and for example here are all the packages which are needed to install all the packages from AutoTools module so that's what this file says and the other file is there in me yeah so there's there in me and yeah I wanted to split it some kind of tools generating all this output yeah so and there's other file which says like are already present in some of the modules so you don't need to modularize it so the difference is that if you want to develop a new module it will be great to add the module in this repository so the tools will start to incorporate it and you can figure out what packages are present in some modules which are planned for F27 yeah okay just bring me it's much less confusing if you go to AutoTools and scroll down there is a read me and it shows you all the packages right here this is a summary of all the small files so this is like what was currently in the module that was needed and they do it after our dependency so this requires to build bootstraps and platforms we have this platform placed on the hack to all the packages that are not yet in platform data in mic well we're talking about tools is there a tool that helps you calculate the build order of the you know you said to do that in your brain do you have a specific license that you brought out yeah I'm not a doctor I'm just reading the letter no I know I have a really ugly shell script so pretty sure that we just said high five oh my god that's a pretty good suggestion high five so one of my favorite files from this dependency report is that on the left side you have the package and on the right side you have the name of the module where it's present so I mean if we had this for Baltron it would save like weeks of work because we're so like disconnected about which packages are in which module so I'm really glad that Adam created this file where you can easily check like okay I need I don't know how did like in which package it is okay it's platform great like I need something else I don't know live DNF like where it is and you might figure out that it's not there so like from that point it's great to like connect with this repository or and add your module in there and put it in the pipeline this is way you should go web application at some point I would love to no rush because this like solves the need instead of doing a repo where it's confusing I saw the confusion on call space we're like do this together let's run it let's run the script and just run it for 10 minutes it just does stuff maybe we can run it on a server I like that but also you need to do like real dependency checks it's not that like is this package over there like you really need to like do proper dependency resolution like DNF or something like that yeah I was replying to okay so our module is built so we can finally submit a new review and get the module reviewed and have it in infrastructure and build it in infrastructure so finally it's like I know a couple nice we have review process we had the review process before that it's approved last time okay so we have approved review process for modules here it is it's in federal wiki okay so we have the review process so what I already did I submitted review for auto tools but I didn't have time to finish it because there was someone pointed out an issue so here it is like a standard review bug so what I did I just uploaded the module and defile on my federal people account and like there's already some conversation so once that happens like you get this git repo with your module and you can then submit the build inside infrastructure and as I said on our website there's a guide how to do it just like put the changes and do mbs build submit and that's it yeah so the important point is that you then use Fed package to interact with the build tools yes Adam why are they testing, why did they go from another test of penalty I don't talk about this around 20 minutes but the main guy is in the golden who selected the meta test penalty it sounds good it sounds very good it's very good it tests a lot more things than much when you have a module how do you do the equivalents how do you kick off the equivalents in infrastructure of a Fed package build it's mbs build mbs build is the command it's all the plan is to keep the sand on I would really like to see it role in the Fed package itself which type it is my call did not integrate earlier I can understand it faster ok so we skip testing because this is the next session is there any I'm assuming this is coming is there any thought to all of these dependencies in the initial package they get set up all of these just having to do a 1-1-1 mbs build it builds here I didn't understand so you have the spec file and module on v file you have to find the spec file and I don't have to build a part of it they're rpn separate and in terms of review processes it should separate things if you wanted to add a new rpn you should have to do a jam process and if you wanted to add a module we may look to that's how I asked because now we have three different review processes one with the module one with the rpn one and it seems it's a lot of layers containers I thought that was the perfect it's just a lot of layers I can figure out why I'm doing this because I'm going to be turning those into various details that's in my drum I swear I'm going to beat it so okay so so that's probably end of this workshop unless you have more questions so we were actually running feedback form internally but internal feedback form is not very helpful for community so even now from our team change it to open Google Doc so if you have any questions feel free to put them in and I hope that at some point we put the Q&A in our website or something like that so this is your feedback form on this this isn't the bolt run feedback so we started internal feedback form for the other group to get feedback on how to build modules it's not the same as the bolt run yeah definitely this is different and I probably missed a bit so all of us hang out at the RC channel federal modularity that's also the place unless you submit the review or if you have some questions feel free to connect to it and someone will reply from the contact yes so this is kind of like this is a technical question so I'm looking in Koji right now at the Yaju package YHGL it's like a small library so I see all these builds that have module in the name like the package name right I know the module build system sticks that in and rebuilds it and then there's like a git tag it's also correct what does that point it is a hash of the module streaming that it's a part of we originally had that this tag be module underscore platform underscore master so you could look at it and know what it was and we ran to a limitation of Koji's database for the NPRN to be longer than 50 characters so we started hashing it away at small that database change is now being fixed so it was just a matter of to switch it back and be able to implement it and see what module it's coming for you'll be able to look at a build in Koji and see like what did you say that new format is going to be the more descriptive one module underscore what so the answer to your question though is you want to be able to look at Koji and figure out what module build these are a part of yeah because I mean my first thought was is this part of a module and then I go to try to check it out but it's not it's not a stand-alone module which it's not so I don't know how to map that back to where what module in D5 Guy on our team wrote the patch to the module build service it keeps internally a list of all the components of every build so you should be able to ask it take one of these NPRNs and ask the service what module build this is for but we never exposed it in the API it got written last week so the module build service doesn't have a web view it's just just it doesn't have a command line tool to do with that or do I need to actually write a script to talk to you can write it yourself it's not good for you but if you write it tell me so like this this is what it is so for example I can query the build service and see last last module build unless the internet works no this is normal that's why I limited to just 15 and is there also a command which also shows which rpms are built in the specific module build you just run you see the build id so you can do it with it for example I'm building 3 modules but I thought we had some info right I didn't I know you're okay yeah so this lets you go one way where if you know the module build you can find out what components are in it and again to your question it's going the other way given the accuracy build what's it like so just probably all in 5 minutes or 7 minutes we'll have the other part when we go through how to test modules and containers so thank you for attending