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