13:00:52 <mvollmer> #startmeeting meeting
13:00:52 <zodbot> Meeting started Mon May 29 13:00:52 2017 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:52 <zodbot> The meeting name has been set to 'meeting'
13:00:57 <mvollmer> .hello mvo
13:00:58 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:01:00 <garrett> .hello garrett
13:01:01 <zodbot> garrett: garrett 'Garrett LeSage' <garrett@lesage.us>
13:01:12 <pitti> .hello martinpitt
13:01:13 <zodbot> pitti: martinpitt 'Martin Pitt' <martin@piware.de>
13:01:49 <dperpeet> .hello dperpeet
13:01:50 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:03:09 <mvollmer> #topic Agenda
13:04:08 <mvollmer> * Server Applications update
13:04:39 <mvollmer> anything else?
13:04:50 <pitti> ø
13:04:54 <petervo> * libvirt integration
13:05:18 <larsu> .hello larsu
13:05:19 <zodbot> larsu: larsu 'Lars Karlitski' <lars@karlitski.net>
13:05:43 <mvollmer> let's start!
13:05:51 <mvollmer> #topic Server Applications update
13:06:01 <mvollmer> so I am still working on that. :-)
13:06:18 <mvollmer> i think the plumbing work is coming to an end
13:06:36 <mvollmer> well, it's open for review
13:06:53 <mvollmer> which isn't really the end, of course
13:07:22 <mvollmer> so we have a way to adapt to changing manifests without logging out
13:07:47 <mvollmer> and there is a way to generate menu entries from AppStream metadata dynamically
13:08:08 <mvollmer> I am putting that all together for a new screen cast, any minute now
13:08:37 <mvollmer> andreasn has worked on the design, and I think I am ready to implement it
13:09:09 <mvollmer> concrete next step is to make a PR for the AppStream spec for the new "service" component type
13:10:10 <mvollmer> and we can probably start thinking about how to integrate this with the new navigation stuff that garret and petervo are working on
13:10:32 <mvollmer> that's it
13:10:51 <petervo> so are we writing new manifests to the filesystem
13:11:00 <petervo> sorry i haven't looked at the code yet
13:11:16 <mvollmer> no, we read stdout of a process
13:12:04 <mvollmer> if .../override.exec exists, it is spawned and stdout is used in the same way as override.json
13:12:43 <mvollmer> the generator can do some caching if that is called for
13:14:03 <mvollmer> next?
13:14:48 <petervo> sure, i guess i'm interested in the seeing the example of how this all fits together
13:15:09 <mvollmer> yeah
13:15:32 <mvollmer> briefly: we install a rpm package that contains a systemd service, but no cockpit code
13:15:42 <petervo> and what the advantage is of doing it this way as opposed to doing more of this on the JS side
13:16:10 <mvollmer> after installation, the manifests are loaded again, and a override.exec generates a menu entry for the rpm package
13:16:45 <mvollmer> when navigating to that entry, cockpit shows a semi-generic UI that let's the user control that service
13:17:24 <mvollmer> the rpm package has to opt into this via its AppStream metainfo file
13:18:07 <mvollmer> petervo, yes, this can be done via plugins in the shell
13:18:31 <mvollmer> i think override generators are simpler and more efficient
13:19:39 <mvollmer> but they are also limited
13:20:07 <petervo> we also are going to need to add menu entries for containers
13:20:17 <mvollmer> yes
13:20:38 <petervo> and in those cases that will probably happen via js code only
13:20:43 <mvollmer> the override generators need a concrete package to work within
13:22:14 <mvollmer> petervo, are you thinking of some plugin api for the shell, or some concrete changes to the shell that teach it about containers?
13:22:43 <petervo> more of a plugin api for the shell i think
13:22:54 <mvollmer> yes, makes sense
13:23:20 <petervo> i just don't want to have too many different ways to do similar things
13:23:28 <petervo> but maybe they are different enough
13:23:30 <mvollmer> the application stuff can be done that way, too, but it requires a lot of roundtrips, I am afraid
13:23:42 <petervo> so probably not ideal
13:23:54 <mvollmer> maybe caching can help
13:24:09 <petervo> anyways i'll think about that a little more when i review
13:24:14 <mvollmer> great
13:24:22 <petervo> and i guess if you think of anything in the mean time
13:24:28 <mvollmer> in any case, we can keep override.exec "internal-only"
13:24:47 <petervo> alright next topic was mine, libvirt
13:24:57 <mvollmer> #topic libvirt
13:25:30 <petervo> for anyone who didn't see my email, we are looking at integrating with libvirt
13:26:11 <petervo> initially I was sort of hoping to integrate with their XDR RPC daemon
13:26:31 <petervo> but they are pretty strongly against anyone doing that
13:27:13 <petervo> to it's looking like we'll need to decide between trying to do something more generic like generalized dbus or REST service for it
13:27:30 <petervo> or writing a one off cockpit-bridge for it
13:27:41 <petervo> that integrates with their C api
13:28:08 <dperpeet> I guess the biggest question is whether there are more potential consumers for such an API
13:28:14 <petervo> I'm still in the gathering ideas phase
13:28:20 <petervo> that's always the question yes
13:28:24 <dperpeet> if there are, a dbus or REST service would be promising
13:28:47 <petervo> so far I've heard that everyone things there would be interest
13:28:57 <petervo> but nothing concrete i can point to
13:29:02 <petervo> thinks*
13:29:25 <pitti> you mean adding a dbus service to libvirt proper?
13:29:29 <dperpeet> from what we've done before, the generalized dbus/REST interface sounds more interesting
13:29:37 <dperpeet> and less cockpit specific
13:30:02 <pitti> they don't want us to interface directly with their RPC because they consider it an internal implementation detail? or is that a stable API?
13:30:10 <petervo> well it would have to be a separate project
13:30:33 <petervo> it is an internal only API, and they do not want to make it stable
13:31:11 <pitti> ack; so a generic RPC bridge/REST <-> RPC gateway wouldn't help with that
13:31:21 <petervo> right
13:31:34 <mlibra> .hello mlibra
13:31:34 <mlibra> I think we need commitment from libvirt guys to maintain it otherwise it will be to much unreliable in the long term
13:31:35 <zodbot> mlibra: mlibra 'Marek Libra' <mlibra@redhat.com>
13:31:51 <petervo> mlibra, yes that's the big question
13:32:08 <petervo> who gets to maintain it and get in all the distros
13:32:22 <mlibra> I don't like recent virsh either, but it would be a dead end to build and maintain somthing like that on my/our own
13:32:23 <petervo> we had similar issues with storaged before
13:33:39 <petervo> anyways we don't have to make a decision right now
13:34:02 <mvollmer> storaged was a 'hostile' fork, this would be something new and uncontroversial, right?
13:34:32 <petervo> something new for sure, not sure about uncontroversial
13:34:37 <petervo> hopefully
13:36:05 <pitti> so interfacing through virsh and/or XML is too clumsy?
13:36:26 <petervo> the biggest problem with virsh is we don't get events
13:36:34 <petervo> so we have to poll
13:37:09 <pitti> ah -- maybe there's a compromise where the libvirt guys can commit to keeping the notification part of the API stable?
13:37:18 <petervo> i asked that
13:37:23 <petervo> but the answer was no
13:37:27 <pitti> although that would then speak both rpc and virsh or XML, not exactly elegant either
13:38:15 <petervo> we don't have to make a call now, but would be good to think about, i guess let me know if anyone has any further thoughts or reply to list
13:39:53 <mvollmer> so virt-manager (the GUI) uses the internal api?
13:40:05 <petervo> well it uses the C API
13:40:12 <petervo> which is stable
13:40:17 <mvollmer> ahh
13:40:28 <petervo> but it's not remotable
13:40:39 <mvollmer> right, got it
13:42:31 <petervo> next topic?
13:42:43 <mvollmer> #topic Any other business
13:43:54 <mvollmer> we are done I guess
13:44:00 <mvollmer> thanks!
13:44:02 <mvollmer> #endmeeting