13:00:25 <mvollmer> #startmeeting
13:00:25 <zodbot> Meeting started Mon Sep 14 13:00:25 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:36 <mvollmer> .hello mvo
13:00:37 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:00:44 <andreasn> yay
13:00:48 <andreasn> .hello andreasn
13:00:50 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:01:14 <dperpeet> .hello dperpeet
13:01:15 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:01:23 <mvollmer> #topic Agenda
13:01:32 <mvollmer> * Fedora 23 and Rawhide testing
13:01:44 <dperpeet> * test: vm boot optimization
13:02:24 <stefw> * Continuous delivery updates and architecture
13:02:36 <stefw> * Dashboard work
13:02:39 <mvollmer> * Moving things out of the shell (cont.)
13:04:21 <mvollmer> Ok, let's start.
13:04:29 <mvollmer> #topic Fedora 23 and Rawhide testing
13:04:40 <mvollmer> So i have been poking at that again
13:05:06 <mvollmer> and I think we are close to the point where we can look at the real test failures.
13:05:26 <mvollmer> i was going to give up on Rawhide...
13:05:38 <mvollmer> but I was doing the package installation wrong.
13:05:48 <mvollmer> so now I think we can usefully test Rawhide
13:06:05 <mvollmer> current 'blocker': docker pull hangs with some of our images.
13:06:16 <mvollmer> in f23
13:06:34 <dperpeet> did andreasn reproduce that error?
13:06:48 <mvollmer> anyway, I think we should merge the two pull requests and then check what happens with the periodic master checks.
13:06:48 <andreasn> I was unable to with 1.7.1
13:07:00 <stefw> mvollmer, merging sounds good
13:07:02 <andreasn> and then I was unable to install 1.8.1 on F23
13:07:02 <mvollmer> subin is trying to reproduce
13:07:12 <dperpeet> mvollmer, can you link the two requests you mean?
13:07:16 <mvollmer> yep
13:07:35 <mvollmer> #link https://github.com/cockpit-project/cockpit/pull/2541
13:07:52 <mvollmer> #link https://github.com/cockpit-project/cockpit/pull/2543
13:08:09 <dperpeet> I can get on those
13:08:12 <dperpeet> thanks for the links
13:08:12 <mvollmer> Actually, Rawhide is being tested for some time already
13:08:25 <dperpeet> stefw, do you mind if I review?
13:08:28 <mvollmer> and it now even runs the tests
13:08:33 <stefw> yeah for sure, go ahead
13:08:56 <mvollmer> i guess we need to get better at following up on issues that are found during the master checks
13:09:11 <mvollmer> at least I treat them as "yeah, always red".
13:09:37 <dperpeet> I had some thoughts about that, but I'll be better prepared to present them next week
13:09:37 <mvollmer> maybe we could report more details: "tests could not start"
13:09:45 <mvollmer> "2 out of 300 tests failed"
13:10:32 <mvollmer> or "3 more tests failed since last week, and 2 pass now"
13:10:34 <dperpeet> I was thinking of improving the hubbot output a bit
13:11:03 <dperpeet> an additional html output, split the log into sections
13:11:06 <dperpeet> and summarize
13:11:18 <mvollmer> or have some out-of-tests database that marks some tests as "known to fail"
13:11:35 <dperpeet> should we start a wiki page with how test output should look?
13:11:39 <fabiand> .hello fabiand
13:11:40 <stefw> mvollmer, yup
13:11:40 <zodbot> fabiand: fabiand 'Fabian Deutsch' <fabian.deutsch@gmx.de>
13:11:59 <stefw> we should make sure this stuff works distributed though
13:12:04 <stefw> so that multiple machines can work together on the tests
13:12:07 <mvollmer> right
13:12:16 <stefw> i'll talk about this during a later agenda point
13:12:22 <mvollmer> stefw, you did some work on TAP earlier on, right?
13:12:26 <mvollmer> ok.
13:12:36 <stefw> yeah, TAP is a good way to bring them together
13:12:58 <stefw> even if we store the output, and have the UI process it all as it displays it
13:13:07 <mvollmer> yep
13:13:58 <mvollmer> #action dperpeet review 2541 and 2543
13:14:13 <mvollmer> ok, next?
13:14:19 <stefw> yup
13:14:39 <mvollmer> #topic vm boot optimization
13:15:11 <dperpeet> while working on moving some of our qemu calls to libvirt, I noticed that our virtual machines have a grub boot delay
13:15:27 <dperpeet> while 5 seconds are pretty brief, we have to consider that virtual machines boot for every single test
13:15:43 <dperpeet> I believe we have >30 tests right now
13:15:49 <stefw> we can kill the delay during .bootstrap
13:15:51 <stefw> no?
13:15:54 <dperpeet> so that's a significant amount of time
13:15:59 <dperpeet> yes, I think it would be worth testing that
13:16:15 <stefw> the waiting happens in parallel
13:16:17 <stefw> but yeah
13:16:29 <dperpeet> yeah, you can divide by 4
13:17:00 <dperpeet> the downside is, that if you want to test a vm, it's more difficult to get into grub
13:17:08 <dperpeet> e.g. vm-run
13:17:17 <mvollmer> can we get in at all right now?
13:17:21 <stefw> GRUB_TIMEOUT=5
13:17:24 <stefw> in /etc/default/grub
13:17:35 <stefw> and rebuild grub
13:17:40 <dperpeet> mvollmer, with libvirt, vm-run is fully interactive
13:17:47 <mvollmer> ah, I see.
13:17:48 <dperpeet> including grub menu
13:18:18 <dperpeet> stefw, do you want to do this or should I, after libvirt changes have landed?
13:18:20 <dperpeet> or tack it on?
13:18:39 <stefw> it's a separate thing
13:18:48 <stefw> i don't even think there will be a merge conflict
13:19:05 <dperpeet> we have to increase version numbers on all images for this
13:19:09 <dperpeet> as for the libvirt changes
13:19:29 <stefw> yup, that happened like 20 times while you were away
13:19:45 <dperpeet> ok, fair enough
13:20:44 <dperpeet> one of us can do it then and we'll merge when we merge
13:21:13 <mvollmer> so the libvirt changes replace the calls to qemu?
13:21:30 <mvollmer> then we only need to get rid of the libguestfs stuff, right?
13:21:47 <stefw> yeah, that should move to bootstrap
13:21:51 <stefw> which uses virt-builder
13:21:52 <mvollmer> yes
13:21:54 <stefw> which uses libguestfs
13:22:10 <mvollmer> yes, of course
13:22:28 <mvollmer> but we keep the setup scripts?
13:22:39 <mvollmer> or do we also move them to virt-builder?
13:22:43 <mvollmer> maybe later
13:22:56 <stefw> the setup scripts have to be keept
13:23:01 <dperpeet> I think we should keep those
13:23:03 <stefw> because virt-builder runs with strange network, disks, and so on
13:23:07 <mvollmer> would be nice to refacter them a bit
13:23:10 <stefw> it's not possible to combine the bootstrap and setup scripts
13:23:13 <stefw> although we can clean them up
13:23:45 <mvollmer> avoid dupliction, mostly
13:23:55 <mvollmer> *duplication
13:24:06 <stefw> right
13:24:20 <dperpeet> I already refactored creation and package installation out of testvm
13:24:21 <dperpeet> #link https://github.com/dperpeet/cockpit/tree/test_libvirt
13:24:35 <mvollmer> nice
13:24:55 <mvollmer> next?
13:24:58 <dperpeet> yes
13:24:59 <stefw> yup
13:25:05 <mvollmer> #topic Continuous delivery updates and architecture
13:26:19 <stefw> peter and I have cleaned up the continuous delivery scripts further, and put them into two docker containers
13:26:26 <stefw> docker containers are great for "but it works on my machine" style development
13:26:51 <stefw> https://github.com/cockpit-project/cockpituous
13:27:13 <stefw> pushed some of the latest updates there
13:27:18 <stefw> basically there are different components working together
13:27:31 <stefw> one of which is the automated release scripts
13:27:42 <stefw> each of these pieces run in a container, and have various things mounted into the container, such as credentials
13:27:59 <stefw> the second component i've worked on is a bip relay
13:28:13 <stefw> than allows IRC access to the other components, and logging to this channel #cockpit
13:28:27 <stefw> i'd like to find or come up with a logger that allows us to gather logs from these various pieces
13:28:42 <stefw> very likely piped in over ssh, and then displayed using a simple web page
13:29:11 <stefw> the idea being that a component (such as the release scripts) can send a logging link to IRC when it starts and all the output goes to that link
13:29:31 <stefw> as we talked about earlier, i'd like to get to the point where our integration tests are also run distributed
13:29:47 <dperpeet> how about appending a github gist?
13:29:52 <stefw> with each os being tested on a separate machine, to spread the load
13:29:55 <dperpeet> we can use authentication tokens for that
13:30:08 <dperpeet> and we have the api code
13:30:14 <dperpeet> even works via shell
13:30:17 <stefw> and so when the integration tests are distributed, the similar code would be used for logging and status of the tests.
13:30:30 <stefw> in other words the logging component brings together all of these things publically
13:30:37 <stefw> Why not use fpaste.org or gist.github.com?
13:30:40 <stefw> for two reasons:
13:31:00 <stefw> 1) with most paste services you cannot get a link before it's finished being posted.
13:31:18 <stefw> 2) no custom ui, such as sending updates to the browser, or making sense of TAP output (see discussion earlier in this thread)
13:31:25 <stefw> Also, why not use Jenkins?
13:31:31 <stefw> well ... we can use jenkins as a runner
13:31:40 <stefw> if someone would let us do things like start VMs on jenkins
13:31:45 <stefw> but as far as public UI and logging output
13:31:48 <dperpeet> so you want the public display to follow the logs as they are being created?
13:31:58 <stefw> public jenkins instances are not available for us to use.
13:32:04 <stefw> dperpeet, yes, that would be nice
13:32:26 <stefw> but anyway, the basic point here ... is that all of this ends up pretty distributed
13:32:36 <stefw> with some frontend bits available to the internet
13:32:48 <stefw> and all the various other parts running distributed in various places
13:32:59 <dperpeet> it would be pretty simple to set up a database on a server
13:33:11 <stefw> sure, if that becomes necessary
13:33:17 <dperpeet> log creators could just pipe there
13:33:31 <dperpeet> line by line if necessary, and decide on their own when to flush
13:33:32 <stefw> any of these distributed pieces can grow if there's a need
13:33:35 <stefw> but obviously we start very simple
13:33:45 <stefw> such as just having the logging stuff log to a directory
13:33:55 <stefw> that is web listable
13:34:10 <stefw> that's good enough for the continuous delivery (ie: rolling releases) use case we have right now.
13:34:44 <stefw> anyway ... so the reason I bring thisup
13:35:23 <stefw> is because we need to make sure that the automated stuff we're planning ... can eventually work in a  distributed fashin
13:35:25 <stefw> fashion
13:35:46 <dperpeet> good job on consolidating those scripts and automating the process somewhat, stefw and petervo
13:37:40 <stefw> thanks
13:37:43 <stefw> that's it on this point
13:37:55 <mvollmer> ok, good stuff
13:38:16 <mvollmer> #topic Dashboard work
13:38:23 <stefw> The dashboard fails a lot of tests
13:38:39 <stefw> so i've been working today to simplify how it works
13:38:46 <stefw> and how the navbar interacts with the dashboard
13:38:55 <stefw> hopefully it'll be more predictable
13:39:42 <stefw> and i'm going to try to finish off the last issue here:
13:39:44 <petervo> is there a PR yet?
13:39:51 <stefw> https://trello.com/c/59Ajm8lz/53-multiple-dashboards
13:39:56 <stefw> petervo, no not yet
13:40:04 <stefw> as well as move the dashboard into its own component.
13:40:15 <stefw> and this work is why i haven't merged mvollmer's plot work ... which is ready to go
13:40:30 <stefw> but seems to exacerbate the multi machine dashboard test failures
13:40:42 <mvollmer> right, I thought I broke it
13:40:49 <stefw> i don't think so
13:41:17 <mvollmer> at least I have made the failure reproducible. :)
13:41:28 <stefw> yes, mostly
13:42:07 <stefw> i would also like to then go further and do more dashboard work
13:42:16 <stefw> rework the setup dialog, to support accessing servers as other users
13:42:23 <stefw> fix up its ui, and so on
13:42:28 <andreasn> sounds good
13:42:32 <mvollmer> right, that would be awesome
13:42:34 <stefw> http://stef.thewalter.net/installer-anti-pattern.html
13:42:47 <stefw> currently it has the wizard anti-pattern
13:42:50 <mvollmer> yes
13:43:07 <stefw> hopefully i'll be able to do this as Atomic work, and we can have time allocated for it
13:43:56 <stefw> that's it for that topic
13:44:00 <mvollmer> alright
13:44:13 <mvollmer> #topic Moving things out of the shell (cont.)
13:44:31 <mvollmer> the work on the graphs is mostly done
13:44:51 <mvollmer> and it allows us to delete cockpit-wrapper completely
13:45:08 <stefw> which is amazing :)
13:45:11 <mvollmer> the "multi instance" plots are now quite ugly
13:45:26 <mvollmer> actually, all the plots are ugly
13:45:34 <mvollmer> because they are small and have tick labels
13:45:48 <stefw> what's the source of the regression?
13:45:52 <mvollmer> and because they are just ugly
13:46:04 <andreasn> is this on master?
13:46:06 <mvollmer> previously they didn't have any tick labels
13:46:11 <mvollmer> andreasn, no, not yet.
13:46:37 <andreasn> I'm happy to check out the branch and see if there is anything that can be unuglified
13:46:39 <mvollmer> they only had a grid, which looked clean, and was quite a it larger also
13:47:04 <mvollmer> yes, that would be nice
13:47:16 <mvollmer> maybe we need to make them bigger?
13:47:20 <andreasn> what's the issue number?
13:47:20 <mvollmer> anyway
13:47:45 <mvollmer> andreasn, https://github.com/cockpit-project/cockpit/pull/2741
13:47:50 <mvollmer> #link https://github.com/cockpit-project/cockpit/pull/2741
13:47:52 <andreasn> thanks
13:48:15 <mvollmer> I also think that the server page with the four graphs is quite ugly...
13:48:41 <andreasn> on master or on this branch?
13:48:46 <mvollmer> on master
13:49:38 <andreasn> there is some new style guides on graphs in patternfly, would be nice to adapt to those
13:49:43 <andreasn> they look less busy
13:49:59 <stefw> we need to rework our dashboards
13:50:03 <stefw> to match the patternfly dashboards
13:50:15 <stefw> i think all three would be good, no?
13:50:21 <andreasn> yeah
13:50:21 <stefw> https://www.patternfly.org/patterns/dashboard-layout/
13:52:05 <andreasn> yeah, these looks pretty clean
13:52:16 <dperpeet> do we use https://www.patternfly.org/patterns/sparkline/ ?
13:52:55 <andreasn> no, I think those are newer than our graphs
13:53:14 <andreasn> the page is like a month old
13:53:17 <dperpeet> I wonder if using that would incur performance issues
13:53:46 <dperpeet> we would have to compare the update mechanics, I think
13:53:50 <andreasn> yeah
13:54:15 <andreasn> did mvollner get disconnected?
13:54:40 <andreasn> what's the next topic?
13:55:12 <dperpeet> this was the last topic
13:55:19 <dperpeet> next?
13:55:44 <andreasn> open floor I guess
13:55:46 <dperpeet> #topic open floor
13:56:28 <andreasn> I have SSH key designs on paper now, will create proper digital mockups and have them ready in a bit
13:56:35 <dperpeet> great
13:57:18 <andreasn> the selinux mockups are still in flux, but getting there
13:57:48 <stefw> andreasn, i'd like to talk a bit about the SSH key designs
13:57:58 <andreasn> good, me too :)
13:58:00 <stefw> and make sure we cover the "my current credentials" use case
13:58:07 <stefw> including the dumb "Drop extra privileges"
13:58:14 <stefw> finally we can end up solving that
13:58:44 <dperpeet> that menu entry is confusing if you don't know the implementation :)
13:58:56 <mvollmer> whoops, network went down here
13:59:00 <andreasn> it's anti-sudo :)
13:59:10 <stefw> right, so if we move all of these things into a dialog
13:59:19 <stefw> "Login credentials" or something like that
13:59:29 <andreasn> that's a nice label
13:59:40 <stefw> we could have [x] Use my credentials to escalate privileges automatically
14:00:04 <stefw> "The following keys to authenticate against other servers"
14:00:19 <stefw> something along those lines?
14:00:38 <dperpeet> why not label it just "credentials"?
14:00:54 <andreasn> so the dialog will list the private keys, right?
14:01:29 <petervo> we need a way to load keys too
14:01:47 <petervo> change passwords?
14:01:47 <dperpeet> and generate new ones?
14:01:57 <andreasn> yep, what I have on my list is:
14:02:05 <andreasn> * change password of individual key
14:02:10 <andreasn> * load new keys
14:02:19 <andreasn> * copy out public key of individual key
14:02:32 <andreasn> * turn keys on and off
14:02:39 <andreasn> * show fingerprint
14:03:02 <dperpeet> what about:
14:03:02 <andreasn> is loading a new key the same as creating a new key?
14:03:04 <dperpeet> * copy out private key
14:03:09 <dperpeet> * generate new key
14:03:19 <dperpeet> maybe loading / generating could be the same dialog
14:03:33 <dperpeet> hm, we're already in a dialog?
14:03:40 <dperpeet> it isn't the same
14:03:40 <stefw> yes, in a dialog, as previously discussed
14:03:49 <stefw> but andreasn, generating a key can be done for any user
14:03:56 <stefw> could be in the users UI ... to be honest
14:04:03 <dperpeet> I'd say generating one is a separate feature, but extra scope
14:04:17 <stefw> but this would be a good place to have a generate button
14:04:25 <stefw> because otherwise people have to run around the ui to get the task done
14:04:49 <dperpeet> yep
14:05:12 <andreasn> ok
14:05:45 <mvollmer> there is also FreeIPA that can distribute keys, no?
14:08:43 <andreasn> anyway, I think I can get the escalate priviledges and the ssh keys into the same dialog
14:08:53 <andreasn> hopefully at least
14:09:14 <andreasn> anything more for the meeting?
14:09:39 <mvollmer> nope
14:09:49 <mvollmer> #endmeeting