14:00:54 <stefw> #startmeeting 14:00:54 <zodbot> Meeting started Mon Mar 2 14:00:54 2015 UTC. The chair is stefw. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:57 <mvollmer> i was mostly worried that someone did some work for us and then we ignored it. 14:00:59 <stefw> #meetingname cockpit-weekly-meeting 14:00:59 <zodbot> The meeting name has been set to 'cockpit-weekly-meeting' 14:01:02 <stefw> #meetingtopic Cockpit Weekly Meeeting 14:01:18 * mvollmer has 10 minutes... :-/ 14:01:26 <stefw> lets list agenda 14:01:31 <dperpeet> I have to leave a bit early as well 14:01:39 <stefw> * Multiple dashboard status 14:01:59 <stefw> * Removal of package aliases 14:02:10 <mvollmer> * New test infra update 14:02:43 <stefw> * GZIP compression of resources and use of debuginfo for non-minified 14:02:56 <mvollmer> * Optional PCP 14:03:09 <stefw> alright, should we start, before everyone has to run away? 14:03:23 <stefw> #topic New test infra update 14:03:26 <mvollmer> yep 14:03:33 <dperpeet> yes 14:03:35 <mvollmer> Good progress, really close 14:03:51 <mvollmer> we found a way to make virt-deploy use a custom network 14:04:06 <stefw> oh good 14:04:11 <mvollmer> once that is in, we start testing it on files.cp.o 14:04:27 <mvollmer> jan has ported check-realms 14:04:32 <stefw> oh cool 14:04:37 <mvollmer> as an example of a difficult test 14:04:39 <stefw> so i guess he'll rebase on top of dashboard-multi? 14:04:48 <mvollmer> yes 14:05:04 <mvollmer> the changes are quite independent. 14:05:33 <mvollmer> so, any day now... :-) 14:05:47 <mvollmer> but then we need to port the rest of the tests 14:06:00 <mvollmer> I haven't checked yet what changes are necessary 14:06:01 <stefw> #action jscotka and mvollmer will test new CI on files.cp.o once custom network code is merged 14:06:29 <mvollmer> eot? 14:06:31 <stefw> ideally jscotka will contiue to be able to help 14:06:36 <stefw> #topic Optional PCP 14:06:54 <mvollmer> So we decided to make PCP optional, and stef did the work. 14:07:00 <stefw> only part of it 14:07:14 <stefw> #info https://trello.com/c/ub3zQOUE/129-pcp-optional-dependency 14:07:22 <mvollmer> The missing piece are internal metrics for the graphs that we currently have. 14:07:31 <mvollmer> I'll continue with that 14:07:46 <mvollmer> I think I put it on top of the current metric pull requests 14:07:52 <stefw> in addition, this is a big part of migrating away from cockpitd 14:07:58 <mvollmer> yes, true 14:08:15 <mvollmer> those pull requests block a bit on andreas for the final tweaks 14:08:40 <mvollmer> should start rolling tomorrow 14:09:21 <mvollmer> eot? :) 14:09:24 <stefw> #topic Multiple dashboard status 14:09:39 <stefw> last week i finished implementing the multiple dashboard and new navigation code 14:09:42 <stefw> #info https://github.com/cockpit-project/cockpit/pull/1861#issuecomment-76426457 14:09:46 <stefw> you can see a screenshot tour at the link above 14:10:02 <stefw> the basic concepts have remained the same since we discussed it, although a few design tweaks happened while implementing it 14:10:20 <stefw> particularly in order to make it really easy to jump to machines, when you're on one of the dashboards 14:10:48 <stefw> i put a lot of work into making Cockpit look really good for the single machine use case 14:10:52 <stefw> and then upgrade gracefully when you add a second machine 14:11:06 <stefw> in particular, things like the host switcher are not shown when there is just one machine 14:11:22 <stefw> there are lots of follow up issues noted, to further fine tune the work 14:11:30 <stefw> but because this is a big navigation change, we shouldn't block on those 14:11:57 <stefw> mvollmer is reviewing the code, found one last issue 14:12:02 <stefw> well one last test failure 14:12:28 <stefw> #info All the Cockpit links change 14:12:36 <stefw> #info You need to reinstall Cockpit after this change 14:12:40 <stefw> and restart it 14:12:51 <stefw> that's it from me on that topic 14:13:22 <stefw> #topic Removal of package aliases 14:13:44 <stefw> As a follow on from last week's work on simplifying the package system, I'd like to remove the concept of package aliases 14:14:02 <stefw> #info https://github.com/cockpit-project/cockpit/pull/1869 14:14:15 <stefw> Makes things simpler and more understandable ... 14:14:29 <stefw> requires renaming a couple of the directories in pkg/ and the location to which they're installed 14:14:48 <stefw> mvollmer gets to say "told you so" with regard to package aliases :) 14:15:11 <stefw> that's it on that topic 14:15:49 <petervo> so something like which system update status 14:16:24 <petervo> should i get needs to have explicit logic or be solved by packaging 14:16:33 <stefw> to be solved by packaging 14:16:50 <stefw> in Fedora and RHEL we would likely end up with two sub packages that conflict with each other 14:17:00 <stefw> if we want to get more fancy than that, we can use the alternatives system, and symlinks 14:17:09 <petervo> ok 14:17:10 <stefw> but i prefer the former, unless there's a reason to get more complex 14:17:17 <stefw> but in both cases these are handled by downstream packaging 14:17:30 <stefw> there is one open question: what do we do on 'make install'? 14:18:17 <stefw> could be that we install both OS update packages to /usr/share/cockpit/alternatives/xxx 14:18:43 <stefw> and put a symlink in /usr/share/cockpit/updates ... if nothing exists at that location 14:18:52 <stefw> as a sort of poor mans "alternatives" system 14:19:04 <stefw> but in any case the current aliases system did not solve this properly 14:19:17 <stefw> the first package alphabetically with the given alias would get used 14:19:39 <stefw> so removing aliases makes it much more explicit and transparent 14:19:46 <petervo> oh interesting i never actually tried it 14:20:10 <petervo> this seems good, i'm sure we can make it work 14:20:10 <stefw> next topic? 14:20:32 <stefw> #topic GZIP compression of resources and use of debuginfo for non-minified 14:20:39 <stefw> #info https://github.com/stefwalter/cockpit/tree/gzip-compression 14:20:49 <stefw> i've done some work on loading and passing gzipped resources in packages 14:21:00 <stefw> Files would be installed already gzipped 14:21:08 <stefw> eg: pkg/base/cockpit.js.min.gz 14:21:21 <stefw> and then they are served with Content-Encoding: gzip 14:21:47 <stefw> This speeds up loading of cockpit 14:21:58 <stefw> and also nice, reduces our install size a bit 14:22:12 <dperpeet> do you have metrics on the actual speedup? 14:22:18 <stefw> yes 14:22:29 <stefw> 3.2 M -> 640K 14:22:35 <stefw> for a load of all resources 14:23:01 <stefw> well, actually that's the unminified status 14:23:02 <stefw> wait 14:23:15 <stefw> 1.4M -> 640K 14:23:22 <stefw> is the reduction when already minified -> gzipped 14:23:32 <stefw> this includes things that aren't gzipped such as images 14:23:43 <stefw> gzipping a png file makes it bigger, so obviously we wouldn't do this for everything 14:23:45 <dperpeet> not bad - it'll probably help even more once we look at multiple machines and pull things from there 14:23:56 <stefw> multiple identical machines are already deduplicated 14:24:12 <stefw> if they have identical cockpit installs, then they share urls, and thus the browser cache 14:24:32 <stefw> and the amount of resources data loaded from the second machine is about 200 bytes 14:24:44 <dperpeet> yes, but the interesting case is when we have different versions and configurations 14:24:48 <stefw> indeed 14:24:59 <dperpeet> so, good job on that! 14:25:02 <stefw> the down sides are: 14:25:16 <stefw> when we want to modify a resource during serving (which we still unfortunately have to for certain html files) 14:25:22 <stefw> we have to uncompress it 14:25:29 <stefw> and we do that on the fly in cockpit-bridge 14:25:32 <stefw> at least in that branch above 14:25:43 <stefw> but this is really fast, and i don't think it's such a big problem 14:25:55 <stefw> to mitigate this we could just not ship those files compressed 14:26:07 <stefw> but i wanted to make sure this was generic, and wouldn't fall over 14:26:29 <stefw> this work is not done yet, but basic code is written, and played with it a bit 14:27:10 <stefw> 2. on the second part of this topic: i'd like to have downstreams ship the non-minified (and non-gzipped) resources in the debuginfo package 14:27:24 <stefw> in Fedora they would be installed with the cockpit-debuginfo package 14:27:29 <dperpeet> that makes sense 14:27:46 <dperpeet> and lowers the hurdle for useful bug-reporting significantly 14:27:48 <stefw> or perhaps in a noarch debuginfo 14:27:58 <stefw> yeah 14:28:03 <stefw> we currently ship it all together 14:28:11 <stefw> but this would split it out, so really just the stuff needed to run cockpit comes by default 14:28:14 <stefw> and the rest comes optionally 14:28:59 <stefw> but this needs some more thought 14:29:35 <stefw> that's it from me on that topic 14:30:05 <stefw> #topic Open Floor 14:30:22 <stefw> dperpeet, petervo, sub-mod, jvance, do any of you have further topics to add? 14:30:49 <dperpeet> nope 14:30:49 <petervo> i don't 14:31:56 <stefw> 3 ... 14:32:02 <stefw> 2 .... 14:32:07 <stefw> 1 ... 14:32:14 <stefw> boom 14:32:15 <stefw> #endmeeting