14:31:58 <mboddu> #startmeeting RELENG (2017-05-15)
14:31:58 <zodbot> Meeting started Mon May 15 14:31:58 2017 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:31:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:31:58 <zodbot> The meeting name has been set to 'releng_(2017-05-15)'
14:31:58 <mboddu> #meetingname releng
14:31:59 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
14:31:59 <mboddu> #topic init process
14:31:59 <zodbot> The meeting name has been set to 'releng'
14:31:59 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
14:33:51 * masta is here
14:33:54 <contyk> .hello psabata
14:33:57 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:34:08 * nirik waves
14:35:03 <maxamillion> .hello maxamillion
14:35:05 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
14:35:24 <Kellin> .hello kellin
14:35:25 <zodbot> Kellin: kellin 'None' <kellin@retromud.org>
14:36:51 <mboddu> Okay, its better than last week ;)
14:36:53 <mboddu> lets start
14:36:55 <contyk> ;)
14:37:08 <mboddu> #topic #6746 Produce a slimmed-down compose whenever certain packages appear in an update
14:37:16 <mboddu> #link https://pagure.io/releng/issue/6746
14:37:44 <mboddu> So, I think I need to make couple of changes to the pungi config and waiting on Adam W to reply to my last question
14:38:52 <mboddu> We decided to implement a standardized procedure to do these composes
14:39:27 <maxamillion> is this part of Factory 2.0 or no?
14:39:45 <mboddu> maxamillion: I dont think so
14:40:53 <mboddu> maxamillion: it basically helps QA team to perform tests faster when there is an update for certain pkgs
14:41:29 <maxamillion> +1
14:41:50 <maxamillion> the Atomic WG wants something similar, I'll follow up outside the meeting though
14:42:02 <dgilmore> hi all
14:42:13 <maxamillion> dgilmore: o/
14:42:56 <mboddu> So, I wanted to know how to implement the fedmsg driven tasks and where can we do it, like do we need new VM to do these tasks? And who wants to write the script to do it?
14:44:00 <dgilmore> mboddu: thats really off topic for this meeting
14:44:08 <dgilmore> mboddu: its going to need its own meeting
14:44:30 * nirik thinks we should use loopabull if it can be ready/usable by when we need this
14:44:57 <dgilmore> nirik: most of us have no idea what loopabull is
14:45:09 <maxamillion> dgilmore: really? I've been talking about it for months
14:45:16 <dgilmore> maxamillion: I have no clue
14:45:25 <nirik> it's basically a thing that listens for fedmsgs and runs ansible scripts based on them...
14:45:27 <dgilmore> first I heard about it was a few weeks back
14:45:33 <maxamillion> mboddu: Kellin: are y'all familiar with loopabull?
14:45:38 <dgilmore> and I do not know what it is or what it does
14:45:55 <Kellin> maxamillion: no, but I was going to ask you for an indepth runthrough this week now that you're back from conference-o-rama
14:46:15 <Kellin> maxamillion: (I know what it is in theory, but the practice of it)
14:46:20 <maxamillion> dgilmore: it's been on the planning board since January
14:46:27 <maxamillion> Kellin: +1
14:46:38 <nirik> perhaps next week in this meeting, maxamillion could go over it?
14:46:42 <dgilmore> maxamillion: I guess I missed it all
14:46:42 <mboddu> maxamillion: I heard the name from you and I know you are working on it and its for automation. Not sure whats the status on it and how to use it
14:47:25 <maxamillion> nirik: I could, or at the end of today's meeting if we have time ... I don't think it would take long
14:47:31 <maxamillion> mboddu: rgr
14:47:56 <mboddu> maxamillion: last time I heard you were planning on releasing it, nothing after that
14:48:27 <mboddu> Anyway, I will create a meeting and we can discuss about the compose process
14:48:34 <maxamillion> mboddu: +1
14:48:48 <maxamillion> sorry for the line noise, I didn't realize I hadn't properly communicated about it
14:48:50 <dgilmore> maxamillion: I knew you were working on some automation ideas, but as to the details there has been zero communication
14:49:32 <mboddu> #action mboddu will create a meeting to discuss on how can we do the compose process.
14:50:43 <maxamillion> dgilmore: I think "zero communication" is bit harsh, we've literally sat in the same video calls while I've discussed this with both Kate and Amanda
14:51:06 <Kellin> maxamillion: and mohan, and patrick, and me
14:51:13 <maxamillion> right
14:51:22 <maxamillion> I definitely could have done better on the details
14:52:21 <mboddu> Okay, lets move on
14:52:37 <mboddu> #topic #6791 Create module-bootstrap-master tag similar to f26-modularity
14:52:45 <mboddu> #link https://pagure.io/releng/issue/6791
14:53:03 <mboddu> I just added this ticket to the meeting list
14:53:14 * jkaluza is here in case of questions
14:54:11 <contyk> so am I :)
14:54:19 <mboddu> So, that ticket sort of explains how modularity wants to have tags and when they should be created.
14:56:23 <mboddu> So, they want to have a module master tag that sort of follows rawhide. Modularity people will decide what will go into the tag and when but it might follow the rawhide.
14:56:35 * dgilmore would like to have a much clearer set of requirements
14:56:53 <dgilmore> I also want the same of ostree
14:58:12 <jkaluza> mboddu: this is only about the bootstrap module (tag), which is somehow unique, because it is created manually from existing fedora packages
14:58:30 <contyk> and it's only created manually because the packages are in a poor state
14:58:40 <contyk> otherwise it would have been built by mbs
14:58:41 * dgilmore suggests that using f26 packages for rawhide is not appropriate
14:58:42 <jkaluza> mboddu: it is used to build the real module (base-runtime), which is later used as dependency for other modules.
14:59:31 <contyk> it is not rawhide, it what we want to use
14:59:36 <contyk> it's not tied to any fedora release
15:00:10 <contyk> right now we have one tag that is referenced by two module records; we want to change that by creating a copy
15:00:24 <contyk> one would be kept fairly stable for boltron
15:00:33 <contyk> and the other one would be... a playground
15:01:05 <contyk> at the moment of the split I'd prefer having the same content in both; we'll update the master branch as we see fit
15:02:13 <mboddu> contyk, jkaluza : how can we keep track of whats in what tag? I mean the master tag might contain builds from both f26 and f27, right?
15:02:38 <contyk> mboddu: even epel, even builds not tagged anywhere else... does it matter to you?
15:03:15 <contyk> it's a module :)
15:04:33 <mboddu> contyk: yeah, that is true
15:05:44 <dgilmore> contyk: lets step back a bit
15:06:16 <jkaluza> mboddu: the "master" here means that it will be something like master branch in fedora. After branching, you have two same masters, eventually after some time, they will start becoming different.
15:06:17 <dgilmore> whats the end goal, where is the requiremets doc on how modules are supposed to work? and how does this all fit in
15:06:27 <jkaluza> I think it kind of describes the situation we want to achieve
15:06:32 <dgilmore> what is the actual problem we are trying to solve?
15:07:20 <contyk> dgilmore: I'm not aware of any such doc that would be up to date
15:07:36 <contyk> dgilmore: although I wonder why is that all relevant for a simple "please create a tag" request
15:08:14 <contyk> dgilmore: a general host & platform + buildroots doc is on my agenda
15:08:22 <contyk> it's been for a while
15:09:02 <contyk> just haven't had the time to do it yet
15:09:04 <Kellin> implementation happens after specifications; specifications come from documentation and a clear understanding of long term goals and how it fits into the infrastructure of daily, reproducible, auditable tasks
15:09:31 <Kellin> also - more to the point - as I study factory and modularity it appears that modules and containers solve the same task - so why are we solving this problem twice?
15:09:41 <Kellin> which in effect, doubles the support and long term maintenance work
15:09:49 <Kellin> until that is resolved - we are correct in questioning the 'why' of things
15:10:13 <contyk> Kellin: containers are a binary representation of modules, modules are more abstract
15:10:20 <dgilmore> contyk: well I am trying to solve the problem of random requests coming in without context
15:10:46 <contyk> Kellin: selecting components from one unified pool of packages isn't enough if you want to provide different compile-time options
15:11:15 <contyk> dgilmore: I can try in a few sentences :)
15:12:02 <dgilmore> contyk: I would like to have some more context for when we get such requests
15:12:08 <contyk> the plan for f27+ is to provide two basic, disconnected modules -- the "host" which would contain the kernel, bootloaders, firmware and anything closely tied to hardware
15:12:36 <contyk> this host module should be developed at a fast pace and independently of the main release
15:13:09 <contyk> the platform module would then contain all the standard minimal userspace, from glibc to systemd to auth services and container runtime
15:13:10 <dgilmore> contyk: thats not even close to answering the question
15:13:24 <maxamillion> contyk: what impact does that have on anaconda and the QA teams?
15:13:29 <contyk> dgilmore: I'm trying to provide some background as I don't know what you really want to know
15:13:51 <dgilmore> contyk: I think we should get a proper doc and specification
15:14:08 <contyk> maxamillion: that's a very broad question but the expectation is platform would include the installer
15:15:25 <contyk> maxamillion: regarding QA teams... that's difficult :)
15:15:30 <jkaluza> dgilmore: The problem I personally try to solve by that new tag is that we are using single tag for two different things. We have bootstrap-master module which is defined by f26-modularity tag and also bootstrap-f26 modules, which is defined by f26-modularity tag.
15:15:39 <maxamillion> contyk: alright, it's likely outside the scope of this meeting but I'm interested in more information on that ... are there docs on this anywhere?
15:16:04 <contyk> maxamillion: on testing... modules?
15:16:33 <jkaluza> dgilmore: Now when we want to sing a base-runtime, we are going up the build tag inheritance to find out the core module, which defines what sig key should be used for signing.
15:16:37 <jkaluza> *sign
15:17:16 <jkaluza> dgilmore: So, robosignatory checks that you want to sign base-runtime package, it finds out it inherits f26-modularity and in PDC, it finds out that there are two modules defined by this tag: bootstrap-master and bootstrap-f26
15:17:23 <jkaluza> dgilmore: and it has no clue what sig key should be used
15:17:54 <jkaluza> dgilmore: That is my F26 related reason why I want this new tag. But it makes sense also from contyk's point of view as bootstrap module "maintainer"
15:17:59 <maxamillion> contyk: installer
15:18:02 <contyk> maxamillion: I can point you to https://fedoraproject.org/wiki/Changes/InvokingTests but it's very generic
15:18:03 <maxamillion> contyk: in platform
15:18:34 <contyk> maxamillion: ah, no, not yet
15:18:50 <dgilmore> jkaluza: okay. So we need to have documentation
15:19:10 <contyk> maxamillion: but you can picture platform as fedora minus ~15k packages; not really different, just smaller package set
15:19:25 <dgilmore> jkaluza: none of us has a picture of how it all is supposed tow ork
15:20:05 <contyk> maxamillion: if this is more about "is anaconda expected to know about modules and handle them somehow?", then I don't know
15:20:15 <maxamillion> contyk: yeah, that's the question
15:20:18 <contyk> maxamillion: the answer would be "probably" but afaik nobody has discussed that yet
15:20:40 <jkaluza> dgilmore: not sure it would help, we have changed robosignatory last week anyway, because we had to remove those targets
15:20:46 <contyk> maxamillion: even the dnf team has just started looking into this :)
15:20:54 <jkaluza> dgilmore: I want to say by that, that Boltron is experimental thing
15:20:55 <mboddu> contyk, jkaluza : Can you create documentation on how the koji tags should be created for you guys and why you want them to create in that way. And anything related to koji that you might need.
15:20:56 <dgilmore> jkaluza: it work to keep it updated
15:21:07 <maxamillion> contyk: I don't understand how we're going to install all this stuff if anaconda doesn't understand modules
15:21:42 <contyk> maxamillion: I don't understand that either ;)
15:21:59 <Kellin> so we're trying to support something that doesn't even have a way to be installed?
15:22:17 <maxamillion> contyk: alright
15:22:42 <contyk> maxamillion: so far we've been only considering a small base set where everything exists only in one variant, basically no modules... in that world you don't need any special support in any of the tools
15:23:19 <contyk> maxamillion: once you have multiple variants available in parallel, it becomes more complicated but I don't know what the plan is there
15:23:37 <mboddu> contyk: so, what about the modules you have creating so far? Are they installable?
15:23:39 <contyk> there's no such content yet
15:23:57 <contyk> mboddu: they are installable just fine
15:24:08 <contyk> you can completely ignore the module metadata if you don't care for it
15:24:16 <contyk> it's all in one repo
15:24:59 <mboddu> contyk: okay, back to my question about documentation, can you be able to do it?
15:25:12 <contyk> yes, it's on my plate
15:25:18 <contyk> but I can't promise you any date
15:25:31 <mboddu> contyk: okay, thanks
15:25:33 <contyk> I also have no idea what you guys consider sufficient
15:26:02 <jkaluza> contyk: I can create some general documentation, but I think it's more up to you write your plans with bootstrap
15:26:10 <contyk> I said that in the beginning but I'll say it again -- if the packages were in a better state, we wouldn't have to request this tag from you -- we'd have mbs create it for us
15:26:33 <contyk> this is a workaround for the sad state Fedora packages are in
15:26:34 <mboddu> contyk: You can start with what and when you want it and why do you want them in that particular way. And we can go from there.
15:27:28 <jkaluza> OK, the situation here is that I have to decide how to sign F26 Boltron modules
15:27:51 <jkaluza> Not much time for that
15:28:20 <mboddu> #info contyk, jkaluza and team will provide documentation on koji related stuff related to modularity
15:28:22 <jkaluza> I can either hardcode f26-modularity to be signed by f26 sigkey in robosignatory, and ask puiterwijk|cld to deploy that, or have two two tags
15:28:54 <mboddu> jkaluza: we will take this outside, since we dont have much time
15:28:59 <jkaluza> I mean, sign modules inheriting from f26-modularity
15:29:04 <jkaluza> mboddu: ok then
15:29:40 <mboddu> #topic Open Floor
15:30:12 <mboddu> One quick thing I have is to remind everyone that tomorrow is freeze
15:30:47 <mboddu> Again a friendly remainder to masta to push f26-updates at 00:00 UTC :)
15:30:58 <mboddu> Anybody got anything else?
15:32:12 <mboddu> Okay, lets close this meeting
15:32:14 * nirik has a few things, but actually they can wait probibly for next week or whatever.
15:32:49 <mboddu> nirik: okay, probably next week then :)
15:33:06 <mboddu> Thanks everyone for joining
15:33:11 <mboddu> #endmeeting