15:00:56 <langdon> #startmeeting modularity_wg
15:00:57 <zodbot> Meeting started Tue Aug  9 15:00:56 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:57 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:18 <langdon> #chair  dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink, threebean
15:01:18 <zodbot> Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:01:37 <langdon> .hello langdon
15:01:37 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:01:44 <cpacheco> .hello cpacheco
15:01:45 <zodbot> cpacheco: cpacheco 'Courtney Pacheco' <cpacheco@redhat.com>
15:01:45 <haraldh> .hello harald
15:01:47 <zodbot> haraldh: harald 'Harald Hoyer' <harald@redhat.com>
15:01:48 <asamalik> .hello asamalik
15:01:51 <nils> .hello nphilipp
15:01:53 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:01:56 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:02:02 <contyk> .hello psabata
15:02:03 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:03:15 <dgilmore> hi
15:03:35 * langdon waves
15:03:44 <contyk> do we have an agenda?
15:04:06 <langdon> contyk, not really.. proposals to the etherpad? http://piratepad.nl/modularity-wg-agendas
15:04:12 <langdon> i didn't have much time to prep
15:05:21 <contyk> hmmm
15:05:58 <langdon> thought we could discuss flock stuff
15:06:00 <langdon> or things people had brought up
15:06:34 <langdon> #topic agenda
15:06:52 <langdon> no lubos?
15:06:59 <contyk> he's just left
15:07:13 <contyk> coremodule: cool name, btw
15:07:21 <contyk> coremodule: /nick base-runtime
15:07:24 <langdon> contyk, ?? where did that come from?
15:07:31 <contyk> langdon: no idea :)
15:07:43 <asamalik> langdon, AI in a module :)
15:07:48 <langdon> ha
15:07:51 <dgilmore> langdon: I think I scared him
15:07:56 <langdon> ok.. seriously folks.. agenda?
15:08:14 <langdon> dgilmore, he added multi-arch module builds for next week.. he seemed pretty excited to try it
15:08:15 <contyk> langdon: a brief flock report sounds good
15:08:24 <asamalik> well, there have been great demo at flock
15:08:34 <langdon> #info flock report
15:08:34 <asamalik> and Nils created a nice video with the same demos
15:08:39 <langdon> yeah
15:08:44 <langdon> ok.. other stuff?
15:08:45 <asamalik> I'll send a link
15:08:52 <langdon> asamalik, not yet
15:08:58 <langdon> finish agenda first..
15:09:00 <dgilmore> langdon: well, we have managed to either not consider multiarch, or we do things that do not work due to only running on one arch
15:09:07 <asamalik> langdon, ah, sorry :)
15:09:09 <langdon> dgilmore, details
15:09:12 <langdon> ;)
15:09:24 <dgilmore> langdon: So i think it is critical that we do at least two to make sure that it all works as expected
15:09:27 <langdon> ok.. im gonna shift..
15:09:46 <langdon> dgilmore, +1 .. i totally agreed with lkocman's discussion/cards
15:09:52 <langdon> #topic flock report
15:10:12 <langdon> asamalik, will be giving us a brief update on what happened at flock.. others will chime in :)
15:10:14 <dgilmore> flock was positive
15:10:36 * langdon notes this is the first asamalik has heard he is giving a report ;)
15:11:07 * asamalik is good in doing things ad-hoc
15:11:13 <asamalik> so...
15:11:14 <dgilmore> langdon: way to throw people under the bus :P
15:11:27 <asamalik> langdon, did a presentation about modularity
15:11:37 <langdon> ohh.. and.. contyk do you want to give a report on base-runtime? like next steps after this?
15:11:43 <asamalik> the room was full and there was no "no" from the audience
15:11:44 <langdon> dgilmore, everyone needs a talent
15:11:50 <asamalik> lot of questions and interest
15:11:58 <langdon> asamalik, that was the best part
15:12:01 <contyk> langdon: I was think I'd announce it on the list after the formal kickoff
15:12:04 <asamalik> if you want to see a demo from a user perspective, have a look: https://www.youtube.com/watch?v=KK4Id8TKydQ
15:12:06 <contyk> *thinking
15:12:32 <contyk> but sure, I can mention it extremely briefly, if it's worth an agenda item
15:12:32 <langdon> i thought a lot of people raised good points.. luckily, we had considered most of them..
15:12:42 <langdon> contyk, yeah.. after this..
15:13:12 <langdon> asamalik, more to add? thoughts on the workshop? hallway convo? server wg?
15:14:31 <asamalik> I guess there is still a lot to think about - especially about versioning
15:15:11 <asamalik> we probably won't use the same NVR model as in RPMs because it will make people think that higher version number means "better" version
15:15:32 <langdon> for the group.. we realized that people got hyper-focused on the NVR of a module .. we need people to start looking at module metadata to understand the "right" choice.. and, because rpm, people assume nvr is enough
15:15:51 <asamalik> but it's not like that - so from psychological perspective, we might want to use name-stream-version instead
15:16:03 <asamalik> where "stream" would be just a random identifier
15:16:19 <contyk> it kinda works like that already but the terminology is confusing
15:16:44 <contyk> the current "version" already identifies an update stream of a module
15:16:51 <langdon> yeah.. "stream" also implies something.. which I don't think we mean.. its really just "word" (or words) ..
15:16:55 <contyk> and the "release" identifies the version in that particular stream
15:17:01 <langdon> a la docker container instance naming
15:17:08 * contyk nods
15:17:37 <asamalik> it is really just an ID
15:17:41 <langdon> so.. we stuck that change in the backlog.. including working out how to do it
15:17:44 <asamalik> and users will search for their modules by metadata
15:17:45 <langdon> asamalik, right
15:18:06 * dgilmore thinks the anaconda side needs considering also
15:18:07 <langdon> yeah.. as i think i mentioned somewhere... like parsing the ip command output
15:18:15 <jkaluza_> asamalik: we also have a card for that searching
15:18:16 <dgilmore> but thats probably a future task
15:18:20 <langdon> dgilmore, true
15:18:31 <jkaluza_> created by me today in new :)
15:18:38 <langdon> jkaluza_, :)
15:19:00 <jkaluza_> (That would probably need some online service for searching...)
15:19:00 <langdon> dgilmore, we have been punting so far on "making a new machine from modules"..
15:19:43 <langdon> so.. i would also add that I liked that we had such good attendance for the workshop.. which was a late addition ... people sitting on the floor
15:20:21 <langdon> we do need to add a followup with maxamillion to understand why he thinks parallel install is such a common use case
15:20:35 <asamalik> langdon, right
15:20:41 <langdon> #info need to engage with anaconda team to understand installing modules
15:20:47 <asamalik> btw about the parallel install
15:21:08 <nils> langdon: ym "parallel" as in "two versions of the same module side-by-side"?
15:21:08 <langdon> #action langdon to follow up with maxamillion re: parallel install use cases
15:21:14 <langdon> nils, correct
15:21:18 <asamalik> we (read I can't remember who) had an idea that we should use the native parallel install method from the component
15:21:19 <langdon> ohh
15:21:21 <langdon> no.. sorry
15:21:21 <nils> thanks for clarifying
15:21:27 <asamalik> like rubygems suport that etc
15:21:43 <asamalik> and maybe use SCL-like method on stuff that doesn't support that
15:21:51 <langdon> nils, more like .. two installs of the same binary, different versions, may or may not be the same modules
15:21:52 <nils> containers, images?
15:21:57 <nils> aah
15:22:07 <contyk> langdon: that's pretty important giving the amount of bundling
15:22:10 <nils> well, same modules would break down to that lower-level anyway :)
15:22:11 <contyk> we plan to do
15:22:17 <langdon> nils, sct still working on the doc... but IIRC "containers"
15:22:40 <langdon> contyk, what's important?
15:22:43 <nils> yeah, that looks like the most promising way to tackle this
15:22:56 <contyk> langdon: parallel installation
15:23:14 <asamalik> contyk, good point
15:23:15 <langdon> nils, yeah.. but it means dnf needs to be able to introspect a container.. if we want it to remain "unbundled" like we do with rpm-modules
15:23:40 <langdon> contyk, right.. i think ^^ is the same comment
15:24:18 <asamalik> we have also talked about Copr
15:24:27 <asamalik> we will probably use Copr for scratch builds
15:24:37 <langdon> asamalik, ahh right.. can you elaborate on why? and what is involved?
15:25:10 <asamalik> langdon, because some kind of koji magic stuff I don't understand :)
15:25:17 <asamalik> maybe contyk can provide more details?
15:25:19 <langdon> asamalik, :)
15:25:30 <contyk> :)
15:25:45 <contyk> it's about builds on koji being permanent
15:26:14 <dgilmore> koji enforces globally unique nvra on all rpms
15:26:22 <contyk> dgilmore: that's not really an issue
15:26:29 <dgilmore> contyk: it can be
15:26:31 <contyk> dgilmore: we put the module "NVR" in the dist tag
15:26:41 <dgilmore> contyk: also the cost of new repos is really high in koji
15:27:06 <langdon> well.. also .. stg.fp.o is not "complete" in a bunch of ways.. so perms are a thing and lookaside cache.. so using copr as a backend and "arbitrary git" for the frontend would allow more people to experiment
15:27:07 <dgilmore> it has to read all the inherited tags rpms when making a new repo initially
15:27:20 <dgilmore> we really need to rethink repo generation and management
15:27:38 <dgilmore> langdon: indeed
15:27:50 <asamalik> another thing about Copr is building "community versions" of modules - as we do with RPMs now
15:28:00 <asamalik> Copr is ideal place for that, because it supports namespaces
15:28:04 <asamalik> a project would become a module
15:28:30 <asamalik> and from a UX perspective, I would like to see the same tools being used to install copr modules
15:28:51 <dgilmore> contyk: there will be issues down the road with the "fc<release> = 1" and "fedora = <release>" macros down the road as well
15:28:59 <dgilmore> and the rhel equivilents
15:29:00 <asamalik> for example, official module from fedora would be installed by "name-stream-version"
15:29:12 <asamalik> module from copr would use "username/name-stream-version"
15:29:49 <asamalik> if would of course gave you a warning that modules from copr can break your system and everything...
15:30:00 <langdon> #info proposal to implement rida with arbitrary git as input and copr building output came up at flock as well
15:30:44 <langdon> i also think we had a bunch of good meetings with server wg.. as has been the plan for awhile, server is where we expect to see modules first
15:31:05 <contyk> client crashed
15:31:07 <langdon> server wg seemed very much in support of that and looks forward to us getting more tightly aligned..
15:31:21 <langdon> unfortunately, their meeting time and ours are the same
15:31:24 <langdon> so...
15:31:49 <langdon> #info we need to review the modularity wg meeting time to try to deconflict with server-wg
15:31:55 <langdon> ugggh ^^
15:32:07 <asamalik> and I also have an idea about building modules in Copr without writing the yaml spec file - you would be able to add the packages, define install profiles, api, etc in the UI... and Copr would generate that yaml spec for you... I guess I'll write a blog bost about it :)
15:32:10 <tflink> whee, figuring out consensus on time again :)
15:32:32 <langdon> tflink, honestly the thing i hate the most..
15:32:52 <langdon> we need to try to sucker^Wconvince jkurik to take it on again ;)
15:33:16 <langdon> more comments re:flock?
15:33:25 <langdon> any more #infos?
15:33:29 <langdon> or #actions
15:34:17 <langdon> everyone sleeping? or should we move on to base-runtime update?
15:34:26 <asamalik> that's all from me I guess :)
15:34:38 <langdon> ok..
15:34:44 <langdon> #topic base-runtime update
15:34:48 <contyk> right
15:35:19 <contyk> so we've decided to spin up a new team that will focus on the base-runtime module stack
15:35:48 <contyk> the team will have its own taiga board but I don't expect any special, dedicated meetings
15:35:55 <contyk> it's still part of modularity
15:36:08 <contyk> base-runtime is... well, that's what we don't really know yet :)
15:36:12 <langdon> ha
15:36:19 <haraldh> hehe
15:36:24 <contyk> but the basic idea is that it should be a module stack that lights up the hardware, where applicable
15:36:43 <contyk> and possibly adds some common "platform runtime" stuff that other modules can build on
15:36:52 <contyk> although that might go into a separate module stack
15:36:58 <contyk> we'll have to figure it out; that's the purpose of the team
15:37:03 <contyk> so... yeah
15:37:09 <langdon> contyk, when can we expect you to have cards and/or a report on status?
15:37:22 <contyk> later this week
15:37:40 <haraldh> lights up the HW... kernel -> dracut -> systemd -> udev ... done
15:37:44 <contyk> I'll send an announce mail to the devel list
15:37:45 <langdon> contyk, cool.. want to add it to the agenda for next week's meeting?
15:38:17 <contyk> haraldh: it could be even simpler... or more complicated :) everyone has an opinion
15:38:20 <contyk> it's beautiful ;)
15:38:24 <haraldh> I know :)
15:38:27 <langdon> #chair contyk
15:38:27 <zodbot> Current chairs: contyk cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:38:28 <contyk> langdon: sure
15:38:56 <langdon> contyk, ok.. move to open floor?
15:39:04 <contyk> #action contyk will send a base-runtime announce mail to devel@lfpo later this week
15:39:07 <langdon> any other comments on b-r at this point?
15:39:30 <contyk> hmm, no, not really
15:39:33 <langdon> ok
15:39:38 <langdon> #topic open floor
15:39:52 <asamalik> I have forgot to mention one important thing
15:39:53 <langdon> anyone have anything from flock they wanted to mention/ask about?
15:40:17 <asamalik> there has been some confusion about building module stack
15:40:31 <asamalik> these will use "component" rather than "dependency" relationship
15:40:36 <dgilmore> langdon: just that we all need toget marketing people to help with our terrible slides
15:40:47 <asamalik> which means that all the "submodules" in a stack will be rebuilt and bundled into the stack
15:41:15 <dgilmore> langdon: one thought I had today
15:41:17 <dgilmore> epel
15:41:18 <langdon> dgilmore, MY SLIDES WERE AWESOME!
15:41:21 <asamalik> so we'll get a bundle, but we will know what's in it because we will have a list of RPMs
15:41:28 <dgilmore> when an epel module depends on a rhel module
15:41:33 <dgilmore> how will taht work
15:41:52 <asamalik> dgilmore, I guess there will be no dependencies, right langdon?
15:42:19 <langdon> #info we realized at flock that we use the term "dependency" when we should say "includes" re:module-stacks.. the resultant module made from a stack is a bundled set of modules not a set of deps
15:43:03 <langdon> dgilmore, asamalik well.. both.. we still need deps we just want to discourage them because otherwise we tie lifecycles together..
15:43:05 <contyk> dgilmore: the module should "just work" as long as the "base-runtime" is compatible
15:43:10 <langdon> so .. the short answer is .. it is tough..
15:43:19 <contyk> langdon: right?
15:43:21 <langdon> much like the problems of dependent scls..
15:43:44 <langdon> contyk, yes... but.. you don't know if they work with each other.. or they get stuck tightly together
15:44:06 <asamalik> langdon, right, the lifecycles a good argument here
15:44:16 <langdon> so.. we need to think about "x org module-stacks" or something.. like is that ok
15:44:36 <langdon> we even have it with copr module including a fedora module
15:45:05 <asamalik> langdon, well, Copr will not be able to work without using fedora modules
15:45:24 <langdon> my first thought is x-org inclusion should be deps.. but .. i think you end up with bad things
15:45:37 <dgilmore> contyk: well we have the issue where EPEL can not ever ship a RHEL binary
15:45:39 <langdon> asamalik, well.. i really mean is it "dep" or "inclusion"
15:45:42 <asamalik> langdon, so it's a requirement for copr to use fedora modules - rather than a fetaure - at least from my point of view
15:45:57 <dgilmore> as in it is to not possibly happen
15:46:22 <contyk> dgilmore: it can ship its rebuild of the more-or-less same sources, though
15:46:28 <langdon> dgilmore, i think that constraint may be fine.. but does a epel-module include or just dep on the rhel-module?
15:46:29 <dgilmore> contyk: nope
15:46:38 <langdon> similar to the copr->fedora problem
15:46:55 <contyk> dgilmore: oh wait, I was reading it as centos
15:46:58 <dgilmore> contyk: EPEL is not allowed to replace or ship a binary that is shipped in RHEL period
15:46:58 <contyk> dgilmore: never mind :)
15:47:07 <contyk> you're right, of course
15:47:19 * nils gotta go
15:47:26 <nils> see ya
15:47:35 * langdon waves
15:47:42 <dgilmore> just another wrinkle
15:47:47 <dgilmore> adios nils
15:48:12 <langdon> do you guys understand/agree with my comments? like i don't think it is a "problem" but I think the implementation can make some bad choices
15:48:54 <dgilmore> langdon: not sure I fully understand what you are getting at
15:49:25 <dgilmore> langdon: there is nothing saying that copr can't rebuild something from fedora and bundle
15:49:37 <dgilmore> might be funky and ugly
15:50:04 <langdon> so.. i am calling epel+rhel or copr+fedora like "cross-org relationships" .. and, as we discussed above.. having a module or module stack depending on another module ties their lifecycles together..
15:50:11 <langdon> whereas "including" a module does not
15:50:54 <langdon> however, should x-org relationships always be deps? like that seems more logical from a separation perspective.. but loses lifecycle independence which is bad..
15:51:08 <asamalik> langdon, I got the same idea
15:51:16 <langdon> so .. suffice to say .. technically, i don't think it is hard.. but from a policy perspective, it might be tough
15:51:23 <asamalik> langdon, for x-org relationships as deps
15:51:33 <contyk> x.org and similar should be deps rather than bundled for practical reasons
15:52:08 <langdon> contyk, i hear ya.. but it is yucky
15:52:46 <langdon> #info need further discussion on guidance regarding cross-org deps of modules (e.g. copr-modules on fedora-modules)
15:52:57 <asamalik> I guess we will not make the decision here, but we will definitely make a note and have a look at it
15:53:05 <asamalik> ha! you were faster :)
15:53:09 <langdon> well.. geppetto, you around?
15:53:28 * dgilmore needs to run to another meeting in 5
15:53:33 <geppetto> yeh
15:53:33 <langdon> geppetto has been working on the guidelines for modules.. and I would like to see a placeholder added for this
15:53:59 <langdon> dgilmore, i was gonna wrap right after convincing geppetto to keep track of this :)
15:54:09 <dgilmore> langdon: :) okay
15:54:18 <geppetto> what do you mean by placeholder?
15:54:35 <langdon> geppetto, oh like a "section in the guidelines" that may not be filled out yet
15:55:45 <geppetto> From the FPC POV I thought the x-org deps. would mostly be stricly one way, but who knows for inside
15:56:10 <geppetto> I think a bunch of that will fall out from the meeting tomorrow
15:56:12 <langdon> geppetto, right.. hence "placeholder" :) .. or if it needs separate docs?
15:56:16 <geppetto> Well, some
15:56:30 <geppetto> Yeh, we at least need to say sothing :)
15:56:44 <langdon> i dont know.. i just don't want to forget to keep track of it
15:56:54 <langdon> ok.. gonna wrap
15:56:58 <langdon> going oncee
15:57:06 <geppetto> #action geppetto don't forget to add something about x-org deps. to policy
15:57:15 <langdon> geppetto++ ;)
15:57:16 <zodbot> langdon: Karma for james changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:57:22 <langdon> going twice
15:57:37 <langdon> going three times
15:57:53 <langdon> #endmeeting