20:05:49 <jds2001> #startmeeting server wg
20:05:49 <zodbot> Meeting started Tue Jun 27 20:05:49 2017 UTC.  The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:05:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:05:49 <zodbot> The meeting name has been set to 'server_wg'
20:05:52 <jds2001> #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf
20:05:52 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
20:06:02 <adamw> .hello adamwill
20:06:03 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
20:06:05 <jds2001> #topic roll call
20:06:11 <jds2001> heya adamw
20:06:22 <dperpeet> .hello dperpeet
20:06:22 * jds2001 didnt see anyone else volunteer to run this
20:06:22 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
20:06:25 <mjwolf> .hello mjwolf
20:06:28 <mhayden> .hello mhayden
20:06:29 <zodbot> mjwolf: mjwolf 'Michael Wolf' <mjwolf@us.ibm.com>
20:06:32 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
20:07:04 <sgallagh> I'm not really here, but i may be able to answer the occasional question if mentioned
20:08:07 <jds2001> im only aware of one topic for this meeting, which is the modularity change for f27
20:08:27 <jds2001> #topic Modularity in F27 Server
20:08:48 <jds2001> so as i exepcted, there's been some feedback on devel@
20:09:10 <jds2001> seems most of it was that folks wanted to be able to install non-modularized things.
20:10:43 * nirik is sort of here.
20:11:18 <langdon> .hello langdon
20:11:19 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
20:11:21 * jds2001 just went and checked his mail, I havent followed the thread for a few days because of things.
20:11:26 <adamw> jds2001: is that not something we were expecting?
20:11:58 <jds2001> adamw: there was loose consensus in here last week that we consider that as a 'failure mode'
20:12:39 <langdon> well .. part of it is conflating "install a single rpm from  a module" vs "install an rpm from some random place"
20:12:43 <jds2001> adamw: if you wanted something 'more traditional' the Everything netinstall is there for you.
20:12:46 <langdon> the first is fine .. the second not so cool
20:13:23 <jds2001> langdon: thanks for making that distinction, it's an important one that I missed.
20:14:41 <langdon> so .. if i have httpd-module, i may not get mod_ssl as an rpm in the default install .. i can still install it.. i will just get the right one based on  the httpd-module-stream .. however, if i install "gnome" which isn't a module .. it isn't gonna be pretty becuase it would be like installing f26-gnome on f22-fedora
20:14:41 <jds2001> adamw: i noted you had schedule concerns as well.
20:14:49 <adamw> well, just the question, really
20:16:14 <langdon> adamw, so .. i share your concern.. but, yes, the goal is to deliver everything for server by  the current schedule.. if we don't have enough time, i propose we cut things.. but, thats a decision for later
20:16:34 <langdon> later == cut vs change schedule
20:16:49 <langdon> and i think server-wg also agreed to that plan at the last meeting
20:16:58 <adamw> i'm...deeply sceptical that we're going to be able to get all those interlocking bits done in time. with my Debbie Downer QA Person hat on.
20:17:11 <adamw> sorry if i'm repeating stuff, i haven't been strictly keeping up lately :(
20:17:20 <adamw> (just moved house)
20:17:26 <langdon> no worries..
20:17:32 <smooge> I am also mainly because I feel like we have many idea(s) of what modularity means
20:17:46 <langdon> adamw, and i am sure that moving went all to schedule too :)
20:18:10 * nirik thinks we are only going to find and fix some of the sharp edges by getting cut. ;)
20:18:35 <jds2001> nirik++
20:18:35 <zodbot> jds2001: Karma for kevin changed to 46 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:18:58 <adamw> smooge: for me it's mainly the fact that changes seem to be needed in the compose process, bodhi, koji etc.
20:19:09 <adamw> in my experience getting all those changes lined up always takes longer than people expect
20:19:25 <smooge> agreed
20:19:26 <adamw> nirik: yeah, i'm just wondering if we should be budgeting in more time to apply the band-aids ;)
20:19:35 <jds2001> so i guess the question is where are we on each of those?
20:20:20 * adamw notes his job in this group could probably be replaced by a robot programmed to say "that's going to be broken at first and take longer than you think to fix" at random intervals
20:21:43 <nirik> well, there's already modular pungi composes... (not sure how usable they are tho)
20:22:00 <nirik> bodhi is mostly set, but needs pungi to do the composing for updates
20:22:14 <nirik> koji is pretty set, modules are building, etc
20:22:23 <adamw> hmm, okay, that sounds quite promising
20:23:00 <nirik> not to say there isn't a ton of work still to do.
20:23:53 <langdon> adamw, yeah.. most of that work is falling on ralph and team.. they have a schedule that they are mostly on track for.. you know, except, bugs
20:24:10 <langdon> im worried more about putting the module wrappers around things
20:24:34 <langdon> and that last bits/details on composing which is harder than expected..
20:24:58 <langdon> but your major concerns are exactly why we did boltron.. to try to get 90% of the way there before it mattered
20:25:16 <langdon> but boltron isn't out yet (~2 weeks yet) .. so ..
20:25:21 <langdon> we still have some kinks
20:25:25 <smooge> my main worry at the moment is how this will be laid out on the mirrors?
20:25:50 <jds2001> smooge: you're concerned about the space?
20:25:57 <langdon> smooge, threebean's plan was flattened in to directories.. what we have been calling "virtual repos" ..
20:25:59 <smooge> both space and layout
20:26:21 <langdon> so . instead of a "repo per module" .. it is ~1 repo and the modules are identified by the metadata and dnf
20:26:38 <smooge> and how updates are put out for mirrors to get
20:26:44 <langdon> so that the mirrors don't really  see anything different
20:27:22 <langdon> the update would be to the "server repo" as it is today .. and would mirror the same way .. but that part is still a bit in flux .. updates were for after boltron
20:27:32 <smooge> as I would like to make sure mirrors are aware of any changes before hand as many of them have special scripts to manager their local layout
20:28:02 <langdon> smooge, i think we share your concern.. hence this design .. but.. ralph could answer better than i can
20:28:19 <langdon> or nirik ... i am just not sure how close you are to this bit nirik
20:28:53 <nirik> not sure, but I think it's just more repos of rpms... so we should be able to handle that
20:32:32 <langdon> glad  i could allay all your concerns.. i can take the rest of the day off now, right?!?! ;)
20:33:00 <jds2001> langdon: go home and have a beer :D
20:33:05 <langdon> jds2001, lol
20:33:31 * langdon has to transport kid to softball game..
20:33:37 <langdon> in a while
20:33:43 <adamw> langdon: that's what your back yard catapult is for
20:33:44 <jds2001> ok, maybe the beer isnt such a hot idea :D
20:34:21 <langdon> adamw, still in testing .. qa keeps saying "we are too busy testing the last version to get to it"
20:34:40 <langdon> </snark>
20:34:43 <adamw> =)
20:35:01 <jds2001> speaking of which, we need acceptance criteria for this stuff :)
20:35:14 * adamw suddenly discovers he has something terribly important to do somewhere else
20:35:50 <jds2001> is someone working on that, or is that an open item?
20:36:12 <langdon> jds2001, i should probably have a better idea what you mean.. but .. i got nothing..
20:37:00 <jds2001> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
20:37:01 <langdon> my fedora slang is failing me
20:37:06 <jds2001> and similar for beta and final :)
20:37:10 <langdon> that is what i thought.. ok
20:37:27 <adamw> well
20:37:48 <adamw> the release criteria are generally speaking functional, they talk about how the final product should behave
20:38:08 <jds2001> adamw: that will necessarily change, no?
20:38:29 <adamw> we're probably going to need to change / add to them *somewhat*, but a lot of what's there will probably still be appropriate, and the release criteria may not be the appropriate mechanism to assess / define some of the work that's involved
20:38:35 <adamw> sure, to some extent
20:38:37 <jds2001> this product is not only plumbed differently, the user visible behavior is different.
20:38:52 <adamw> but i don't think the release criteria are necessarily the way to cover, for instance, 'are the bodhi changes in shape yet'
20:39:09 <jds2001> adamw: agreed
20:39:12 <adamw> so aside from those, i notice that most of the Change proposals so far have no "How To Test" section, for instance
20:40:11 <langdon> yeah.. i ran into that and i think we need to work through it.. in a sense it is the same question as jds2001 has..
20:40:17 <adamw> i'm not sure how well this is formulated, but i kinda have a high-level expectation that Change proposals should at least attempt to cover: i) how exactly do we decide that this change is 'done' to a sufficient degree, ii) what do we do if it all goes wrong (which is the 'Contingency Plan' section, which similarly appears to be missing)
20:40:47 <langdon> adamw, i had a contingency plan.. and mine is the only one that actually hits anything
20:40:50 <langdon> didn't i?
20:41:10 <langdon> if host & plat don't ship, it just drops on the floor
20:41:27 <langdon> and my contingency plan kicks in
20:41:32 <dperpeet> I'm not sure it's efficient to spend too much time on contingency plans
20:41:38 <langdon> because my deps aren't met
20:41:45 <adamw> langdon: sorry, which change are you referring to here?
20:42:18 <adamw> i don't see either 'how to test' or 'contingency plan' for: 'Modular Release', 'Host and Platform', or 'Modular Server' (unless i'm missing them)
20:42:22 <langdon> so .. the modular server one (the one i wrote) ... is the only one that materially impacts the fedora release .. as in it is a modular server or it isn't
20:42:25 <adamw> i hadn't got any further in the list yet
20:42:39 <langdon> arggh .. did i drop it?
20:42:43 <langdon> i stink at wiki
20:42:51 <adamw> well, i'm reading the email, not the wiki
20:42:53 <langdon> in short.. it is "deliver without modules"
20:42:59 <adamw> so i guess either that, or jan missed it out of the email
20:43:20 <langdon> and that should be triggered with any of the others failing
20:43:21 <adamw> anyhow, i agree with dperpeet that the concepts may not necessarily be *entirely* applicable to something as big as this
20:43:45 <adamw> but the higher-level idea that 'we need a way to decide how "done" it is' and 'we need a plan for what happens if it ain't done' are still i think valid
20:43:47 <dperpeet> adamw, but a measure of success is essential
20:43:51 <langdon> there is nothing in the changes that gates a traditional release .. we just are electing to do a modular release
20:44:13 <langdon> adamw, +1 .. we need AC or release crit .. or test
20:44:27 <adamw> langdon: well, the Modular Server change states:
20:44:28 <adamw> "This change replaces the Fedora 26 Server release-blocking
20:44:28 <adamw> deliverables with exactly the same things (DVDs and netinst images)
20:44:28 <adamw> but delivered via Modularity instead of the traditional process."
20:44:34 <langdon> i just couldn't figure out how to say "well.. all of fedora server needs to "work" in that format
20:44:49 <langdon> "
20:44:57 <langdon> format == change proposal
20:45:07 <adamw> which sounds like we're not hedging our bets and *also* doing a traditional server release, it sounds like basically "for F27 Server is gonna be modular, end of story"
20:45:14 <adamw> did I misread that?
20:45:26 <langdon> adamw, that is correct.. we were talking about the contingency plan ..
20:45:29 <jds2001> adamw: thats the proposal.
20:45:29 <adamw> ah, okay, i see
20:45:42 <adamw> sorry, wasn't quite sure what you meant by "there is nothing in the changes that gates a traditional release"
20:45:48 <langdon> so .. change = everything modular; fail = nothing is modular
20:45:56 <smooge> ok I need to head out and pick up kid
20:46:00 <adamw> sorry smooge
20:46:06 <adamw> that seems plausible, sure.
20:46:11 <langdon> smooge, one at a time.. don't hurt your back :)
20:46:28 <smooge> he's bigger than me.. so maybe I should have him pick me up
20:46:40 <langdon> but .. we don't have a great doc for "what is fail?"
20:46:44 <langdon> smooge, lol
20:47:42 <adamw> yeah, obviously the 'success definition' and 'contingency plan' bits kinda go together
20:47:45 <jds2001> langdon: i dont think we're going to accomplish everything that we want by f27, its ambitious. But we need to know what's "good enough"
20:48:00 <jds2001> and what causes us to hit the Big Red Button(TM)
20:48:10 <langdon> jds2001, right .. which "test" in the change proposal didn't really seem to cover it
20:48:48 <langdon> and /me thinks change proposals should be the beginning of the discussion more than the end of it .. but that's just me..
20:49:00 <adamw> oh for sure
20:49:08 <adamw> i'm just pointing it out as something we need to figure out
20:49:12 <langdon> so .. i think f-qa, modularity, and server need to get together and figure out how to document this..
20:49:19 <adamw> that's one of the reasons we do change proposals, for sure :)
20:49:21 <langdon> adamw, ohh yeah.. no offense taken
20:49:37 <adamw> i think we may possibly also want to involve some subset of fesco, if we can do it without being too unwieldy
20:49:51 <langdon> i think the hardest thing will be how do i say "this is fail" .. i am pretty sure most of us "know" what we mean .. just not how to say it
20:50:00 <adamw> as i suspect scheduling concerns may come up
20:50:01 <langdon> i think the release-crit might be a good model
20:50:22 <adamw> there are rules for the Change process already, but we've already kinda established that this is a bit of a 'special' situation
20:50:36 <langdon> adamw, yeah.. hence my overview email :)
20:50:53 <adamw> the rules in the Change process are kinda simple and implicitly assume that Changes are easy to 'drop out': the rule is if the Change isn't 'done' enough at various points, it gets dropped
20:50:59 <langdon> "so there are these 52 moving parts that don't seem linked in anyway"...
20:51:12 <adamw> that seems like it might be too inflexible here, so i'm suggesting maybe we might want to thing about potential situations ahead of time
20:51:33 <adamw> like 'we get to Alpha freeze and we're not *quite* ready to deliver a modular Server Alpha but maybe we'd be able to do it in a week'
20:51:35 <adamw> what do we do then?
20:52:23 <langdon> right .. exactly .. but more importantly (for now at least) "what is the modular server alpha"? and how flexible is that definition?
20:52:51 <dperpeet> wouldn't a more constructive way be to define a minimal set of features?
20:52:52 <langdon> let me put it a little differently .. we need host, platform, shared-userspace but then everything else is kinda optional ..
20:53:01 <langdon> but it wouldn;t be usable
20:53:27 <langdon> kinda like fedora could ship with a kernel and glibc .. and, technically, it would be a release .. but not very usable
20:53:33 <adamw> i guess we could start out with just the folks suggested and broaden out as necessary
20:54:13 <adamw> langdon: well, it seems a bit more complex than that to me, there are various 'dimensions' to it...what if we can ship all the initial release bits but there's some kind of significant issue with the update process? stuff like that.
20:54:22 * adamw likes to complicate things!
20:54:51 <langdon> adamw, ahh yes.. but, that is all in the infra.. we have those triggers already .. on the f-2 proposals (IIRC)
20:54:57 <adamw> fair enough
20:55:40 <langdon> this is more about "what is a legit fedora server" .. if that is built as modules and works .. \o/
20:56:10 <langdon> adamw, there are no release-crit for each edition, are there?
20:56:25 <adamw> there are actually some server-specific criteria, yeah
20:56:42 <langdon> oh i see them
20:56:46 <adamw> https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#Server_Flavor_requirements
20:57:01 <adamw> we may need to rejig the Role stuff for the new gen role implementation, but that's a separate topic i guess
20:57:07 <langdon> so .. maybe this is the answer? maybe re-work this to be applicable for a modular-edition?
20:57:22 <langdon> this == the release criteria
20:57:29 <adamw> we can certainly cover some things with release criteria changes for sure
20:57:30 <langdon> i am not even sure it is that different
20:57:46 <adamw> but i suspect we may also want to come up with sorta 'mini criteria' for each change, to aid assessment of the changes' status
20:58:23 <adamw> there's a sort of...thing...with the release criteria which i have in my head but have trouble formulating
20:58:48 <langdon> adamw, yeah.. i think this only applies to "mine" .. the "modular server" .. the pieces that modular-server needs should or do i have their own "fail/pass" rules.. and are less complex to test, i believe
20:58:52 <adamw> but my best attempt is...the release criteria *kind of* assume some sort of underlying stability in the really fundamental bits of the distro
20:59:33 <adamw> otherwise there's a danger of trying to encode *everything* about building an OS into the release criteria and it'd just get (even more) unwieldy
20:59:42 <langdon> adamw, well.. i think you mean.. you can fail well before you get to the first "test" .. which i agree with.. but it doesn't change the test
20:59:45 <adamw> might be better to say "the project" than "the distro" there
21:00:02 <adamw> yeah, but even beyond that, there are things that practically speaking we need to be working that we don't write into the criteria
21:00:36 <adamw> as i said, i have trouble expressing what i mean here, but basically it comes down to: when we start making radical changes to really critical things, we may need mechanisms beyond the release criteria until they settle down
21:00:42 <adamw> mechanisms and processes
21:00:59 <adamw> which can sometimes boil down to 'let's all sit down and have a meeting and agree whether this stuff is even vaguely viable' (like we did with newUI, for instance)
21:01:11 <langdon> like .. "installer must run" requires the installer to have a working knowledge of modules before it can even sorta be run.. but you don't need to add that to the test.. the installer still doesn't run :)
21:01:27 <adamw> anyhoo, i sense this is kinda getting a bit bogged down
21:01:58 <adamw> i think we agreed at least we should look into somehow defining ultimate 'success' / 'MVP' state for the changes, so that's a concrete thing to work on
21:02:00 <langdon> adamw, ill have adamS setup a meeting to plan a meeting to talk about a larger meeting where we can hash this out
21:02:03 <adamw> and revising the criteria, of course
21:02:36 * langdon kids .. he will jst schedule a meeting
21:03:34 * langdon points at the clock
21:03:57 <jds2001> ahh, the pitfalls of having a meeting that runs against beer o'clock
21:04:07 <jds2001> sorry adamw, not quite yet for you :D
21:04:13 <nirik> it's always beer o clock. ;)
21:04:17 <nirik> ...somewhere.
21:05:12 <jds2001> langdon: so i guess the action is to schedule another meeting to talk about success criteria?
21:05:57 <langdon> jds2001, yeah.. i think so
21:06:22 <jds2001> #action langdon to schedule another meeting to talk about success criteria for modular-server
21:06:43 <jds2001> anything else?
21:07:09 <langdon> ok... gotta run.. kid -> softball .. but znc will let me know if anything else happens
21:07:32 <jds2001> i think ending the meeting is the next thing that happens :D
21:07:39 <jds2001> unless anyone has objections to that?
21:08:10 <adamw> I OBJ- no, wait, i don't.
21:08:59 <jds2001> #endmeeting