16:00:48 <sgallagh> #startmeeting Server SIG Weekly Meeting (2016-01-05) 16:00:48 <zodbot> Meeting started Tue Jan 5 16:00:48 2016 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:48 <zodbot> The meeting name has been set to 'server_sig_weekly_meeting_(2016-01-05)' 16:00:48 <sgallagh> #meetingname ServerSIG 16:00:48 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo danofsatx mhayden jds2001 16:00:48 <sgallagh> #topic roll call 16:00:48 <zodbot> The meeting name has been set to 'serversig' 16:00:48 <zodbot> Current chairs: adamw danofsatx jds2001 mhayden mizmo nirik sgallagh simo stefw 16:01:00 <sgallagh> .hello sgallagh 16:01:02 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 16:01:07 <mhayden> .hello mhayden 16:01:08 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net> 16:01:09 * nirik is here barely. 16:01:39 <jds2001> .hello jstanley 16:01:40 <zodbot> jds2001: jstanley 'Jon Stanley' <jonstanley@gmail.com> 16:01:57 <kushal> Hello everyone :) 16:02:08 * jds2001 has a cold, but is here :) 16:02:11 <mhayden> jds2001: haven't forgotten about your email! (sorry) 16:02:27 <jds2001> mhayden: was wondering if you'd seen it :) 16:02:50 <mhayden> i tried to get away from the computer for 2 weeks over the holidays... i was mildly successful :P 16:03:02 <jds2001> mhayden: you're probably as busy as I am too :D 16:03:19 <mhayden> indeedy :) 16:03:19 <simo> mhayden: I was fully successful ... if we exclude one day I was very weak and failed :-P 16:03:24 <mhayden> hah 16:03:42 <mhayden> sgallagh: i need to leave about halfway through as i'm doing a talk on the FAAAAAAR other side of the building here 16:03:54 <simo> .hello simo 16:03:55 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com> 16:03:58 <sgallagh> mhayden: That's fine. 16:04:12 <sgallagh> mhayden: Do you have anything you'd like to discuss at the beginning? 16:04:15 <sgallagh> #topic Agenda 16:04:20 <adamw> ahoy to the oy 16:04:30 <mhayden> i'd like to bring up systemd-networkd briefly for two reasons if possible ;) 16:04:50 <sgallagh> #info Agenda Item: systemd-networkd 16:05:07 <sgallagh> #info Agenda Item: Brainstorming plans for 2016 16:06:31 <sgallagh> OK, I guess we'll get started. 16:06:55 <sgallagh> #topic systemd-networkd 16:07:00 <sgallagh> mhayden: Take it away 16:08:18 <mhayden> alrighty, so the cloud folks brought me into their meeting before the holidays to talk systemd-networkd 16:08:36 <mhayden> there's a push on the cloud side to prefer it from their images over NetworkManager (current default) 16:08:50 <mhayden> but there's concerns around the cloud image changing to networkd without workstation/server going along 16:08:58 <mhayden> obviously, networkd isn't optimal for workstation 16:09:11 <mhayden> but it is really applicable to a server/VM/container 16:09:12 <simo> mhayden: neither it is for server 16:09:42 <simo> vm/container maybe 16:09:48 <mhayden> simo: networkd isn't good for servers? 16:09:50 * jds2001 is a bit ill-informed here, I've not looked at systemd-networkd 16:10:09 <sgallagh> simo: Rather than blanket statements, could you list the limitations that make it unsuitable? 16:10:15 <sgallagh> I think that will frame the 16:10:23 <sgallagh> conversation better 16:10:24 * nirik isn't sure what issues there would be with just cloud changing? 16:10:30 <simo> mhayden: last time I looked it didn't support all configurations and tools where nowhere near what nm offers 16:10:34 <mhayden> the cloud folks would like to know if a move could be made to systemd-networkd, and if not, where it comes up short 16:10:45 <simo> there is no nmtui equivalente and similar stuff 16:10:45 <sgallagh> mhayden: One of the primary reasons we selected NetworkManager was its very rich API 16:10:59 <simo> also no integration with desktop stuff if you install a DE in the server which we support 16:11:18 <mhayden> right, networkd isn't optimal for workstations at the moment 16:11:21 <sgallagh> stefw can correct me, but I think Cockpit only works with NM as well 16:11:24 <jds2001> since im not informed, can networkd do bridges, vlans, bonds, and all that fun stuff that nm has grown recently? 16:11:29 <simo> mhayden: nor for server 16:11:33 <mhayden> jds2001: yeah, i've written docs on it 16:11:39 <stefw> cockpit currently wortks with NetworkManager only 16:11:47 * mhayden makes notes 16:11:49 <stefw> but we worked with the systemd guys to help an API 16:11:52 <stefw> for networkd come about 16:11:53 <mhayden> that's all good information to know 16:11:59 <stefw> so we can also work with networkd 16:12:05 <simo> stefw: are they using the same config files or different config files ? 16:12:06 <tflink> nirik: testing coverage, mostly - introducing a new network stack would mean that the cloud image would need new test cases, docs etc. 16:12:12 <stefw> simo, totally different 16:12:18 <simo> then that's a deal breaker 16:12:18 <sgallagh> stefw: I'm guessing that sentence should have included "in the future"? 16:12:20 <stefw> and the cockpit code to deal with them would be totally different 16:12:23 <adamw> i don't think networkd is compatible with the ifcfg config format either (the way NM works quite hard to stay compatible with it because many admins are used to it) 16:12:27 <simo> until mhayden volunteers to build an automatic migration tool :) 16:12:28 <tflink> that's QA's concern with networkd, anyways 16:12:32 <mhayden> adamw: right, it uses a new format 16:12:36 <mhayden> it's a paste-config type format 16:12:48 <stefw> yup 16:12:57 <mhayden> simo: i'm writing docs + ansible to get underway with the basics :) 16:13:00 <stefw> it's also a different way to think about your network configuration 16:13:02 <simo> tbh I see no compelling reason to switch 16:13:16 <mhayden> good point 16:13:17 <nirik> tflink: sure. Of course I doubt workstation would change, so we would still have NM. ;) 16:13:19 <simo> mhayden: what is the advantage for the server product to switch ? 16:13:38 <mhayden> would it be possible to get something into the server deployment docs about using systemd-networkd as an alternative to networkmanager or existing network scripts? 16:13:49 * mhayden is willin' to write 16:13:51 <simo> if we were in 2010 with the old init scripts for netowkring it would be ano brainer 16:13:59 <simo> but NM does its job well nowadays 16:14:13 <tflink> nirik: yeah, there's just a lot of work that doesn't seem to have been addressed or assigned/claimed yet 16:14:34 * mhayden is certainly not advocating for dropping NM :) 16:14:54 <mhayden> perhaps we could offer systemd-networkd as an alternative in the docs 16:15:01 <tflink> at least that's how it seems to me but I'm just getting into paying more attention to cloud stuff 16:15:17 <sgallagh> mhayden: That would seem to defy the intent of the Server edition entirely. 16:15:18 <mhayden> simo: the cloud folks are interested in systemd-networkd for resource-constrained environments 16:15:21 <jds2001> but then cockpit breaks 16:15:30 <sgallagh> Which is that we provide a platform and a set of reference docs for how best to use that platform. 16:15:32 <mhayden> and the config files are a little easier to work with, especially with cloud-init or config mgmt 16:15:33 <simo> mhayden: right, but it is a very niche case 16:15:35 <nirik> mhayden: did they look at the NM onshot stuff/ 16:15:38 <nirik> ? 16:15:43 <mhayden> nirik: i'm not aware of that 16:16:01 <nirik> ie, NM starts, configures network and exits... 16:16:09 <nirik> but I guess in cloud you dhcp all the time. 16:16:16 <mhayden> in some clouds, yes 16:16:52 <mhayden> #action mhayden to take systemd-networkd feedback to cloud sig + systemd upstream 16:17:12 <sgallagh> mhayden: So one of the early decisions we made (documented in the PRD) was that part of the definition of Server was a stable API for managing the network. 16:17:23 <sgallagh> networkd today does not meet this requirement 16:17:39 <mhayden> #link https://fedorahosted.org/cloud/ticket/14 16:17:47 <mhayden> ^^ that's the cloud sig ticket with much more context 16:18:11 <mhayden> sounds good 16:18:40 <mhayden> i'm assembling talk proposal for the summit to familiarize folks with systemd-networkd -- any feedback that anyone has on that would be greatly appreciated 16:18:47 <adamw> nirik: it was mentioned in the cloud thread, but didn't get a lot of notice i don't think. 16:19:02 <nirik> just a thought 16:19:14 <sgallagh> mhayden: You said at the beginning that you had two networkd-related topics. 16:19:24 <mhayden> sgallagh: the second was the summit talk proposal :) 16:19:27 <sgallagh> ok 16:19:30 <mhayden> which i just did, so i'm done there :) 16:19:44 <sgallagh> Just wanted to make sure we didn't burn all your time on the first item 16:19:54 <sgallagh> So, something else tangentially related here: 16:20:10 <sgallagh> the systemd-resolved folks are currently working on a competing DNSSEC solution 16:20:28 <sgallagh> It's unclear (to me, maybe not to you) whether this will be usable by other network stacks or only networkd 16:20:57 <mhayden> i'd hope it would be used elsewhere 16:21:07 <mhayden> systemd-resolved is mainly used for handling local lookups for machine names and such 16:21:14 <mhayden> so you can ssh root@containername or something like that 16:21:15 <sgallagh> But I expect that the Server SIG will need to weigh in on a DNSSEC approach at some point 16:21:25 <mhayden> or have containers speak to each other using their container names without DNS in place 16:21:38 <mhayden> ah, DNSSEC :) 16:22:06 <mhayden> if anyone needs a chuckle later -> http://dnsreactions.tumblr.com/ 16:22:09 <sgallagh> I'll gather more information about this and bring it up next week 16:22:24 <sgallagh> #action sgallagh to research alternative DNSSEC implementations for next week 16:23:07 <sgallagh> #info mhayden asked whether Server might consider switching to systemd-networkd. Responses remained in favor of Network Manager at this time. 16:23:17 <sgallagh> (Fair summary?) 16:24:11 <adamw> seems reasonable 16:24:15 <mhayden> good stuff 16:24:17 <sgallagh> OK, anything further on this topic? 16:24:18 <mhayden> thanks sgallagh 16:24:23 * mhayden yields 16:24:43 <simo> sgallagh: systemd-resolved is a bad idea (implementationally bad) 16:25:16 <simo> I am not looking forward to use it in server (or workstation for that matter) any time soon 16:25:20 <sgallagh> simo: I'm reserving judgement until I do my homework. But my gut instinct agrees. 16:25:32 <sgallagh> #topic Brainstorming plans for 2016 16:25:36 <simo> the problem is using non-dns to carry dns requests it is just wrong 16:25:55 <simo> using a local resolver is the correct course of action 16:26:06 <sgallagh> OK, so this is a pretty broad topic, but I was hoping we could attempt to do a little wild brainstorming and then narrow down into actual plans. 16:26:24 <simo> sgallagh: go ahead 16:26:52 <sgallagh> /me opens his Management for Dummies book to the page on "lists" 16:27:30 <sgallagh> So, I was thinking it might not be a bad idea to do a couple quick lists of things Server does well and poorly. 16:28:01 <sgallagh> (These do not have to be unique to Server) 16:28:37 <sgallagh> It's a new year, most of us have just had a vacation, so let's start with the positives. 16:28:49 <sgallagh> #topic Brainstorming List - What Server Does Well 16:29:00 <sgallagh> Please #info your thoughts 16:29:25 <sgallagh> #info Simple installation 16:29:28 <jds2001> #info Easy to use WebUI 16:29:59 <jds2001> #info pre-defined roles or personas 16:29:59 <sgallagh> #info Versatile networking features 16:30:13 <jds2001> (but that can also go into negative, will get there in a bit :D) 16:30:31 * mhayden must depart -- sorry 16:30:40 <sgallagh> mhayden: Thanks for coming. No parting words of praise? ;-) 16:31:04 <sgallagh> #info Wide variety of available software 16:31:21 <mhayden> #info Virtualization/container tools are easy to use 16:31:27 * mhayden winks 16:32:22 <sgallagh> #info Functional and useful out of the box 16:33:02 <sgallagh> stefw, adamw, simo: Thoughts? 16:33:32 <simo> sgallagh: sorry I am not sure what you aree asking 16:33:42 <simo> comments on your list or additions to the listr or ? 16:33:47 <sgallagh> Additions 16:33:56 <stefw> A big topic for Cockpit in 2015 will be troubleshooting. (eg: SELinux, firewall, disks) 16:34:00 <stefw> is that something worth mentioning here? 16:34:13 <sgallagh> stefw: That's probably right for the next topic: Things Server Can Improve Upon 16:34:27 <jds2001> stefw: you intend to travel back in time? :D 16:34:36 <stefw> heh, okay misread 16:34:38 <jds2001> stefw: i want that time machine! 16:34:45 <stefw> me too 16:34:53 <adamw> sgallagh: i think you've covered it... 16:34:56 <sgallagh> OK 16:35:07 <stefw> Fedora Server has one other distinct advantage 16:35:12 <sgallagh> #topic Brainstorming List - Things Server Can Improve Upon 16:35:14 <stefw> ability (nay requirement) to stay near the cutting edge 16:35:15 <sgallagh> #undo 16:35:15 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f4759e68310> 16:35:22 <sgallagh> stefw: Please #info it 16:35:48 <sgallagh> (also, I can't believe I missed that one) 16:35:51 <stefw> #info A Server OS that agressively updates the included software 16:36:01 <simo> stefw: yeah torubleshooting is very important for server and in general for FOSS imho 16:36:06 <sgallagh> #topic Brainstorming List - Things Server Can Improve Upon 16:36:53 <jds2001> #info Expanding the functionality of Cockpit (i.e. software management, probably lots of other things) 16:37:06 <sgallagh> jds2001: Mind listing things individually? 16:37:09 <jds2001> #info User-defined roles 16:37:12 <sgallagh> I want to be able to reference this list later 16:37:18 <stefw> #info Discoverable troubleshooting of the system 16:37:38 <jds2001> #info Software Managemnt (updates) in cockpit 16:37:40 <sgallagh> #info Stability guarantees between updates 16:37:49 <jds2001> #info deployment of roles in cockpit 16:38:05 <jds2001> #info role repair tool 16:38:11 <simo> #info Change Management when (not if) APIs break 16:38:14 <adamw> is the documentation for role deployment still 'go read the rolekit trac'? 16:38:19 <adamw> if so, that could be better :) 16:38:43 <sgallagh> adamw: Yes, but we've always intended for that to become part of Cockpit 16:38:55 <sgallagh> The CLI has always been a reference implementation, not a solution 16:39:08 <adamw> sgallagh: i kinda suspect there are always going to be some server admins who want a CLI... 16:39:16 <jds2001> sgallagh: there should be parity between the CLI and GUI, IMO 16:39:19 <adamw> (links?) 16:39:28 <sgallagh> adamw: OK, info it 16:39:38 <stefw> #info https://trello.com/c/7CZqL9AQ/54-rolekit-integration-for-domain-controller 16:39:43 <adamw> #info more user-friendly and better documented role CLI 16:39:49 <sgallagh> jds2001: The CLI and GUI both just consume the API 16:39:59 <sgallagh> So the feature-parity will be handled at that level 16:40:37 <sgallagh> But I agree with needing better documentation 16:41:05 <nirik> it would be nice if we had a bunch more roles... 16:41:28 <jds2001> nirik: that goes into my "there's no way for a user to define a role" 16:41:32 <sgallagh> nirik: We have many potential roles listed on the rolekit upstream site. 16:41:41 <jds2001> i.e. I'm not a C developer, so I can't touch it atm. 16:41:43 <sgallagh> jds2001: Info that? 16:41:44 <nirik> yeah. agreed on both. 16:41:51 <sgallagh> jds2001: Roles are python, actually 16:42:01 <jds2001> sgallagh: already did, first one :) 16:42:04 <adamw> should we just say easier role development? 16:42:10 <sgallagh> Oh, missed that 16:42:12 <jds2001> sgallagh: oh, rly? 16:42:29 <sgallagh> And FWIW, we are revamping the role development entirely. 16:42:37 <sgallagh> The next release should be vastly simplified. 16:42:42 <adamw> since the difference between 'user-defined' and 'distro-provided' is really just submitting a ticket or something i guess 16:42:49 <sgallagh> See the logs from this morning's rolekit meeting 16:43:20 <sgallagh> #link https://meetbot.fedoraproject.org/teams/rolekitweekly/rolekitweekly.2016-01-05-14.30.log.html 16:43:56 <sgallagh> adamw: Well, upstream we're also going to separate "user-defined" from "system-provided" and ensure that they have a prefix so that we don't have a namespace problem. 16:44:04 <sgallagh> But I get the point you were trying to make 16:44:07 <adamw> rgr 16:44:45 <sgallagh> I'll just throw this one out there since we keep hearing about it: 16:44:54 <sgallagh> #info No long-term support guarantees 16:45:38 <jds2001> hearing about something a lot and it being the right place here to do things about it are two different things :D 16:45:58 <sgallagh> jds2001: Well, there are multiple ways to solve the underlying problems. 16:46:03 <jds2001> though I do 100% agree that there needs to be a middle ground between us and CentOS 16:46:03 <sgallagh> Listing it is still useful 16:47:01 <sgallagh> #info Better support for coexisting with Windows 16:47:20 <sgallagh> (For example, the domain controller role should eventually support setting up cross-realm trusts) 16:48:28 <sgallagh> #info Need support for DNSSEC out of the box 16:49:30 <sgallagh> OK, we seem to be slowing down. Any other big things we're overlooking? 16:50:39 <simo> sorry I was triple booked today so hard to context switch 16:50:40 <sgallagh> #info Easily build an OpenStack cloud 16:50:50 <adamw> unicorns 16:50:55 <simo> sgallagh: ^ 16:51:12 <simo> I do not think openstack is something server should touch 16:51:23 <sgallagh> simo: No worries, this is mostly an exercise to have us looking at things we might want to address 16:51:47 <sgallagh> simo: Perhaps not. 16:52:32 <jds2001> simo: im not sure what product *will* touch that, but worth noting as a laudable goal for the overall project 16:52:33 * nirik liked the idea of a storage server. 16:52:38 <sgallagh> #info We have no good story for server management 16:52:57 <sgallagh> nirik: Yeah, a storage server is still something we need to plan. 16:53:17 <jds2001> sgallagh: i thought that was cockpit for smaller deployments and katello for larger ones. 16:53:20 <sgallagh> By "server management", I mean that we don't have an Ansible, Puppet, Chef, OpenLMI, etc. story. 16:53:26 <jds2001> #info easily set up katello 16:53:48 <simo> sgallagh: server managment -> cockpit ? 16:53:54 * jds2001 knows that katello and easily dont belong in the same sentence :D 16:53:56 <simo> -> ansible ? 16:53:59 <simo> -> not our problem ? 16:54:04 <simo> :-) 16:54:07 <sgallagh> simo: Unclear if it's our problem. 16:54:20 <sgallagh> But it's something we don't do well beyond a couple dozen machines right now 16:54:25 <sgallagh> So we should figure out our story 16:54:28 <simo> sgallagh: what I know is that is it a very hard problem with half a dozen competing solutions in FOSS 16:54:43 <simo> not sure it make sense for us to do anything specific 16:54:49 <sgallagh> Right, but our mandate is that we pick one and make it work for us 16:54:58 <sgallagh> We're providing a platform, not a toolbox 16:55:25 <sgallagh> (Ideally, we'd also find one that our primary sponsor is fond of and would put resources into helping with) 16:56:02 <sgallagh> For small setups, clearly Cockpit is our answer and we should continue that. 16:56:21 <sgallagh> But we don't have a hundred-plus-machine answer. 16:56:49 <sgallagh> We originally planned on using OpenLMI for this, but that project was scrapped. 16:56:52 * jds2001 points to katello for that, but maybe not? 16:57:03 <sgallagh> Katello/Satellite are valid answers. 16:57:07 <sgallagh> So is Ansible 16:57:26 <sgallagh> I don't expect us to make a decision here, just to decide if it's something we agree is lacking. 16:57:39 <simo> sgallagh: is it our project goal to provide that ? 16:57:51 <simo> I weould think we need to make sure all agents/clients/whatever work well 16:57:57 <simo> but not necessarily provide more than that 16:58:16 <sgallagh> simo: I don't know that this is an achievable goal. 16:58:29 <simo> ok 16:58:30 <sgallagh> It's probably best if we pick one (or two) and make those work exceptionally well 16:58:43 <simo> I just do not want to spend scarce resources on non-achievable goals 16:58:51 <sgallagh> Agreed. 16:59:05 <sgallagh> Like I said, today's exercise was to see where we might be able to improve. 16:59:17 <sgallagh> Next week's exercise will be narrowing that to a list of things we want to focus on 16:59:53 <sgallagh> #topic Open Floor 17:00:13 <sgallagh> We're at the top of the hour, so I'll understand if everyone is ready to depart, but anything for Open Floor? 17:01:15 <sgallagh> OK, thanks for participating. 17:01:21 <sgallagh> /me closes Management for Dummies 17:01:25 <sgallagh> #endmeeting