21:01:32 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2017-03-07)
21:01:33 <zodbot> Meeting started Tue Mar  7 21:01:32 2017 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:33 <zodbot> The meeting name has been set to 'server_working_group_weekly_meeting_(2017-03-07)'
21:01:33 <sgallagh> #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf
21:01:33 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
21:01:33 <sgallagh> #topic roll call
21:01:33 <sgallagh> .hello sgallagh
21:01:34 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
21:01:45 <mjwolf> .hello mjwolf
21:01:46 <mhayden> .hello mhayden
21:01:46 <zodbot> mjwolf: mjwolf 'Michael Wolf' <mjwolf@us.ibm.com>
21:01:49 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
21:01:57 <dperpeet> .hello dperpeet
21:01:58 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
21:02:02 <nirik> morning
21:02:17 <dperpeet> good evening
21:02:27 <jds2001> .hello jstanley
21:02:28 <zodbot> jds2001: jstanley 'Jon Stanley' <jonstanley@gmail.com>
21:02:37 <marc84> hi everyone
21:03:37 <sgallagh> Hello, marc84. You're a new face (nick). Welcome to the Server SIG :)
21:04:54 <marc84> sgallagh: thanks
21:05:05 <sgallagh> #topic agenda
21:05:48 <sgallagh> OK, I don't have anything specifically on the agenda for this week, but I can talk briefly about the Fleet Commander stuff if desired. Does anyone else have a topic they particularly want to bring up this week?
21:06:27 <dperpeet> I wanted to note that I sent a comment on Cockpit and server roles to the mailing list
21:06:34 <dperpeet> as a reply to last week's notes (sent it today)
21:07:13 <sgallagh> dperpeet: Thanks for that. I suspect that some folks will have follow-up questions.
21:07:26 <sgallagh> /me nods in jds2001's direction
21:07:37 <dperpeet> also the plan to join the Cockpit meeting next week on Monday is good
21:07:48 <sgallagh> #topic Fleet Commander
21:08:25 <sgallagh> So, Fleet Commander is a project coming out of the Workstation team that is very much in *our* wheelhouse.
21:08:40 <nirik> yeah, I saw mention of it... looked cool.
21:08:44 <sgallagh> Essentially, it's a way to centrally-manage desktop profiles for a business.
21:09:22 <jds2001> sounds cool and useful
21:09:30 <sgallagh> It's being developed in part as a Cockpit plugin and it relies heavily on FreeIPA (with a possible option for Active Directory at some point).
21:10:11 <sgallagh> I asked cschalle to have his team propose some extensions to our Domain Controller proposal to identify what features of the DC we want to make sure to keep on our release criterion.
21:10:51 <sgallagh> The initial pass was a little miscommunicated, but I spoke with aruiz this morning and he's going to send an updated version for the DC and probably a follow-up of a proposal for a Fleet Commander Role as well, modeled after the DC one.
21:11:36 <sgallagh> Given that this provides us with an opportunity to integrate our two efforts, I'm very excited about these developments and I'm going to be doing what I can to facilitate them.
21:11:37 <jds2001> what would a fleet commander role look like?
21:11:55 <jds2001> is it a cognizable piece of software that runs on a server of some sort?
21:12:32 <sgallagh> jds2001: Effectively it will be an optionally-installable Cockpit component on a machine enrolled with a FreeIPA domain.
21:12:47 <sgallagh> It also has a plugin for FreeIPA to extend the schema, so it will need pieces there as well.
21:13:36 <linuxmodder> .hello linuxmodder
21:13:37 <zodbot> linuxmodder: linuxmodder 'Corey W Sheldon' <sheldon.corey@openmailbox.org>
21:13:42 <jds2001> ahhhh
21:13:46 <sgallagh> Beyond that, I think it's probably premature to discuss it too much until we get a proposal from the Workstation folks.
21:13:57 <sgallagh> (I don't have all the details yet)
21:14:07 * jds2001 is just interested in what it is......
21:14:28 <jds2001> do they enviison running Cockpit on workstation?
21:14:34 <sgallagh> jds2001: I'm going to try to book aruiz to record a demo for us.
21:14:59 <nirik> basically it makes profiles for workstations in a central place and then lets you push them out to clients...
21:15:03 <sgallagh> jds2001: It's sort of the other way around; the fleet commander would be on a server, but it would push out desktop configuration
21:15:36 <jds2001> ahhh, got it. Sounds like a perfect use for Ansible execution in Cockpit :D
21:15:43 <sgallagh> :-D
21:16:14 <dperpeet> :)
21:16:51 <sgallagh> Alright, I don't have much more on that for today. Mostly I just want to be open about what may be coming our way.
21:18:13 <sgallagh> jds2001: Actually, I'm having trouble seeing where you're coming from on that specific example.
21:18:32 <sgallagh> Maybe I missed a logical leap somewhere
21:18:34 <jds2001> use Ansible to push configuration to the end system.
21:18:51 <jds2001> Nothing required on the end system but a working Python interpreter.
21:19:06 <sgallagh> jds2001: I think the client systems actually pull the configuration, because it's not per-machine but per-identity.
21:19:22 <sgallagh> There are pieces going into SSSD to handle it.
21:19:44 <sgallagh> So as long as they're enrolled with a FreeIPA server, SSSD will automatically detect that it's offering profiles and honor them
21:19:55 <jds2001> oh, ok....but somehow SSSD has to be configured to talk to it :)
21:20:13 <sgallagh> jds2001: Once SSSD is enrolled with FreeIPA, it gets its configuration from FreeIPA.
21:20:17 <sgallagh> It's clever that way ;-)
21:21:17 <sgallagh> (it's been doing that for a long time, for things like host-based access control and ID views)
21:21:56 * jds2001 clearly needs some edjumication
21:22:14 <sgallagh> Anyway, that's what the FreeIPA plugin bits are for: they add the pieces that SSSD will query for profile data for user sessions.
21:23:04 <sgallagh> OK, I'm going to stop here, because we've actually now exhausted everything I know so far on the subject.
21:23:28 <sgallagh> I've sent cschalle and aruiz a message asking for a demo video, which I'll share with the server@ list when I get it.
21:25:13 <linuxmodder> maybe I'm just dense today but in the absence of an identity in freeIPA/AD how would FC manage a end machine push?
21:25:13 <sgallagh> Ah, I do have a couple links I can share, though
21:25:32 <sgallagh> linuxmodder: It doesn't it requires FreeIPA to operate today, IIUC
21:25:53 <sgallagh> #link https://wiki.gnome.org/Projects/FleetCommander
21:25:53 <sgallagh> #link https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki
21:25:53 <sgallagh> #link https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration
21:26:40 <jds2001> ummm, where is sssd now that fedorahosted is dead?
21:27:07 <sgallagh> jds2001: The wiki is still there at the moment
21:27:19 <linuxmodder> sgallagh,  so not in the old fashioned classical Domain required sense I'm remembering ?
21:27:32 <linuxmodder> pagure ( or should be migrating there )
21:27:37 <sgallagh> The upstream is now hosted at https://pagure.io/SSSD/sssd/
21:27:38 <linuxmodder> jds2001, ^
21:27:56 <sgallagh> linuxmodder: I don't understand the question.
21:28:33 <linuxmodder> I'm thinking I'm scattered today not enough coffeee disregard me
21:28:54 <sgallagh> Done ;-)
21:30:01 <sgallagh> OK, let's move on for today. We'll come back to this in a future meeting.
21:30:20 <sgallagh> #topic Cockpit and Ansible
21:30:29 <sgallagh> jds2001: Feel free to direct your questions at dperpeet
21:30:31 <sgallagh> :-D
21:30:37 <dperpeet> heh
21:30:44 <jds2001> heh
21:30:53 <jds2001> thought we were crashing the meeting in a week :)
21:31:23 <jds2001> but anyhow, im basically concerned about the maintainability of the proposed solution
21:31:58 <dperpeet> yes, that's one of the reasons Cockpit prefers to talk to system APIs instead of implementing details itself
21:31:59 <jds2001> how can I be sure that what I get from a generated Ansible playbook, and what I get from Cockpit, are the *exact same thing*
21:32:21 <dperpeet> if they talk to the same system APIs
21:32:32 <dperpeet> that shouldn't be difficult
21:32:41 <dperpeet> it's like using networkmanager CLI vs cockpit interface
21:33:10 <jds2001> but NM has an API that Cockpit can talk to.
21:33:14 <jds2001> Not everything does.
21:33:30 <dperpeet> and I'm not saying cockpit won't use ansible playbooks
21:33:56 <dperpeet> I'm saying the feature of switching roles shouldn't be limited to using Ansible
21:35:17 <sgallagh> "switching roles"?
21:35:34 <dperpeet> I mean picking one / installing one / et cetera
21:35:42 * jds2001 had the same scratching head moment
21:35:43 <dperpeet> not sure if we picked a terminology
21:36:17 <sgallagh> We usually use the term "deploy" around here.
21:36:21 <dperpeet> right
21:36:39 <dperpeet> I'm saying the feature of deploying roles shouldn't be limited to using Ansible
21:36:41 <dperpeet> :)
21:36:48 <dperpeet> shouldn't necessarily
21:36:55 <jds2001> but why not?
21:37:15 <jds2001> ansible is a "system API" for the entire system.
21:37:36 <jds2001> I thought from what sgallagh said last week it had to do with non-deterministic state?
21:37:48 <dperpeet> how can we be sure what actually happens?
21:37:56 <dperpeet> how do we change parameters?
21:38:12 <dperpeet> what happens if a user's browser disconnects?
21:38:26 <jds2001> why do you *care* what happens?
21:38:31 <dperpeet> how do we present feedback to the user?
21:38:36 <jds2001> so long as the system is in the desired state at the end
21:39:23 <jds2001> the nice thing about a well written playbook is that it's idempotent.
21:39:37 <jds2001> apply it as many times as you like, changing what you like.
21:39:48 <sgallagh> jds2001: Which is sometimes a bold-faced lie, of course
21:40:00 <jds2001> sgallagh: of course :)
21:40:02 <dperpeet> that needs to be curated also
21:40:08 <jds2001> notice i qualified it :)
21:40:35 <jds2001> yep, totally agree that the roles need to be curated.
21:40:46 <dperpeet> I'm not saying Ansible can't be one way
21:41:08 <dperpeet> but other parts of a system have good APIs
21:41:14 <dperpeet> and why not use them directly?
21:41:27 <dperpeet> I don't see why everyone should be tied to Ansible
21:41:51 <dperpeet> and I'm certain there are more reasons I'm missing here that are probably best discussed at the Cockpit meeting
21:42:01 <dperpeet> with Marius who worked on the proof of concept
21:42:12 <dperpeet> running a playbook certainly is possible
21:42:20 <dperpeet> and I don't see why Cockpit shouldn't support that
21:43:18 <jds2001> but it seems that we're diverging.....
21:43:30 <jds2001> from using an abstraction layer (Ansible) to direct implementation.
21:43:45 <dperpeet> depends on the API
21:44:04 <sgallagh> jds2001: Well, what they're advocating for is that the Ansible modules that run on the target system should be using the same APIs that Cockpit uses directly.
21:44:19 <dperpeet> if those exist
21:44:52 <dperpeet> the best Cockpit solutions are (in my personal opinion) if there are good APIs to talk to
21:45:12 <dperpeet> I think I'm coming across in a way I didn't intend
21:45:22 <dperpeet> I'm not against Cockpit using Ansible at all
21:45:56 <dperpeet> and things like "can I get a playbook for what I just did to this server?" would be great
21:46:33 <dperpeet> I think that in the long run "special sauce" should be moved out of playbooks and into underlying APIs
21:46:38 <dperpeet> so everyone can benefit
21:47:18 * jds2001 too, but that's a bit of a utopian future :)
21:47:29 <dperpeet> sure, but Cockpit has to think *long* term
21:47:35 <sgallagh> jds2001: Except that really *is* exactly what Cockpit has been doing.
21:47:52 <sgallagh> It's part of why storaged and NetworkManager have come so far, so fast in the last two years
21:48:00 <dperpeet> every time we add a feature, we try to make sure that stuff lands "upstream"
21:48:22 <dperpeet> that will also make sure that playbooks are easier to maintain
21:48:34 <dperpeet> I don't really think we're disagreeing :)
21:49:03 <jds2001> me either :)
21:49:05 <dperpeet> and if there is no good underlying API
21:49:11 <dperpeet> but there is a good playbook
21:49:13 <dperpeet> then we use that
21:49:23 <sgallagh> dperpeet: One that springs readily to mind is samba
21:49:30 <dperpeet> get things working, then iterate
21:49:43 <sgallagh> Which has an unreasonably bad config file and no supported API to modify it.
21:50:17 <jds2001> so whose remit is it to write such an API?
21:50:21 <jds2001> anyone's?
21:50:55 <dperpeet> everyone who has a stake in having it work :)
21:52:04 <sgallagh> I have a hard stop in ten minutes today, but if the conversation needs to continue, plenty of you have #chair
21:52:17 <dperpeet> I think at the next Cockpit meeting is also good
21:52:23 * jds2001 too
21:52:26 <dperpeet> more people involved who actually tried this stuff out
21:53:38 * linuxmodder has been uncharacteristically absent recently on the testing side
21:55:49 <sgallagh> OK, then let's take this to the Cockpit meeting on Monday.
21:55:56 <sgallagh> #topic Open Floor
21:55:59 <sgallagh> Any final remarks?
21:56:13 <dperpeet> yeah, I'm happy to see this moving forward :)
21:57:22 <sgallagh> OK, thanks for coming and participating, all!
21:57:26 <sgallagh> #endmeeting