17:00:10 #startmeeting Server Working Group Weekly Meeting (2017-06-21) 17:00:10 Meeting started Wed Jun 21 17:00:10 2017 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:10 The meeting name has been set to 'server_working_group_weekly_meeting_(2017-06-21)' 17:00:10 #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf 17:00:10 #topic roll call 17:00:10 .hello sgallagh 17:00:10 Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez 17:00:35 .hello asamalik 17:00:39 * asamalik waves 17:01:58 Greetings 17:02:09 .hello langdon 17:02:18 (Apologies if I'm a little slow today. I'm concurrently preparing lunch for my daughter) 17:02:29 sgallagh, i would like to propose an agenda topic.. which i meant to do on email.. but..yeah.. 17:02:53 morning 17:03:16 langdon: OK, once we have something approaching quorum 17:03:23 sgallagh, sure 17:04:23 zodbot seems to be lagging a bit today 17:05:00 he just got restarted a bit ago... likely rejoining all his channels. 17:05:04 A lot of people responded to the WhenIsGood... I kind of expected them to show 17:05:46 .hello jstanley 17:05:54 sorry, was in wrong channel :) 17:06:48 Welcome 17:07:39 #topic Agenda 17:07:57 Today's agenda: Discuss proposal to modularize Fedora Server for Fedora 27 17:08:04 langdon: you had something additional? 17:08:12 sgallagh, nope..that was it :) 17:08:23 * langdon apparently endlessly behind on his email 17:08:42 #topic Fedora Server 27 Modularization 17:09:14 So asamalik sent out an email with a proposal for Fedora 27 17:09:46 it's bold. I like bold. :) 17:09:54 and various are working up change proposals to make it happen 17:10:02 but .. we need server wg to "agree" 17:10:17 I like it. :) I have a bunch of dumb questions about things, but I think they likely would be answered by playing with a prototype some to see how it all works. 17:10:18 langdon, asamalik: Go ahead and make your pitch 17:10:24 * sgallagh needs to grab something off the grill 17:10:28 * langdon is also writing an overview which includes all the relevant work.. but it isn't done yet 17:10:42 prototype exists (while we wait for f26) 17:10:45 * langdon digs 17:11:00 https://hub.docker.com/r/modularitycontainers/boltron-preview/ 17:11:06 #link https://hub.docker.com/r/modularitycontainers/boltron-preview/ 17:11:12 * langdon not sure if he has privs 17:11:22 cool. 17:11:34 so.. it is an externally built container.. but the contents all come from koji (mostly) 17:11:35 the Modularity WG is curently finishing a prototype... yeah :) 17:11:41 so can I mix packages and modules? ie, install modular, but then install some random packages? 17:11:45 #chair asamalik langdon 17:11:45 Current chairs: adamw asamalik dperpeet jds2001 langdon mhayden mjwolf nirik sgallagh smooge vvaldez 17:11:54 nirik, mostly? still showing some bugs 17:12:10 sure, I meant more the intent... bugs always happen. ;) 17:12:11 working up a "test script" cause there is like no help.. 17:12:25 asamalik,do we have that published yet? 17:12:54 but .. dnf install httpd will install httpd from the module and set it to follow the default stream 17:13:07 we have a documentation page that also documents the Boltron release: https://docs.pagure.org/modularity/ 17:13:49 sgallagh: [hellomynameis sgallagh] 17:13:52 asamalik: [hellomynameis asamalik] 17:13:52 it's basically the only link you know for modularity.. langdon should we #link that one instead? 17:13:54 langdon: [hellomynameis langdon] 17:13:55 #link https://docs.pagure.org/modularity/ modularity docs 17:14:19 #link https://docs.pagure.org/modularity/prototype/boltron.html deep link to boltron preview 17:14:24 i hit them all :) 17:14:31 cool :) 17:15:09 so.. basically ... we want to iron out the kinks over f26 .. but the change proposals for f27 are due before f26 ships (july 4ht iirc) 17:15:15 sure. 17:15:47 langdon: One question that came up in a different discussion recently: Are we committed to feature-parity in F27? 17:15:54 so yeah... we are finishing F26 Boltron Server which is a prototype that includes a basic set of modules, DNF that can work with modules, it has been built by the production Fedora infrastructure which now supports building modules 17:16:10 jds2001: [hellomynameis jstanley] 17:16:11 and this{1] is the draft change proposal i have been working on 17:16:12 In particular, I haven't seen anyone working on a FreeIPA module, and that's a primary feature of current Fedora Server 17:16:22 #link https://fedoraproject.org/wiki/Changes/Modular_Server draft change proposal for modular server 17:16:45 sgallagh, the content we have in Boltron was really to test everything 17:17:00 we won't be re-using almost any of that in F27 17:17:01 sgallagh, i would say "no" with modules.. but "yes" with "all the rpms would still be available but not all of them will act like modules" 17:17:41 one of the changes between F26 Boltron and the F27 Server we are proposing is the base layer 17:17:46 but.. we may.. like i would love too.. but it means we need LOTS of pkg mantainers to build modules this summer 17:17:58 F26 has Base Runtime, F27 will have Platform <- they have a bit different scope 17:18:26 asamalik: is the difference documented somewhere? They sound similar :) 17:18:37 jds2001, it is.. i think.. 17:18:40 * langdon digs 17:18:42 so we will choose the basic set of modules to match Server's needs 17:18:50 jds2001, yes :) 17:18:55 * asamalik is digging 17:19:01 but.. basically.. platform is ~OS where as brt is ~kernel+ 17:19:25 https://fedoraproject.org/wiki/Changes/Host_and_Platform 17:19:55 #link https://github.com/fedora-modularity/hp is the details on host&platform 17:20:12 #link https://fedoraproject.org/wiki/Changes/Host_and_Platform is the change proposal for host & platform 17:20:30 * langdon hopes the formatting he is using for #link is right.. can never remember 17:20:42 the change proposal also briefly describes the difference between Base Runtime and Platform 17:21:40 how I imagine we would start with developing: 17:22:05 the Platform team is defining the Host and Platform - the base of a modular distribution 17:22:13 lets not get to into "the list of modules" 17:22:27 that doesn't need to be in the change proposal(s) 17:22:46 we (the Modularity WG + Server WG) then pick features we need to include 17:22:51 module updates will use bodhi right? is a module update the entire changed thing? or just the updated rpms or To be determined? 17:22:57 correct 17:23:12 so .. logically.. it should be the "whole thing" .. practically .. 17:23:18 it should be just the changes.. 17:23:37 Is there a committed resource to make Bodhi changes? 17:23:38 then we display the whole dependency graph of Platform + features/packages we picked, and design a proper module set 17:23:38 so.. current impl is "just the changes" 17:23:45 sgallagh: yeah, thats in the pipeline 17:23:50 sgallagh, ralph et al is working it now 17:24:46 sgallagh, I think that Bodhi is almost done.. 17:24:49 there is not a change proposal for bodhi per se.. but it is on the infra pipeline (as nirik said) 17:24:50 ok 17:25:11 i believe it was infra & fesco tickets.. 17:25:39 from devel list: "bodhi-2.8.0b1 is deployed to stg[0]. This is probably the most 17:25:39 substantial Bodhi release I've made (except for the very first one), so 17:25:39 I'm a bit nervous since it has a huge diff from 2.7.0, but it's got 17:25:39 some cool stuff. It has pingou's CI patch, a whole lot of modularity 17:25:39 work (it can do everything except mash modules!), and a new home page 17:25:40 layout by Ryan Lerch." 17:25:48 right 17:25:51 langdon: So what if anything are you asking for from the Server SIG? Permission? Assistance? 17:26:10 Approval to make the Modular-build artifacts the default deliverables? 17:26:25 all three ;) .. 17:26:33 but.. the easy one is the last one 17:26:59 can server-wg be a "member" of the change proposal .. and agree to a modular server as the default 17:27:13 sgallagh, so basically we won't be able to modularize all the RPMs in Fedora... 17:27:47 sgallagh, we need to modularize the things Server promises to deliver 17:27:50 * jds2001 is confused as to the delivery mechanism for modules 17:28:12 asamalik: So you're asking for packaging help? 17:28:53 jds2001: dnf... or anaconda via dnf... right? 17:28:55 * jds2001 proably needs to read lots of docs, but how technically is a module delivered? 17:29:10 jds2001, "just rpms" .. sorta... as in, most of the packages go over the wire just like they do now..the change(s) is to "why" or "when" .. so dnf is smart enough, based on modulemd and .module files to know if the new rpm is approporiate for the "version" installed 17:29:14 right, as an rpm? some other format? 17:29:39 we also plan to deliver some system-containers versions of stuff.. but not as a "default" 17:29:53 jds2001, did my answer help? lots of typing was needed :) 17:30:20 ok, but if I have thing A that requires httpd 2.4, adn thing B that requires httpd 2.2 (for example) I should be able to have both.....I thought that was the promise of modularity, no? 17:30:29 sgallagh, basically I'm asking for permission to make a change that might be a bit disruptive 17:30:44 jds2001, not at once.. both available.. you can do both at once with containers.. 17:30:47 jds2001: You can have both in the rois 17:30:48 repos 17:31:02 There's no guarantee that they are parallel-installable though 17:31:06 sgallagh, as mattdm pointed out in the email thread... a lot of people use Fedora _as_ a server, not neccessarily Fedora Server Edition 17:31:15 yes 17:31:30 we would like to see both at once some day.. but we need more time.. and..containers solve it pretty well already .. so .. it is arguably if we should invest in another solution 17:31:54 sure, makes sense. 17:31:59 so we have an opportunity to release a Server that might not include all the Fedora content... which would be fine for some people (and will bring a lot of benefits thanks to modularity) 17:32:09 asamalik, that isn't true 17:32:22 but people will still be able to use Fedora Everything as a server if that doesn't work for them 17:32:31 the modular server would have EVERY rpm available to every edition..they just may not all be marked up as modules 17:33:09 so .. emacs.rpm will still be there.. it just might not have a modulemd .. so you can't have multiple versions available 17:34:03 * langdon notes there may be some disagreement on this point .. and apparently missed that part of adam's thread .. 17:34:26 but i certainly don't see why any rpm that is not in a module couldn't still be available 17:34:42 in the worst case as an "everything else" module 17:35:32 yeah, I would definitely think it would make sense to allow/provide those... 17:35:48 s/make snese/be required :) 17:36:53 ok .. well... apparently we need an offline discussion to ensure we are on the same page.. let's table that bit til $future-meeting 17:37:03 jds2001: Well, there are two approaches that could be taken here 17:37:38 1) We make a new thing that can consume all the old stuff exactly the same way we always have or 2) We can build an entirely new approach from the ground up and bring stuff in as it becomes modularized 17:38:03 The second option would be wiping the table clean of a lot of historical tech debt, but it would be much more disruptive 17:38:04 sgallagh, right 17:38:23 exactly 17:38:37 sgallagh, well.. only for people who "only know how to download fedora server edition" .. which i think is no one 17:38:38 :) 17:38:40 and we would still have Fedora Everything for people who won't be able to use the new approach 17:39:07 the upside to that approach is also massive cleanup .. 17:40:26 * jds2001 can see the advantages of both approaches. 17:40:32 Yes 17:40:54 how about this.. 17:40:57 modularity also brings more flexibility for packagers who want to package new stuff 17:41:09 As long as Fedora will still have the Everything netinstall, I think we *can* be open to taking the Big Risk 17:41:24 nevermind.. my idea won't work as i think about it 17:41:25 * jds2001 agrees. 17:41:33 langdon: Story of my life :) 17:41:39 no risk == no innovation 17:42:10 for example... you are adding a new package with some deps.. if these deps are not in Fedora, you can add them, but when people start to use them, you can't just change the version when you need it because that would break other stuff... 17:42:27 Maybe we try for a purely-modular approach and hold "The Everything Module" in our back pocket? 17:42:46 of the deps can be there... but in different version than you need... Modularity with arbitrary branching solves that :) 17:42:58 * sgallagh nods 17:43:10 sgallagh, right.. thats kinda what i was thinking .. the minor problem is .. we need to add the "everything else module" as a dep for all moduels..but we could do that with a script if need be 17:43:11 Still doesn't solve the parallel-installability problem though 17:43:25 langdon: Sorry, what do you mean? 17:43:34 I can see it being needed as a builddep 17:43:36 But runtime? 17:44:00 sgallagh, so you can package in a way it won't conflict... and say it's packaged like this, because you can create a branch.. 17:44:05 or use containers 17:44:07 sgallagh: why a build dep? If we force all deps into modularity? 17:44:16 you need to lock all modules to the versions of things in e-e-m .. it effectively becomes a 2nd shared userspace module.. else.. conflicts can happen 17:44:30 jds2001: "it's complicated". 17:44:46 Short version: it takes about 1000 SRPMs to make the kernel self-hosting... 17:46:02 that doesnt make a ton of sense, but I'll trust you on that one since you're much closer than me :) 17:46:10 langdon: e-e-m? 17:46:21 everything else module .. im not a fan of typing ;) 17:46:25 ah 17:46:34 You picked the wrong career 17:46:38 point 17:46:48 * langdon should probably have learned to type at some point 17:46:54 *touch type 17:47:08 but could we agree without having the everything-else-module? and maybe leave it as a stretch goal? 17:47:37 * jds2001 wouldnt want it in the runtime with this discussion. 17:47:55 i wouldsay the reverse ..the e-e-m is a failure mode.. but it would work 17:48:03 langdon: +1 17:49:03 so .. "only modules in server" & "we will get as much content in as possible for GA" .. and.. don't forget.. the whole point of this project is to make it easy to add things later.. 17:49:19 we could drop 50 more modules mid november 17:49:44 Yeah, I'm leaning the same way. 17:49:55 drop == "add in" (drop in the sense of "release") .. words are hard 17:50:19 Given the tepid adoption of Fedora Server, I don't think making this big change will be a significant problem for The Fedora Project 17:50:59 sgallagh: and there's always the fallback of Everything. 17:51:09 basically..as we get packagers in to the idea/benfits of modules .. they can start releasing them whenever they want .. without much disruption .. we should probably have some policy on the often-ness though 17:51:10 Is anyone strongly opposed to going big? 17:51:44 go big or go home :) 17:51:51 jds2001: My thoughts exactly 17:51:57 that's the spirit! :) 17:52:24 nirik: you in? 17:52:52 sure, but what do you mean by 'only modules in server' ? 17:53:17 no arbitrary rpms.. only rpms that are a part of a module will be available in the "server repo" 17:53:23 Yes, that 17:53:54 user fall back is to use the fedora-everything install to approximate fedora-server-of-the-past 17:54:03 * langdon likes making up phrases 17:54:13 ah, humf. I was hoping to have rpms available... 17:54:28 but yeah, I guess people could ignore the modular and just netinstall. 17:54:32 nirik, so.. they will be.. just a part of a module.. so...let me give an example 17:54:34 ... 17:55:19 sorry if I am slow today. ;) I'm also trying to fix repos from a issue this morning. ;( 17:55:57 so .. httpd-@f27 comes with httpd.conf and the executable installed .. but .. mod_ssl is still available.. you just have to add it by dnf install mod_ssl .. but you will get the one for httpd-2.4 rather than the httpd-2.2 that is also available because you are on the correct module stream 17:56:27 what won't be availabale is my-random-server-app.rpm that no one has made in ot a module yet 17:57:04 nirik, does that make sense? 17:57:24 yeah, I can see that is a failure case for allowing rpms and modules to mix. 17:57:28 One mitigation: there WILL be a container runtime as well, yes? 17:57:43 yes 17:57:46 So those random server app RPMs could be loaded into a container as well 17:57:50 maybe multiple 17:57:56 definitely.. 17:57:58 So it's not like we're saying there's no way to run them on our new Server 17:58:09 again I suspect aall this will work out, just need to sit down and play with it for a while. ;) 17:58:09 we may even want to "ship something" that way as an exmaple 17:58:22 langdon++ 17:58:59 yeah 17:59:05 langdon, good idea :) 17:59:52 we can use mattdms only rpm .. i don't remember what it is.. but it is important to him .. and him alone ;) 18:00:13 nethack! 18:00:17 ha 18:00:29 langdon: https://admin.fedoraproject.org/pkgdb/packager/mattdm/ 18:00:47 nethack .. the definitive server role.. cause what are you supposed to do while waiting for "dnf update" otherwise? 18:01:07 ... 18:01:08 langdon++ 18:01:22 as a complete aside.. i have been super in to shattered pixel dungeon: an open source android app that is basically a graphical version of nethack 18:01:29 Didn't we once upon a time have a clone of Tetris in the installer? 18:01:39 if not.. there should be 18:01:50 aaaanyway 18:02:07 We're at the top of the hour and I don't here any argument 18:02:08 vote? 18:02:17 langdon: We have lazy consensus 18:02:25 ohh right 18:02:38 I'll put up a rough outline of what we discussed here on the list and we'll give it a week for anyone to yell loudly about it. 18:03:23 sgallagh, ill try to be done with my overview today'ish .. which may help with that too 18:03:28 ok 18:03:55 Alright, any parting thoughts? 18:04:56 Thanks for coming, everyone! 18:05:04 #endmeeting