14:00:21 <nils> #startmeeting modularity_wg 14:00:21 <zodbot> Meeting started Tue Aug 8 14:00:21 2017 UTC. The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:21 <zodbot> The meeting name has been set to 'modularity_wg' 14:00:21 <nils> #meetingtopic Meeting of the Modularity Working Group (once every two weeks) 14:00:21 <nils> #chair dgilmore langdon mikedep333tflink 14:00:21 <zodbot> Current chairs: dgilmore langdon mikedep333tflink nils 14:00:29 <nils> #topic Roll Call 14:00:31 <contyk> o/ 14:00:34 <contyk> .hello psabata 14:00:35 <nils> .hello nphilipp 14:00:35 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com> 14:00:38 <nils> hey all 14:00:38 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com> 14:00:44 <jkurik> .hello2 14:00:45 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com> 14:00:49 <asamalik> .hello asamalik 14:00:50 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com> 14:01:14 <langdon> .hello2 14:01:18 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com> 14:01:41 <asamalik> wooot, hello2 - is that new? 14:02:00 <contyk> .hello43 14:02:01 <nils> asamalik, I think so 14:02:13 <nils> I've seen it last meeting for the first time 14:02:17 <asamalik> contyk: psabata 'Petr Šabata' <psabata@redhat.com> 14:02:23 <sgallagh> .hello sgallagh 14:02:25 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 14:02:49 <asamalik> contyk, I think hello 43 should even run the meeting for you 14:02:56 <nils> that would be great :) 14:03:15 <langdon> Maybe? New to me :) 14:03:38 <tflink> ,hello tflink 14:03:39 <tflink> er 14:03:44 <tflink> .hello tflink 14:03:45 * asamalik needs to leave after 15-20 mins :( 14:03:46 <ttomecek> .helloΠ 14:03:47 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com> 14:03:53 <nils> so let's get this going 14:03:56 <nils> #topic Agenda 14:03:56 <nils> #info Module naming policies 14:03:56 <nils> #info Host & Platform availability 14:03:56 <nils> #info Fedora 27 modular design 14:03:56 <nils> #info Modular Atomic Host 14:04:01 <nils> anything else? 14:04:20 <ttomecek> guidelines and review process 14:04:37 <nils> #info Modular Guidelines and Review Process 14:04:55 <nils> good 14:05:05 <nils> #topic Module naming policies 14:05:12 <contyk> ok 14:05:16 <contyk> this should be quick :) 14:05:19 <nils> #chair contyk 14:05:19 <zodbot> Current chairs: contyk dgilmore langdon mikedep333tflink nils 14:05:57 <contyk> lately we've been discussing how to serialize unique module identifiers for use in various tools -- IDs in PDC, module references in bodhi, pungi or koji, and, of course, dnf 14:06:10 <contyk> there were various proposals, some were more popular than others 14:06:24 <contyk> the discussion is still ongoing so I just wanted to draw some attention to it 14:06:40 <contyk> #link https://pagure.io/modularity/pull-request/43 Module naming policy proposal 14:06:55 <contyk> feel free to go through the PR and the plentiful comments and add your own! 14:07:24 <contyk> unless anyone has anything, that's all I wanted to share 14:07:52 <asamalik> thanks contyk, I guess that's all we need right now... we should continue in that PR 14:08:03 <contyk> yep 14:08:10 <nils> good 14:08:14 <nils> #topic Host & Platform availability 14:08:22 <contyk> ok, in other news... 14:08:42 <contyk> as of yesterday we finally have builds of host, platform and shim -- the main three modules defining f27 14:08:53 <contyk> this is a very early prototype; they currently bundle py2, py3 and perl 14:09:10 <contyk> that's going to change pretty soon; they don't define any API or filters yet either 14:09:26 <langdon> contyk, are they incorporated in the nightly composes? 14:09:49 <contyk> we also reviewed the shared-userspace module from f26 boltron (every single component!) and decided what could be included and what should go into a separate module 14:10:03 <contyk> langdon: oh yes; we should have the very first compose ready later today 14:10:22 <contyk> but since the modules don't define any filters, the repoclosure log will be far from clean 14:10:33 <contyk> we also cannot build any images at the moment as we don't have the installer yet 14:10:42 <langdon> contyk, cool.. i just meant it is getting pulled in to the automatic one.. /me really needs to make a "boltron-rawhide" container 14:11:00 <langdon> really .. f27-modular or rawhide-modular 14:11:07 <ttomecek> contyk, what about common-build-deps{,-bootstrap}? 14:11:26 <contyk> ttomecek: that module never made sense to me so I do not intend to resurrect it 14:11:45 <contyk> ttomecek: many dependencies will be present in platform directly; software like autotools should live in a separate module 14:11:53 <ttomecek> contyk, which means that packages from those two modules should be placed into separate modules? 14:11:53 <contyk> named... I don't know... autotools? 14:12:22 <contyk> ttomecek: yes, but you're basically touching the next topic on the agenda ;) 14:13:12 <nils> speaking of which 14:13:18 <nils> #topic Fedora 27 modular design 14:13:26 <asamalik> ha, right 14:13:29 <langdon> sorry.. 14:13:31 <langdon> wait 14:13:32 <ttomecek> my point is: you decide on what is meant to land in platform module and say screw common-b-d and -b modules; how are we going to build modules for F27 then? 14:13:35 <langdon> should we #undo 14:13:39 <nils> langdon, okay 14:13:42 <nils> #undo 14:13:42 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1c85d7d0> 14:13:46 <langdon> i would like to have an info or something closing the prior 14:13:48 <nils> langdon, go on 14:14:02 <langdon> contyk, can you #info something? 14:14:07 <contyk> ttomecek: you will use platform and other modules that provide the components you need 14:14:20 <contyk> langdon: um, sure 14:14:53 <ttomecek> contyk, what are the other modules? who will create them? who will decide what's suppose to be inside them? 14:14:54 <dgilmore> hola contyk 14:14:56 <contyk> #info The very first builds of Host & Platform are now available and the initial test composes should be ready later today. 14:15:07 <asamalik> there is just not going to be any artificial modules like 'shared-userspace' or 'common-build-deps' - there will be just the platform and other modules like Perl, Python2, autotools, etc... the next topic gives more info 14:15:29 <contyk> #info Images will be available once we have the new installer module available. The current Platform is messy and will be sanitized over the next week or two. 14:15:31 <langdon> ok.. next topic.. ttomecek hold your horses :) 14:15:32 <contyk> dgilmore: hey 14:15:42 <nils> #topic Fedora 27 modular design 14:15:46 <asamalik> so.. 14:16:10 <asamalik> last Friday, I hacked together this thing https://github.com/fedora-modularity/dependency-report 14:16:34 <asamalik> we'll use it with contyk to identify the initial set of modules in F27 Server 14:16:45 <asamalik> we already got some requirements from the Server WG 14:17:02 <asamalik> we have to include FreeIPA, Cockpit, PostgreSQL, NetworkManager, and storaged 14:17:06 <asamalik> and their deps 14:17:11 <asamalik> obviously 14:17:14 <contyk> and their build deps 14:17:18 <asamalik> yes 14:17:43 <asamalik> we wanna do an initial draft tomorrow morning, right contyk ? 14:17:47 <langdon> well... and a bunch of basic stuff.. but those are the "features" 14:17:57 <asamalik> langdon, yes 14:18:01 <ttomecek> (no container runtime in 2017 server? :o ) 14:18:07 <asamalik> so the things I have mentioned above are blocking 14:18:17 <contyk> ttomecek: surprisingly there was no such requirement from the server wg :) 14:18:24 <asamalik> everything else, even if very important, is not blocking the release 14:18:25 * ttomecek lolz 14:18:33 <contyk> ttomecek: but nobody is stopping you from making such module 14:18:38 <asamalik> exactly 14:18:57 <langdon> ttomecek, i think "container-runtime" was on the implied "basic" list 14:19:09 <contyk> I believe including docker (and I would just name it docker) would totally make sense 14:19:13 <ttomecek> implied =/= requirements 14:19:28 <contyk> we also have a very basic container runtime in platform -- runc 14:19:31 <langdon> ttomecek, ha... apparently you are new to software ;) 14:19:35 <nils> ttomecek, you're not familiar with implied requirements? :D 14:19:36 <contyk> but that's not very useful to general public 14:19:40 <asamalik> langdon, lol 14:19:42 <ttomecek> :D 14:19:49 <contyk> anyway 14:20:05 <contyk> to ship the required components for f27 server, we will have to create several other modules 14:20:13 <langdon> asamalik, i am not sure where you are keeping the formal "list" but let's add docker to it.. 14:20:15 <contyk> most dynamic languages would need to be packaged 14:20:24 <contyk> autotools are another prime example 14:20:34 <contyk> we will need a webserver and an ldap server to satisfy dependencies of freeipa 14:20:45 <contyk> obviously we will need an installer, sssd... 14:20:46 <ttomecek> langdon, just fyi, lsm5 is working on modularizing their stack (skopeo, crio...) 14:21:08 <nils> ...anything to #info from the above? 14:21:14 <contyk> figuring out what exactly we need and what bucket it should go into -- something reasonable and maintainable -- is what we intend to do tomorrow 14:21:18 <contyk> and in the upcoming days 14:21:19 <langdon> ttomecek, yeah.. as soon as he has something kinda viable, we should add it to the nightlies 14:21:36 <ttomecek> contyk++ 14:21:36 <zodbot> ttomecek: Karma for psabata changed to 2 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:21:37 <contyk> threebean: are you around? 14:22:02 <contyk> threebean had an idea, long time ago, to create a module stack that would define the compose 14:22:05 * threebean reads up 14:22:17 <contyk> something like "fedora:f27" -- pungi config would then reference this one module 14:22:18 <ttomecek> langdon, he is blocked on the fact that he cannot build in the infra (threebean said he wants review process to create new module dist-git repos) 14:22:23 <asamalik> langdon, no formal list, yet, just the Server WG reqs + deps... but I'll make that soon (and send it to you for feedback as well) :) 14:22:39 <contyk> the upside is we wouldn't need to update the configuration every time we decide to add a new module -- we would just update the module stack 14:22:45 <contyk> threebean: is that still on the agenda? 14:22:49 <threebean> hm, 14:22:51 <threebean> it could be. 14:22:55 <jkaluza> It can work like that 14:22:58 <asamalik> contyk, that sounds good 14:22:59 <jkaluza> Or it can be defined in PDC 14:22:59 <langdon> asamalik, well.. and I should bring it to the server-wg and say "if it aint here, you aint getting it" .. to make sure the "implied reqs" get captures 14:23:03 <langdon> *captured 14:23:11 <asamalik> langdon, exactly 14:23:21 <threebean> contyk: can I pursuad you to hold off on that until f28? 14:23:26 <asamalik> langdon, I make sure you have it for the next Server WG meeting 14:23:32 <contyk> threebean: of course 14:23:34 <threebean> for now, we should be able to rapidly merge things into the pungi config. more rapidly than for f26. 14:23:51 <threebean> there's just some small amount of development work that would be needed to make pungi "depsolve" the deps of a f27 release module 14:23:58 <threebean> and I want to conserve development cycles for other projects. 14:24:12 <contyk> ah, right, module-level depsolving 14:24:16 <contyk> it affects mbs too :) 14:24:20 * threebean nods 14:24:30 * asamalik is sorry, needs to go 14:24:36 * asamalik might be able to react to mentions 14:24:40 <threebean> yeah. again, merging changes to variants-modular.xml should be much less of a bottleneck than in f26. 14:24:49 <threebean> (do ping me if you ever post one) 14:24:54 <jkaluza> threebean: I want to write that piece of code to Pungi for ODCS too, so +1 14:24:55 <contyk> ok; that was somewhat OT 14:25:09 <asamalik> contyk, could you please do the #info and #link for me? https://github.com/fedora-modularity/dependency-report 14:25:23 <jkaluza> threebean: meaning the module level depsolving 14:25:31 <threebean> jkaluza: yeah :) 14:25:44 <contyk> #info We will be going through the list of required modules for Fedora 27, their built-time and runtime dependencies and deciding what buckets they should go into. 14:26:07 <contyk> # We will also generate module templates for upstream maintainers willing to help us with implementation, to guide them 14:26:11 <contyk> #info We will also generate module templates for upstream maintainers willing to help us with implementation, to guide them 14:26:27 <contyk> #link https://github.com/fedora-modularity/dependency-report A helper module dependency reporting tool. WIP. 14:26:28 <langdon> threebean, jkaluza you would put that depsolving in pungi? I guess i was thinking you would just have another tool that turned the module -> variants-modular.xml 14:28:31 <jkaluza> langdon: I think this is mostly implementation detail. I don't see a reason why to write that as separate tool, which would generate variants-modular.xml, but I might start seeing some later :) 14:29:05 <langdon> jkaluza, well... the reason it may not be a detail is .. you don't have to know anything about pungi to write what I proposed :) 14:29:11 <langdon> so you guys wouldn't have to do it 14:29:21 <jkaluza> langdon: that's true 14:29:33 <contyk> I don't think you should edit pungi configuration if you don't know anything about it :) 14:30:17 <contyk> although adding stuff to variants is trivial 14:30:19 <langdon> contyk, you could still have the PR process... it would just be automatically generated, pr created, ticket filed and then some human would just review it before merging 14:31:17 <contyk> yeah, sure 14:31:23 <contyk> it shouldn't be more than 20 lines in python 14:31:23 <jkaluza> note that for F27 modular release this time, we want to define the NSV of a module, not just NS 14:31:44 <contyk> jkaluza: nsv? in pungi? why? 14:32:54 <jkaluza> contyk: wait, waiting for pagure... 14:33:31 <langdon> jkaluza, threebean wonder if you could file a ticket in "somewhere" for "my" version.. and then we could promote it and someone else may step up to write the ~20 lines (per contyk) 14:33:38 <jkaluza> contyk: with normal fedora release, at certain time before the release, the compose is done from "f26-compose" tag instead of "f26" tag. 14:33:53 <jkaluza> contyk: they freeze the "f26", tag things to "f26-compose" and use that for a compose 14:34:17 * threebean nods 14:34:18 <contyk> jkaluza: ok, so you want to freeze certain versions 14:34:25 <threebean> this is so we can stabilize things in the weeks before GA. 14:34:27 <contyk> jkaluza: I hope that version will be optional for this use case? 14:34:44 <jkaluza> We need to do the same thing for modules - we should not pull random latest version of a module from the stream 14:34:44 <contyk> so we don't have to keep updating it during the development phase 14:34:54 <jkaluza> contyk: during development, there will be NS 14:34:59 <contyk> cool 14:35:01 <threebean> yeah - we'd only enter the "V' of the NSV after certain freeze points. 14:35:15 <threebean> (will need a script to read in the variants-modular.xml and write out a new "frozen" version) 14:35:40 <jkaluza> contyk: but composes like the "beta" one will be done using NSV defined by "someone" or by a script as threebean mentioned 14:35:48 <contyk> yeah 14:36:03 <contyk> I hope we will be able to use the new naming scheme we will agree upon soon ;) 14:36:07 <jkaluza> threebean: hm, got an idea, we can tag the module builds defined by content generator to f26-modular-compose 14:36:15 <jkaluza> threebean: maybe wrong ;) not sure 14:36:34 <threebean> jkaluza: oo :p 14:36:57 <jkaluza> *f27-modular-compose 14:36:58 <threebean> yeah - but then we'll need to modify pungi to *use* that f26-modular-compose instead of variants-modular.xml which may be more work than is worth it. 14:37:05 <threebean> just to have things "look like the old way" 14:37:05 <jkaluza> yeah 14:37:10 <threebean> what releng really needs is the ability to freeze. 14:37:16 <jkaluza> yeah, we don't need old days 14:37:20 <jkaluza> *old ways 14:37:29 <threebean> and (tbh) it seems easier to freeze based on an xml file in git than it does by manipulating koji tags. 14:37:38 <jkaluza> sure 14:38:27 <nils> are we done with this, or only strayed from the topic :)? 14:39:24 <langdon> jkaluza, threebean can we #action to file the ticket so someone else "could" build the module->xml generator? 14:40:16 <threebean> langdon: can you just file it in the FACTORY backlog? :p it still requires a pungi patch even after its done, which I'm asking not to do this cycle. 14:40:29 <threebean> we have big fish to fry(!) 14:40:29 <contyk> what patch? 14:40:36 <jkaluza> threebean: he only wants to generate variants-modular.xml, that does not need pungi patch 14:40:47 * threebean shrugs 14:40:55 <jkaluza> threebean: based on the requires: from the fedora:27 module stack 14:40:57 <contyk> yeah, basically you would just read the modulemd files recursively and add everything to variants 14:41:08 <threebean> sure, but then you still need to commit the output and and merge it for it to be used by anything. 14:41:20 <contyk> yes, but you said that should be easy now :) 14:41:31 * threebean was thinking of having pungi just use this script directly, so we get rid of a committed variants-modular.xml -- *that* would require a patch. 14:41:32 <langdon> threebean, ohh i wasn't gonna be that cool... i just would have the script do a PR and file a ticket 14:41:39 <jkaluza> threebean: you can put that to nightly.sh 14:42:00 <threebean> \o/ go for it ;) 14:43:08 <langdon> ok.. i brought it up.. ill file the ticket :/ 14:43:09 <jkaluza> langdon: still not sure - do we want that to define f27 modules? 14:43:19 <langdon> jkaluza, ?? 14:43:20 <jkaluza> langdon: I mean to have module stack to define f27 14:43:39 <langdon> jkaluza, can't hurt to try it.. we can always delete the script if we don't like it :) 14:43:45 <jkaluza> langdon: ok 14:43:56 <langdon> atomic is thinking about the same thing.. 14:44:02 <langdon> so .. i think there is value 14:44:09 <nils> ...speaking of Atomic :) 14:44:12 <jkaluza> because I'm not 100% sure how MBS handles module build without components, but this should be easy to fix 14:44:21 <nils> we have a quarter of an hour left and two topics 14:44:35 * jkaluza should not join next time... :/ 14:44:55 <nils> jkaluza, no worries 14:44:57 <langdon> #action langdon to file a ticket in pungi(?) backlog to create a modulemd -> pungi config generator 14:45:01 <jkaluza> nils: :) 14:45:12 <langdon> my terminology correct ^^ ? 14:45:25 <contyk> :) 14:45:32 <contyk> dgilmore will implement it 14:45:53 <nils> good, let's continue 14:46:03 <nils> #topic Modular Atomic Host 14:46:06 <contyk> :D 14:46:15 <nils> whose is this one? 14:46:21 <contyk> guess mine again 14:46:25 <nils> :) 14:46:26 <contyk> so this will be super short 14:46:35 <nils> 👍 14:46:36 <contyk> #link https://pagure.io/atomic-wg/issue/312 Experiment with building Atomic Host out of a module 14:47:05 <contyk> so I just wanted to announce this experiment -- we will try to define atomic host as a module 14:47:13 <contyk> and of course -- build it and compose it 14:47:27 <contyk> this will be independent of host & platform but it will be using the same buildroot 14:48:07 <contyk> kinda similar to f26 base-runtime, it will be a standalone module and the intention is it will, unlike host & platform, follow the latest development branches for most components 14:48:32 <contyk> it will also bundle some big container runtime because we don't care that it changes too often in this case 14:48:58 <contyk> we'll try to deliver something that builds first, and then make it track rawhide 14:49:31 <contyk> the end goal is a fully automated rebuild of atomic host every time one of its packages changes 14:49:47 <contyk> it should then be tested, fully automatically, and pushed out if CI says it's good 14:50:05 <contyk> it's a great stress test for the pipeline and motivation for extending our test suites 14:50:22 <contyk> but this is by no means meant to be a stable deliverable in f27 14:50:26 <contyk> it's just an early experiment 14:50:35 <contyk> I suppose we could have something within the next two weeks 14:50:51 <contyk> #info Expect a modular Atomic Host prototype within the next two weeks! 14:50:56 <contyk> ...done; questions? :) 14:51:19 <langdon> contyk, wont you need the modulemd -> pungi thing for that? 14:51:29 <contyk> no, I can do those things by hand 14:51:48 <contyk> was doing that during the whole f26 development cycle :) 14:52:25 <langdon> :) 14:52:47 <nils> ok, next 14:52:50 <nils> #topic Modular Guidelines and Review Process 14:53:00 <nils> tflink, that was yours, right? 14:53:04 <contyk> no 14:53:06 <contyk> it was ttomecek 14:53:07 <nils> no? 14:53:09 <nils> aah 14:53:14 <nils> #chair ttomecek 14:53:14 <zodbot> Current chairs: contyk dgilmore langdon mikedep333tflink nils ttomecek 14:54:27 <ttomecek> sorry, in other meeting 14:54:50 <contyk> should langdon summarize it? 14:54:57 <contyk> we talked about it just before this meeting 14:55:02 <langdon> current status.. 14:55:07 * langdon types 14:55:49 <langdon> fedora council approved fesco approving the initial guidelines and process, after that this group will be reponsible for maintaining them 14:56:39 <langdon> contyk, nils and geppetto are updating the spec (based on a couple missing items from the last week or so) and associated guidelines to be as close as possible make sure they are 14:56:50 <langdon> oops.. ignore "make sure they are" 14:57:16 <langdon> shooting to file a ticket with fesco by the end of the week to review it at the next fesco meeting next friday 14:57:43 <langdon> "someone" needs to get the bz product created to file review requests.. which I don't think we have done or assigned anyone too 14:58:01 <langdon> "someone" also needs to identify any other gaps in the process that I am not thinking of 14:58:09 <langdon> ok.. thats the status... any questions? 14:58:22 <nils> langdon, can you #info that :)? 14:58:46 <langdon> yep.. wondering if we had anyone we could assign to the process things first 14:59:30 <langdon> ha.. don't all jump up at once :) 14:59:36 <langdon> ok... infoing. 14:59:45 <langdon> can we have an #action that is unassigned? 14:59:58 <geppetto> Yeh, just don't put a name there 15:00:01 <nils> checking... 15:00:05 <langdon> #info fedora council approved fesco approving the initial guidelines and process, after that this group will be responsible for maintaining them 15:00:23 <langdon> #info contyk, nils and geppetto are updating the spec (based on a couple missing items from the last week or so) and associated guidelines to be as close as possible 15:00:40 <langdon> #action langdon shooting to file a ticket with fesco by the end of the week to review it at the next fesco meeting next friday 15:00:50 <langdon> #action needs to get the bz product created to file review requests.. which I don't think we have done or assigned anyone too 15:00:58 <contyk> +1 15:01:03 <langdon> #action needs to identify any other gaps in the process that I am not thinking of 15:01:12 <langdon> ok.. how's that? 15:01:16 <nils> ace 15:01:24 <geppetto> 👍 15:01:35 <langdon> cool 15:01:40 <langdon> i think we are out of time 15:01:45 <nils> yep 15:01:53 <nils> anything important for open floor? 15:02:20 <nils> doesn't look like it 15:02:21 <contyk> we only have one more meeting before flock 15:02:39 <contyk> just a reminder how little time we have :P 15:02:51 <nils> :) 15:02:57 <langdon> wow 15:03:59 <contyk> nils: countdown? :P 15:04:03 <nils> 10 15:04:05 <nils> 5 15:04:06 <langdon> nils, endmeeting? 15:04:07 <nils> 2 15:04:08 <nils> 1 15:04:11 <nils> #endmeeting