13:01:46 #startmeeting 13:01:46 Meeting started Mon Apr 13 13:01:46 2015 UTC. The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:59 .hello andreasn 13:02:00 andreasn: andreasn 'Andreas Nilsson' 13:02:00 .hello dperpeet 13:02:03 dperpeet: dperpeet 'Dominik Perpeet' 13:02:12 .hello sgallagh 13:02:13 sgallagh: sgallagh 'Stephen Gallagher' 13:02:19 .hello mvo 13:02:20 mvollmer: mvo 'Marius Vollmer' 13:02:31 .hello stefw 13:02:32 stefw: stefw 'Stef Walter' 13:02:52 petervo: around as well? 13:03:33 #topic Agenda 13:03:38 what do we have today? 13:03:42 * Metrics, Graphs, cAdvisor, Kubernetes update 13:03:44 * Fedora 22 13:03:52 * OSTree update, if Peter's around 13:04:06 * Services rework 13:04:53 yep 13:05:14 * Multi OS testing 13:06:04 * New CI migration progress 13:06:14 * Translations to Zanata 13:07:34 sounds like we have quite the agenda to fill the hour 13:07:38 ok, lets start 13:07:51 * Metrics, Graphs, cAdvisor, Kubernetes Update 13:07:54 err.. 13:08:01 #topic Metrics, Graphs, cAdvisor, Kubernetes Update 13:08:28 I've been writing some javascript code to handle populating time series data from various sources, including our own metrics channels, and also things like cAdvisor 13:08:32 some work here: https://github.com/cockpit-project/cockpit/pull/2131 13:09:05 I'll continue working on this and adapting it until I have working graphs on the kubernetes page and also pulling from some other source 13:09:22 the goals of the work are to a) Put something other than 'TODO Graphs' on the cluster dashboard 13:09:33 and b) migrate the remaining graphs throughout cockpit to use the metrics channels 13:09:51 One other interesting thing to note, is that cAdvisor now comes as part of kubernetes (in the kubelet process) 13:09:56 sounds like good goals 13:10:05 the other interesting thing to note is that 'docker stats' sucks various things 13:10:06 happy to hear the TODO going away 13:10:33 i think that's the brief highlevel, i don't mind going into more detail if people have questions 13:10:59 just to confirm: 13:11:09 does the kubernetes page still use the old patternfly version? 13:11:18 this will allow us to port the 'multi' graphs away from cockpit-wrapper, right? 13:11:30 andreasn, i don't think so 13:11:36 mvollmer, yes, that's right 13:11:43 multi graph = multiple network devices in one plot. 13:11:52 stefw: so we're rid of the old patternfly? Nice! 13:11:52 right, very good. 13:11:55 andreasn, yes 13:12:02 mvollmer, the code contains ways to combine information from multiple channels into a single 'grid' ... and then perform calculated rows 13:12:05 as well 13:12:20 nice. 13:12:41 so in theory you could even do crazy things like combining data from cAdvisor and metric channels into a single graphs 13:12:59 /s$// 13:13:02 doesn't sound too crazy. 13:13:50 we do this by quantizing the time series data 13:13:51 so that it lines up based on the interval 13:14:28 we already had some elements of this in our metric channel code, but this takes it a step further, so that you can intelligently calculate stuff between various sources 13:14:49 #info https://github.com/cockpit-project/cockpit/pull/2131 13:15:14 sounds good 13:15:30 #topic Fedora 22 13:15:30 very nice indeed. 13:15:49 sgallagh: when is the beta date? 13:15:57 one thing on the list is "partial exposures" to make scrolling smoother 13:15:59 does that fit into #2131? 13:16:19 err, I mean, did you take it into consideration already? 13:16:32 in the D3 world the smoother scrolling happens at the view level 13:16:42 (don't want to say that it should be part of it) 13:16:42 and has nothing to do with the data 13:16:44 mvollmer: We are in Beta freeze right now 13:16:53 We hoped to release tomorrow, but we had to slip a week. 13:16:57 all right 13:17:02 me missed the topic change, sorry. 13:17:28 We need to have a new Release Candidate today or tomorrow to approve the release at Go/No-Go on Thursday 13:17:31 mvollmer, so i'm personally not ready to figure that out, as i don't understand the tradeoffs 13:17:51 (oops, I responded to mvollmer and meant to respond to andreasn) 13:18:04 no worries, now we should be on the Fedora 22 topic 13:18:14 it's all messed up, let's start again! 13:18:28 :-) 13:18:52 [cockpit] stefwalter opened pull request #2134: tools: Allow make-srpm and make-rpms to be used without git clone (master...make-srpm-without-git) http://git.io/vv3wT 13:18:59 do we have everything that we want in F22? 13:19:20 andreasn, we want to push some more changes 13:19:24 would be nice to get https://github.com/cockpit-project/cockpit/pull/2061 in, so I'll review that asap 13:19:26 there are several that help with Fedora Atomic 13:20:01 I think we're totally within the guidelines pushing our recent releases into Fedora after the beta freeze. 13:20:47 right 13:20:55 anything else on that topic? 13:21:39 #topic OSTree update 13:22:06 still don't have any ui to show 13:22:29 finalizing the changes based on the last feedback i got from the ostree guys 13:22:48 how are things with the dependencies? 13:23:18 ostree is fine, packagekit was the one with the issues 13:23:26 right 13:23:42 but we decided to not do any implementation there for now and focus on ostree 13:23:56 yeah, I mixed them up 13:24:06 [cockpit] mvollmer closed pull request #2133: shell: Correctly transcribe !startsWith to indexOf !== 0. (master...fix-starts-with) http://git.io/vvOAr 13:24:31 let me know as soon as you have any ui I can play around with, anxous to try that 13:24:44 play around/destroy systems 13:24:49 andreasn, petervo, by the way /usr/local/share/cockpit is the ticket 13:25:02 ticket? 13:25:05 as well as ~/.local/share/cockpit 13:25:12 when trying to develop this stuff directly on top of Atomic 13:25:16 as you can't 'make install' 13:25:19 oh, good to know 13:25:20 right 13:25:33 so you just compile things and dump them into that? 13:25:52 just copy or link the pkg/ostree (if that's what peter calls it) directory into those locations 13:25:58 and ideally that'd be enough 13:26:01 good 13:26:16 compiling is a good step to check javascript correctness and stuff like that 13:26:40 all right. Anything else on ostree? 13:26:55 petervo, any obstacles come up? 13:27:25 i have one issues i wouldn't mind getting advice on, but we can talk after the meeting 13:27:29 k 13:27:42 #topic Services rework 13:28:14 alright 13:28:35 I have been rewriting the old services page 13:28:37 to directly talk to systemd 13:28:46 this is still work in progress 13:29:04 https://github.com/cockpit-project/cockpit/pull/2128 13:29:18 nice 13:29:25 works well enough, and it's not much code at all at the end of the day 13:29:30 cool 13:29:46 stefw has given us a very nice architecture, it's a lot of fun 13:30:23 the graphs are gone for now, but should come back after "the grid", I guess 13:30:28 thanks. glad it's fun :) 13:30:33 so did you move it into a component? 13:30:36 or is that a seperate step? 13:30:39 oh wait, i see it here 13:30:39 yes, systemd/init 13:30:42 nice 13:31:16 we can add the graphs back later 13:31:26 i am still not happy with the code structure, but, yes, it's not a lot of code, so... 13:31:31 they need to also be conditional, and have a way of turning on and off the cgroup stuff that makes them work 13:31:36 one open issue is whether or not to use DBusProxies for the long lists. 13:32:06 i don't use them now, but I should try and if anything makes it problematic, we should try to fix that. 13:32:09 DBusProxies works well with org.freedesktop.DBus.ObjectManager based services 13:32:30 which systemd is not, but they should work well regardless 13:32:32 so since systemd doesn't use ObjectManager, if DBusProies doesn't work 13:32:40 then it wouldn't be *too* much of a surprise 13:33:14 i am worried about excessive traffic, and the mysterious UnitNew/GetAll loop. 13:33:22 indeed 13:33:29 what is "the grid"? Isn't that a TRON thing? 13:33:33 since the systemd code forces us to do roundtrips 13:33:37 andreasn, the first agenda point 13:33:50 ah, ok 13:34:24 "the grid" is the metric channel/plot interfacing thing that stef is doing. 13:34:43 right 13:34:50 ok, next topic? 13:35:10 #topic Multi OS testing 13:35:22 * andreasn rushes along with the agenda 13:35:27 let me know if it's too rushed 13:35:34 stefw, yeah, so we would call ListUnits to trigger the filling of the cache, which would flood the bus with 200 or so GetAll messages. 13:35:34 yep 13:37:26 it's fine, I guess. 13:37:31 so, Multi OS testing. 13:37:44 we started testing rhel 7 along with fedora 22 on github 13:37:58 and everything is red until we figure out the issues. 13:38:07 should happen soonish. 13:38:22 https://github.com/cockpit-project/cockpit/pull/2122 13:38:25 So from my side, I'm working to have also test installing sources from mock. I have plan to rewrite all sigle host tests ASAP 13:38:32 also, hubbot now checks master. 13:38:37 dperpeet did that. 13:38:44 yeah, that's cool 13:38:50 i wish the status icons could be higher on the page 13:38:54 results are in the cockpit readme. 13:38:57 but probably at the top of README is the best we can do 13:39:00 yes. 13:39:06 mvollmer, why isn't https://github.com/cockpit-project/cockpit/pull/2122 green? 13:39:09 we can have less files in the tree. :-) 13:39:23 I haven't found any other way, except to look at http://files.cockpit-project.org/hubbot/ 13:39:40 stefw, I don't know. It was green, but not any more. 13:39:55 ah ok. good to know that it was green at one point though 13:40:13 maybe I broke it with the recent update... 13:41:02 jscotka, very good! 13:41:18 hubbot doesn't run the avocado tests anymore, unfortunately. 13:41:30 right, i think that's the next agenda item 13:41:33 it got stuck and we didn't get around to make it unstuck... 13:41:42 okay 13:41:43 mvollmer, np 13:41:44 I can get on that soon-ish 13:41:58 should we move on to CI then? 13:42:33 yup 13:42:44 #topic New CI migration progress 13:43:10 so few words 13:43:14 So now that Fedora and RHEL stuff is mostly done, I was wondering how we can make progress on this? 13:44:05 migration to new CI is in most cases very easy, supporting libs are writtend for disc anc networks 13:46:15 so i guess it'll happen by itself? 13:46:24 on my end, when writing new kubernetes tests, i'll try and use the new arch 13:46:42 but we need to figure out how to run them reliably, and make progress there 13:46:47 stefw, cool, perfect 13:46:48 as well as migrate old tests over 13:47:11 unfortunately we haven't reached the tipping point, where the work has begun to pay off 13:47:25 we should aim to get there, i guess 13:47:25 yes, the problem is from my POV, that libvirt is sometimes unreliable in 13:48:54 mvollmer, didn't we have failed tests that crashed the new CI? 13:49:05 or rather suspended it 13:49:08 We need make a small change to how we make VM snapshots 13:49:15 ok 13:49:46 no, avocado was hanging in the VMs. 13:50:02 (the snapshot comment was general) 13:50:24 it sometimes happen, discussed with avocado devel, there is (will be added feature for remote timeouts) 13:50:44 ahh, timeouts.... :-) 13:51:19 it is connected with troubles, that for example network can be gone down -> ssh connection is lost -> no results returned as an example 13:51:47 well, let's look into when we have a more significant sample base (more tests) 13:52:08 https://github.com/avocado-framework/avocado/issues/513 13:52:18 jscotka, what is the next test to be ported to the new CI? 13:53:00 and mvollmer, dperpeet ... what do you think needs to happen before we can remove an old style test that was migrated to the new CI? 13:53:01 can we put a comment in the old tests if they've been ported? that way there's a lower chance of losing changes when we delete old ones 13:53:04 hmm, it is up to us, do you have some suggetion, or I shoulduse alphabetival order :-) 13:53:20 jscotka, i would suggest check-storage 13:53:34 okay, to test also new disc library inside 13:53:34 as we discussed earlier, doing the hard ones first makes sense 13:53:38 yes 13:54:13 stefw, the new CI needs to get a clean track record of not dying on us during a significant amount of runs 13:54:23 at least a week 13:54:31 and/or have automatic recovery 13:54:57 I can get on enabling the new tests this week 13:55:04 and work with jscotka on that 13:55:10 yes probably add timeouts and as you mention some recovery (restart libvirt or similar) 13:55:12 since I've familiarized myself with hubbot 13:55:53 dperpeet, We should do that on another server, not on recept hubbot, to not waste resources on hubbot and stuct actual resutl process 13:56:09 jscotka, I think we should test it where it will be used 13:56:37 then it can run alongside the other tests 13:57:02 next topic? 13:57:12 sure 13:57:12 dperpeet, understant, but for me clean enviroment is better, because it also shows that there are some undocumented things, like (installing packages, what are on hubbot already installed) 13:57:23 yep, okay, next topic :-) 13:57:29 #topic Translations to Zanata 13:57:45 what's Zanata? 13:57:47 so at some point, somebody setup cockpit with Transifex fedora infrastructure 13:57:52 and now they want us to migrate to Zanata 13:58:00 because somebody reinvented transifex i guess? 13:58:05 and there's all these reminder emails about it. 13:58:51 is anyone interested in working on the i18n situation in Cockpit in general, or perhaps just syncing translations with Zanata? 13:58:54 all of Fedora is moving to this? 13:58:58 yes 13:59:08 obviously we are not fedora 13:59:11 transifex is sort of dying/dead 13:59:22 but since someone put our stuff in transifex, people want it moved to zanata 13:59:32 andreasn, https://fedoraproject.org/wiki/L10N_Move_To_Zanata 13:59:53 i can take it as a low priority todo 14:00:17 cool. i hope you have the necessary access 14:00:24 i'm sure i don't 14:00:26 if not, i'm not sure who does ... we'd have to hunt them down 14:00:31 that will be half the work 14:00:36 i don't see why i would either 14:00:39 hence my confusion about this 14:01:09 is fedora running their own? 14:01:09 i see this: https://fedora.transifex.com/projects/p/cockpit/ 14:01:22 and we're all listed there 14:01:52 oh look at that. 14:01:58 somehow i accepted to be a maintainer 14:02:02 okay i guess i must have access 14:02:09 i don't remember this at all 14:02:10 let me see 14:02:10 was it accepted for you maybe? 14:02:30 sorry, gotta run 14:02:38 dperpeet, o/ 14:02:53 how does this workflow work? Do these become pull requests? 14:03:11 i haven't done this in a while, but i imagine they do once they're synced over 14:04:40 AIUI projects -pull- from zanata via some commands 14:04:52 right, and then the result is commited, right? 14:05:00 at least that's how i did it in other projects with transifx 14:05:58 [cockpit] stefwalter closed pull request #2132: Compilation test update (master...lib_compilation) http://git.io/vvObx 14:06:06 cool 14:06:13 anything else for this week? 14:06:22 alright, i'll try to get access to Transifex again for the migration 14:07:33 on a different topic, coverity has some issues with the storaged code 14:08:26 is it worth spending time on fixing it up? or just leave it till we remove that code 14:08:35 i think it's worth fixing 14:08:52 ok 14:09:26 but i guess mvollmer would be the one to ask 14:09:34 depending on how long we're keeping the code 14:10:38 yeah, I can't answer that either. 14:10:38 personally, I would like to attack storage as the next big topic. 14:11:02 after wrapping up metrics and services. 14:11:02 and whetever else is ongoing. 14:11:23 right, makes sense 14:12:02 stefw, fyi, https://bugzilla.redhat.com/show_bug.cgi?id=1211287 14:12:08 it's 11 past, so ending meeting 14:12:10 #endmeeting