15:00:34 <bowlofeggs> #startmeeting Bodhi stakeholders (2017-03-28)
15:00:34 <zodbot> Meeting started Tue Mar 28 15:00:34 2017 UTC.  The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:34 <zodbot> The meeting name has been set to 'bodhi_stakeholders_(2017-03-28)'
15:00:35 <bowlofeggs> #meetingname bodhi_stakeholders
15:00:36 <zodbot> The meeting name has been set to 'bodhi_stakeholders'
15:00:37 <bowlofeggs> #topic salutations
15:00:38 <bowlofeggs> #chair acarter bowlofeggs dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag
15:00:38 <zodbot> Current chairs: acarter bowlofeggs dgilmore masta mboddu nirik pbrobinson puiterwijk trishnag
15:00:48 <trishnag> .hello trishnag
15:00:49 <zodbot> trishnag: trishnag 'Trishna Guha' <trishnaguha17@gmail.com>
15:00:53 <roshi> .hello roshi
15:00:54 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
15:00:58 * puiterwijk is half here
15:01:11 <bowlofeggs> half-hello puiterwijk ☺
15:01:24 <sochotni> .hello sochotni
15:01:25 <zodbot> sochotni: sochotni 'Stanislav Ochotnicky' <sochotni@redhat.com>
15:01:25 <puiterwijk> Two meetings at exactly the same time :(
15:01:32 <sochotni> hmm
15:01:35 <sochotni> interessant
15:01:42 <dustymabe> .hello dustymabe
15:01:42 * threebean 
15:01:42 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
15:02:12 <trishnag> bowlofeggs: heh
15:02:23 <sochotni> puiterwijk: what's the other one?
15:02:29 <puiterwijk> sochotni: hubs
15:02:29 * nirik is sort of here.
15:02:40 <bowlofeggs> #topic announcements and information
15:02:42 <bowlofeggs> #info A Bodhi 2.5.0 beta is deployed to staging: https://bodhi.stg.fedoraproject.org/
15:02:43 <bowlofeggs> #info Release notes available at https://bodhi.stg.fedoraproject.org/docs/release_notes.html
15:03:21 <nirik> I wonder if it's worth posting to devel list asking for feedback...
15:03:30 <nirik> could be brutal, but might be worthwhile.
15:03:33 <bowlofeggs> the beta has been on staging for about a week, so i think i will release it this week. it can't get deployed to prod obviously, but it can get released to rawhide and f26 updates-testing
15:03:54 <alcir> .hello alcir
15:03:55 <zodbot> alcir: alcir 'Alcir Azevedo dos Santos' <alazsan@gmail.com>
15:04:02 <alcir> .hello alciregi
15:04:03 <zodbot> alcir: alciregi 'None' <alciregi@gmail.com>
15:04:33 <bowlofeggs> nirik: i did actually post it deep in a thread on fedora-devel in response to the taskotron results, so probably not that many people read it, but it was "kind of" posted there
15:04:46 <nirik> ok, cool.
15:04:52 * masta is around
15:04:53 <dgilmore> hi
15:05:00 <threebean> wow, 2.5.0 looks nice!  https://bodhi.stg.fedoraproject.org/updates/FEDORA-2017-cb0ff57e45
15:05:03 <bowlofeggs> i don't have ny other announcements
15:05:07 <bowlofeggs> yeah i really like the new theme
15:05:11 <bowlofeggs> that was ryanlerch++
15:05:13 <threebean> ryanlerch++
15:05:13 <zodbot> threebean: Karma for ryanlerch changed to 9 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:05:34 <bowlofeggs> updates in particular are much easier to find the info you care about
15:05:39 <sochotni> bowlofeggs: are the icons missing alt text?
15:05:43 <bowlofeggs> the comments are the main thing
15:05:47 <nirik> and the front page doesn't load a million things.
15:06:05 <bowlofeggs> sochotni: that's fixed on the develop branch (or it might be in a PR, can't rememebr if i merged it yet or not)
15:06:19 <sochotni> ok
15:06:49 <bowlofeggs> cool, well let's move on to what i think will be the main thing to discuss today:
15:07:03 <bowlofeggs> #topic Requirements gathering: multi-type support in Bodhi
15:07:05 <bowlofeggs> #info There is a milestone tracking adding multi-type support to Bodhi: https://github.com/fedora-infra/bodhi/milestone/4
15:07:06 <bowlofeggs> We need to gather requirements for this effort.
15:07:36 <bowlofeggs> it's time to start working on adding support for other types of content to Bodhi, which means we have a lot of things to figure out
15:07:52 <bowlofeggs> it sounds like the first type we will add will probably be modules
15:07:55 <sochotni> I started a doc (and I promised I'd put it on a Fedora wiki or a git or something of the sort...)
15:08:15 <sochotni> yeah, I'd probably try to focus on what the minimum requirements would be for F27 deadlines
15:08:20 <bowlofeggs> sochotni: is that doc publicly accessible? can you link it here?
15:08:37 <sochotni> bowlofeggs: well...that's the part I haven't gotten around to :/
15:09:19 <bowlofeggs> one question i have is whether updates should be able to have more than one type in them. for example, should a single update be able to include an RPM and a container, or should those be two updates?
15:09:47 <sochotni> bowlofeggs: https://public.etherpad-mozilla.org/p/fedora-modules-in-bodhi
15:10:22 <sochotni> for that I would go with not mixing content in a single update
15:10:53 <dustymabe> bowlofeggs: could you put both updates out at the same time? and have one depend on the other?
15:11:14 <dustymabe> i.e. container depends on rpm, but someone could theoretically use the container to test the rpm and karma the rpm
15:11:36 <trishnag> +1
15:11:38 <bowlofeggs> dustymabe: i don't know that using one update to test another would be ideal
15:11:53 <dustymabe> bowlofeggs: one is basically a derivative of the other
15:12:02 <puiterwijk> bowlofeggs: well, it'd end up in more test results in bodhi I think
15:12:12 <bowlofeggs> yeah kind of, but what if the environment affects your testing in some way
15:12:22 <dustymabe> bowlofeggs: i think we have that problem today
15:12:28 <bowlofeggs> true
15:12:31 <dustymabe> i install rpm on "my" system
15:12:35 <dustymabe> and test it
15:12:58 <dustymabe> I guess the only "new problem" this would introduce is possibly too many people testing it the "same way"
15:13:03 <dustymabe> so not enough variety
15:13:13 <bowlofeggs> having relationships between updates is certainly possible, an interesting proposal
15:13:36 <sochotni> I kinda think we are heading into too much details right away... could we just agree what would the minimal required functionality be in Bodhi to ship modules for F27?
15:13:37 <bowlofeggs> yeah
15:13:56 <sochotni> i.e. obviously - shipping modules *somehow* through the UI
15:13:57 <bowlofeggs> sochotni: well we do need to figure this question out now because it influences the data modeling
15:14:08 <bowlofeggs> sochotni: after all, the topic is "multi-type", not just modules
15:14:14 <bowlofeggs> we need bodhi to handle containers too
15:14:32 <bowlofeggs> and the modeling choices we make early on will make adding third/fourth types easier or harder
15:14:43 <bowlofeggs> so i think it's important to think this through early on
15:14:57 <sochotni> right, but the problem is that if we have to meet F27 deadlines we need to limit what we do
15:15:02 <bowlofeggs> mdoules also have these questions
15:15:08 <sochotni> I am OK with keeping some things open
15:15:19 <sochotni> but we need to say what is non-negotiable for F27
15:15:48 <bowlofeggs> right, but i also don't want us to be "painted into a corner" because we tried to take shortcuts
15:16:39 <bowlofeggs> so it sounds like nobody thinks we will need updates to have more than one type in them
15:16:51 <bowlofeggs> which means that updates are type-specific
15:17:14 <threebean> yeah, I could go either way.  but type-specific seems cleaner.
15:17:25 <bowlofeggs> we haven't heard from releng on this: dgilmore, mboddu, masta: do you have thoughts on that?
15:17:31 <threebean> having some kind of reference between derivative updates seems like a *very* good idea.
15:17:36 <sochotni> yeah, I'd rather we create a separate update for each type same as we do for each build
15:17:43 <mboddu> bowlofeggs: just joined, let me take a look
15:18:03 <sochotni> (for each release I meant)
15:18:26 <dgilmore> bowlofeggs: sorry not really following this meeting
15:19:01 <sochotni> dgilmore: so whatever we come up with for Bodhi/shipping non-rpm stuff RCM will be fine with?
15:19:20 <dgilmore> sochotni: no, Just doing 20 things at once
15:19:40 <dgilmore> I am not sure what is even being asked here
15:20:19 <sochotni> dgilmore: what are your thoughts on bodhi updates having multiple content type in a single update?
15:20:33 <dgilmore> sochotni: likely we have to support it
15:20:34 <sochotni> dgilmore: i.e. one update having rpm as well as container or something else
15:20:47 <dgilmore> in the case of something like shell shock
15:20:58 <dgilmore> a single update with all updates would be ideal
15:21:37 <dgilmore> but even when the change is say glibc, we may want, container, cloud image, rpm updates all in one
15:21:58 <nirik> but if it's one update that means they could all go or not at once...
15:22:09 <sochotni> bowlofeggs: what happens to karma/votes etc when you change one of the builds in a single update?
15:22:11 <nirik> say the rpm is ok, but there's a -1 on the container
15:22:14 <sochotni> nirik: yeah
15:22:26 <sochotni> exactly where I was going with that
15:22:40 <bowlofeggs> sochotni: currently karma is reset
15:22:52 <nirik> hum, can you attach one bug to multiple updates?
15:23:05 <bowlofeggs> i'd think we would want to be able to release the rpm even if the container is broken
15:23:08 <dgilmore> I would suggest that if there is a bug in the container it also exists in the rpm
15:23:38 <bowlofeggs> what if it's something more fundamental about the container, like it just doesn't function at all, and not due to the rpm?
15:23:39 <nirik> perhaps or yeah, perhaps we want to fix the container before pushing anything out
15:24:08 <bowlofeggs> the more types we add, the higher chance of having one of them preventing pushing out an update
15:24:21 <bowlofeggs> that could be bad int he case of a severe security issue i'd think
15:24:21 <nirik> sure.
15:24:40 <bowlofeggs> we see a problem like this today with ostrees
15:24:41 <dustymabe> yeah i'd rather the container not block the rpm
15:24:43 <dgilmore> bowlofeggs: there may be cases we want to decouple them
15:24:53 <dgilmore> so the flexibility to do so might be good
15:25:02 <sochotni> if you have security fix - it has assigned CVE - can you list bodhi updates if you have a CVE ID?
15:25:15 <bowlofeggs> the ostree builder is lately the most frequent reason for the masher to fail (over the past 2-3 months or so)
15:26:05 <sochotni> in any case - I'd prefer we really limit update to one content type. It gives us better UX options too
15:26:24 <sochotni> once you start mixing content you might realize some things are useless for some content types
15:26:35 <bowlofeggs> sochotni: they would link against the same CVE bug, but i'm not sure you can easily search bodhi by that today
15:26:36 <dgilmore> am pretty strongly opposed to that
15:26:42 <dgilmore> I am
15:26:49 <sochotni> dgilmore: because?
15:26:56 <dgilmore> I would rather make sure we deliver all the things fixed by a bug
15:27:40 <dgilmore> sochotni: we ship a ssl cve fix, people see it out, pull updated containers thinking its fixed but hey suprise thats done differently
15:28:22 <dustymabe> dgilmore: i think that's going to be the case anyway, we only build containers every two weeks right?
15:28:23 <bowlofeggs> there's another problem with putting multiple types into a single update: suppose users karma beacuse they tested the rpm, but nobody actually tested the container/module/whatever. the update will go out with those being untested
15:28:43 <dgilmore> dustymabe: no
15:28:48 <bowlofeggs> with separate updates, we have better tracking on what was/wasn't tested
15:28:53 * threebean nods
15:29:03 <sochotni> mixed content type in a single update it just makes everything confusing and unnecessarily harder on our end - making erros easier everywhere
15:29:04 <dgilmore> bowlofeggs: Ideally we automate the testing
15:29:22 <threebean> we do, in general, want to be able to say "we fixed CVE $foo across the board, in all content types", but we don't necessarily have to use a single bodhi update as the mechanism to track that.
15:29:27 <dgilmore> bowlofeggs: and things go out quickly after a comprehensive set of tests on all artifacts
15:29:39 <nirik> some kind of tagging (with cve) might be nice... ie, you look at rpm foo and it fixes cve bar, but that is a link to all the things related to that cve... container, rpm, cloud image, etc
15:30:07 <dgilmore> threebean: sure. linking the updates, or something could be done also
15:30:21 <bowlofeggs> yeah maybe a new "update group"
15:30:25 <sochotni> nirik: yeah, I think I'd rather add CVE info and cross-link updates which fix the same CVE - this would be useful even for pure rpm content (across releases)
15:30:25 <threebean> ooo
15:30:36 <bowlofeggs> some kind of thing that links related updates together
15:30:44 <bowlofeggs> could be used for CVEs, or even just any kind of update
15:30:51 <bowlofeggs> "these updates are related"
15:30:55 * threebean nods
15:31:15 <threebean> take that as an option.  another option could be to relate them in a tree of derivative relationships.
15:31:23 <bowlofeggs> we could also give releng tooling to push update groups OR updates, as they please
15:31:33 <nirik> or 'these things all say they fix bug xyz123'
15:31:36 <bowlofeggs> yeah that would do it too
15:31:38 <threebean> if, say, someday we ship openshift templates that group together multiple containers (no one is asking for this...)
15:32:04 <threebean> ...one rpm cve fix could go into multiple containers, which in turn get bundled into still more deliverables.
15:32:47 <bowlofeggs> i think we could pretty easily make it so you can search bodhi for bug numbers too, to see all updates that claim to related to a particular bug
15:33:10 <bowlofeggs> oh nirk said that ☺
15:34:24 <bowlofeggs> dgilmore: so it sounds like the use case needed is for there to be a mechanism to push out related updates together as the "normal" mode of operation, but also the ability to push out individual artifacts if needed on-demand
15:35:01 <sochotni> would that support be a blocker for F27?
15:35:02 <bowlofeggs> dgilmore: i could envision soemthing like bodhi-push changing to operate on "update groups" or "update trees" (as threebean) suggested, but retaining the ability to push updates too
15:35:15 <sochotni> I'd say no?
15:35:51 <dgilmore> bowlofeggs: well we have limitations in how often we can push content
15:35:55 <bowlofeggs> sochotni: i'm not sure. i do think having modeling flexible to support the requirement would be needed for f27
15:36:33 <bowlofeggs> dgilmore: sure, but if bodhi-push lets releng push either way, then releng can decide what to do on a case-by-case basis
15:36:52 <sochotni> bowlofeggs: it was more wrt does it have to be finished and working ?
15:36:54 <bowlofeggs> i.e., maybe it's default is to push related updates (which i think is what you were saying you would want to do normally)
15:37:17 <bowlofeggs> sochotni: ah, yeah i'm not sure - that's not really for me to decide i dont' think ☺
15:37:39 <bowlofeggs> i mostly want tomake sure that releng is satisfied with what we deliver for them
15:38:28 <sochotni> bowlofeggs: well there's multiple levels of satisfied :-)
15:38:34 <bowlofeggs> hahah yeah
15:38:47 <dgilmore> bowlofeggs: I would like to get the pushing process be less doing and more gathering
15:39:05 <dgilmore> the same as the compose process
15:39:37 <bowlofeggs> dgilmore: i'm not familiar with the compose process - can you explain it a bit for me?
15:39:40 * nirik thinks we could replace push process with cron or something... but thats a topic for another meeting I guess
15:39:47 <bowlofeggs> nirik: +1
15:39:52 <mboddu> nirik: +1
15:40:07 <dgilmore> nirik: -1
15:40:15 * dgilmore does not want it run by cron
15:40:21 <dustymabe> nirik: +1
15:40:23 <dgilmore> but we could do something to automate it
15:40:30 <dustymabe> dgilmore: +1 for automate
15:40:49 <threebean> is there a rolling agenda for these meetings?
15:40:58 <dgilmore> threebean: no idea
15:40:59 <threebean> that topic would be good to cover.  maybe we can schedule it for a future week.
15:41:20 <threebean> another good topic would be "continuous mashing"
15:41:23 <nirik> getting back to bodhi... ;) We wouldn't be doing containers via bodhi right? or would we?
15:41:25 * dgilmore wants to remove cron from all of the releng processes
15:41:42 <dgilmore> nirik: I believe we plan to
15:41:45 <sochotni> nirik: I believe yes - that's would be one of the new content types supported
15:41:48 <nirik> ok.
15:41:48 <bowlofeggs> so i think the current proposal is that updates DO have a single type in them (to meet a requirement that we know what was/wasn't tested), but we would offer some way to group or relate updates so they can be optionally pushed together if desired, or pushed individually when desired
15:42:11 <bowlofeggs> threebean: there is a gobby document i use
15:42:22 <sochotni> and I'd like to make that second part a stretch goal for F27
15:42:27 <nirik> what are all the types then? rpms/groups of rpms, containers, modules, ?
15:42:46 <sochotni> nirik: groups of updates (any type of them)
15:43:03 <sochotni> not sure that would be a type in itself :-)
15:43:05 <threebean> nirik: yeah, and anticipating new types we don't know about yet.  flatpaks?  rocket thingies?
15:43:12 <bowlofeggs> flatpaks are definitely in there too
15:43:23 <bowlofeggs> i've been talking with some peeps about that as well
15:44:33 <mboddu> nirik: but the priority is to support modules "<bowlofeggs> it sounds like the first type we will add will probably be modules"
15:44:54 <nirik> ok
15:45:32 <bowlofeggs> yeah i've heard from a few sources that modules are the highest priority for new types in bodhi
15:45:55 <bowlofeggs> the good thing is that once we've added a second type, it should be easier to add a third
15:45:56 <sochotni> yup, since lacking module support would block F27... the question is how "finished/polished" the support has to be (from my POV)
15:46:45 <dgilmore> we will need to be able to push updated modules in order to support them
15:47:00 <sochotni> right, does the push have to be a "single button" push?
15:47:08 <dgilmore> sochotni: I would love it to be finished, complete and polished
15:47:12 <sochotni> does it have to have UI? CLI? API?
15:47:20 <dgilmore> but realistically it has to be functional
15:47:24 <bowlofeggs> sochotni: i'd think it would be "single button" because that's how bodhi-push is today
15:47:30 <dgilmore> sochotni: all three
15:47:44 <bowlofeggs> id ont' thinkt releng would want the push process to be more complicated than it is today
15:47:51 <bowlofeggs> (just a guess ☺)
15:48:12 <sochotni> well then they likely use a single workflow
15:48:28 <sochotni> so probably not all three methods are required
15:48:33 <sochotni> maybe CLI is optional
15:48:41 <sochotni> that's what I am trying to get to
15:48:52 <dgilmore> sochotni: cli is not optional
15:49:01 <sochotni> so then UI is optional?
15:49:05 <sochotni> in the web I mean
15:49:11 <dgilmore> sochotni: none of its optional
15:49:15 <bowlofeggs> i think a lot of testers might use the easy-karma tool which would use the API. also based on bug reports, the CLI tool is a very popular way to interface with bodhi
15:49:21 <dgilmore> we need a way to visualise
15:49:23 <bowlofeggs> the CLI also uses the API of course
15:49:49 <dgilmore> we need a way to submit and manage the updates via the cli
15:49:57 <dgilmore> both of which need an api
15:50:00 <bowlofeggs> the UI also uses the API to some extent, actually
15:50:36 <dgilmore> I know I typically submit updates using fedpkg update
15:50:44 <dgilmore> but then use the web to push stable
15:51:14 <sochotni> the point is - we would *survive* with subset of all of those features for a few months for modules
15:51:40 <dgilmore> not in how bodhi works
15:51:45 <bowlofeggs> ok, here's another question i have: what should API compatibility requirements be? i'm thinking about introducing a new /v3/ endpoint in parallel with the current API, so we can add the new functionality while maintaining the current API (deprecated) for a while (6 months? a year?)
15:51:48 <dgilmore> with changes sure
15:51:59 <dgilmore> and the CLI to me is more important that web ui
15:52:05 <bowlofeggs> this way we can do backwards incompat stuff in /v3 while not disturbing things that use the old API
15:52:45 <dgilmore> bowlofeggs: the current cli on el7 is using an old api right?
15:53:01 <dgilmore> and older fedora's?
15:53:26 <sochotni> bowlofeggs: I guess as long as you update the CLI to work with latest API you could get away with 6 months (IMO)?
15:53:27 <bowlofeggs> dgilmore: yes, but el7 is also the same version as rawhide right now (i got an EPEL exception to do that)
15:53:34 <bowlofeggs> and older fedoras actually barely work witht he current api sadly
15:54:16 <bowlofeggs> sochotni: yeah, or maybe a year. i guess my overall suggestion is taht we shouldn't change the existing API endpoints for this work, but should introduce entirely new ones
15:54:39 <bowlofeggs> because it'll be a headache for compatibility if we change how, say, /updates/ works
15:54:42 <sochotni> bowlofeggs: unless we come up with a way to have our cake and it it too (i.e. preserve compat)
15:54:51 <bowlofeggs> but if we introduce /v3/updates/, we can do whatever we want there
15:54:55 <sochotni> true
15:55:02 <sochotni> it's probably going to be less of a headache
15:55:05 <bowlofeggs> sochotni: yeah if we can preserve compat that could work
15:55:07 <sochotni> and easier to develop
15:55:28 <bowlofeggs> we could have the client declare an API version it wants with a header as another way to do this, without /v3/
15:55:30 <sochotni> I'd suggest considering preserving compat, but not spending a lot of time on it
15:55:50 <sochotni> bowlofeggs: we could also keep track how many clients are hitting the old APIs
15:56:01 <bowlofeggs> yeah
15:56:13 <bowlofeggs> so anyways, that's something to think about too
15:56:17 <bowlofeggs> we only have 4 minutes left
15:56:37 <bowlofeggs> we normally have a look at open bugs in this meeting, but i don't think we have time today
15:57:01 <bowlofeggs> in lieu of that, if you think i am misprioritizing any bugs you care about, please feel free to let me know ☺
15:57:17 <bowlofeggs> Bodhi's high priority issue list https://github.com/fedora-infra/bodhi/issues?q=is%3Aopen+is%3Aissue+label%3A%22High+priority%22
15:57:25 <bowlofeggs> i'm going to open floor
15:57:30 <bowlofeggs> #topic Open floor
15:57:39 <bowlofeggs> it sounds like we have more to discuss on this topic
15:58:05 <bowlofeggs> so i propose to schedule another discussion about this outside of the stakeholders' meeting
15:58:10 <bowlofeggs> perhaps in a week or so?
15:58:17 <sochotni> yeah I would like to have a full list of things that we have to get working for F27 for module support
15:58:20 <nirik> yeah, and/or perhaps we could setup some tracking bugs...
15:58:40 <sochotni> and not have everything be a hard requirement
15:59:00 <sochotni> because I know it's not...
15:59:07 <bowlofeggs> nirik: i did make a milestone to track the effort: https://github.com/fedora-infra/bodhi/milestone/4
15:59:15 <nirik> sure, there's gonna be some hard ones and some nice to haves for sure
15:59:45 <sochotni> bowlofeggs: does web UI use the same API as CLI?
16:00:01 <bowlofeggs> sochotni: it does use it a little bit, but not entirely
16:00:07 <sochotni> ok, just wondering
16:00:09 <bowlofeggs> so, sort of? ☺
16:00:28 <sochotni> ok, gotta run, ty for driving the discussion
16:00:31 <bowlofeggs> #action bowlofeggs will schedule a follow-up requirements meeting
16:00:35 <bowlofeggs> #endmeeting