20:01:09 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2017-03-21)
20:01:09 <zodbot> Meeting started Tue Mar 21 20:01:09 2017 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:09 <zodbot> The meeting name has been set to 'server_working_group_weekly_meeting_(2017-03-21)'
20:01:10 <sgallagh> #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf
20:01:10 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
20:01:10 <sgallagh> #topic roll call
20:01:10 <sgallagh> .hello sgallagh
20:01:11 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
20:01:27 <nirik> morning
20:01:28 <mjwolf> .hello mjwolf
20:01:29 <zodbot> mjwolf: mjwolf 'Michael Wolf' <mjwolf@us.ibm.com>
20:01:33 <dperpeet> .hello dperpeet
20:01:36 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
20:02:59 <smooge> .hello smooge
20:03:00 <zodbot> smooge: smooge 'Stephen J Smoogen' <smooge@gmail.com>
20:03:10 <vvaldez> .hello vvaldez
20:03:10 <zodbot> vvaldez: vvaldez 'Vinny Valdez' <vvaldez@redhat.com>
20:03:10 <jds2001> .hello jstanley
20:03:13 <zodbot> jds2001: jstanley 'Jon Stanley' <jonstanley@gmail.com>
20:03:18 * mhayden can't make it today as he's at a conference with terrible wifi
20:03:29 <jds2001> vvaldez: :(
20:03:35 <jds2001> er, mhayden
20:03:47 * jds2001 must be going blind
20:04:10 <adamw> .hello adamwill
20:04:11 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
20:04:35 <sgallagh> mhayden: That sentence probably could have stopped three words sooner with exactly the same meaning :-/
20:06:33 <sgallagh> #topic Agenda
20:06:44 <jds2001> sgallagh: summit last year was surpirsingly decent
20:07:01 <sgallagh> I only had one topic on the agenda for today: jds2001 and dperpeet were going to summarize the meeting with the Cockpit team.
20:07:09 <sgallagh> Did we have other topics to discuss?
20:07:33 <sgallagh> adamw: Anything we might have to deal with for Alpha?
20:10:06 <sgallagh> OK, I guess we already lost adamw to the void.
20:10:14 <sgallagh> #topic Cockpit and Roles
20:10:20 <sgallagh> jds2001, dperpeet: Please take it away
20:10:37 <jds2001> #link https://meetbot.fedoraproject.org/cockpit/2017-03-13/meeting.2017-03-13-14.03.log.html
20:10:56 <jds2001> so we met with the cockpit team, see link above
20:11:08 <jds2001> it was pretty productive, actually
20:11:43 <dperpeet> and an intense discourse :)
20:11:53 <jds2001> Cockpit seems to prefer having API's to do things, we clarified that Ansible roles are really an API
20:12:02 <jds2001> and playbooks are the client of that API.
20:12:39 <jds2001> there are issues with getting notifications of change from Ansible, which is perfectly a valid concern.
20:13:10 <dperpeet> due to the way a browser session works
20:13:12 <dperpeet> also
20:13:26 <jds2001> and we're not looking to displace existing functionality was a big one.
20:13:34 <jds2001> (for example NM)
20:15:30 <sgallagh> jds2001: we == Ansible in that sentence?
20:15:40 <dperpeet> one part that wasn't entirely clear was how to weigh the different user stories
20:15:41 <jds2001> yeah
20:16:05 <sgallagh> dperpeet: As in prioritize them?
20:16:10 <jds2001> not looking to displace existing functionality that NM with Ansible
20:16:47 <jds2001> er, sorry phone rang
20:16:53 <dperpeet> well, priorities for one
20:17:11 <dperpeet> but which functionality should be how comfortable to use et cetera
20:17:23 <dperpeet> and how important is it to get notifications
20:17:24 <sgallagh> ah
20:18:35 <jds2001> also, there were some misconceptions that it was not possible to obtain status from Ansible....really you can obtain anything you want from a running system without changing anything.
20:18:54 <jds2001> but you do have to poll obviously
20:19:18 <jds2001> there is no active notification as there is no daemon running on the system to provide it.
20:20:22 <vvaldez> that’s usually true, most modules don’t have a ‘status’ equivalent (e.g. service or systemctl), but you can use ansible facts or a command to grab that
20:21:02 <jds2001> vvaldez: good modules would implement 'check' correctly ;)
20:21:10 <vvaldez> jds2001: true
20:21:21 <dperpeet> we'd have to see how that would integrate into the cockpit ui
20:21:23 <sgallagh> jds2001: By which we mean: any modules produced by our team would require that for acceptance. Fair?
20:21:29 <dperpeet> which usually responds to changes instead of doing polling
20:21:33 <vvaldez> sgallagh: +1
20:21:38 <jds2001> sgallagh: +1
20:21:47 <jds2001> s/produced/used though
20:22:05 <jds2001> because I doubt we'd produce new ansible modules (though it certainly is possible)
20:22:11 <sgallagh> Well, there's no *existing* daemon that can do this stuff, but I wonder if we might work ourselves into something else that's commonly on the system. SCAP perhaps?
20:22:32 * linuxmodder looks in
20:22:53 <adamw> adamw: sorry, no, nothing i'm aware of for alpha right now. the remaining freeipa bug we downgraded to not-a-blocker.
20:23:11 <adamw> sgallagh: ^
20:23:27 <jds2001> adamw: quit talking to yourself, only crazy people do that :D
20:23:35 <adamw> .fire jds2001\
20:23:35 <zodbot> adamw fires jds2001\
20:24:06 <sgallagh> You missed :-P
20:24:47 <dperpeet> one more comment on the "replacing" comment
20:25:18 <dperpeet> we agreed not to replace the things already done in cockpit, e.g. using networkmanager to configure the network
20:25:33 <dperpeet> that doesn't mean there couldn't be another cockpit package that also configures the network, but via ansible
20:25:57 <sgallagh> dperpeet: That seems like a waste of effort.
20:26:05 <dperpeet> I just pulled the networking example out of thin air
20:26:19 <sgallagh> If we start having multiple ways to accomplish the same thing in Cockpit, it'll quickly become webmin and everyone will be sad again
20:26:20 <dperpeet> I'm just saying there's no technical reason why they couldn't coexist
20:26:40 <dperpeet> I think Cockpit should have a default way, so I agree with you
20:27:10 <sgallagh> s/default/definitive/ IMHO
20:27:33 <sgallagh> dperpeet: So, one case we need to come back to: NFS
20:27:48 <sgallagh> As it stands, there is no existing API for managing NFS today.
20:28:12 <dperpeet> yup
20:28:17 <dperpeet> good candidate
20:28:40 <dperpeet> especially if the module supports "status"
20:29:11 <sgallagh> Well, that's part of the problem: it's actually hard to get NFS to tell you what it's sharing
20:29:37 <sgallagh> You can't just read the /etc/exports, because that's only accurate as of the moment the service starts. After that, you can edit it as often as you like until your reload/restart
20:29:41 <jds2001> sgallagh: we can use the existing tools, which are obviously inaccurate
20:29:54 <jds2001> but it is what exists :/
20:30:10 <jds2001> sgallagh: showmount -e
20:30:25 <sgallagh> jds2001: That doesn't really work in NFSv4
20:30:34 <dperpeet> well, there can be limits
20:30:36 <sgallagh> Because it will only show you the mounts available to the user identity you present
20:30:43 <dperpeet> to the accuracy... as long as we make that clear
20:30:58 <dperpeet> there doesn't have to be magically more information
20:31:05 <dperpeet> if something needs to change, then in the underlying tools
20:31:22 <jds2001> sgallagh: i havent much used NFSv4, but there should be some way to get the kernel's view of the world, no?
20:31:48 <sgallagh> dperpeet: I guess we could always indicate to the user that the modification time of /etc/exports was more recent than when the service started...
20:32:05 <sgallagh> jds2001: Ah, *should*. My favorite word...
20:32:05 <jds2001> sgallagh: i suspect that most people in the Real World(TM) don't use kerberized NFSv4 either.
20:32:32 <sgallagh> jds2001: Except that's a major part of what we're fixing here :)
20:32:42 <sgallagh> Our initial pass was meant to be Kerberized NFSv4-only
20:33:21 <sgallagh> /me doesn't really want to rehash that decision
20:33:56 <dperpeet> sgallagh, there is precedent for that
20:33:58 <jds2001> that's fine - so it's difficult/impossible to get real status.
20:34:27 <sgallagh> dperpeet: Sorry, precedent for what?
20:35:03 <dperpeet> sgallagh, indicate to the user that something may have changed (selinux enforce state can be changed after the next reboot for example)
20:35:12 <sgallagh> /me nods
20:35:23 <dperpeet> as long as we know that it's off, we don't necessarily need to know exactly what happened
20:35:28 <dperpeet> of course it would be preferable
20:35:55 <sgallagh> dperpeet: OK, so I guess the open question is: do we use an Ansible module to control the NFS state, or do we build a service that ansible (and Cockpit) will talk to that controls the NFS state?
20:36:24 <sgallagh> I'd prefer *not* doing the latter, mostly because there is already effort in place for an Ansible module that is OS-independent
20:36:32 <sgallagh> If we build a service, it will be rather NIH
20:36:37 <dperpeet> NIH?
20:36:45 <sgallagh> "Not Invented Here"
20:37:03 <sgallagh> A perjorative term for making our own thing when other solutions exist
20:37:29 <dperpeet> inserting extra layers shouldn't be done lightly
20:37:45 <dperpeet> if there is an ansible module to control the state, I don't see why we couldn't use that
20:37:52 <sgallagh> Right, if we insert extra layers, they shuold be as heavy as possible!
20:37:58 <sgallagh> Viva OpenLMI~! ;-)
20:37:59 <dperpeet> sgallagh, well put!
20:38:03 <vvaldez> heh
20:38:14 <dperpeet> let's invent our own config file format, just to make sure
20:39:14 <jds2001> dperpeet: it should be a binary config file!
20:39:16 <vvaldez> YACF?
20:39:32 <sgallagh> But seriously, is that where we're going to go? Stick with the ansible module as the implementation for Cockpit to use?
20:39:45 <dperpeet> well, if there is one, cockpit can use it
20:39:51 <sgallagh> (And with it, acknowledge that it means carrying an ansible client implementation on the machine)
20:39:54 <dperpeet> but I would like to be clear on what that module will offer
20:40:00 <dperpeet> to see if we can make it work in the ui
20:40:01 <sgallagh> Or else automatically downloading the ansible client on first use...
20:40:10 <sgallagh> (Yes, that's still my personal bugbear)
20:40:18 <dperpeet> I haven't forgotten :)
20:40:21 <jds2001> sgallagh: right, and the py2 stack that currently comes with :/
20:41:01 <dperpeet> ideally we would fix up nfs to provide everything we need
20:41:17 <sgallagh> dperpeet: Sorry, meaning what?
20:41:32 <dperpeet> nfs server: proper system service with a dbus interface :)
20:41:37 * nirik notes there has been a lot of work on py3 ansible, but yeah
20:41:59 <jds2001> nirik: thats why i used the word "currently" :)
20:42:11 <sgallagh> dperpeet: NFS is part of the kernel itself. The "services" are mainly support functions.
20:42:22 <dperpeet> yeah, they could be put into a service :)
20:42:27 <dperpeet> anyway, sidetracked
20:42:39 <sgallagh> dperpeet: See Ganesha. That's basically what it is.
20:42:43 <sgallagh> Also pNFS, IIRC
20:42:44 <smooge> YetAnotherXML format
20:42:52 <jds2001> userland NFS is a disaster :/
20:43:05 <sgallagh> But that's not useful, because it's not the implementation we actually ship
20:43:25 <sgallagh> jds2001: Whereas kernel NFS is merely a crisis.
20:44:16 <dperpeet> I think we should do the nfs ansible role as a proof as concept, like we said
20:44:33 <dperpeet> we can make it work and then we can always decide to do it differently for the next module
20:45:00 <sgallagh> /me agrees
20:45:18 <dperpeet> we should plan the "status" from the start
20:45:22 <sgallagh> yes
20:45:28 <dperpeet> but it doesn't have to be implemented in the first iteration
20:46:35 <sgallagh> Honestly, parsing /etc/exports[.d/] and simply alerting the user if the service start time is older than the modification times is probably sufficient.
20:46:41 <sgallagh> At least for a PoC
20:47:17 <dperpeet> and cockpit has the ability to watch files
20:47:26 <dperpeet> so that wouldn't require polling
20:47:42 <dperpeet> which makes me happy :)
20:47:58 <vvaldez> sgallagh: I agree, and we can certainly use different techniques to try and get a bigger picture as we iterate through it
20:48:13 <sgallagh> vvaldez++
20:48:13 <zodbot> sgallagh: Karma for vvaldez changed to 1 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:49:23 <sgallagh> dperpeet: So the biggest potential complaint I can think of is adding ansible as a dep.
20:49:55 <dperpeet> yeah, but that won't add the dependency for all of cockpit
20:49:58 <sgallagh> But you know my recommended solution for that already :)
20:50:03 <dperpeet> if cockpit-nfs needs ansible, so be it
20:50:23 <sgallagh> dperpeet: No, but since we'd ideally want to ship cockpit-nfs by default, it's functionally the same.
20:50:28 <sgallagh> (by default in Fedora Server, I mean)
20:50:48 <dperpeet> sgallagh, for the record, what's your recommended solution? =)
20:51:20 <sgallagh> dperpeet: lazy installation of needed packages. Don't install cockpit-nfs by default, but auto-install it the first time someone clicks on that tab.
20:51:46 <jds2001> sgallagh: no likey
20:51:50 <dperpeet> yes, I'm sure we'll tackle software installation some time :)
20:51:52 <sgallagh> and/or don't install ansible by default, but install it automatically the first time you need to effect a change with it.
20:51:56 <jds2001> sgallagh: what happens if that for some reason doesn't work?
20:52:10 <vvaldez> clippy pops up?
20:52:15 <sgallagh> /me snickers
20:52:29 <sgallagh> jds2001: Well, there's nothing saying you can't *opt* to install things ahead of time
20:52:33 <dperpeet> we'll get to that story sometime (not clippy)
20:52:43 <sgallagh> I'm just saying that if we want to be lean-and-mean out of the box, that's a good way to do it.
20:53:15 <vvaldez> sgallagh: I don’t know cockpit well enough, are there other lazy install components? I like this idea
20:53:16 <jds2001> it is, but if you're on a slow connection....
20:53:30 <jds2001> (3 days later)..."what was I going to do again?"
20:53:53 <dperpeet> vvaldez, jds2001 this is a long term feature wish that's not part of cockpit currently
20:54:05 <vvaldez> ack
20:54:25 <sgallagh> jds2001: I'm kind of working from the assumption here that if you're setting up NFS, you're not doing it over dial-up :)
20:54:39 <dperpeet> sgallagh, daring assumption!
20:54:47 <jds2001> why wouldnt you be?
20:54:59 <jds2001> you want to set up a fileserver at home or something
20:55:05 <vvaldez> jds2001: fair point, or a disconnected environment possibly
20:55:05 <sgallagh> jds2001: Sorry, I don't mean you as the web client
20:55:12 <dperpeet> anyway, I think we should make sure the scope and iterations of the ansible modules need to be written out a bit
20:55:23 <sgallagh> I mean that even in a disconnected environment, you're probably running a local fast mirror
20:55:39 <vvaldez> that should be true
20:55:40 <sgallagh> And you wouldn't be *serving* NFS over dialup.
20:55:59 <sgallagh> Or if you are, I'm willing to count you as the exception we don't optimize for )
20:56:01 <sgallagh> :)
20:57:09 <sgallagh> dperpeet: OK, so what's our next step?
20:57:26 <dperpeet> decide on what the ansible module should be able to do
20:57:38 <dperpeet> in the first iteration and eventually
20:57:51 <dperpeet> (design)
20:58:05 <dperpeet> then we want a rough module
20:58:10 <dperpeet> ansible that is
20:58:21 <dperpeet> and then we implement a cockpit ui for that
20:58:41 <dperpeet> these steps could be somewhat parallelized
20:58:48 <jds2001> we need a contract between ansible and cockpit at some point
20:59:29 <dperpeet> that's why we want to decide on the functionality first, so we know what to expect
20:59:34 <dperpeet> and can sync up on our needs
21:01:46 <sgallagh> ok
21:01:59 <sgallagh> So what is the very *first* of those steps?
21:02:26 <sgallagh> Requirements? I think we have those
21:02:48 <dperpeet> look at the design document and then start defining interfaces between cockpit and ansible
21:03:06 <sgallagh> ok
21:03:30 <sgallagh> jds2001: This is your baby: can you take that on?
21:03:53 <dperpeet> jds2001, and coordinate with me for the cockpit site
21:03:54 <dperpeet> side
21:04:04 <dperpeet> I'll get a designer onboard also
21:04:12 <dperpeet> for UX requirements
21:04:45 <sgallagh> OK, we are over time.
21:04:48 <jds2001> sure, sorry....
21:05:07 <sgallagh> Everything begins to come together, at least...
21:05:21 <sgallagh> Any last-minute thoughts?
21:05:31 <vvaldez> Make Fedora Great Again!
21:05:34 * vvaldez runs away
21:05:59 <smooge> none from me
21:06:06 <vvaldez> that was uncalled for, I have nother else
21:06:11 <sgallagh> /kick vvaldez
21:06:25 * vvaldez kicks himself
21:06:27 <sgallagh> Thanks for participating, folks
21:06:30 <sgallagh> #endmeeting