14:02:12 <andreasn> #startmeeting Weekly Cockpit meeting 2016-11-07
14:02:12 <zodbot> Meeting started Mon Nov  7 14:02:12 2016 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:12 <zodbot> The meeting name has been set to 'weekly_cockpit_meeting_2016-11-07'
14:02:22 <andreasn> .hello andreasn
14:02:23 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:02:51 <mvollmer> .hello mvo
14:02:52 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:04:59 <andreasn> #topic agenda
14:05:20 <andreasn> (I don't really have anything myself)
14:06:25 <petervo> * cockpit-ssh
14:08:06 <andreasn> anything else?
14:08:29 <mvollmer> uhh
14:08:40 <mvollmer> * ubuntu
14:09:05 <mvollmer> * atomic package layering
14:09:25 <andreasn> cool. Lets start
14:09:32 <andreasn> #topic cockpit-ssh
14:10:33 <petervo> so stefw and I have been discussing moving cockpit-ssh to a separate package
14:11:00 <petervo> to remove the hard dependency on libssh
14:11:25 <mvollmer> interesting
14:11:50 <petervo> so that cockpit-ws is easier to bring in
14:12:08 <mvollmer> are we going 'soft' with our dependencies? :-)
14:12:28 <petervo> heh, bad choice of words i guess
14:12:45 <petervo> but basically on some OSes libssh is harder to bring in
14:13:04 <petervo> so we wouldn't be able to do any multi-machine stuff without it
14:13:17 <petervo> but we'd still like to be able to have a local only cockpit
14:13:29 <mvollmer> yeah, I was hoping that we could 'define the experience' and the rest like dependencies follows from that
14:14:04 <stefw> on RHEL we have to support our dependencies for 10 or 13 years
14:14:13 <mvollmer> but yeah, i totally understand the compromises
14:14:20 <stefw> anyone signing up for libssh? or do we want to have a more pragmatic balance
14:14:23 <stefw> if nobody else is using the dependency?
14:14:29 <stefw> we can always take the next step of supporting it later
14:14:52 <stefw> but yes, lets define the experience
14:15:01 <stefw> that's why i'm trying to make networkmanager actually work on debian
14:15:03 <stefw> for example
14:15:10 <mvollmer> yeah
14:15:12 <andreasn> so no libssh means no multi-host, right?
14:15:17 <stefw> our defining the experience is an active development and involvement with the operating system
14:15:21 <stefw> not forcing change via deps
14:15:56 <petervo> yes, you wouldn't get the dashboard or any of the multi-machine bits
14:16:13 <stefw> yes, unless you insalled the cockpit-ssh package
14:16:19 <stefw> in which case all that shows up again
14:16:19 <andreasn> cool. I think that's an OK compromize
14:16:56 <petervo> there's work to be done to make it all work nicely, but the main thing i wanted to bring up is that to do this we need to make all communication between cockpit-ws and cockpit-ssh part of what we consider stable API
14:17:27 <mvollmer> is there a chance to use /usr/bin/ssh instead of libssh, somehow?
14:17:52 <stefw> yup
14:17:55 <petervo> ssh would require a lot of screen scraping
14:17:56 <stefw> with *lots* of code
14:18:08 <stefw> but the work petervo is doing allows either of that
14:18:16 <stefw> just insane amount more code to use /usr/bin/ssh
14:18:36 <mvollmer> right
14:19:47 <petervo> so the best solution we came up with to ensure backwards compatibility is to use env vars to replace the command line arguments that cockpit-ssh currently takes
14:20:01 <stefw> yes, i was thinking about that more
14:20:02 <stefw> and it makes sense
14:20:08 <stefw> as long as we always set the environment variables
14:20:11 <stefw> even when they're empty
14:20:17 <petervo> yep
14:20:30 <stefw> that way the called process can tell the capabilities of the caller, even when the value is not relevant in the given context
14:20:44 <stefw> and such an extensible spawn interface has a precedent with cgi ... for better or worse
14:21:04 <stefw> so we should look there to make sure interpretting it is robust
14:21:14 <stefw> such as the above "always set the environment variable" point
14:21:18 <petervo> yeah that's a good point
14:22:28 <andreasn> next up?
14:22:49 <andreasn> #topic Ubuntu
14:22:50 <petervo> i think so, just wanted to make everyone aware since it's something we will need support
14:23:02 <petervo> as stable
14:23:31 <mvollmer> okay, ubuntu
14:23:36 <mvollmer> just a quick status report
14:23:41 <mvollmer> should be done very soon
14:24:01 <mvollmer> and stefw has already unblocked networking on debian and ubuntu
14:24:18 <mvollmer> so let's see how that looks in action
14:24:36 <mvollmer> i think there were no big surprises with ubuntu
14:24:47 <mvollmer> some old packages, same issues as debian
14:25:16 <mvollmer> the biggest was of course UDisks2 instead of storaged
14:25:46 <mvollmer> which doesn't make me super happy, of course
14:26:02 <stefw> but you have done work to help replace udisks with storaged right?
14:26:13 <stefw> talking to maintainers, etc?
14:26:18 <mvollmer> yes, a little bit
14:26:25 <mvollmer> it is going to happen, I am pretty sure
14:26:45 <mvollmer> it is happening in Fedora 25 already
14:26:52 <mvollmer> thanks to tomas and gang
14:27:24 <mvollmer> and the de-facto UDisks2 maintainer Martin Pitt also wants it to happen
14:28:25 <andreasn> EOT?
14:28:26 <mvollmer> that's it
14:28:30 <andreasn> #topic atomic package layering
14:28:32 <mvollmer> unless you want to hear more
14:28:40 <mvollmer> alright
14:28:54 <mvollmer> this topic is just me catching up
14:29:24 <mvollmer> and trying to get over my dislike of the cockpit situation in Atomic
14:29:36 <mvollmer> so package layering works now
14:29:42 <mvollmer> should we embrace it?
14:29:47 <petervo> for some packages
14:30:04 <mvollmer> yeah
14:30:19 <mvollmer> so one idea is to have cockpit-ws and cockpit-shell in a container
14:30:28 <stefw> right, i did work towards that
14:30:31 <mvollmer> and the rest in the host, via package layering
14:30:41 <stefw> needs a bit more work in src/bridge/cockpitpackages.c
14:30:59 <stefw> so essentially diluting atomic host to the level of an RPM based system?
14:31:03 <mvollmer> so navigating to storage will let you install the cockpit-storaged package
14:31:22 <mvollmer> yeah, essentially
14:31:29 <stefw> wouldn't we have cockpit-storaged in the container anyway?
14:31:34 <stefw> and we'd offer to install its deps on the system?
14:31:36 <mvollmer> that would avoid having to put the tricky bits into containers
14:31:56 <stefw> and system updates work?
14:32:02 <mvollmer> yes
14:32:19 <stefw> so a new version of storaged that works with the given lvm2 and kernel gets pulled in appropriately?
14:32:22 <stefw> and it's tested together?
14:32:38 <mvollmer> i think it would be nice to have a cockpit-ws-plus-shell container that is very independent of the OS
14:32:44 <stefw> yup
14:33:09 <stefw> so concretely this lets us ...
14:33:17 <stefw> ... unblock something we're working on now?
14:33:21 <mvollmer> so the actual UI bits (cockpit-storaged) that need to be matched to the APIs are not in it.
14:33:22 <stefw> actually deliver something?
14:33:38 <stefw> but i'm not against it
14:33:43 <stefw> seesm like we should deliver that container first
14:33:47 <stefw> and then embrace the next step
14:33:52 <mvollmer> i think it would make "Storage" work with almost zero work
14:33:54 <stefw> if things haven't been resolved at the operating system level
14:34:27 <stefw> so yeah, if you're going to work on the container ... i'd be a fan
14:34:32 <mvollmer> cool
14:34:50 <stefw> i'm less of a fan of diluting one of the few actually integrated and tested Linux operating systems that exist
14:34:57 <stefw> but i hope we can help make that situation better
14:35:02 <stefw> anyway, rather than working around it
14:35:16 <stefw> as in making storaged so solid that its just part of the operating system
14:35:23 <mvollmer> which OS is that?  Fedora or Atomic?
14:35:26 <stefw> Atomic
14:35:44 <stefw> everything else is distro based and essentially 52-card-pickup
14:35:54 <stefw> https://en.wikipedia.org/wiki/52_Pickup
14:36:19 <stefw> as in a pile of random legos ... that is put together differently for everyone and we hope works
14:36:39 <mvollmer> embrace the chaos, it's stronger than you... :-)
14:37:15 <stefw> i know you're kidding ... since you're about 'define the experience'
14:37:21 <stefw> :)
14:37:37 <stefw> "Cockpit helps the server evolve coherently" and all that
14:37:43 <stefw> but yeah, lets work on the container
14:37:48 <stefw> that's a next step in any case
14:38:05 <mvollmer> so the container would serve port 9090
14:38:10 <stefw> yup
14:38:19 <stefw> and it would be a logical progression of the current cockpit-ws container
14:38:20 <mvollmer> and be able to put up a empty shell, basically
14:38:35 <stefw> just when the host has no packages, it would find an apprpropriate one
14:38:40 <mvollmer> yes
14:39:02 <stefw> there's already work done to have the atomic version show up in the init message
14:39:14 <stefw> so cockpit-ws can easily figure out a directory to use, similar to branding
14:41:24 <mvollmer> right
14:42:35 <andreasn> cool. Anything else?
14:42:40 <andreasn> #topic Open floor
14:42:44 <andreasn> anything for the open floor?
14:42:51 <stefw> Next Release
14:42:56 <andreasn> oh, right
14:43:10 <stefw> The next release is going to have the tarball changes we talked about
14:43:26 <stefw> where we don't bundle any javascript or node dependencies in the main tarball
14:43:39 <stefw> and instead we bundle files that are ready to be installed ... dist/ files
14:43:51 <stefw> but they are easily removed by removing the dist/ directory or 'make clean'
14:44:06 <stefw> in addition there's an awful lot of unreviewed and pending changes to the release process
14:44:18 <stefw> that are going to make this release quite exciting, and a bit of bug hunting.
14:44:36 <stefw> i need help reviewing this: https://github.com/cockpit-project/cockpituous/pull/44
14:44:39 <stefw> and merging it
14:44:44 <stefw> and i'll probably have lots of follow up fixes
14:44:58 <stefw> that's blocking the release
14:47:32 <github> [cockpit] stefwalter opened pull request #5320: Makefile: Setup DIST_ARCHIVES correctly for multiple outputs (master...many-dist-archives) https://git.io/vXRY8
14:47:36 <stefw> that's it on that
14:47:58 <andreasn> cool
14:48:01 <andreasn> #endmeeting