14:01:46 <andreasn> #startmeeting Cockpit 14:01:46 <zodbot> Meeting started Mon Feb 16 14:01:46 2015 UTC. The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:58 <andreasn> .hello andreasn 14:02:00 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com> 14:02:13 <andreasn> who else is here? 14:02:26 <mvollmer> .hello mvo 14:02:27 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 14:02:30 <dperpeet> .hello dperpeet 14:02:31 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com> 14:02:40 <sub-mod> .hello sub-mod 14:02:41 <zodbot> sub-mod: Sorry, but you don't exist 14:03:04 <mvollmer> sub-mod, you need to give your Fedora account id thingy. 14:03:17 <mvollmer> sub-mod, I don't think it is important. 14:03:18 <andreasn> petervo, stefw: you around as well? 14:03:21 <sub-mod> ah , i was thinking freenode one 14:04:49 <mvollmer> ok, agenda.... 14:04:50 <andreasn> #chair dperpeet andreasn mvollmer sub-mod 14:04:51 <zodbot> Current chairs: andreasn dperpeet mvollmer sub-mod 14:05:00 <mvollmer> * Brief metrics update 14:05:04 <andreasn> #topic agenda 14:05:24 <mvollmer> * Brief metrics update 14:05:32 <andreasn> * OS Updates, but only if petervo is around 14:05:33 <mvollmer> * Way forward with pmlogger 14:05:41 <petervo> i'm here 14:05:47 <andreasn> ah, excellent 14:06:02 <sub-mod> * Kubernetes plugin update 14:06:04 <andreasn> * enterprise subscription support 14:07:03 <andreasn> * docker validation maybe? 14:07:13 <dperpeet> yes, very briefly 14:07:23 <andreasn> ok, sounds like we're good to go 14:07:32 <andreasn> #topic brief metrics update 14:07:52 <mvollmer> going quite well, zooming works 14:08:14 <mvollmer> now refactoring things so that we can drive all plots from a single source 14:08:38 <mvollmer> and don't need to poll twice for two CPU plots, for example. 14:08:42 <andreasn> nice! 14:08:52 <mvollmer> code gets nicer with every refactoring, which is a good sign. 14:08:56 <andreasn> #info metrics zooming https://github.com/cockpit-project/cockpit/pull/1816 14:09:16 <andreasn> I've been unable to run this, but not sure if that's a issue on my end or not 14:09:19 <mvollmer> this needs some serious design love, though 14:09:28 <mvollmer> we'll figure that out 14:09:32 <andreasn> yeah 14:10:03 <andreasn> so this is for the dashboard only right now, right? 14:10:19 <mvollmer> the code in the bridge now does more in a pcp-independent way, and we can use that for other data sources, like our old cgroups monitor 14:10:26 <mvollmer> andreasn, yes. 14:10:53 <mvollmer> the current refactoring will make it trivial(tm) to switch the #server page over to metrics channels. 14:11:00 <andreasn> great 14:11:04 <mvollmer> but it will need its own code for zooming etc. 14:11:25 <mvollmer> this is all still under review 14:12:12 <andreasn> and hopefully I'll get it running soon 14:12:26 <andreasn> anything else on that point? 14:12:37 <mvollmer> there is a nice bug waiting for you: if you zoom out far enough, the plots start dancing. 14:12:51 <mvollmer> really weird. :-) 14:13:30 <andreasn> ooh :) 14:13:31 <mvollmer> no, nxt topic 14:13:48 <andreasn> #topic OS Updates 14:14:18 <andreasn> petervo is working on this. And is planning to support both ostree and rpm 14:14:44 <petervo> i have a PR waiting with packagekit for adding a method to their dbus api 14:14:49 <stefw> link? 14:14:59 <petervo> https://github.com/hughsie/PackageKit/pull/46 14:15:15 <petervo> also trying to see what can be done about all the dependencies 14:15:38 <stefw> yes, very good 14:15:38 <petervo> i thought it was just a packaging issue 14:15:41 <andreasn> does it have a heavy dependency list? 14:15:42 <petervo> but it's not 14:15:50 <petervo> yes very 14:16:16 <petervo> so looking for a way forward on that 14:16:23 <stefw> hmmm interesting 14:16:25 <andreasn> does it pull in X and all? 14:16:38 <petervo> https://github.com/hughsie/PackageKit/commit/62bc031cab55e1830a99f79ea12b7e59a9f54c3a 14:17:00 <fabiand> hey 14:17:09 <petervo> that commit added a bunch of x and gtk deps to the main PackageKit rpm 14:17:12 <fabiand> I just saw today that cockpit from F22 pulls in mesa components - indirectly. 14:17:22 <stefw> fabiand, oh my :S 14:17:27 <andreasn> hups 14:17:45 <petervo> for ostree, starting work on a dbus api to support the basic operations 14:17:59 <stefw> cool 14:18:10 <stefw> petervo, so obviously the ostree and PackageKit work will have to be optional 14:18:17 <stefw> because they're not available everywhere 14:18:23 <petervo> yes 14:18:39 <stefw> petervo, but if you feel we could do better just using the yum + http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ 14:18:43 <andreasn> I've started some mockups based on the Update stories in the wiki, but still sketchy 14:18:49 <stefw> petervo, then that would be your call 14:19:34 <stefw> if it turns out that PackageKit doesn't actually do much more than a few yum commands when preparing the system for http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ 14:19:52 <stefw> then i guess we should consider that 14:20:16 <stefw> the downside of course being that every package manager would need some abstraction :S 14:21:06 <stefw> fabiand, if you have the dependency tree that pulls in mesa, can you post about it to cockpit-devel? 14:21:11 <stefw> we need to sort that out ahead of Fedora 22 14:21:23 <petervo> yeah, it also handles the actual install during the boot 14:21:30 <fabiand> stefw, yeah, that is on my list . I try to work that out .. 14:21:41 <lonix> I Just discoverd this 14:22:04 <petervo> but we could work around without packagekit if we have to 14:22:23 <lonix> IS there any particular reason there is no deb package or as a container for debian\ubuntu ? 14:22:37 <lonix> Sorry if im asking dumb here... 14:22:52 <andreasn> lonix: nobody packaged it yet 14:23:00 <stefw> someone did 14:23:03 <stefw> but just last week 14:23:14 <lonix> So there is not a technical then 14:23:35 <stefw> https://github.com/oerdnj/deb.sury.org/issues/38 14:23:38 <andreasn> oh https://lists.fedorahosted.org/pipermail/cockpit-devel/2015-February/000251.html 14:23:59 <stefw> we're having the cockpit weekly meeting now though, so probably best to get back on topic 14:24:12 <andreasn> yep, next topic 14:24:22 <lonix> sorry 14:24:23 <andreasn> #topic Way forward with pmlogger 14:24:27 <mvollmer> right 14:24:41 <mvollmer> i have no good plan, but will try to come up with ont. 14:24:42 <andreasn> (we also have a open floor as a last item on the agenda) 14:24:43 <mvollmer> *one 14:25:19 <mvollmer> i still need to check pmmgr and see whether that is better than pmlogger+support-scripts 14:25:44 <mvollmer> the basic problem with pmlogger is that its integration with systemd is weird 14:25:58 <stefw> they really just need to fix it 14:26:08 <mvollmer> no failure messages in the journal, unit status does not reflect pmlogger status 14:26:11 <mvollmer> yeah 14:26:16 <stefw> otherwise it's unusable for us 14:26:19 <andreasn> the whole "sure, sure, I'm stopped, but ACTUALLY IM LYING HAHAHA" 14:26:19 <mvollmer> but maybe pmmgr is the fix. 14:26:24 <andreasn> ? 14:27:16 <mvollmer> however, we can do our part: starting/stopping will work well enough. 14:27:25 <mvollmer> as long as pmlogger doesn't fail. 14:28:04 <mvollmer> I don't see much movement re bug fixing 14:28:20 <mvollmer> so we might need to help, and have a fallback plan. 14:29:07 <stefw> maybe systemd will reimplement pcp and save us all 14:29:09 <stefw> :) 14:29:11 <andreasn> hehe 14:29:15 <mvollmer> hehe. 14:29:15 <stefw> no but seriously 14:29:20 <stefw> i guess we should start patching pcp 14:29:30 <stefw> if they don't accept patches, then we know it's not just a matter of being overloaded 14:29:44 <stefw> and we have to turn somewhere else. best case, they accept patches for the issues we've run into 14:30:10 <stefw> ditto for PackageKit 14:30:23 <stefw> if they want to be relevant on the server, we can help, and see if they accept patches, etc. 14:30:30 <stefw> otherwise we can try and find another solution 14:30:32 <mvollmer> it might be difficult to fix the established pcp scripts-and-cron-magic infrastructure without breaking it for someone else 14:30:51 <mvollmer> but we can build a alternative 14:30:59 <stefw> well then pcp is not usable for us? only for dudes in white lab coats somewhere? 14:31:07 <mvollmer> parts of it 14:31:09 <stefw> so we have to find a compromise 14:31:17 <mvollmer> yeah 14:31:34 <mvollmer> libpcp, pmcd, pmdas: good 14:31:34 <andreasn> next topic? 14:31:43 <andreasn> whups, sorry 14:31:48 <mvollmer> pmlogger: mostly good 14:32:05 <mvollmer> pmlogger_check, pmlogger_daily: mmkay 14:32:36 <mvollmer> I'll figure this out by next week, I hope. 14:32:45 <mvollmer> it's more fun to tweak the graphs. :-) 14:33:01 <andreasn> :) 14:33:10 <andreasn> all right, lets move ahead 14:33:12 <andreasn> Kubernetes plugin update 14:33:12 <mvollmer> yep 14:33:16 <andreasn> err 14:33:20 <andreasn> #topic Kubernetes plugin update 14:33:37 <stefw> so i've been working on this a bit 14:33:38 <sub-mod> stefw do you want to start ? 14:33:42 <stefw> sure 14:33:52 <stefw> as mentioned in an earlier discussion, we're currently targetting a proof of concept. 14:34:04 <stefw> Kubernetes itself doesn't yet "work" per se. 14:34:15 <stefw> in that there are large holes that are currently being worked on. 14:34:26 <stefw> eg: security between containers and the system, or storage of stateful containers 14:34:47 <stefw> so the fact that we're now doing a proof of concept frees us up a bit 14:34:53 <stefw> we no longer have to completely set up the kubernetes cluster 14:35:09 <stefw> and secondly, we can require cutting edge version of kubernetes, rather than the one in atomic 14:35:22 <stefw> so ... the first thing i've done after this is move to the new v1beta3 API 14:35:34 <stefw> this is a significant change, and i'm glad we haven't done more work against the old API 14:35:59 <stefw> what i worked on today was using kube-apiserver to monitor for changed objects 14:36:10 <stefw> they have a very nice 'watch' API, which returns all the objects, and then changes to them 14:36:27 <stefw> and has a concept of a resourceVersion which lets you make sure yo udon't miss any changes 14:36:35 <stefw> much like etcd, and perfect for Cockpit 14:36:54 <stefw> in addition i've done some design work: 14:37:17 <stefw> https://github.com/cockpit-project/cockpit/issues/1687#issuecomment-74067191 14:37:51 <stefw> we got feedback from people last week that the first screen of showing the cluster needs to be dead simple 14:38:20 <stefw> otherwise we don't reach our goal: "Make complex features discoverable" 14:38:20 <stefw> with kubernetes, that's really the only goal that's relevant 14:38:51 <stefw> so it would be nice to show a very simple screen first, and then dive into more complex models and graphs ... the latter which are to be shared with the openshift team 14:39:17 <andreasn> looks good 14:39:25 <stefw> there has been wireframes on the more complex browse screens from openshift ... and i've volunteered to turn them into html 14:39:36 <stefw> in addition, i've already turned the above screen into html: 14:39:58 <stefw> https://github.com/cockpit-project/cockpit-design/blob/master/kubernetes/dashboard.html 14:40:17 <stefw> i think that about covers it on the kubernetes status update from me 14:40:26 <stefw> sub-mod, anything to add? 14:41:12 <sub-mod> I am currently looking at label-query , 14:41:39 <sub-mod> which currently needs moving to v3 api , 14:42:06 <sub-mod> kubernetes has added a lot more constructs like namespace , resource , spec , etc 14:42:09 <stefw> yes a lot blocks on the v1beta3 API work 14:42:35 <sub-mod> yep 14:43:10 <sub-mod> thats all from last week 14:44:22 <mvollmer> i still need to try this all out. 14:44:28 <mvollmer> last time I think I ran out of disk 14:44:39 <stefw> heh, my main server is just churning and churning 14:44:44 <stefw> because kubernetes is trying to do crazy stuff 14:44:57 <stefw> so it's not really all stable yet, i don't think 14:44:59 <mvollmer> running out of disk is not supported, I guess. 14:45:17 <stefw> well docker generally just does harikari when disk runs out 14:45:18 <sub-mod> resource limits will take care of that 14:45:20 <mvollmer> it wasn't clear at all what was happening, just creaming in the journal 14:45:23 <mvollmer> :-) 14:45:25 <mvollmer> *screaming 14:45:47 <mvollmer> anyway, anecdotes 14:45:59 <andreasn> we're getting closer to the hour mark 14:46:08 <sub-mod> and also kubernetes is having policy under devleopment, so we can have policy along with resource limits to avoid such situations 14:46:12 <andreasn> so lets move on if that was all re kubernetes 14:46:18 <sub-mod> ok 14:46:32 <andreasn> #topic enterprise subscription support 14:46:49 <andreasn> so this is something me and dperpeet is working on right now 14:46:52 <dperpeet> andreasn posted a wiki page https://github.com/cockpit-project/cockpit/wiki/Subsciptions 14:47:20 <andreasn> and this is the trello page https://trello.com/c/szxKULKA 14:47:36 <dperpeet> to sum it up, we decided to do a bare minimum implementation 14:48:09 <andreasn> and then more complex workflows can follow later 14:48:11 <dperpeet> show whether a system has subscriptions or not and to help set them up 14:48:31 <dperpeet> I don't have all things in place yet that I need to start serious work on that 14:48:55 <dperpeet> so more next week :) 14:49:10 <dperpeet> for now, look at the use cases and see if they are enough 14:50:19 <dperpeet> that's it from my point, regarding subscription support 14:50:49 <andreasn> greaty 14:50:59 <andreasn> great I mean 14:51:07 <andreasn> next up is some docker 14:51:12 <andreasn> #topic docker validation 14:51:33 <dperpeet> well, it's regading #1772 14:51:35 <andreasn> #info https://github.com/cockpit-project/cockpit/pull/1772 14:51:46 <dperpeet> after feedback from andreasn and stefw we've decided to simplify the validation 14:52:09 <dperpeet> there will be no messages until the user presses "run" for the first time 14:52:35 <dperpeet> at that point, we will check for errors - if there are any, they will be displayed and the 'run' command aborted 14:52:59 <andreasn> that will avoid displaying errors on launch of the dialog 14:53:03 <dperpeet> yes 14:53:15 <dperpeet> after that first check, we will keep checking like before 14:53:25 <dperpeet> so as soon as you fix an error, that message will disappear 14:53:42 <dperpeet> and when there are no more errors, 'run' will become available again 14:53:49 <andreasn> dperpeet also suggested filling the link alias names with a default name, so that will reduce the number of errors as well 14:53:55 <andreasn> but as a separate pull request for that 14:54:17 <dperpeet> also, we decided to get rid of warnings - namely ports, if one of the two fields is empty 14:54:28 * stefw has gotta run now. talk to you guys later o/ 14:54:34 <andreasn> later stefw! 14:54:55 <andreasn> dperpeet: could you document the above on the pull request? 14:55:02 <andreasn> so it doesn't get lost in time and space? 14:55:12 <dperpeet> I will comment when I push the changes 14:55:17 <andreasn> sounds good 14:55:27 <andreasn> #topic open floor 14:55:42 <andreasn> we have five minutes to go 14:55:57 <dperpeet> what's our targeted browser compatibility? 14:56:13 <andreasn> http://cockpit-project.org/running.html 14:56:21 <andreasn> under Minimum client browser versions 14:56:28 <dperpeet> ah, thanks 14:58:18 <andreasn> I think those all support web sockets 14:58:26 <andreasn> and that's the criteria there 14:59:04 <dperpeet> I asked because stefw proposed that I use hidden attribute instead of display: none, but according to http://www.w3schools.com/tags/att_global_hidden.asp that's ie11+ 14:59:20 <andreasn> oh, I see 14:59:30 <dperpeet> everyone else adopted it a lot earlier 15:00:12 <andreasn> was this in the docker validation? 15:00:18 <andreasn> docker validation issue 15:00:20 <dperpeet> yes 15:00:28 <dperpeet> I'll comment there 15:00:37 <andreasn> I'll check it out as well 15:00:44 <andreasn> I think that was all for today 15:00:48 <andreasn> #endmeeting