13:03:04 #startmeeting meeting 13:03:04 Meeting started Mon Sep 12 13:03:04 2016 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:03:04 The meeting name has been set to 'meeting' 13:03:09 .hello mvo 13:03:10 mvollmer: mvo 'Marius Vollmer' 13:03:13 .hello andreasn 13:03:13 andreasn1: andreasn 'Andreas Nilsson' 13:03:17 .hello dperpeet 13:03:19 dperpeet: dperpeet 'None' 13:03:58 .hello stefw 13:03:59 stefw: stefw 'Stef Walter' 13:04:13 #topic Agenda 13:05:15 .hello larsu 13:05:16 larsu: larsu 'Lars Karlitski' 13:07:02 * cockpit version number 13:07:15 * log pruning 13:07:41 * known issues 13:08:11 * pcp (if time) 13:08:26 alright 13:08:34 #topic cockpit version number 13:09:03 cockpit has dropped the 0.x 13:09:10 #info https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org/thread/UTSBRX6XQ2GJY4EHNY7DFOVE5OBITICN/ 13:09:28 nothing ground to a halt as a result so far 13:09:31 from what I can tell 13:09:40 so it went from 0.117 to 118 13:09:45 people are missing the ".0" moment 13:09:48 https://github.com/cockpit-project/cockpit/releases/tag/118 looks nicer than 0.x 13:09:53 sorry, the "1.0" moment 13:10:16 can we do something instead? 13:10:21 code names once in a while? 13:10:32 yeah, Josh brought that up in the thread, but I think that's a thing we can control to some extent as well 13:10:38 cockpit 119 'funny monkey'? 13:10:48 there can be a big bang if we make it a big bang :) 13:11:17 or milestones like cockpit is default in fedora server 13:11:25 cockpit has reachd debian unstable 13:11:29 things like that 13:11:31 are there any blogs/posts that need to be written? 13:11:36 dperpeet, yup 13:11:38 two things 13:11:43 1. what we define as stable 13:11:50 2. and a general post saying "yay" 13:12:16 are there places where we will collaborate on any of these, or are you on it stefw ? 13:12:49 i think josh was treating cockpit as a kinf of add-on application 13:12:57 i don't have time to do it this week or next 13:13:02 that people go and download and try out 13:13:55 maybe this is part of the current discussion… anyone know when release 118 will be pushed to docker hub? the build failed: https://hub.docker.com/r/cockpit/kubernetes/builds/bj6njmsjrqsuxpwkx39vghg/ 13:14:00 the way I see it, we should go for the content of the "what we define as stable" post first 13:14:31 * aweiteka didn’t realize this was an official call. sorry 13:15:16 aweiteka, I think 118 was only built for fc25 13:15:21 we can tackle that after the meeting 13:15:57 let's see if we can get the posts stefw mentioned started in bullet points this week 13:16:13 I'm happy to flesh those out once we agree on the content 13:16:49 and I'm glad Cockpit dropped the 0.x! 13:17:45 yes, me too 13:18:14 okay, next? 13:18:29 #topic log pruning 13:18:54 mvollmer reviewed and merged the changes to our log sink https://github.com/cockpit-project/cockpituous/pull/32 13:18:57 thanks! 13:19:18 now our logs on fedorapeople should be deleted after 30 days 13:19:23 how often does the pruning run now? 13:19:31 twice a day 13:19:36 our logs folder went from 70G to 6.9G 13:19:42 a lot more manageable 13:20:05 I also saved the raw log files (along with index.html) to my local machines in case we need some statistics 13:20:10 as an interesting side story, I found a change in the production code that wasn't in any commit... 13:20:11 not sure yet if we'll actually use that 13:20:39 mvollmer, cockpit or the sink? 13:20:43 sink 13:21:02 it was probably a change that I made when testing a new feature in production 13:21:08 and then got interrupted etc 13:21:20 so, example of worst practices 13:21:24 hrr 13:21:39 thanks for deploying the new sink, mvollmer :) 13:21:51 i imported that change to the repo now 13:22:17 https://github.com/cockpit-project/cockpituous/commit/4c23d67c619001c605423c4eb55bc756506ae067 13:23:06 also, there are a couple of files in the logs dir that are now owned by "cockpit" 13:23:10 those will never be pruned 13:23:25 very few, so we can just ignore that, I guess 13:23:32 we can take care of that manually 13:24:00 mvollmer, you mean ones that *aren't* owned by cockpit 13:24:08 yes, sorry 13:24:12 "not" 13:24:16 those are stef's 13:24:18 I htink 13:24:19 *think 13:25:06 end of topic? 13:26:55 #topic known issues 13:27:11 just a quick thanks to stef for removing a bunch of old known issues today 13:27:30 I removed a few recently and I'm happy to see that list actually get shorter for once 13:27:36 yay! 13:27:47 end of topic :) 13:28:21 yay 13:28:23 cool 13:28:36 #topic pcp 13:28:45 there was some renewed interest in pcp 13:29:12 where? 13:29:16 https://github.com/cockpit-project/cockpit/issues/4941 13:29:21 sorry, had to dig out the link 13:29:37 #info https://github.com/cockpit-project/cockpit/issues/4941 13:29:49 some people are thinking of adding more pcp specifics to Cockpit, such as changing the default sampling rate 13:30:02 Lets start from the basic point that: 13:30:19 Our integration with PCP is currently implemented in such a way that goes counter to the way the rest of Cockpit is built. 13:30:33 We normally only consider APIs as those that are remotable 13:30:42 the PCP API is not remotable ... in our books it's not an API 13:30:48 hmm. 13:30:59 it's our big exception ... and we need to consider a plan for reconciling that 13:31:10 before we dig ourselves deeper into that hole 13:31:28 not to say such work is a blocker for fixing bugs 13:31:33 but at least there should be a plan 13:31:37 can you elaborate? what is not remoteable? 13:32:00 it is the only system monitoring/configuration/management subsystem by which we push bits onto the C stack 13:32:05 and make actual C function calls 13:32:22 ahh, I see 13:32:28 As a general architecture, Cockpit interacts with the system from javascript 13:32:38 and the binary parts are only there to facilitate that 13:32:55 our binary parts typically have no knowledge of how to configure a system, or monitor a system 13:33:02 the PCP, and to a lesser extent metrics stuff 13:33:19 are the areas where we compromise on that 13:34:07 yeah, makes sense 13:36:11 what is the exact UI they are asking for? I didn't read through the entire thread 13:36:25 nothing concrete 13:36:39 https://github.com/cockpit-project/cockpit/issues/4941#issuecomment-246273069 13:37:07 "a rich UI for optional pmmgr use someday" 13:37:23 sounds like it's not critical right now at least 13:37:33 i agree 13:38:38 what was the connection with the original issue? 13:38:44 why didn't it work properly? 13:39:06 pcp crashing because of a missing / malformed file 13:39:26 that's what I found, not sure if that was the original issue 13:39:34 quite likely, though 13:39:56 and malformed in this case meant: zero bytes 13:40:04 err, I mean size 0. 13:40:28 those files appear all the time after a unclean shutdown 13:40:42 andreasn1, as far as "not-critical" ... our response should be 13:40:45 make a remotable API 13:40:55 and it'll be easy to build a rich UI for pmmgr use 13:41:09 whether a DBus, REST, cmdline+JSON ... anything 13:41:15 in 2016 C APIs aren't 13:41:35 yes, and I think for the use case " the Red Hat customer support folk would like an easy way to query and set the default pmlogger recording interval for a given site" 13:41:59 that sounds a bit outside the core cockpit use case, but could still be useful to make into a plugin that someone else maintains 13:45:00 done? 13:45:20 I think so 13:45:23 #topic any other biz 13:47:34 okay, that's it? 13:47:40 I think so 13:47:43 #endmeeting