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