21:01:15 #startmeeting Server Working Group Weekly Meeting (2017-02-28) 21:01:15 Meeting started Tue Feb 28 21:01:15 2017 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:01:15 The meeting name has been set to 'server_working_group_weekly_meeting_(2017-02-28)' 21:01:15 #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf 21:01:15 Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez 21:01:15 #topic roll call 21:01:24 .hello kevin 21:01:25 nirik: kevin 'Kevin Fenzi' 21:01:28 .hello mjwolf 21:01:29 mjwolf: mjwolf 'Michael Wolf' 21:01:41 .hello mhayden 21:01:42 mhayden: mhayden 'Major Hayden' 21:01:52 .hello sgallagh 21:01:53 sgallagh: sgallagh 'Stephen Gallagher' 21:01:59 * nirik runs to get more coffee. 21:02:09 agh 21:02:12 .hello adamwill 21:02:13 adamw: adamwill 'Adam Williamson' 21:02:16 only i have to go run to the store. 21:02:29 mjwolf: btw we have totally not forgotten you and i'm gonna write you a mail this afternoon 21:02:45 adamw: Context? 21:03:01 openQA ppc worker host box 21:03:05 Gotcha 21:03:42 new domain controller role stuff looks fine to me 21:04:02 hello 21:04:02 adamw: Any opinion on the definition of "Linux Client" before you go? 21:04:26 sgallagh: ehhh, for testing purposes we can restrict the scope further down in the release criteria / test cases 21:04:31 so i don't mind it being general that high up 21:04:33 .hello jstanley 21:04:34 jds2001_: jstanley 'Jon Stanley' 21:04:39 adamw: WFM. Thanks 21:05:44 #topic Agenda 21:05:54 #info Agenda Item: Feedback on the Domain Controller Role second draft 21:05:55 #info Agenda Item: Cockpit and Ansible Status 21:05:57 sgallagh: i expect my Alpine Linux to work! :D 21:06:08 We may or may not be able to cover the second one without dperpeet 21:07:15 Other topics this week? 21:07:58 I can at least give an overview of what happened at DevConf and why it hasn't seen obvious forward momentum lately. 21:08:08 #topic Feedback on the Domain Controller Role second draft 21:08:24 #link https://github.com/libre-server/proposals/tree/master/Domain%20Controller 21:08:28 * nirik sent feedback to the list... for once. ;) 21:08:34 nirik: Much appreciated. 21:09:21 I tried to capture everything from the discussion on Feb 1. 21:11:16 the milestones look reasonable (logically, not time-wise) ;) 21:11:41 Yeah, they're written on water right now 21:11:48 ooh 21:12:11 * smooge waits for someone to throw a rock into the pool 21:12:30 so what happened at DevConf? 21:13:07 smooge: That's on the second topic. Please wait. (Also, let's hope dperpeet shows up late) 21:13:27 Just got some feedback from Simo. 21:13:42 He wants me to fix up that there are two lines that basically say the same thing in different words. 21:13:46 * jds2001 wanted to review but didn't last night :( 21:13:52 Otherwise, it looks good from the IPA perspective 21:14:23 oh sorry 21:14:32 sgallagh: would having AD installed *after* FreeIPA be something worth trying? 21:14:52 i.e. AD must install into an existing FreeIPA forest as a subdomain. 21:15:18 * jds2001 isn't sure if that's even possible or how much work it might require. 21:15:47 jds2001: That's actually captured in the use case section 21:16:04 ahh, i was looking at the milestones 21:16:14 Except that we don't treat FreeIPA as the master, because of technical reasons. 21:16:28 FreeIPA always ends up merged into the AD domain, not vice-versa. 21:16:39 I'm not prepared to try to make that a requirement. 21:17:15 .hello linuxmodder 21:17:16 linuxmodder: linuxmodder 'Corey W Sheldon' 21:17:25 Greetings, linuxmodder 21:17:29 o/ 21:17:33 .hello vvaldez 21:17:34 vvaldez: vvaldez 'Vinny Valdez' 21:17:52 sgallagh: makes sense. 21:17:57 * vvaldez shuffles in slowly 21:18:02 Nice to see you, vvaldez 21:18:23 sgallagh: apologies, back late from a dr. appointment 21:18:29 Not a problem. 21:18:45 We were just discussing https://github.com/libre-server/proposals/blob/master/Domain%20Controller/ 21:19:10 Do you have anything to add? If not, we can consider this approved and I'll migrate it to the Wiki later this week. 21:20:06 sgallagh: no looks good 21:20:22 +1 from me 21:21:01 Proposed: Server SIG accepts the Domain Controller Role proposal 21:21:06 +1 21:21:20 +1 21:21:22 +1 21:21:41 +1 21:21:59 +1 21:22:05 +1 21:22:54 #agreed Server SIG accepts the Domain Controller Role proposal (+6, 0, -0) 21:22:57 +1 21:23:01 #undo 21:23:01 Removing item from minutes: AGREED by sgallagh at 21:22:54 : Server SIG accepts the Domain Controller Role proposal (+6, 0, -0) 21:23:05 #agreed Server SIG accepts the Domain Controller Role proposal (+7, 0, -0) 21:23:11 Thanks, smooge ;-) 21:23:23 sorry kid came home and needed to talk 21:23:29 No problem 21:23:40 #topic Cockpit and Ansible Status 21:24:09 So, I wish dperpeet was here to relate the details, but the short version is that Cockpit upstream decided that they don't want to talk Ansible directly. 21:24:32 Mostly citing the difficulties with monitoring 21:24:46 oh those ansible people are nice 21:24:48 bmonitoring? 21:24:49 ? 21:25:37 jds2001: Cockpit prefers to always be able to accurately retrieve the current state of the machine 21:25:52 Ansible's job is to force the machine into a particular state and it doesn't much care what it looks like beforehand 21:25:55 So there's a mismatch there 21:25:56 * smooge snorts at that conundrum 21:26:50 sgallagh: So cockpit isn't going to generate playbooks anymore as a feature? 21:27:06 geppetto: That part is probably still available. 21:27:08 but I ain't writing it so ok 21:27:35 Unclear regarding the ability to load and execute a playbook though. 21:28:02 So there are several moving parts here. Let me try to enumerate them 21:28:06 sgallagh: would they be amenable to a plugin to do that? 21:28:13 I don’t want to get into impelmentation details, but I’d think some sord of python module to talk to cockpit and update state is feasibly possible? 21:28:25 jds2001: I doubt they'd refuse a patch, provided that the UI was discussed with andreasn ahead of time 21:28:26 ok … so they'll let you tweak stuff and generate a playbook but won't add one button to the UI to just run it? 21:28:39 vvaldez: Cockpit is stateless. 21:28:47 All its information is retrieved from OS APIs 21:29:05 ok, becomes more complex 21:30:37 geppetto: Again, I don't have an official answer on that part. 21:31:03 But running playbooks requires a lot more than just dumping some YAML out to you that you can run for yourself. 21:31:10 sgallagh, how can it be stateless and keep knowing the current state of the machine? [Talk on this offline?] 21:31:12 So I suspect that it will not be in v1 at least 21:31:37 smooge: Most of the APIs it talks to allow registering for change updates. 21:31:39 sgallagh: in what way? 21:31:56 ansible-playbook localhost 21:32:07 possibly with extra_vars which becomes more complex. 21:32:09 jds2001: Well, if nothing else you need to install the ansible package on your local machine and all its (python2) dependencies 21:32:14 from a UI perspective. 21:32:34 The UI perspective is problably the least of it 21:34:01 Also, they are rightfully wary of having the ansible client tools installed on the machine it's managing. That's kind of odd 21:34:37 I've been pestering them to add on-demand package installation for a while now, so at least we could avoid installing ansible and its deps until the first time someone tried to hit such a button. 21:34:58 (which would also benefit the rest of Cockpit's footprint) 21:35:23 ansible doesn't really have that many deps tho... 21:35:58 nirik: It has the python 2 interpreter, which is not small 21:36:13 it can run with python3 now 21:36:21 for now yeah. (look for a python3-ansible subpackage soon coming to rawhide) 21:36:39 (at least on the control node, the remote side is still subject to testing by people so we can fix bugs) 21:37:13 * nirik nods. 21:37:18 misc: we're talking about doing both on the same host. 21:37:22 Anyway, I think we're getting a little into the weeds. Having Cockpit actually execute a playbook isn't necessarily in scope for this effort. 21:37:32 * vvaldez cries 21:37:35 misc: it may be possible to limit the modules we use, but that might not be practical either. 21:37:37 vvaldez: ? 21:37:53 was hoping to have that capabiliity is all :) 21:38:16 * jds2001 cries as well, but understands. 21:38:40 it would make things *so much* easier. 21:38:44 jds2001: I think the most used module would work. Openshift-ansible deploy on python 3, so that should cover a lot 21:38:49 vvaldez, jds2001: Well, let me redirect the question back to you: why would having the ability to execute an ansible playbook from within Cockpit be valuable 21:39:14 essentially to gain the UI convenience, rather than needing Tower to do the same 21:40:03 vvaldez: I'm not sure we want to go anywhere near looking like we are an alternative to Tower. That's probably a good way to annoy the Ansible folks, rather than get them to help us. 21:40:14 sgallagh: it's a one stop shop - generate teh config and apply it. 21:40:25 jds2001: Ah, but I didn't say it wouldn't get applied. 21:40:29 I get that 21:40:32 I said it wouldn't use Ansible to do it 21:40:44 sgallagh: the swivel-chair of lets go generate teh config over here. and then you have to go do this other thing to make it effective. 21:40:45 That was why I was going to try to describe the moving parts before 21:41:27 sgallagh: im listening.... :) 21:41:28 What is happening is that Cockpit upstream is going to coordinate with the Ansible people to make the underlying APIs that the Ansible Modules consume available for both purposes. 21:41:55 (This is one of those times I wish I had a whiteboard for these meetings) 21:42:20 On the ansible side, we have (from top to bottom): Playbooks -> roles -> modules -> system APIs 21:42:21 * jds2001 sees potential problems with different outcomes from differnt methods of execution 21:42:28 of purportedly the same thing. 21:42:40 On the Cockpit side we have Web UI -> system APIs. 21:43:12 Cockpit will be interacting with the system APIs in the same way that Ansible will be. 21:43:18 sgallagh, Jitsi is always an option :) j/s 21:44:01 sgallagh: are we sure of that? Who's going to validate that? 21:44:15 and when things change, there are now two places to change. 21:44:21 I should mention that "system APIs" here are going to be wrapping whatever is actually happening on the system. So things that normally require file-editing will get wrapped, etc. 21:44:24 leads to out of sync nightmares 21:44:55 jds2001: I raised that same point myself and didn't get a satisfactory answer, unfortunately. 21:45:13 (We're hitting the limits of what I can say about this without the Cockpit folks present) 21:46:10 To be clear, I'm not entirely on-board with this, but ultimately I don't have any authority to direct either team. 21:46:39 So I'm reporting the current state and attempting to represent their position as best I can recall from DevConf. 21:48:32 jds2001, vvaldez: If you also have strong opinions on the subject, I suggest that we should arrange to meet with Stef, Marius and Dominik 21:48:48 sure, and without dperpeet obviously we're slightly at a disadvantage :) 21:49:05 I do think a further discussion would be good 21:49:34 * jds2001 too 21:49:39 Cockpit has a weekly public meeting on Mondays at 9am EST in #cockpit. 21:49:48 Should we plan to crash that next week? 21:49:57 9AM EST? Blergh.... 21:50:01 1400 UTC 21:50:03 +1 on blergh ... 21:50:08 just out of curiosity did the cockpit team offer an alternative or did they simply stick with it wont work here? 21:50:14 and actually I’ll be heading to the airport unfortunately 21:50:27 on my way to westford that day 21:51:10 mjwolf: An alternative to what? 21:51:24 if we cant use cockpit what should be used 21:51:40 so should we crash it a week from Monday? 21:51:47 Oh, I think I failed to communicate that part. 21:52:10 They still want to do the roles 21:52:15 They still want to provide that UI. 21:52:27 They just don't want to use Ansible as the underlying interface to execute it. 21:53:14 They're also still willing to dump out an ansible playbook that one could use manually elsewhere, but you don't have to use it. 21:53:23 Is that more clear? 21:53:57 sgallagh: yes it is! 21:54:01 * vvaldez stops crying as much 21:54:11 the position is clear but I must be missing something. that doesnt make sense to me. anything to replace ansible would still have the state vs stateless problem wouldnt it? 21:54:14 OK, sorry if I failed to mention that. 21:54:22 * jds2001 got all of that from sgallagh's initial description 21:54:31 but there's still teh maintenance nightmare 21:54:38 * nirik is still confused. you do roles, you have a ui, you can spit out the playbook, but... you cannot run it? 21:54:58 nirik: you implement $OTHER_WAY in Cockpit. 21:55:31 nirik: The ansible playbook is just a convenience feature, not part of the actual execution process. 21:55:32 and make sure that's the same as how Ansible would implement. 21:55:53 that "make sure" seems... difficult to me. 21:55:58 which seems impossible, but...... 21:56:00 jds2001: Like I said, the idea is that the two teams are building libraries to actually do the work and both will consume them 21:56:35 This is definitely the part I'm not communicating well 21:56:58 In this scenario, Ansible is agreeing not to do an end-run around things (like slapping files directly onto the FS). 21:57:27 They will *both* collaborate on a system API (implementation TBD) that will do that part of the interaction. 21:57:47 So the Ansible *modules* will be designed to tell these interfaces what to do, and Cockpit will also use those same interfaces. 21:58:45 We should perhaps stop talking about the part where Cockpit can generate a playbook for later use, because that's sort of a side-story. 21:59:12 /me wonders if everyone is confused or if it's just him 21:59:55 * jds2001 isnt confused as such, but just seems like a bit of extra work for dubious value. 22:00:24 * vvaldez doesn’t know enough about cockpit internals to know if I’m confused or not 22:00:53 vvaldez: i dont *think* that these internals exist as yet. 22:01:09 jds2001: The value to cockpit would be that these APIs are going to be designed to properly monitor the state of these roles and be able to report both the current state and notify Cockpit on changes. 22:01:15 Which is something that they can't do with Ansible 22:02:00 Anyway, I'll restate that I'm attempting to argue on behalf of a position with which I don't totally agree, so that's probably not helping; 22:02:40 * jds2001 thinks we should take this to the Cockpit meeting on 3/13 when vvaldez would be available. 22:02:48 works for me 22:03:08 will have to cut it short on walking dead party the night before, that’s ok 22:03:09 * jds2001 marks his calendar. 22:04:50 OK, thanks 22:05:00 We are now a bit over time, so shall we call it a day? 22:05:08 +1 22:05:21 yes. 22:05:23 #action vvaldez, jds2001 and sgallagh to attend Cockpit meeting on 3/13 and discuss role developments and Ansible 22:05:27 we can talk about devconf next time 22:05:39 smooge: Sorry, that *was* the Devconf stuff 22:05:56 is soooo confused. ok :) 22:06:14 That was the output of the half-day Cockpit hackfest I attended where we beat this topic to death then ran away from the zombie 22:06:25 yeah. I see where my mind lost track 22:06:41 i'm good lets call this 22:06:47 Must be nice, mine jumped the tracks so far back that I can't even see them anymore 22:07:17 Thanks for coming folks. Good discussion as well. 22:07:21 #endmeeting