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