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