14:04:58 <mvollmer> #startmeeting meeting
14:04:58 <zodbot> Meeting started Mon Mar  6 14:04:58 2017 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:58 <zodbot> The meeting name has been set to 'meeting'
14:05:03 <garrett> .hello garrett
14:05:04 <zodbot> garrett: garrett 'Garrett LeSage' <garrett@lesage.us>
14:05:06 <pitti> .hello martinpitt
14:05:06 <dperpeet> .hello dperpeet
14:05:07 <mvollmer> .hello mvo
14:05:07 <zodbot> pitti: martinpitt 'Martin Pitt' <martin@piware.de>
14:05:10 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:05:13 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:05:21 <andreasn> .hello andreasn
14:05:22 <mvollmer> #topic Agenda
14:05:22 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:05:38 <pitti> how do I add topics ? hash-topic or dot-topic?
14:05:40 <dperpeet> * Outreachy
14:05:48 <pitti> * container/ws: backwards compatibility for moving ssh known_hosts
14:05:51 <pitti> * update container/ws during testsuite-prepare?
14:06:06 <mvollmer> error: inconsistent whitespace
14:06:14 * pitti collects $1000 for formatting skills
14:06:16 * mvollmer dumped core
14:06:36 <dperpeet> well, pitti obviously wants to propose those as future outreachy projects
14:06:42 <pitti> sorry, my fingers are not able to type an enumeration without spaces, they only speak markdown
14:07:58 <mvollmer> okay, let's start
14:08:04 <mvollmer> #topic Outreachy
14:08:44 <dperpeet> The Outreachy project phase is ending this week
14:09:11 <dperpeet> bhakti wants to tell us a bit about the results and current state of her work on firewall support in cockpit, I believe
14:09:51 <bhakti> Yep. Last week we did usability testing on the prototypes and had a lot of valuable feedback.
14:10:35 <bhakti> I have added all the results from the testing and a few screenshots of the UI on the firewall wiki page here: https://github.com/cockpit-project/cockpit/wiki/Feature:-Firewall
14:11:46 <bhakti> There are a few more changes that needs to be made in the UI implementation
14:12:33 <dperpeet> bhakti, thanks for that
14:12:38 <bhakti> But the usability testing has helped a lot to provide an insight into the changes that need to be included in the firewall.
14:13:04 <dperpeet> compared to the goals at the beginning, how would you say the project actually was?
14:14:20 <bhakti> the initial user stories that had been decided upon helped to keep a track on the key features in the project.
14:15:47 <dperpeet> would you say this is ready for a rough implementation?
14:16:01 <dperpeet> or does this need more design before trying it out?
14:16:16 <bhakti> A rough implementation,yes.
14:16:35 <dperpeet> that sounds good
14:16:57 <dperpeet> thanks!
14:17:14 <bhakti> The current design satisfies the user stories as we saw from the usability testing.
14:17:42 <bhakti> And the feedback has been included in the design too.
14:17:55 <dperpeet> for everyone who's interested in more details about the project progress, bhakti kept a blog at https://bhaktibhikne14.wordpress.com/
14:18:41 * pitti queues for later reading, thanks
14:18:44 <bhakti> Thank You! :)
14:19:20 <dperpeet> end of topic from me, unless you have more to add bhakti
14:20:23 <bhakti> Yes! I would like to thank everyone in the community for helping and supporting me throughout the project!
14:20:41 <andreasn> thank you for all the work!
14:21:04 <bhakti> It's been a pleasure to work on Cockpit! :)
14:21:32 <dperpeet> thanks for working on this, bhakti, and now you're part of the community with the work you've done :)
14:21:44 <Son_Goku> hey folks
14:22:03 <Son_Goku> oops, you're in a meeting
14:22:08 <Son_Goku> I'll be back later
14:22:08 <mvollmer> Son_Goku, yeah
14:22:13 <dperpeet> Son_Goku, hi - you're welcome to add a topic
14:22:15 <dperpeet> if you have one
14:22:27 <Son_Goku> dperpeet: I just wanted to find out about new udisks release
14:22:32 <mvollmer> bhakti, thanks!
14:22:37 <Son_Goku> Mageia 6 is getting close to release, and I'd like to pull that in before we release
14:22:48 <bhakti> Thank You!
14:23:00 <bhakti> mvollmer: :)
14:23:16 <Son_Goku> though, bhakti, congrats on the firewall thing :)
14:23:27 <bhakti> Son_Goku: Thank you! :)
14:23:27 <mvollmer> Son_Goku, I add that to the agenda, right?
14:23:35 <Son_Goku> mvollmer: you can if you want
14:23:42 <Son_Goku> I think it's important :)
14:23:56 <mvollmer> okay, let's see
14:24:09 <mvollmer> no bigg difference whether it is on the agenda or off, I guess
14:24:25 <mvollmer> #topic  container/ws: backwards compatibility for moving ssh known_hosts
14:24:34 <pitti> some context for that:
14:24:38 <pitti> we want to move /var/lib/cockpit/known_hosts to the "official" /etc/ssh/ssh_known_hosts
14:24:47 <pitti> i. e. machines.js will then write /etc/ssh/ssh_known_hosts only
14:24:58 <pitti> but on atomic, it might be that we have an older cockpit-ws container which still only looks at /var/
14:25:04 <pitti> in principle, AFAIUI, there is no dashboard on Atomic, so there is no user-visible "multi-machines" feature there; or am I missing anything?
14:25:25 <pitti> two of our test cases fail on this issue (https://github.com/cockpit-project/cockpit/pull/6025) as they prod the "machines" URLs directly and thus sneak around the dashboard not being present
14:25:39 <pitti> so I was wondering: is this an user-visible backwards compat break and we need to somehow detect this in the web UI, or only a CI issue?
14:25:45 <dperpeet> pitti, the dashboard was removed on Atomic, yes
14:26:30 <pitti> (this underlines the importance of settling down the on-disk format before this becomes more widely deployed in long-term releases..)
14:26:39 <mvollmer> pitti, so the issue is that container/ws will never ever find the keys, right?
14:26:50 <mvollmer> it's not just that the user has to add them a second time
14:27:05 <pitti> right, as currently it only looks at /var/lib/cockpit/known_hosts
14:27:20 <pitti> so you'd need to update the container to fix this if you update the host
14:27:34 <pitti> *if* this is an user-visible feature (which I'm not sure about, see above)
14:27:40 <mvollmer> would it work currently?
14:27:57 <pitti> well no, as you don't have any UI to add remote machines on atomic
14:27:58 <mvollmer> or is container/ws looking at the 'wrong' /var, maybe? inside the container?
14:28:16 <pitti> mvollmer: no, /var is bind-mounted to the host, /etc/ssh is not -- that's the very change I need to land
14:28:17 <mvollmer> if we would add the UI, would it work now?
14:28:19 <pitti> (if I do that, it works)
14:28:25 <pitti> mvollmer: yes, it would
14:28:30 <mvollmer> right, thanks
14:28:52 <mvollmer> can we bind mound /etc/ssh to /var/lib/cockpit/? :-D
14:29:03 <pitti> eww :)
14:29:14 <mvollmer> anyway, I think it would be nice not to break this, if reasonably possible
14:29:18 <pitti> mvollmer: not without updating the container
14:29:39 <pitti> as these bind mounts happen inside the /container/atomic-run script which is stored in teh container, not the host
14:29:44 <mvollmer> or machines.js writing two files?
14:29:46 * pitti took a few hours this morning to dissect that
14:30:15 <dperpeet> I think it's important not to break containers
14:30:18 <pitti> well, before we talk about teh "how": is this an actual problem?
14:30:20 <dperpeet> people will continue using the container
14:30:29 <dperpeet> and use the newer one for older versions of cockpit also
14:31:01 <mvollmer> but is there a reason not to update the container?
14:31:10 <mvollmer> only ignorance, right?
14:31:31 <pitti> we need to update the container to keep our tests passing (as I said, the tests hack around the absence of the dashboard)
14:31:42 <dperpeet> the new container should keep working with old versions of cokcpit
14:31:49 <pitti> but that aside, I was wondering if that is just a CI issue or a real-life backwards compat issue
14:32:00 <pitti> yes, that's not a problem at all that way around
14:32:01 <mvollmer> updating = bind mount /etc/ssh and newer version of cockpit-ws, right?
14:32:12 <pitti> new ws/ssh work fine with old cockpit setups
14:32:27 <pitti> just that old ws/ssh doesn't work with new cockpit packages on the host
14:32:59 <pitti> mvollmer: yes; the "newer version of cockpit-*.rpm" is done by testsuite-prepare, but not the bind mount (but that's my second topic)
14:33:09 <dperpeet> ok, can we detect that from the container and give a sane error message?
14:33:10 <mvollmer> right
14:33:15 <dperpeet> or use the version info we have?
14:33:27 <pitti> we can't detect anything from the container if it doesn't get updated to a new version
14:33:37 <pitti> and once it does get updated, there's no breakage to detect any more :)
14:34:10 <pitti> we coudl hack machines.json to detect if the remote ws is running in a container (somehow)
14:34:20 <pitti> and fall back to writing /var/lib/cockpit/known_hosts
14:34:26 <pitti> but that'd be a really ugly hack
14:35:01 <pitti> the problem is that the bridge (which writes known_hosts to the atomic host) is running on the host, thus writes the host's file system
14:35:10 <pitti> but -ws and -ssh are in the container, so they rely on the bind mounts
14:35:13 <mvollmer> but, the existing container doesn't do dashboards, so it wont run into that problem
14:35:25 <pitti> mvollmer: right; and that's exactly what I was seeking confirmation of
14:35:27 <mvollmer> no wait, this is not up to the container
14:35:34 <mvollmer> or is it?
14:35:51 <pitti> if there is no dashboard, then multi-machines isn't a feature on Atomic and there's no compat break
14:36:14 <mvollmer> right, and how would we add the dashboard?
14:36:27 <pitti> our test images don't have a dashboard, but I'm not sure if that's generally so on atomic or just the way we configured it in our test images
14:36:32 <mvollmer> that doesn't need any change to container/ws, right?
14:36:43 <pitti> I don't know
14:36:45 <mvollmer> just adding a package to atomic host
14:37:19 <mvollmer> would it suck to let machines.js write both files?
14:37:25 <dperpeet> pitti, just fyi: you can use the container even if not on Atomic
14:37:26 <pitti> IMHO yes
14:37:33 <dperpeet> and people do
14:37:33 <pitti> as there is no defined time/point when to stop doing so
14:37:47 <mvollmer> we can do it forever...
14:38:14 <pitti> I mean, if the docker images don't update automatically, then supposedly they will run old code forever (potentially) and thus we have to support ancient ws/ssh forever
14:38:23 <mvollmer> yeah
14:38:28 <mvollmer> *shrug*
14:38:30 <dperpeet> I think it can be expected to update containers
14:38:33 <dperpeet> that's what they're for
14:38:42 <dperpeet> but the new container should be able to connect to an older cockpit
14:38:50 <pitti> new containers are fine
14:39:12 <pitti> there's code to search /etc/ssh/known_hosts, fall back to /var (and soon also look into $HOME and machines.d/*.json)
14:39:40 <pitti> the difficulty is updating cockpit on the host, but keeping an old container, as there is no dependency relation between those
14:39:53 <mvollmer> so, we need a general mechanism to tell people: there is a new container, go get it
14:40:03 <mvollmer> right?
14:40:20 <pitti> yeah (which is a much wider-scale problem, and a general source of brokenness and insecurity of containers :) )
14:40:29 <dperpeet> mvollmer, if possible, but I don't think it is a must - containers can be expected to be updated
14:40:43 <petervo> pitti, how about a capability system-sshkeys
14:40:49 <petervo> or something
14:40:58 <petervo> that machines js can check for
14:41:05 <petervo> to decide where to write
14:41:46 <pitti> petervo: that would go towards the direction of "detect whether the remote ws is running in a container"? what kind of capability to you mean?
14:42:03 <petervo> well it's not just about the container
14:42:26 <petervo> there are various ways cockpit-ws could be old
14:42:35 <petervo> but yes that's the most common case
14:42:48 <petervo> capabilities are a cockpit feature
14:43:33 <petervo> https://github.com/cockpit-project/cockpit/blob/master/src/ws/cockpitwebservice.c#L1644
14:43:39 <pitti> petervo: so machines.js can somehow talk to the runing ws?
14:44:20 <petervo> there's an init message that gets sent when the socket is setup
14:44:38 <pitti> petervo: ah nice; if ws exports those and we can query those in js, we could implement that
14:44:53 <petervo> i think there should be a way we can find out what they are
14:45:12 <pitti> so that means our CI tests would detect that "backwards compat" fallback path, and not test the code path with writing /etc/ssh on Atomic
14:45:23 <pitti> but as soon as we release a new container, they would test the new code path
14:45:35 <pitti> and the new code path is tested on all non-atomic targets, so that shoudl be fine
14:46:14 <pitti> so I take it from the discussion above that having a dashboard on atomic is a supported use case, we just don't cover it in our CI
14:47:22 <dperpeet> pitti, or use a container with non-atomic
14:47:52 <pitti> well, that seems a bit far-fetched, but sure
14:48:03 <petervo> pitti, at the moment the dashboard isn't support on atomic
14:48:16 <petervo> but it used to be
14:48:36 <petervo> and will be again at some point
14:49:18 <pitti> petervo: so should I look into the capability checking and fall back to writing the old file?
14:49:34 <petervo> that would be my suggestion
14:49:38 <pitti> ack, thanks
14:49:50 <pitti> so my second topic is kind of moot now
14:50:06 <pitti> and we're running out of time, so let's skip it
14:50:08 <mvollmer> petervo, thanks, that was excellent!
14:50:44 <petervo> i thought we used to update cockpit/ws durning test suite prepare
14:50:58 <pitti> we only install the rpms
14:51:11 <pitti> we don't update /containers/ scripts
14:51:44 <petervo> and installing the rpms is not enough?
14:51:57 <pitti> but I suppose it's useful to let our CI run against the old container until we release 234, to test the fallback path
14:52:10 <pitti> no, need to change atomic-{install,run} for the new bind mount
14:52:31 <pitti> these scripts aren't packaged (and they don't need to be)
14:53:21 <petervo> oh i see, i think that's probably ok
14:54:54 <pitti> (end of topic from my POV)
14:55:55 <mvollmer> #topic Any other business
14:56:32 <dperpeet> mvollmer, the udisks topic?
14:56:34 <mvollmer> Son_Goku, do you want to bring up Mageia 6?
14:56:39 <pitti> Son_Goku: I'm waiting for a new udisks release myself too (but not nearly as pressuring as for you); there was supposed  to be a new one "soon'O
14:56:50 <Son_Goku> pitti: we're about to put out Mageia 6 sta2
14:57:10 <Son_Goku> and I'm having arguments with people over whether upgrading from udisks 2.1.8 to udisks 2.6.4 will be "safe"
14:57:23 <Son_Goku> because we want to release Mageia 6 in the upcoming weeks
14:57:34 <Son_Goku> (Mageia 6 is horribly overdue...)
14:57:36 <pitti> it's backwards compatible, yes
14:58:04 <Son_Goku> in terms of API and ABI, or is there something I should be aware of?
14:58:05 <pitti> but nevertheless a lot of changes of course, so don't do this right before a release (just for good practice, not because we know about regressions)
14:58:19 * Son_Goku shrugs
14:58:28 <Son_Goku> I'll probably wind up sticking it in a COPR repo and testing myself
14:58:43 <Son_Goku> it may wait until Mageia 7, but the situation is a complete mess to begin with
14:58:54 <pitti> the integration tests are fairly good, though
14:59:00 <Son_Goku> it's quite likely it might wind up being a post-release upgrade at some point, but I'd like to get a handle on this
14:59:14 <pitti> and it's been tested for backwards compat in Fedora (as "storaged")
14:59:21 <Son_Goku> yes, I'm aware of that :)
14:59:29 <Son_Goku> the problem is that from the outside looking in, no one has a clue about the upgrade path and how well of a drop-in it is
14:59:47 <pitti> if you don't pacakge the new plugins (lvm etc.), it pretty well looks exactly the same
15:00:07 <pitti> so it's "just a new upstream version" from that angle
15:00:13 <Son_Goku> right
15:00:50 <Son_Goku> so what's left on making udisks 2.6.4?
15:00:59 <pitti> I'm not sure
15:01:10 <pitti> (not working on it on a day to day basis)
15:03:42 <Son_Goku> hmm
15:03:44 <Son_Goku> basically, I don't want to be put in the bad situation of doing an ugly upgrade post-release
15:04:36 <Son_Goku> maybe with the 2.6.4 release, could some upgrader notes be put together for people coming from 2.1.8?
15:05:50 <Son_Goku> the version jump makes it seem scarier than it might actually be
15:06:06 <pitti> yeah, there's a whole fork and re-merging in between, but from end to end  it's not that scary ;)
15:06:15 <Son_Goku> I know the internals have changed quite a bit, but I don't know if that affects ABI
15:06:15 <mvollmer> Son_Goku, pitti, what about wrapping up the meeting?
15:06:17 <pitti> so the net result is essentially "add some new plugins for LVM"
15:06:20 <pitti> +1
15:06:26 <mvollmer> yeah
15:06:28 <Son_Goku> I'm okay with ending the meeting
15:06:38 <Son_Goku> my bit isn't particularly meeting relevant :)
15:06:40 <mvollmer> sorry, I didn't understand that this is about udisks... :)
15:06:46 <mvollmer> #endmeeting