15:00:04 <bowlofeggs> #startmeeting Bodhi multi-type requirements gathering, part II
15:00:04 <zodbot> Meeting started Tue Apr  4 15:00:04 2017 UTC.  The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:04 <zodbot> The meeting name has been set to 'bodhi_multi-type_requirements_gathering,_part_ii'
15:00:11 <bowlofeggs> #topic salutations
15:00:20 <bowlofeggs> #chair acarter bowlofeggs dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag
15:00:20 <zodbot> Current chairs: acarter bowlofeggs dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag
15:00:28 <marc84> morning everyone
15:01:04 * mboddu is sort of here
15:01:14 <trishnag> hi everyone o/
15:01:21 * cverna is around
15:01:29 * sayan is around
15:01:39 * nirik is slightly here, but also busy... ping if you need me specifically.
15:02:09 <dustymabe> morning
15:02:35 <mmorris4055> good morning
15:03:23 <bowlofeggs> let's get this party started
15:03:32 <bowlofeggs> #topic requirements
15:03:40 <bowlofeggs> there's only really one topic for this meeting
15:04:07 <bowlofeggs> we had a discussion during last week's bodhi stakeholder's meeting about the requirements for adding multiple types for bodhi (i.e., non-rpms)
15:04:22 <bowlofeggs> you can read the log of that discussion here: https://meetbot.fedoraproject.org/fedora-meeting-1/2017-03-28/bodhi_stakeholders.2017-03-28-15.00.log.html
15:04:50 <bowlofeggs> since that discussion ran out of time, i decided to hold another discussion
15:05:25 <bowlofeggs> i started an etherpad to capture the high-level requirements for multi-types: https://public.etherpad-mozilla.org/p/bodhi-multi-type
15:05:44 <bowlofeggs> and sochotni has an etherpad that is specific to modules: https://public.etherpad-mozilla.org/p/fedora-modules-in-bodhi
15:06:46 <bowlofeggs> last week we talked a lot about whether updates can have more than one type in them, and i think we settled on updates having only one type, but that we need to provide releng a way to push related updates out
15:07:17 <bowlofeggs> i felt satisfied with that conclusion, so i'd like to move on to other topics unless anyone is dissatisfied
15:08:58 <bowlofeggs> i'll take that as a "nobody is dissatistfied"
15:09:13 <bowlofeggs> #topic API reverse compatibility
15:09:28 <bowlofeggs> i've been thinking about what goal to set with the API
15:10:07 <bowlofeggs> do we want it to be reverse compatible, so existing API clients continue to work as they do today, or do we want to scrap that API and provide only a multi-type API with bodhi 3?
15:11:33 <dustymabe> crickets
15:12:16 <jcline> I sort of like having two API versions running at once for a little while, but I know there are downsides to that, especially with how bodhi does its API
15:12:58 <bowlofeggs> i think i also lean towards preserving compatibility, but the bigger downside to me is actually just the effort level
15:13:18 <bowlofeggs> the obvious benefit is that it will be less disruptive
15:13:21 <jcline> Yeah, gutting it and starting fresh is certainly appealing
15:15:10 <cverna> which apps are using bodhi APIs ?
15:15:32 <cverna> just to see how disruptive it would be to break compatibility
15:15:48 <bowlofeggs> cverna: i don't know that i can give an exhaustive list, but the main thing that comes to mind is the bodhi CLI and fedora-easy-karma
15:16:01 <nirik> bodhi command line, fedora easy karma, fedora gooey karma... at least
15:16:15 <bowlofeggs> and the bodhi CLI in f24/25 is 0.9, which is not compatible with the 2.x CLI
15:16:28 <bowlofeggs> there's a gooey karma too? ☺
15:16:54 <bowlofeggs> i think dustymabe had been working on something that used teh API too?
15:17:54 <jcline> That's not a bad list, but the CLI might be a pain point
15:18:04 <dustymabe> bowlofeggs: right now i'm just using the bodhi cli
15:18:19 <dustymabe> probably will use the API soon, but don't worry about me
15:18:19 <bowlofeggs> in general, i would prefer not to update the F24/25 CLI to bodhi 2 just because bodhi 2 isn't reverse compatible, and may also not be fully feature compatible either
15:18:22 <jcline> Maybe it's worth making sure the 2.x CLI has parity and updating it in older Fedoras
15:18:32 <dustymabe> whatever i'm doing is small enough that changes can easily be made
15:18:45 <x3mboy> .hello x3mboy
15:18:49 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
15:18:51 <jcline> It'd be nice to avoid that, though
15:19:12 <jcline> The releasing it in old versions, not the making it feature-complete bit, obviously
15:19:24 <bowlofeggs> haha yeah
15:19:52 <bowlofeggs> it doesn't sound like anyone is very passionate one way or the other about API compatibility
15:20:51 <cverna> both direction seems to need some effort anyway
15:21:17 <bowlofeggs> yeah effort is required either way
15:21:54 <bowlofeggs> well i guess i'll take the crickets to mean there is no requirement around API compatibility
15:22:08 <bowlofeggs> so bodhi developers can do what they want there
15:22:32 <bowlofeggs> i had a similar topic lined up about fedmsg compatibility
15:22:41 <bowlofeggs> #topic fedmsg reverse compatibility
15:22:57 <bowlofeggs> i'm not sure that fedmsgs can be done in a reverse compatible way
15:23:15 <bowlofeggs> and there are systems that look for those
15:23:36 <bowlofeggs> i think we may be able to do some of them reverse "compatibly", but i expect that some will not be possible
15:23:53 <bowlofeggs> especially when new types don't have the data that RPMs have
15:24:05 <jcline> Yeah, we talked about this a bit, but mostly it seems to be you make a change, alter a bunch of if statements in fedmsg_meta, and hope for the best
15:24:10 <bowlofeggs> so for fedmsgs, i propose not having a goal of reverse compat
15:24:28 <bowlofeggs> i also plan to document bodhi's fedmsgs since bodhi's docs do not include those today
15:24:37 <jcline> even then plenty of apps dig around the message itself rather than using fedmsg_meta APIs
15:25:00 <jcline> I think that's reasonable
15:26:08 <bowlofeggs> it may be worth it to include a "schema version" with the new messages
15:26:17 <bowlofeggs> so that future changes can be explicit
15:26:29 <jcline> bowlofeggs, you could be the test subject for this fedmsg schema idea
15:26:42 <bowlofeggs> yeah i'm a big +1 on having a formal schema
15:28:34 <bowlofeggs> cool, well let's say that we don't need to be reverse compatible on fedmsgs as the decision here
15:28:50 <bowlofeggs> i documented that and the schema/docs stuff in the etherpad
15:28:57 <bowlofeggs> #topic CLI reverse compat
15:29:10 <bowlofeggs> it may be possible/feasible to make the CLI reverse compatible
15:29:15 <bowlofeggs> would that be a worthwhile goal?
15:29:31 <bowlofeggs> it may be as simple as including a --type flag that defaults to RPM if not present
15:29:43 <jcline> That might be worth doing
15:30:00 <jcline> I have a feeling a lot of scripts are using the cli rather than the API directly
15:30:12 <bowlofeggs> yeah i also have that feeling
15:30:17 <bowlofeggs> i know fedpkg does
15:30:34 <sochotni> sorry for being late, scrolling through backlog now
15:31:09 <cverna> I believe that most of the user will still be interested in the RPM type
15:31:38 <cverna> so CLI reverse compability is quite important
15:31:42 <bowlofeggs> yeah i think we can expect most people to remain heavily RPM focused for F27, but that will probably change over time
15:32:13 <sochotni> bowlofeggs: I'll just repeat the expectation that F27 would be a fully modular release - i.e. no rpms outside modules
15:33:09 <dustymabe> sochotni - we have a long way to go if that is going to happen
15:33:11 <dustymabe> :)
15:33:18 <sochotni> no argument there...
15:34:02 <sochotni> i.e. who maintains the rpms that go into modules and how do those rpms get updated/shipped (i.e. do they get their own bodhi updates still but the yum repodata doesn't get created for them)?
15:34:14 <sochotni> anyway-  outside of scope for this discussion now
15:34:47 <sochotni> wrt CLI reverse compat - I'd guess we should be able to preserve compat without too much trouble?
15:35:02 <bowlofeggs> yeah i think it's feasable
15:35:04 <sochotni> i.e. default to rpm update
15:35:10 * masta is here now (late)
15:35:23 <sochotni> or possibly auto-detect based on the builds/info provided
15:35:28 <bowlofeggs> ok i think we can move to open floor now
15:35:33 <bowlofeggs> #topic open floor
15:35:49 <bowlofeggs> what else do we need to think about for multiple types in bodhi?
15:36:08 <sochotni> the idea threebean had wrt making modules as a first-level builds in koji using content generators would help bodhi too
15:36:10 <sochotni> and other tools
15:36:51 <bowlofeggs> i'm not familiar with content generators - can you explain that a bit more?
15:37:08 <sochotni> I'd have to dig around for links right now  but basically..
15:37:28 <sochotni> it is an API that OSBS uses to import containers back into koji
15:37:48 <sochotni> it enables external buildsystems to record what was built and add more metadata into it
15:37:58 <bowlofeggs> ah cool
15:38:00 <sochotni> effectively creating an NVR/build in koji
15:38:14 <bowlofeggs> yeah it would be nice if builds were always in koji in some  way
15:38:33 <bowlofeggs> i wouldn't say it is a requirement, but it hink it would simplify things a good bit
15:38:58 <sochotni> I agree, I'll reach out to mbs folks to see how much work it would be
15:39:34 <sochotni> #action sochotni - reach out to mbs folks wrt koji content generators
15:40:27 <sochotni> from my POV - we likely have possibility for some parallel development
15:40:53 <sochotni> i.e. some tooling on PST/SRT side, some on MBS, some elsewhere...
15:41:31 <bowlofeggs> cool
15:41:32 <sochotni> bowlofeggs: is there any decision blocking your work atm?
15:41:48 <bowlofeggs> sochotni: no, jcline and i have actually already begun working ont he database models
15:42:01 <bowlofeggs> the Package model is almost done (PR up)
15:42:17 <bowlofeggs> we have to convert about 4 models to be multi-type compatible
15:42:32 <sochotni> ok, I'll try and get some eyes on it from other folks if you'd like?
15:42:48 <bowlofeggs> sure if you want to - i may also merge it soon anyway
15:43:07 <bowlofeggs> jcline wrote the PR so i can merge it after i review it
15:43:22 <bowlofeggs> but more eyes are certainly welcome as always
15:43:48 <bowlofeggs> jcline has also been working on correcting bodhi's usage of sqlalchemy
15:43:56 <bowlofeggs> it turns out that bodhi has been using it pretty incorrectly
15:44:12 <sochotni> I had one question actually - do we have someone from UX team who we could try and engage?
15:44:19 <bowlofeggs> i'm planning to modify the Build model next
15:44:33 <bowlofeggs> sochotni: it would be good to talk to Ryan Lerch
15:44:41 <bowlofeggs> he's actually been doing a bunch of UX work on bodhi recently
15:44:42 <sochotni> I expect we'd keep most things the same as rpms if possible
15:44:48 <sochotni> ok, good
15:44:55 <x3mboy> !
15:45:17 <sochotni> the point there is - I expect we'll want to show some additional things for module updates
15:45:29 <sochotni> for rpms it's easy - this is the rpm you are releasing
15:45:29 <bowlofeggs> yeah i assume the metadata will be different
15:45:45 <sochotni> but I am not sure it's as useful to say the same "you are releasing module abc-123.23-20145343"
15:46:05 <sochotni> it's more useful to say "and this module changed A, B, C from previous module version in the same stream"
15:46:31 <sochotni> even internally for the maintainer to confirm that there are no unexpected changes
15:46:56 <sochotni> it's not *strictly* a requirement I guess, but certainly would be useful
15:48:45 <bowlofeggs> yeah that sounds useful
15:49:05 <bowlofeggs> #action bowlofeggs will talk to ryanlerch about modularity in bodhi
15:49:22 <bowlofeggs> anything else?
15:49:35 <sochotni> potentially - if we assume each of those rpms will have an update in bodhi itself - maybe we want to cross-link them/show them in some way
15:49:50 <sochotni> nothing else from me ATM
15:50:00 <bowlofeggs> yeah that was the thing we talked about extensively last week - providing some way to relate updates
15:50:26 <bowlofeggs> it could be an "update group", or an "update dependency", or just "updates that all reference the same bugzilla"
15:50:29 <bowlofeggs> or CVE
15:50:36 <bowlofeggs> or we could do all four of those ☺
15:50:39 <sochotni> yeah, basically - though now I am thinking more about the maintainer perspective rather than RCM
15:51:08 <bowlofeggs> yeah, the maintainer would be responsible for setting up the groups
15:51:30 <sochotni> ah, no - I meant this would have to be automatically figured out *for* the maintainer
15:51:37 <bowlofeggs> i think the groups could be useful to solve a problem that exists today - if two packagers want to release packages A and B together but neither of them has ACLs on the other, that's currently not possible
15:51:47 <bowlofeggs> but we could let them make an "update group" and put A and B in there
15:51:51 <sochotni> i.e. you have module v1 in repo with specific rpms, and you are shipping an update - show me what has changed
15:52:02 <sochotni> so the use cases are different
15:52:33 <bowlofeggs> oh yeah i see
15:53:00 <sochotni> it would help with more focused testing possibly as well
15:53:14 <bowlofeggs> yeah
15:53:17 <sochotni> i.e. if I know the only package in a module that changed was A, I am going to focus on that
15:53:27 <sochotni> anyway, that's the idea
15:53:46 <bowlofeggs> cool
15:53:51 <bowlofeggs> yeah i think that's feasible
15:54:04 <bowlofeggs> any other thoughts, or shall i end the meeting?
15:54:09 <sochotni> I am again write it down, not necessarily as a requirement - but we can at least lay the groundwork for later
15:54:14 <sochotni> end it please
15:54:16 <sochotni> :-)
15:55:10 <bowlofeggs> #endmeeting