20:00:17 #startmeeting Fedora Server SIG Weekly Meeting (2018-04-03) 20:00:17 Meeting started Tue Apr 3 20:00:17 2018 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:17 The meeting name has been set to 'fedora_server_sig_weekly_meeting_(2018-04-03)' 20:00:18 #meetingname serversig 20:00:18 The meeting name has been set to 'serversig' 20:00:18 #topic Roll Call 20:00:21 .hello2 20:00:22 sgallagh: sgallagh 'Stephen Gallagher' 20:00:24 .hello2 20:00:25 dperpeet: dperpeet 'None' 20:02:08 sgallagh, lots of activity, eh? =) 20:02:18 morning 20:03:13 dperpeet: Hmm? 20:03:25 I'll give people a couple minutes to filter in 20:04:09 :) 20:05:02 I also need a couple minutes to finish collating the responses 20:06:10 OK, I think my thoughts are in order. 20:06:31 I suppose we should get started 20:06:40 #topic Agenda 20:06:46 #info Agenda Item: Brainstorming 20:06:52 Other items for today? 20:07:25 nothing from me 20:07:36 #topic Brainstorming 20:08:11 OK, so two weeks ago I sent out a request for thoughts on what things Fedora Server should focus on. I got back fewer replies than I hoped for, but I still got some useful tidbits. 20:08:31 I've distilled and anonymized them. First, the list: 20:08:35 #info Feedback: Fedora Server has too short a lifecycle 20:08:35 #info Feedback: Fedora Server should be more minimalistic 20:08:35 #info Feedback: SELinux needs better usability 20:08:36 #info Feedback: Support OpenCL 20:08:36 #info Feedback: Easy "home media server" would be nice 20:08:36 #info Feedback: Cockpit should be able to control more of the system 20:08:36 #info Feedback: Focus on simplifying common task execution 20:08:37 #info Feedback: Support enterprise HBAs 20:09:24 Do we want to got through these one at a time or just start talking and see where we end up? 20:09:47 * sgallagh wonders if smooge is around; he's handy at brainstorming activities. 20:10:19 does it make sense to look at them one at a time? or go through them to filter? 20:10:28 dustymabe: Are you around, by the way? I think we have some topics in this queue that might interest you 20:10:38 some of those I think are in progress from upstreams... 20:10:44 sgallagh: he's out today 20:10:51 ok 20:11:29 Might as well iterate through them. 20:11:46 #info We will go through the list individually 20:12:01 #topic Fedora Server has too short a lifecycle 20:12:10 So, this one is not likely to be news to anyone here. 20:12:30 modules should help this... 20:12:54 well, depending on what they really want 20:13:25 Yeah, that's the core of the issue. 20:13:34 We've been working on this false perception for a while now. 20:14:08 The core problem that people want to solve generally is "I don't want my applications to break, because I rely on them" 20:14:16 #info The core problem that people want to solve generally is "I don't want my applications to break, because I rely on them" 20:14:21 well, that might be one thing, but I bet also there is: 20:14:22 we're tackling reliability with CI 20:14:49 I want to install this server and let it just work (get security updates, bugfixes, etc) but not require me to do anything hands on 20:15:10 nirik: Explain to me how that is a different statement? 20:15:40 it's different aspects I guess of the same issue. 20:15:49 Perhaps I can slightly rephrase my original statement:; 20:16:35 #info Rephrased: Core problem is "I want to be able to keep my system up-to-date wrt bug and security fixes without my applications breaking" 20:16:40 Better? 20:16:46 sure 20:17:34 #info Users automatically assume that the classic solution to this problem is the only one: longer compatibility lifecycle for the whole OS. 20:18:25 #info Fedora Server attempts to solve the core problem with Modules and reliable OS release upgrades. 20:18:53 sounds good 20:19:27 OK, I think we've covered that one well enough in the past, so let's move on unless anyone has something new to add 20:19:42 sorry I am here 20:19:43 I wonder... do we think dist upgrades are robust enough to automate? 20:19:43 BTW, I'm probably going to try to convert this conversation into a blog post. 20:20:06 nirik: Probably as long as the automation checks that only Fedora repositories are enabled. 20:20:41 ie, 'f26 goes eol, it waits RAND time and then runs the upgrade to 27' 20:20:51 And we should probably work on having such tools try to automatically manage module enablement on upgrade to avoid major upgrades being implicit 20:20:59 but that might annoy or suprise some people, but might make others happy so hard to say 20:21:12 CI for dist-upgrades would be nice 20:21:22 nirik: I'd say it would be worthwhile shipping as a systemd timer that people could elect to disable. 20:21:22 for core stories 20:21:24 openqa does test them... 20:22:00 I guess the reboot could be bad... what if it reboots to do the upgrade and some crticial thing is down... 20:22:03 #info Enhancement proposal: automatically upgrade when release is EOL 20:22:10 or I guess it could just upgrade on the next reboot... 20:22:43 nirik: If we make it easy to disable or reschedule, those who are running critical infrastructure can just do that. 20:23:11 #info Enhancement proposal supplement: Cockpit UI for scheduling the automatic update after EOL 20:23:17 yeah, as long as they know to. ;) but worth trying 20:24:06 related: should we auto apply security updates? ;) but I guess thats another kettle of fish 20:24:10 i think the auto reboot should be opt in 20:24:15 I'd suggest that we probably should have Cockpit start prompting to update once a month after the next release is out, and after enough time start warning that it's going to be automatic. 20:24:19 20:24:47 bowlofeggs: We can decide the default state once we have a mechanism implemented. 20:25:03 If we do it cleanly enough from a UX perspective, it may become obvious 20:25:13 well people hate this about windows 20:25:27 i think the default state could be more important than the feature itself to some people 20:25:35 especialyl for a server 20:25:42 bowlofeggs: We're only really talking about os upgrades at the moment, not basic updates. 20:25:46 right 20:25:49 but still 20:25:58 So something that wouldn't happen more frequently than annually. 20:26:15 it could still be real bad if it defaulted to this - people do all kinds of things with servers 20:26:39 it's surprising for it to default to that, it's not surprising for it to be opt-in 20:26:44 Can I call a rat-hole on this for now? 20:26:51 We have other topics to get to 20:26:51 yeah... perhaps just setting it up for next reboot would be worth while... 20:26:55 i don't think it's a rat hole, but sure :) 20:27:03 i think it's critical 20:27:11 bowlofeggs: Well, we're not trying to solve the problems today. We're identifying them 20:27:22 I let myself get carried away as well 20:27:38 #topic Fedora Server should be more minimalistic 20:27:56 This was probably the second most common reply I got, after the previous one. 20:28:18 more minimalistic? 20:28:25 Basically, people want Server to be closer to what we were delivering with Cloud. 20:28:28 well, I think this may just require both some hard choices and some pruning of deps... 20:28:41 In that you get very little out of the default install, so they can add what they want. 20:28:57 I think we're already headed that way somewhat. 20:29:18 I'm not sure what's behind "minimalistic" here 20:29:46 so this is smaller than the netinstall with nothing selected? or do they know about that option ? perhaps it's docs and marketing? 20:29:56 dperpeet: The feedback I got is that people feel that there's a lot of services installed by default on Server and they don't understand why. 20:30:19 Some of it is just general paranoia about "more packages == more maintenance cost" 20:30:28 hm, fair - just installed or is it more about what's running / footprint / security? 20:30:36 Some of it is cargo-cult hatred of systemd/networkmanager/udisks2 20:30:56 dperpeet: People use "installed" as a stand-in for all of those things... accurate or not 20:31:26 well in those cases, they can fork their own os 20:31:43 And some of it is about minimal footprint (disk, CPU, RAM) for cloud workloads 20:31:54 This last one I think is the one we might be most likely to actually care about 20:32:21 to me, a minimal install is: a working resolver, a working and listening sshd for keyed access, a working network, {a working 'across the wire' package manager | wget and a local only package manager }, , and vi minimal 20:32:55 I have found that to be a rathole as people will argue that every set of minimal things is the right thing and the other people are worse than emacs users 20:33:15 orc_fedo_: yeah, I agree... way to get in and install more things basically. 20:33:24 nirik: yup 20:34:27 nirik: oh, and a way to do an out of band key injection 20:34:40 but I think the message has a good core though 20:34:44 sgallagh, where do you want the conversation at for this meeting... are we aiming at what should be in %base or that %base should be an option in anaconda 20:34:45 footprint is an issue 20:34:54 would be nice, but cloud-init is a horror show. ;) 20:34:58 in the sense that Fedora Server should have focus stories 20:35:03 smooge: At this meeting, agreeing which problem we want to solve going forward. 20:35:05 and not try to solve everything 20:35:07 Solutions can start next week :) 20:35:12 ok thanks 20:35:23 not that we should define the focus areas right now :) 20:35:27 nirik: thus I did not mention ... ;) no scary clowns 20:36:39 I think minimizing dependencies is a general goal no matter what and something we should always keep in mind. 20:36:42 so I agree it is something we should focus on for the minimal footprint side 20:36:59 I *don't* think we want to go back to offering something that has zero worth out of the box. 20:37:00 * nirik nods. minimal core, then extras on top 20:37:13 solutions on how to make a better coreos (pun intended) next meeting 20:37:23 (e.g. kernel+ssh+dnf is not Good Enough(TM) ) 20:37:48 sgallagh, and that is the rat hole.. because to some people that is too much 20:37:58 smooge: the other would be a smash and destroy mission to kill off sound drivers and capthcas for systemd 20:38:04 what if we actually do focus on some stories? 20:38:12 dperpeet: We absolutely should. 20:38:15 whether that is install footprint, deps, ... is a rathole 20:38:38 We were trying to do that with the roles, but it didn't pan out and the concept didn't really resonate. 20:38:43 So we need new stories. 20:38:43 theres known levels of things tho... so if we decide who we are focusing on that would helpw hat we should make 20:39:08 Perhaps we should come back to this one later. 20:39:15 I want enough OS to be in a container (no kernel, etc), I want enough to ssh into and install packages, I want enough to run freeipa, etc 20:40:10 We have 20 minutes left and six more topics. 20:40:16 we probably need to move our roles concept into the age of modularity :) 20:40:18 I'd like to at least gloss over some of the others today :) 20:40:21 but I'm fine with moving on 20:40:44 #info This topic is really easy to get rat-holed on. Will revisit later. 20:40:52 #topic SELinux needs better usability 20:41:07 well, Cockpit? 20:41:10 This one I think is one of the places where we could have a real impact 20:41:34 Yes, I think Cockpit has an opportunity to make this a lot better. 20:41:45 dperpeet: Right now, Cockpit can report SELinux denials; can it correct them? 20:41:56 Such as setting booleans? 20:42:19 setroubleshoot 20:42:34 That's not enough of an answer 20:42:36 that's what it controls under the hood 20:42:46 so whatever setroubleshoot can fix, cockpit can fix 20:42:51 I'm not sure if the scope has expanded 20:43:09 I'd like to see it be at least a matched set of capabilities to the desktop troubleshooter tool 20:43:28 the desktop one isn't very great these days. 20:43:32 But I'd also like to see it provide a UI for searching the booleans and their descriptions to try to self-diagnose 20:43:47 I remember some goals to improve it, but there's almost certainly room for more 20:43:59 #info Cockpit SELinux Troubleshooter improvements would be ideal for this 20:44:07 but stepping back from Cockpit, I think making SELinux usability one focus would be good 20:44:12 since it's very useful and important 20:44:43 I agree 20:44:59 It's also the number one advantage we have over some other distros' server offerings 20:45:01 sure, but not sure how... we don't have a lot of manpower. ;) 20:45:32 let's gloss over the how today 20:45:33 :D 20:45:34 nirik: If we can come up with a good action plan, I may be able to scrape up a resource or two 20:45:48 cool. 20:46:09 I do think it would be a nice goal... security improvements in general I think have a lot of impact on server users. 20:46:16 ack 20:46:42 #topic Support OpenCL 20:46:55 This was a request I saw come up on the Phoronix thread 20:47:02 I have literally no opinion on that 20:47:22 I think this is pretty much entirely out of scope for Fedora Server 20:47:23 doesn't sound like something I would pursue personally 20:47:56 Mostly they want kernel changes for this and I think that would have to come from a dedicated group that understands the necessary hardware 20:48:04 Motion to ignore this one. 20:48:20 yeah, don't think we can do much here... 20:48:40 #info This task would require specialized expertise that isn't readily available 20:48:56 #topic Easy "home media server" 20:49:06 This is *kind of* what we set out to do with the Server Roles. 20:49:16 I think the world has changed somewhat since then. 20:49:33 yeah, we even talked about doing a media server, but I think we decided there were too many legal things in the way 20:49:46 dperpeet: My thoughts are that this is something that could potentially be addressed with Cockpit Server Apps, but it would probably need to have its own SIG> 20:50:13 Well, there's no reason we couldn't create something similar to a Synology NAS, but I'm not sure that's effort well-spent. 20:50:43 Though I'd *love* to see a Cockpit App for NextCloud (which seems to be getting a maintainer again) 20:51:05 yeah. 20:51:15 sgallagh qnap nas devices are FOSS and published at SF 20:51:52 orc_fedo_: That sentence literally had more words that were initializations than that were English 20:51:58 * nirik thinks perhaps netcloud versions would be good fit for modules... then when one goes eol, upgrade people to the next newer still supported stream, etc. 20:52:21 nirik++ 20:52:52 sgallagh: just pointing out that there is a worked FOSS example of a media server to crib from in a QNAP 20:53:06 I think it's a good story 20:53:17 but needs a lot of work to iron out 20:53:30 orc_fedo_: I got it, I was just amused at the word-salad :) 20:53:43 * orc_fedo_ tosses at sgallagh 20:53:59 so I was wondering.. I found Fedora had a lot of energy when we had "One Laptop Per Child" as a focus. It was a customer story that people could get behind and enjoy working on. Is there anything similar these days for Server world? 20:54:19 smooge: Good question 20:54:43 is this a new topic? 20:54:45 finishing the old one? 20:54:49 Probably 20:54:52 but I agree, it is a good question 20:55:07 #topic Server Focus 20:55:34 #info Q: Is there a customer story similar to our previous OLPC effort that we could get behidn? 20:55:37 #undo 20:55:37 Removing item from minutes: INFO by sgallagh at 20:55:34 : Q: Is there a customer story similar to our previous OLPC effort that we could get behidn? 20:55:41 #info Q: Is there a customer story similar to our previous OLPC effort that we could get behind? 20:56:01 https://freedombox.org/ ? 20:56:45 (well, thats debian based, but the top layer) 20:56:51 ... 20:57:40 probibly too complex. Just a thought. 20:58:28 So what about heavy computational tasks? 20:58:38 Blockchain is all the rage... 20:58:48 folding@home? 20:59:26 Actually, considering the state of the world, maybe we should be the ones attempting to build more secure voting machines... 20:59:38 I thought blockchain was so 2017 20:59:53 OK, we're running out of time. 21:00:07 something to think of for next meeting then 21:00:24 #action Homework assignment: Think of an OLPC-style initiative that Server could back and present it next week. 21:00:32 I think we should look for something wide... not too narrow of a focus... but not sure what off hand 21:00:44 deploy a server with 3 clicks or something 21:00:50 one of those being to pick your "story" 21:01:03 dperpeet: We could call them Server Roles... 21:01:07 exactly 21:01:13 but with snazzy marketing pix 21:01:27 Server Roles X-Treme! 21:01:54 I think that idea has merit 21:02:04 looking at modularity here 21:02:10 * sgallagh nods 21:02:20 because those have the support that the roles didn't have 21:02:46 I think making Cockpit Server Apps modular-aware and using Cockpit to deploy them would be a big win 21:03:06 well, since Cockpit is a ui 21:03:15 that falls squarely on the server 21:03:21 the Server so to speak 21:03:53 OK, plenty to think about, but I don't want to run too far over time. 21:03:59 Any final thoughts? 21:04:06 say good night gracie 21:04:27 Good night, Gracie 21:04:33 #endmeeting