14:03:12 <mvollmer> #startmeeting meeting
14:03:12 <zodbot> Meeting started Mon Mar 13 14:03:12 2017 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:12 <zodbot> The meeting name has been set to 'meeting'
14:03:19 <andreasn> ah, thanks!
14:03:22 <mvollmer> andreasn, please go ahead
14:03:28 <github> [cockpit] stefwalter opened pull request #6091: test: Fix timeout in check-openshift rolebinding check (master...rolebinding-test-wait) https://git.io/vy6Q2
14:03:30 <mvollmer> .hello mvo
14:03:31 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:03:32 <andreasn> then I'll sit back and relax? :)
14:03:34 <garrett> .hello garrett
14:03:35 <zodbot> garrett: garrett 'Garrett LeSage' <garrett@lesage.us>
14:03:35 <andreasn> .hello andreasn
14:03:35 <larsu> .hello larsu
14:03:37 * stefw won't make it ... unfortunately
14:03:37 <sgallagh> .hello sgallagh
14:03:37 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:03:37 <pitti> .hello martinpitt
14:03:40 <zodbot> larsu: larsu 'Lars Karlitski' <lars@karlitski.net>
14:03:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:03:46 <zodbot> pitti: martinpitt 'Martin Pitt' <martin@piware.de>
14:03:50 <mvollmer> andreasn, ok, I'll lead
14:03:52 <dperpeet> .hello dperpeet
14:03:53 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:03:59 <andreasn> thanks! I'll do two in a row
14:04:04 <andreasn> next time
14:04:07 <sgallagh> jds2001: Around?
14:05:11 * jds2001 is here
14:05:23 <jds2001> sorry im late :/
14:05:39 <jds2001> .hello jstanley
14:05:40 <zodbot> jds2001: jstanley 'Jon Stanley' <jonstanley@gmail.com>
14:05:40 <mvollmer> heh, not really! :)
14:05:48 <mvollmer> #topic Agenda
14:07:02 <mvollmer> * system mgmt roles, ansible, nfs?
14:08:52 <mvollmer> dperpeet, is that about ight?
14:08:55 <dperpeet> yes
14:09:01 <mvollmer> okay, anything else?
14:09:02 <dperpeet> * new switcher design
14:09:25 <dperpeet> * translations
14:10:12 <mvollmer> alright, let's get started
14:10:22 <mvollmer> #topic system mgmt roles, ansible, nfs
14:11:13 <sgallagh> How do we want to start?
14:11:28 <sgallagh> Should we have mvollmer summarize the decision process he's followed thus far?
14:11:56 <sgallagh> /me attempted to do this second-hand during the Server SIG meetings, but probably best to hear it straight from him
14:12:04 <mvollmer> ohh, well.
14:12:13 <dperpeet> trello card: https://trello.com/c/N9X1xDT4/433-epic-nfs-server-configuration
14:12:19 <mvollmer> I am just listening and try to write the code that people expect to see
14:12:26 <dperpeet> feature page: https://github.com/cockpit-project/cockpit/wiki/Feature:-NFS-Server
14:13:02 <mvollmer> i can summarize what I think I have heard from people
14:13:32 <mvollmer> i am hoping to gain a lot of new understanding in this meeting, actually
14:13:51 <sgallagh> ok
14:14:09 <dperpeet> mvollmer, I think a good way of describing this is how you came to make the choices in https://github.com/cockpit-project/cockpit/pull/5745
14:14:24 <dperpeet> and why you think we shouldn't implement it that way anymore
14:14:37 <mvollmer> alright
14:15:37 <mvollmer> give me a few seconds
14:16:19 <sgallagh> And if anyone else has time to spare, I could use some more of it too ;-)
14:16:28 <mvollmer> so we have two options, in the big picture
14:17:32 <mvollmer> Cockpit uses the sysmgmt APIs that are defined using Ansible as a framework
14:18:01 <mvollmer> Or Cockpit uses the sysmgmt APIs that are used by the sysmgmt roles
14:18:22 <mvollmer> for example, Cockpit can either call a Ansible playbook to configure the network
14:18:29 <mvollmer> Or it can talk to NetworkManager
14:19:06 <jds2001> there are definite advantages to each.
14:19:11 <mvollmer> This is similar to how in the old days, we had to decide between talking to OpenLMI APIs
14:19:16 <jds2001> and disadvantages :)
14:19:18 <mvollmer> or to talk to the system APIs directly
14:20:07 <jds2001> are you concerned that Ansible meets the same fate of OpenLMI?
14:20:14 <mvollmer> with OpenLMI, we didn't see the advantage, and we went directly with the system APIs
14:21:15 <mvollmer> OpenLMI would just be one more level of indirection, and it wasn't totally mature at the point
14:21:16 <sgallagh> Ansible is independently successful, so that part of it is irrelevant
14:21:51 <larsu> but ansible doesn't define an API
14:21:57 <mvollmer> now with ansible, I would expect a typical sysmgmt role to be non-trivial and have some real value
14:22:08 <jds2001> Ansible *is* an API of sorts.
14:22:15 <mvollmer> for example, there isn't a nice sys api for configuring NFS, I think
14:22:26 <mvollmer> and a ansible role would give us that API
14:22:32 <sgallagh> ack
14:23:00 <sgallagh> larsu: Ansible "roles" are an API. Ansible "playbooks" are a client of that API
14:23:23 <mvollmer> however, if a sys api on the level of NetworkManager od UDisks would exist, it would be better than the sysmgmt role.
14:23:40 <sgallagh> Well, "better" is a loaded term
14:23:47 <mvollmer> it would have a natural way to expose the current state and provide notifications
14:24:00 <sgallagh> It would certainly be more convenient for the way Cockpit likes to interact with things
14:24:01 <larsu> sgallagh: right. my point was that ansible doesn't strive to define an api in the way that openlmi did
14:24:14 <jds2001> Ansible is all about implemeting a desired end state.
14:24:28 <jds2001> what the current state is is somewhat irrelevant.
14:24:39 <pitti> right, and cockpit is kind of the other way around
14:24:51 <larsu> indeed
14:24:57 <pitti> e. g. udisks represents current state but has no policy
14:25:04 <pitti> NM has policy through configuration, but still reacts to current state
14:25:14 <pitti> and cockpit should reflect that
14:25:39 <mvollmer> network bonds are a good example, maybe
14:25:50 <pitti> it almost seems to me that it would be a better fit to use cockpit's bridge API to implement ansible than using ansible to implement cockpit
14:25:52 <mvollmer> for bonds, NM is pretty one-way
14:26:06 <pitti> (not that ansible would actually want to do that, but illustrating the layering)
14:26:08 <mvollmer> and we should really fix that and have it report the state of bonds etc
14:26:22 <pitti> right, but IMHO that's a bug, not by design
14:26:31 <mvollmer> exactly
14:26:45 <mvollmer> with ansible, it would be by design, I guess
14:26:56 <pitti> with sysfs/udev and the CLI tools it's perfectly possible to get notified to bond changes and get current state
14:27:05 <sgallagh> Well, Ansible *can* poll for state.
14:27:08 <jds2001> you can gather state with ansible.
14:27:12 <pitti> yeah, ansible has a different goal
14:27:15 <jds2001> sgallagh: sniped me :)
14:27:15 <sgallagh> But it has no persistent daemon running to notify you
14:27:46 <mvollmer> we can combine ansible with something else
14:28:03 <pitti> cockpit is for interactive/reactive administration, ansible (similar to cloud-init or puppet etc.) for noninteractive creation of "cattle" type machines, or did I misunderstand this?
14:28:10 <mvollmer> for NFS, we could use the nfs role to configure things
14:28:18 <mvollmer> and then use something else to monitor the state
14:28:23 <jds2001> pitti: it can be used for the latter.
14:28:29 <larsu> pitti: you understood perfectly. Ansible is a very bad match for a UI like cockpit
14:28:42 <jds2001> just as im sure you can somehow use cockpit in ways it wasn't designed for to do that.
14:28:47 <jds2001> but it can really do either.
14:28:49 <pitti> jds2001: you mean cockpit can be used for "cattle" targets?
14:29:05 <pitti> oh, I suppose you meant "former"
14:29:09 <jds2001> pitti: im sure somehow, someone could find a way :)
14:29:32 <jds2001> but ansible can do t he latter, it can also do the former.
14:29:36 <pitti> jds2001: yeah, as I said you can use the cockpit API to implement a policy (but that's the opposite of the proposal here, I think)
14:30:15 <petervo> pitti, it is definitely a goal for cockpit to be used on cattle targets, mostly for trouble shooting
14:30:36 <jds2001> if you look at the (proprietary) Ansible Tower, it has the concept of "surveys"
14:30:54 <mvollmer> so, the carrot that would pull me is that with the ansible sysmgmt roles, we get more experts to contribute.
14:31:06 <jds2001> this is used for reactive administration, pulling ansible firmly into that realm.
14:31:07 <sgallagh> Well, with my Red Hat firmly perched on my noggin: There's definitely a goal to unify offerings at Red Hat (this is general knowledge). Ansible has effectively already established itself as the closest thing we have to an administration UI in Fedora/RHEL.
14:31:20 <mvollmer> they would design the best practices and robust implementation, and we would just use that
14:31:23 <sgallagh> That won't soon change, and it would be best if we were not working at cross purposes
14:31:42 <mvollmer> sprinkling some monitoring stuff on top is easier
14:31:46 <jds2001> mvollmer: i think that's the point.
14:31:55 <jds2001> mvollmer: (getting more experts to contribute)
14:32:11 <sgallagh> And that *is happening* right now (re: best practices and robust implementation)
14:32:32 <mvollmer> pardon the bluntness, but there is nothing per-se in ansible that would help Cockpit directly
14:32:36 <dperpeet> I think at this point we should think about whether having reliable feedback from a process (e.g. applying a playbook via ansible) is something Cockpit really *needs* to have, or if it would just be nice
14:32:38 <jds2001> mvollmer: for instance, I can write an Ansible role/
14:32:41 <pitti> petervo: yes, I think jds2001 meant "former", I was just trying to parse it the wrong way :)
14:32:42 <sgallagh> mvollmer: Well, that's not entirely true
14:32:48 <jds2001> you're not going to find me writing C code :)
14:32:52 <sgallagh> But I'll grant you it's not a strong argument
14:32:59 <jds2001> (or rather, you wouldnt want that which i wrote :D)
14:33:09 <sgallagh> For example, Ansible is really the closest thing we have to a reasonable API for managing Samba
14:33:36 <mvollmer> because someone has written the code for Samba
14:33:38 <sgallagh> Because it relies on editing of a largely-incomprehensible text file to manage.
14:34:52 <sgallagh> mvollmer: I think the biggest advantage to using Ansible is the wealth of external contributors it already has, which provides some assurance about its maintenance.
14:35:03 <dperpeet> andreasn, what do you think about this from a user's perspective?
14:35:18 <sgallagh> Add to that the fact that numerous things we want to do have no presently-existing traditional API.
14:35:35 <sgallagh> dperpeet: Well, ideally this is a transport layer that the user wouldn't see.
14:35:38 <mvollmer> you mean the ansible python code?  I am not worried about it going away.
14:35:38 <pitti> ^ that is certainly a big bonus point
14:35:41 <sgallagh> But obviously the feedback question is important
14:35:51 <andreasn> so I feel focusing on the roles, such as NFS, Samba, IPA or whatever is the most critical stuff
14:36:13 <dperpeet> sgallagh, I think in this case it could be important
14:36:19 <andreasn> using Ansible to run that and ALSO networking are two different things
14:36:23 <pitti> TBH I see very little reason to replace our NM backend with an ansible role backend, but for managing complex config files for things which are not hw dependent and thus also don't have hotplugging/enumeration capabilities, such as samba, it makes much more sense
14:36:33 <jds2001> i think that using Ansible as that backend is a force multiplier in the development of those roles.
14:36:42 <dperpeet> if we use something under the hood that doesn't provide the same level of feedback users experience in other parts of Cockpit, we have to make sure that still works in the UI
14:37:04 <larsu> yeah, this is the main problem: we'd still need to connect to the dbus APIs
14:37:05 <sgallagh> pitti: To be clear: I am not personally making *any* suggestion that we replace existing work with an Ansible backend
14:37:18 <larsu> because we want change notifications and stuff
14:37:20 <dperpeet> pitti, I think we're talking about taking specific playbooks
14:37:25 <pitti> sgallagh: completely understood; I was just thinking aloud really, to make sure we're all on the same page
14:37:27 <larsu> but now we talk to the same thing in two different ways?!
14:37:31 <dperpeet> to put the system into a desired state -> a specific role
14:37:33 <sgallagh> pitti: Never a bad idea
14:37:54 <pitti> sgallagh: (I don't pretend to have a deep understanding of ansible)
14:38:00 <sgallagh> Neither do I :)
14:38:26 <jds2001> larsu: not advocating for that. That's what I'd like to *avoid* is that maintenance nightmare.
14:38:54 <larsu> jds2001: right, but how?
14:39:10 <pitti> it generally appears to me that ansible is much like cloud-init or puppet (set a policy, and roll it out), while cockpit is much more like gnome-control-center or nm-applet (show/reflect hw/state changes and interactively administrate)
14:39:41 <pitti> so using one to implement the other seems a bit tricky as they aren't really meant for doing that; but reusing some of its knowledge certainly sounds interesting
14:39:45 <mvollmer> let's look at an example, maybe
14:40:08 <mvollmer> exporting folders (nfs config), and the seeing how many people have them mounted
14:40:14 <mvollmer> (is that even possible)?
14:40:33 <mvollmer> andreasn, I think you hd that in your mockup, right?
14:40:33 <sgallagh> The first half is, the second half is not (really)
14:40:35 <jds2001> mvollmer: there are commands that can do that
14:40:35 <pitti> technically the nfs kernel server should know (not sure how to display it though)
14:40:47 <jds2001> mvollmer: not toally accurate though
14:40:51 <sgallagh> IIRC, you can only see how many separate clients are connected to NFS *at all*, not to any specific share
14:40:56 <mvollmer> let's pretend it's possible
14:41:10 <sgallagh> And you can't differentiate without effort if they are coming from different sources or multiple connections from the same machine
14:41:12 <mvollmer> how would ansible help with getting that number into the UI?
14:41:14 <andreasn> if seeing who has something mounted is not possible we can cut that
14:41:25 <jds2001> mvollmer: easily
14:41:41 <jds2001> it can return such a number to you, if someone expert enough knows how to generate it.
14:41:53 <andreasn> it's something that OSX server has, and it helps with deciding to turn off the thing right now or not. But it can be scaled back to not do that
14:41:54 <pitti> yeah, it's fuzzy -- NFS is (mostly) stateless over UDP, so you don't necessarily have persistent open connections
14:42:19 <mvollmer> jds2001, and we have to poll, right?
14:42:20 <andreasn> oh, and I think I cut that out of the mockups actually
14:42:26 <sgallagh> andreasn: FWIW, I *think* Ganesha can also do this, but we don't use Ganesha as our NFS server. We use the kernel-provided one
14:42:28 <jds2001> mvollmer: yes
14:42:39 <mvollmer> jds2001, yeah, we would need to poll in any case, I guess
14:42:49 <andreasn> so ignore the whole "what users are connected?" part
14:43:00 <mvollmer> unless the kernel nfs server gets a varlink API that exposes this. :-)
14:43:36 <andreasn> so lets focus on the other stuff. Can we do that with Ansible?
14:43:37 <mvollmer> jds2001, what about just polling without trying to make any changes? possible?
14:43:47 <sgallagh> andreasn: Which other stuff?
14:43:53 <andreasn> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/roles/nfs-server.png
14:43:56 <sgallagh> mvollmer: Yes, possible
14:44:05 <mvollmer> okay
14:44:28 <mvollmer> jds2001, did you see the current PoC in Cockpit?
14:44:37 <larsu> sgallagh: how would cockpit be notified about mounts changing?
14:44:42 <jds2001> mvollmer: no :(
14:44:55 <mvollmer> jds2001, here: https://github.com/cockpit-project/cockpit/pull/5745
14:45:31 <sgallagh> larsu: That's actually a more complicated question than you might realize, since there's no state in kNFS.
14:45:37 <sgallagh> larsu: But short answer is "polling"
14:45:42 <mvollmer> one wart is that once a playbook fails, the system is in a "something went wrong, ahhhh" state
14:45:42 <pitti> is ansible just writing /etc/exports, or adding the exports dynamicaly (exportfs)? but in either way we can watch /etc/exports and /var/lib/nfs/etab
14:46:01 <larsu> sgallagh: no, I mean the exports from this machine. Right now we have an inotify on /etc/exports
14:46:43 <pitti> larsu: OOI: "we have" == where?
14:46:50 <sgallagh> larsu: That actually only tells you when the file changes, which isn't the same as the actual export changing
14:47:05 <sgallagh> I can edit it, save it, etc. for hours before I tell the kNFS server to read it
14:47:14 <larsu> pitti: sorry, I think this is only stef's demo thing that he uses at conferences, not a production module
14:47:24 <mvollmer> sgallagh, jds2001, are there any requirements on a sysmgmt role, like "either succeeds, or doesn't change anything"?
14:47:25 <dperpeet> maybe it makes sense to separate the user stories: 1) just apply one role, only care about success 2) interactively change multiple settings depending on feedback 3) monitoring a system
14:47:58 <dperpeet> cockpit does 2 and 3 currently
14:48:00 <sgallagh> mvollmer: Good question.
14:48:29 <dperpeet> with cockpit using ansible 1 is good (except for the mentioned case where something breaks)
14:48:32 <sgallagh> I don't think we actually stated any requirements at that level up to now.
14:48:51 <sgallagh> It's generally been "if you provide valid input, the deployment must succeed".
14:48:59 <sgallagh> But we kind of handwaved how to deal with bad input
14:49:31 <mvollmer> sgallagh, in any case, Cockpit will consume the roles one by one, and we can look at each one very closely to see how well it works for us, and try to improve it if necessary
14:49:35 <pitti> what happens with good input and it still fails? (hw fault, file system errors, timeouts, etc)?
14:49:36 <larsu> sgallagh: so? My point that ansible won't help here still stands. And it's not designed to do something like this at all
14:50:10 <sgallagh> larsu: I think you mean "won't help specifically with change notification", yes?
14:50:16 <larsu> yes
14:50:21 <sgallagh> I agree
14:50:27 <larsu> just trying to apply this to the example at hand
14:50:31 <pitti> "must succeed" works in a cloud or container environment when you can just throw away the instance and retry, but "must succeeds" is an inachievably strong guarantee :)
14:51:10 <sgallagh> pitti: Well, in rolekit I had it written so that it saved the state and restored it, but that was mostly me being picky and not a written requirement.
14:51:16 <sgallagh> Probably it should be, of course
14:51:44 <sgallagh> I also think we may be overthinking the change notification situation when dealing with NFS
14:51:55 <sgallagh> Changes to NFS configuration are generally very rare
14:52:18 <sgallagh> On the order of weeks, months or even years between modifications.
14:52:22 <pitti> yeah, and we can probably deal with that through inotify (etab/exports) and nfs-kernel-server systemd unit watching
14:52:28 <sgallagh> jds2001: (Is that a fair statement?)
14:52:53 <jds2001> sgallagh: yeah i think so
14:53:01 <pitti> (although that kind of moots the point of this -- the change notification is the hard part, adding a new export is rather simple)
14:53:17 <sgallagh> pitti: The point of what?
14:53:24 <mvollmer> let me try to clarify: The PoC will detect changes to the configuration (via inotify on the playbook)
14:53:29 <pitti> of using an ansible role as an implementation backend
14:54:04 <sgallagh> pitti: You still have to manipulate the exports file properly, which Ansible already has a role for.
14:54:33 <mvollmer> here is another point: the sysmgmt roles will be lowest common denominator across many OSes, right?
14:54:58 <mvollmer> while Cockpit wants to offer the best of a specific OS
14:55:10 <sgallagh> mvollmer: sorry, I'm not sure what you refer to when you say "symgmt roles" in that context.
14:55:28 <mvollmer> let's say RHEL 8 gets a super new feature re NFS
14:55:29 <jds2001> Ansible cna work on many OSes yes
14:55:38 <pitti> well, writing a file is easy, regardless of whether it's exports.d/ or yaml; reading/interpreting it is the hard part
14:55:40 <jds2001> mvollmer: what if it does?
14:55:46 <mvollmer> will the ansible role expose that feature although it's not available on rhel 7?
14:55:56 <jds2001> mvollmer: then we write a new thing for $super_new_feature :)
14:56:03 <jds2001> mvollmer: yes.
14:56:08 <sgallagh> mvollmer: Does "sysmgmt roles" == "ansible roles" to you?
14:56:13 <sgallagh> I just want to speak with a common language
14:56:14 <mvollmer> i guess
14:56:18 <andreasn> five minutes left of this meeting
14:56:22 <mvollmer> yep
14:56:22 <jds2001> mvollmer: ansible roles can check the version of a target, etc.
14:56:23 <pitti> the advantage of ansible is that it uses yaml across multiple different use cases (say, NFS or samba), thus it's easier to interface with several different scenarios
14:56:44 <jds2001> mvollmer: and do different things based on that.
14:57:18 <jds2001> so if $super_new_feature becomes available in RHEL 8, we just write that feature in, and only use it there.
14:57:21 <mvollmer> yeah, impossible is nothing
14:57:46 <mvollmer> jds2001, but will it really be done?
14:58:01 <jds2001> mvollmer: it's pretty routinely done, I think.
14:58:05 <mvollmer> aren't the ansible roles all about "reaching back in time"?
14:58:30 <sgallagh> mvollmer: It may depend on the feature, but I do have answers :)
14:58:39 <mvollmer> but yeah, i guess it would be stupid not to expose new features...
14:58:56 <sgallagh> If the feature is possible to be implemented without requiring new information from the user, it will just be done under the hood
14:59:31 <sgallagh> If the feature requires new information, a new option will be available in the ansible script. If used against an older version, the new field will be ignored and the lowest-common-denominator implementation will be used.
14:59:49 <andreasn> gotta dive out of the meeting. Standup time
15:00:07 <jds2001> same here, different standup :)
15:00:32 <mvollmer> alright, that saves me from bringing this to a stop. :)
15:01:17 <mvollmer> dperpeet, do you want to quickly say something about your topics?
15:01:27 <dperpeet> sure
15:01:42 <mvollmer> #topic new switcher design
15:02:10 <dperpeet> this is just a heads up
15:02:15 <dperpeet> https://github.com/cockpit-project/cockpit/pull/6082
15:02:25 <dperpeet> implements the first part of https://github.com/cockpit-project/cockpit/wiki/Feature:-Task-Switcher
15:02:32 <dperpeet> and also finally makes the sidebar menu scrollable
15:03:12 <larsu> neat!
15:03:20 <dperpeet> I think it looks great
15:03:27 <dperpeet> thanks stefw and garrett
15:04:12 <mvollmer> nice
15:04:14 <mvollmer> next?
15:04:22 <dperpeet> yup
15:04:26 <mvollmer> #topic translations
15:04:58 <dperpeet> With release 134 translations are now available on the login page as well
15:05:02 <dperpeet> http://cockpit-project.org/blog/cockpit-134.html
15:05:26 <dperpeet> and I want to add a shameless call for more translations on zanata - https://fedora.zanata.org/project/view/cockpit?dswid=-8859
15:05:49 <dperpeet> and thanks a lot to all the contributors who already added a lot of translations
15:06:10 <dperpeet> for example I could make the login page look very Chinese already with what we have :)
15:06:16 <dperpeet> end of topic
15:06:35 <mvollmer> thanks!
15:06:40 <mvollmer> that's it, right?
15:07:04 <mvollmer> thanks everyone!
15:07:07 <mvollmer> #endmeeting