16:01:37 #startmeeting Cockpit 16:01:37 Meeting started Mon Jan 19 16:01:37 2015 UTC. The chair is stefw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:49 #chair stefw mvollmer andreasn dperpeet petervo jvance subin 16:01:49 Current chairs: andreasn dperpeet jvance mvollmer petervo stefw subin 16:01:56 #topic Agenda 16:02:00 Hello everyone :) 16:02:00 .hello mvo 16:02:01 mvollmer: mvo 'Marius Vollmer' 16:02:05 Hi! 16:02:08 hi 16:02:13 .hello sgallagh 16:02:14 sgallagh: sgallagh 'Stephen Gallagher' 16:02:25 I'm attending another meeting concurrently 16:02:30 .hello subin 16:02:31 subin: subin 'Subin Francis' 16:02:48 .hello petervo 16:02:49 petervo: Sorry, but you don't exist 16:02:53 .hello andreasn 16:02:54 andreasn: andreasn 'Andreas Nilsson' 16:03:05 Anyone can submit agenda points prefixed with a * 16:03:12 * Better IRC meeting time 16:03:17 * Status: Kubernetes work 16:03:24 * Status: Integration test refactoring 16:03:35 * Status: ongoing Docker work 16:03:40 * Status: Metrics channels 16:03:41 hi 16:03:43 .hello 16:03:43 aayush-k: (hello ) -- Alias for "hellomynameis $1". 16:04:10 .hello aayush-k 16:04:13 aayush-k: Sorry, but you don't exist 16:04:23 how does the hellomynameis thing work now again, is it matching it with fedora id's somehow? 16:04:31 i have no idea 16:04:35 i just cargo cult what others do 16:04:38 haah 16:04:41 haha 16:05:22 * Possible next release blockers? 16:05:22 andreasn: Yes, it's your FAS ID 16:05:33 * Fedora 22 16:06:01 okay, is that it for agenda? shout now if you're still typing ... 16:06:31 #topic Better IRC meeting time 16:06:52 so mvollmer mentioned that the current IRC meeting time doesn't work super well 16:07:09 mvollmer, do you have any proposal for a better time? 16:07:15 I like to keep my evenings free... 16:07:34 what's the earliest in the day that would work for you petervo? 16:07:41 two hours earlier, or four hours later. 16:07:47 2 16:07:57 stefw, yes, we can, 16:08:00 2 hours earlier, is the earliest for me 16:08:22 I think I would prefer 2 hours earlier over 4 hours later 16:08:26 i would prefer 2 hours earlier, obviously... 16:08:35 Two hours earlier works better for me as well 16:08:43 alright, although i may have to skip every other week 16:08:52 or be distracted 16:08:54 we can move the day, too. 16:08:58 it'd be fine if someone else takes the lead 16:09:03 it's a good day 16:09:07 ok, sure. 16:09:09 i can just do two things at once 16:09:24 :-) 16:09:32 so as long as someone else chairs it i'm fine with 14:00 UTC Mondays 16:09:36 i have trouble with one. 16:09:45 well i'll do one at a time 16:09:59 I'll chair. 16:10:01 but lots of meetings only need attention part time ... you can multi-task Win 3.1 style 16:10:04 cooperatively 16:10:10 we also have the option to change day of the week 16:10:19 well, lets try this 16:10:20 (to complicate things further) 16:10:24 all right 16:10:33 #info Proposed IRC meeting time is 14:00 UTC on Monday 16:10:33 yep 16:10:48 any objections? 16:10:50 excellent, thanks everyone! 16:10:57 great! 16:10:59 jvance might not be able to make it 16:11:10 * mvollmer feels a bit selfish 16:11:16 yes, that's true, but (for better or worse) not everyone needs/can make it 16:11:17 but i guess we can address that if he brings it up 16:11:18 i am ok with 14:00 UTC on Monday 16:11:19 but only a bit. :-) 16:11:47 mvollmer, will you announce? 16:11:50 on cockpit-devel? 16:12:37 #action IRC meeting moved to 14:00 UTC on Monday 16:12:45 yes 16:12:56 #action mvollmer will announce on cockpit-devel 16:13:01 hi and sorry I'm late - 2 hours earlier is a lot better :) 16:13:10 great 16:13:33 #topic Status: Kubernetes work 16:13:52 So one big theme that a few people are working on is getting Cockpit to work well with Kubernetes orchestration of containers 16:14:01 some proof of concept code was merged into master, than subin and I worked on 16:14:16 it needs to be manually enabled, it's not installed or part of the packages by default 16:14:28 subin, do you have anything to add? 16:14:55 nothing much , just basic GET queries from k8 16:15:18 somewhat related but not quite, does anyone have a good and simple virsh guide? I wasted way too much time trying to get this running today 16:15:20 no PUT/POST request are available on the UI. Very basic info of kubernetes 16:16:46 In addition andreasn has been doing some design work so we can have multiple dashboards ... one of which will optionally be Kubernetes 16:16:54 andreasn, anything to show there? 16:17:18 not yet, but working on it and hope to have something to show tomorrow 16:17:27 great 16:17:35 i am trying out the latest k8 code to see if anything is new 16:17:37 #info Proof of concept commited to git master, designs coming shortly 16:17:55 subin, do we know yet if we have to rewrite anything for the Kubernetes v3 API? 16:18:08 er, i mean "everything" 16:18:38 i just started exploring need a day or 2 on it. But so far old api seem to work 16:18:56 cool 16:19:05 alright, should we move on? 16:19:13 yeah thats all from me 16:19:43 #topic Integration Test Refactoring 16:20:06 So jscotka has been refactoring our integration tests, and has made a proof of concept pull request 16:20:18 Hi, yes 16:20:41 So I've created prototype based on avocado framework 16:20:52 Everything seems well. 16:21:07 jscotka, what can we do as our next step to move this along? 16:21:27 I'm now waiting for avocado developers to make virt machine scheduler working 16:22:11 Next step is to make it fully automated, installation of virt image & schedule test there 16:22:31 fsimonce pointed out that virt-deploy does this 16:22:59 a standard set of images, support for custom repos, uses virt-builder etc. 16:23:10 yes, I'll use it, in case everything will go well. 16:23:37 does avocado run inside the virtual machine? 16:24:17 avocado is able to run tests inside virt machine or use also remote plugin, so that it is able to schedule test everywhere 16:25:29 can we move forward without the avocado virtual machine support, if we only (for now) use it inside the virtual machine, and not to start the virtual machine? 16:26:04 http://avocado-framework.readthedocs.org/en/latest/VirtualMachinePlugin.html 16:26:20 yes, that's exactly what virt-deploy does too 16:26:51 so my question is, if one is not working, and the other is, could we use virt-deploy instead of the avocado code that isn't ready? 16:27:02 I thought that wirt deploy is installation part of process (it installs disto based on template 16:27:22 I hope that it will be ready this week. 16:27:44 ok 16:28:08 #info Test refactoring waiting on incomplete Avocado virtual machine plugin 16:28:11 as I've discussed with Lukas, he said, that it was working well, but somebody broke it accidently 16:28:48 alright. anything else on the integration test refactoring? 16:29:12 I could briefly mention hubbot. 16:29:16 ah yes 16:29:20 ok 16:29:28 I would be glad if somebody is writing new test, could use avocado. 16:29:57 Is anybody now writing some new test? 16:30:08 We used to have a trivial bot called "hubbot" that could run VERIFY for a given pull request. 16:30:36 It broken when github changed something in the API re auth. 16:30:58 I have resurrected it now and changed it to add statuses to github (instead of comments). 16:31:12 So it's just like Travis now. 16:31:31 You can run it via ssh to files.cockpit-project.org 16:31:47 Right, most important bit: You need to run it manually. 16:32:00 If someone wants to automate it.... 16:32:01 :-) 16:32:21 wait, I'll start a run... 16:32:55 https://github.com/cockpit-project/cockpit/pull/1677 16:33:03 it's busy with that pull request now. 16:33:58 I plan to use this instead of running VERIFY on my laptop. 16:34:06 if you want to do that, too, let's talk. 16:34:10 eof. :-) 16:34:18 do you know enough about the github api to automate it? 16:34:43 no, but it appears to be friendly. 16:34:44 or do we have to figure out how to give people access to that server? 16:35:35 giving access is just copying ssh keys into ~hubbot/ssh/ 16:35:38 what is travis running now? 16:35:48 make check? 16:35:51 yes 16:36:23 so the goal is to have both the unit tests and the integration tests run for each pull request 16:36:36 the integration tests can only be run once you're sure that the pull request isn't nefarious 16:36:44 since we run it on our own server 16:37:27 and we run them on our own server since they spawn virtual machines. 16:37:35 right, for the time being 16:37:49 soon they'll run in virtual machines, so we'll have to see how that plays out 16:37:55 once jscotka's work lands 16:38:01 so jscotka will you be reworking further tests? 16:38:04 yep, and if that goes away, hubbot is obsolete, probably. 16:38:07 yes 16:38:14 I'll do that. 16:38:27 so, I don't want to 'invest' much here. 16:38:36 mvollmer, all the github interaction is not obselete 16:38:53 and basically a script can still spawn the vm and run the tests in it, if we want to keep that going 16:39:03 wouldn't we still want the github integration? 16:39:29 probably we could have also some openstack instances aviable somewhere (via some fedora upstream testing) 16:40:04 stefw, petervo, true. 16:40:13 but we might use Travis, no? 16:40:55 is travis debian only? 16:40:56 anyway, should be fun to figure out github events. 16:41:07 or is that just how i always used it? 16:41:21 yes travis is pretty much Debian only 16:41:25 alright, next topic? 16:41:29 (let's move on... :-) 16:41:37 #topic Status: Ongoing Docker work 16:41:43 andreasn, you're on 16:42:18 yeah, this was mostly that I wanted to highlight some of the work dperpeet is doing with docker right now 16:42:52 most of them are here https://github.com/cockpit-project/cockpit/labels/starter 16:43:05 https://github.com/cockpit-project/cockpit/issues/1587 16:43:25 I implemented your design 16:43:39 but I'm currently in the testing phase 16:43:43 cool 16:43:49 and I noticed that the expose in master doesn't work for me 16:43:57 so I'm looking into that 16:44:10 great, looking forward to see all this in master soon 16:44:15 #info Several docker enhancements going on 16:44:15 I'll add updated design screenshots tomorrow 16:44:21 stefw - sorry just saw this invite for the IRC chat! 16:44:24 especially regarding disabled user input 16:44:34 erinaboyd, no worries, welcome 16:44:41 I think I am going to have to change my working hours to match yours more 16:44:48 has anyone tested the port mapping to host recently? 16:45:09 with the docker cli command? 16:45:20 via cockpit 16:45:39 I start a container, the image exposes port X and I want to map it to Y on my host 16:45:43 that is current state 16:46:16 the issue is to extend that to arbitrary ports when running an image 16:46:26 is there a github issue filed for that? 16:46:48 ah, similar to -P? 16:46:48 stefw, the extension is the issue andreasn posted 16:46:51 yes 16:47:00 cool. anything else to highlight? 16:47:17 not at this point 16:47:39 #topic Status: Metrics channels 16:47:53 Last week the work mvollmer did on the metrics channels was merged. yay 16:48:05 Yay! 16:48:07 and it uses PCP to gather it's information 16:48:16 I have archives working here, pretty much 16:48:22 so i've been also working on porting the old monitors over no the new metrics channels 16:48:33 because there's lots of places where PCP doesn't provide all the info we need, or it doesn't work at all 16:48:51 A bit of cleanup here: https://github.com/cockpit-project/cockpit/pull/1677 16:48:56 i hope that doesn't conflict with your code 16:48:58 mvollmer, 16:49:20 no, it shouldn't. 16:49:21 and hopefully i'll have a pull request for the remaining work in the next few days 16:49:40 good stuff, moving thing compression all the way into cockpitmetrics. 16:49:42 once i've ported over the old monitors, it brings us closer to ditching the legacy cockpitd process 16:50:24 I keep thinking that we might want to make custom pmda for the things that are missing from the official pcp release. 16:50:40 magnitude more work, probably, so yeah... 16:50:49 yes, except it seems that PCP wants to run processes and do lots of stuff behind our backs 16:50:56 and as such makes cockpit-bridge not be relocatable 16:51:14 we rely on the relocatable nature of cockpit-bridge for use with privileged containers 16:51:38 I think the metrics channels were designed to be abstracted at that point, and we don't necessarily need to bring everything under PCP 16:52:12 I agree 16:52:33 cool to hear the archives work is nearly done? 16:52:46 andreasn, i don't remember, was there design work done for scrolling graphs backwards and looking at old data? 16:53:12 I can't remember to be honest where things are with that 16:53:15 ok 16:53:22 alright, next topic? 16:53:22 stefw, well, tests, docs, ... 16:53:32 stefw, but it looks good, no blockers. 16:53:35 #topic Possible next point release blockers? 16:53:36 but I'll investigate and make sure we have something if we don't already 16:54:17 We have a regression with the dashboard now using PCP ... it no longer works with Atomic 16:54:26 Do we think we need to sort that out before the 0.37 release? 16:54:50 stefw, I don't think so. 16:55:04 i tend to agree although we need to fix this up quickly 16:55:21 What breaks it? Super prov container? PCp just isn't there? 16:55:41 well first of all the library dependency isn't available 16:55:49 but once you force that into the system, then it fails to initialize 16:56:04 PCP hard codes its paths, and expects lots of infrastructure outside of pcp-libs to be installed before it'll even initialize 16:56:15 some precompiler that it launches for instance 16:56:21 but if we force that into the system, too? 16:56:22 as well as the pmda modules 16:56:26 we cannot write to /usr\ 16:56:37 at it runs it as a hard coded path 16:56:41 so that's a dead-end 16:57:17 this is the binary it wants to run: /usr/libexec/pcp/bin/pmcpp 16:57:26 at least the first one, haven't gotten past that 16:57:44 so pcp is broken with a ro /usr? 16:57:54 it expects to be installed to /usr 16:58:00 and Atomic doesn't allow anything to be installed to /usr 16:58:10 well, at least not after the fact 16:58:12 but i could be part of Atomic? 16:58:17 it allows stuff in /usr/local 16:58:23 just not /usr/*everything-else* 16:58:24 *it 16:58:41 in theory yes, anything could be part of Atomic 16:59:05 right, so maybe that's acceptable. :-) 16:59:16 after trimming down the dependencies of "pcp". 16:59:58 of course, I agree that running the C preprocessor during startup is, err, anachronistic. 17:00:05 yup 17:00:13 so but we agree this isn't a blocker for 0.37? 17:00:21 i agree 17:00:32 ok 17:00:39 #topic Fedora 22 17:00:53 Fedora 22 is starting to close the doors. 17:00:56 * stefw tries to move things along ... last agenda point ... 17:01:08 sgallagh: around? 17:01:09 what does "close the doors" mean? 17:01:12 sgallagh, still here? 17:01:19 sgallagh: I am now 17:01:36 great, so re Cockpit and F22. 17:01:48 I think cockpit in Fedora could be updated until the code freeze there? 17:01:55 stefw: The deadline for submitting System-Wide Change pages for Fedora 22 is less than 24 hours away 17:02:19 does anyone have plans to make a cockpit related system wide change? 17:02:43 The major effect of these Change pages is to coordinate landing things and ensure that they are put into the release notes and marketing materials 17:02:51 there are a few i could think of (such as showing the cockpit url in the Fedora Server VT) ... but no plans here 17:03:34 Should we stabilize master for F22, as we did with F21? 17:03:41 or is that hopeless? 17:03:48 and if there was any UI for Server Roles in Cockpit, that would be a System Wide Change? 17:04:05 andreasn, no, i don't think so 17:04:22 mvollmer: If we don't stabilize master for F22, what would we do? 17:04:22 mvollmer, that's a good question, if we want to update it at all, we probably would need to do another stable release, right? 17:04:35 the alternative is to leave at the F21 version :( 17:04:39 Release a dev pre-release as the public face of Fedora Server? 17:04:50 no, that's not an option 17:04:51 ugh, the F21 version is soo old 17:04:53 yup 17:05:36 It would need to be "testable" (it already is) by Feb 24 and complete by March 31 17:05:40 (As the current schedule stands) 17:06:06 I'd think March 31 is a reasonable target for stabilizing a release. 17:06:09 that seems doable (end of march) 17:06:14 yep 17:06:14 yeah 17:06:21 but then we can do some bug fixing 17:06:30 we don't need to complete the arch rewrite, even. 17:06:35 Right, after March 31 we go into bugfix-only mode 17:06:53 People have used the Fedora Server release of Cockpit to get involved with Cockpit a lot. So delivering something there is quite beneficial to the project as a whole. 17:07:13 we may have enough resources to have two branches for a while 17:07:23 well enough contributors 17:08:14 ok, sounds good to me! 17:08:18 it's also beneficial to Fedora Server: Cockpit continues to be the most-reviewed (and most positively-reviewed) part of Fedora Server 17:08:19 can we agree that we're not delivering any system wide changes? 17:08:23 so March 31 only bugfixes... for how long is it in that mode before release? 17:08:47 andreasn: May 5th is Final Freeze 17:08:49 ok 17:08:55 stefw, yes. 17:08:56 So about one month 17:09:06 stefw: I think so, yes 17:09:20 although it's blurry to me what is a system wide change exactly 17:09:25 Yeah, as I think on it, if we do the Domain Controller component, it's still not likely system-wide. 17:09:34 andreasn: Yeah, it's intentionally left a little subjective 17:09:54 it's a local change in cockpit/rolekit/freeipa. 17:09:59 The idea is that "Self-Contained" Changes are "Things we want to advertise, but don't need to coordinate throughout the project" 17:10:11 is it so you have your back free so people don't shout at you on fedora-devel? 17:10:18 System-Wide Changes are things that can pull the rug out of other groups 17:10:19 * mvollmer hasn't even read the instructions.... 17:10:29 right 17:10:40 but yeah, I don't think we have any of those 17:10:52 Note that: "Blocking the release of Fedora Server" makes something system-wide. 17:11:02 Which is why Cockpit was treated that way in F21 17:11:15 (I.e. having it at all) 17:11:55 But adding a feature to it is not System-Wide unless it would require retooling other pieces. 17:12:21 unless the release blocks on that feature. :-) 17:12:41 The only blocking feature for Fedora Server so far this release is the creation of the Database Server Role 17:13:16 #action Cockpit is not proposing any system wide changes for Fedora 22 17:13:17 (Which I'm not going to push for inclusion into Cockpit, for the record) 17:13:39 ok, I'll have to leave nowish... 17:13:41 #action sgallagh to file Self-Contained Change for Domain Controller setup support in Cockpit. 17:13:41 #action We'll try to plan out further what it means to stabilize a release/branch of Cockpit for F22 17:13:58 #topic Open Floor 17:14:01 anything else? 17:14:08 nothing from me 17:14:14 ah, I'm not chaired. Oh well 17:14:16 https://github.com/cockpit-project/cockpit/pull/1677 17:14:28 hubbot is happy. 17:14:48 ok, thanks! 17:14:58 sgallagh, sorry 17:15:10 #action sgallagh to file Self-Contained Change for Domain Controller setup support in Cockpit. 17:15:14 Thanks 17:15:17 mvollmer, always nice to have happy bots, good job 17:15:22 #endmeeting