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