15:01:07 #startmeeting ceilometer 15:01:08 Meeting started Thu Nov 20 15:01:07 2014 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:12 The meeting name has been set to 'ceilometer' 15:01:29 hey folks 15:01:31 o/ 15:01:35 o/ 15:01:36 <_elena_> o/ 15:01:43 o/ 15:01:56 o/ 15:02:21 #topic kilo blueprints 15:02:25 o/ 15:02:26 o/ 15:02:45 so I discussed the use of BPs and specs with Thierry 15:03:07 o/ hey guys 15:03:25 the upshot is BP+spec is the preference 15:03:29 but we're free to use our judgement to go with BP only 15:03:44 (for smaller features where the path forward is fairly clear) 15:04:11 the other thing I'll be doing is raising placeholder "blocked" BPs in LP for any specs under review 15:04:36 hopefully the whole specs review thing will be less of a drag on folks' time 15:04:50 o/ 15:04:51 what's the general feeling on that? 15:04:59 seems good to me 15:05:09 sounds good 15:05:18 fine with me too 15:05:28 +1 15:05:45 k, so the pressure will be on to get the BP roster for kilo-1 finalized soon 15:05:49 who's deciding what feature falls in to spec territory or not? 15:06:17 and how is that communicated? 15:06:18 gordc: I would say use your judgement and we'll chat collaboratively about any edge cases 15:06:34 * eglynn doesn't want to create yet more bureaucracy 15:06:56 eglynn: cool cool. honour system. 15:06:56 so the default would still be to need a spec 15:07:02 gordc: yeah, exactly 15:07:18 yeah, sepc should be default 15:07:27 llu-laptop: +1 15:07:39 #topic cross-project liaisons 15:08:16 so liaisons are the new thing in openstack, there's 7 positions per project at the last count 15:08:22 https://wiki.openstack.org/wiki/CrossProjectLiaisons 15:08:41 thanks to the folks who have already signed up to take a liaison role 15:08:51 eglynn: do you know if cdent and I can be the API liasion? 15:09:10 fabiog: I've put myself in on the api-wg just as a placeholder until jay removes the core requirement 15:09:23 eglynn: ok 15:09:59 fabiog: once that's done, cdent is interested, are you are as well IIRC 15:10:11 fabiog: (no problem having 2 liaisons, some projects do this already) 15:10:52 I don't have a name yet for https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management 15:11:02 I'll do it if no one else interested 15:11:12 but volunteers welcome :) 15:11:29 similarly I put myself in as stable-maint 15:11:43 happy to do it, but happy also if someone else interested 15:11:50 I'm intrested, but don't know what is required for the security liason 15:12:09 what skill set actually 15:12:21 llu-laptop: mainly being the first line of contact for the Vulnerability Management team 15:12:37 llu-laptop: so doing private reviews on embargoed issues 15:13:11 llu-laptop: and ensuring that the patches are merged lined up with the synchronized disclosure of the CVE 15:13:59 llu-laptop: (the private reviews used to be done by attaching a patch to an embargoed LP bug, dunno if there's also a private gerrit instance now) 15:14:33 llu-laptop: so I guess the skill set is understanding the code base and a general awareness of the "attack surface" 15:15:06 what does private review mean? 15:15:31 llu-laptop: just that the patch is not on the public gerrit system 15:15:52 hmm, interesting, count me in then 15:16:02 llu-laptop: i can help with communication... one of the guys on security team is in my office. 15:16:11 llu-laptop: so if there's a security bug that's validated by the VMT, the patch is prepared kinda "in secret" before the issue is disclosed 15:16:29 llu-laptop: I guess we don't want to disclose how we address security ... 15:16:46 got that 15:17:28 so gordc, do you mind if we both be the liason, one of collegue is in opestack-security team 15:17:54 llu-laptop: sure... i'll be second contact :) 15:18:10 llu-laptop: just for context, a typical issue that came up the past was the mongoDB username/password leaking into the log files 15:18:18 gordc, llu-laptop: thanks guys! 15:18:49 so one other heads-up on the liaisons thing 15:19:31 Thierry has the idea of inviting all the liaisons to the project/release status meeting at 2100UTC on Tuesday 15:19:43 that's the meeting that PTLs normally attend 15:19:57 it wouldn't be mandatory 15:20:16 eglynn: well played... get the volunteers and then drop the additional meeting bomb. :) 15:20:17 that woud be 5am for me, bad time :( 15:20:43 gordc, llu-laptop: TBH I have my doubts as to whether it would be even practical 15:20:53 eglynn: agreed. o 15:20:58 eglynn: I'm not against, I guess we can decide based on the agenda, if we want to attend or not 15:20:59 i'll sit in for llu-laptop 15:21:09 (if i remember) 15:21:19 18 projects times 7 liaisons per project plus PTLs equals what, 144 people at an IRC meeting? 15:21:22 (and to be fair, it's already the case, the meeting is pretty open) 15:21:42 ttx: true 15:21:49 eglynn: it can worth a try and then we can raise if it's not working 15:21:54 eglynn: given that 99% of liaisons roles are filled by the PTL; we are not nearly at that number 15:21:55 gordc: thx 15:22:15 eglynn: also, it's not a must that everyone has to talk 15:22:20 also it would just be an invitation, I don't expect them all to jkoin (same as today) 15:22:56 just want to give more opportunities for liaison to participate in leadership 15:23:25 anyway, it's not a done thing yet :) 15:23:41 ttx: cool, thanks for the clarification 15:23:57 it's more like a "you know, this meeting could be interesting for you" thing 15:24:12 cool, all good 15:25:14 anything else on liaisons? 15:26:50 #topic tie down dates/location for mid-cycle 15:27:37 so we discussed last week whether we even needed a mid-cycle 15:27:55 there was moderate consensus on a yes, IIRC? 15:29:09 fabiog: you were gonna run a poll on potential dates for the two HP sites proposed 15:29:22 eglynn: yes. I can do that 15:29:38 eglynn: I thought the dates we pretty set .. last week of Jan 15:30:10 eglynn: we were talking about 01/30, 01/31 and 02/01 15:30:12 fabiog: turns out I can't do that week, unfortunately :( 15:30:18 ah 15:31:09 eglynn: the real question is, do we want to do the meeting before Kilo2? 15:31:49 fabiog: that would be ideal, otherwise it's getting quite late in the cycle 15:31:54 eglynn: we can move the meeting to a week earlier 15:32:28 fabiog: that would work for me 15:32:30 fabiog: ... but there may be other lurking windows of unavailability for other folks 15:32:48 so I guess a poll of some sort would make sense? 15:33:01 e.g. a wiki page or etherpad that folks could sign up on 15:33:17 eglynn: Ok I will set up one 15:33:28 and post the link 15:33:30 last time the wiki worked fine IIRC 15:33:47 i probably can't commit. i feel like my location puts me in the 'budget restrictions' list. 15:34:49 gordc: boo! ... darned bean-counters :( 15:35:13 gordc: :( 15:35:14 budget would be OK for me, contingent on it being Galway as opposed to Sunnyvale 15:37:29 anything else on mid-cycle? 15:38:24 #topic TSDaaS/gnocchi status 15:38:56 jd__ is not here, so I'll give a quick update 15:40:37 jd__ and gentux have landed a bunch of clean-up and re-organization patches in the past week 15:40:41 https://review.openstack.org/#/q/status:merged+project:stackforge/gnocchi,n,z 15:41:33 from an API PoV the major change was https://review.openstack.org/#/c/133353/6/gnocchi/rest/__init__.py 15:41:59 measures are now returned as a odered list of tuples, instead of a dict as was previously tha case 15:42:14 the dict was problematic because ordering was lost 15:42:48 and there could be key collisions for timestamps of different granularities for boundary times 15:42:56 so the list is a lot cleaner 15:43:19 what did folks think of the g+ hangout, useful? 15:43:56 sorry I missed that:( i'm looking at gnocchi code these days, and got questions about 'resource', can i ask here? 15:44:36 llu-laptop: sure! 15:44:44 hangout was really useful! 15:44:52 missed that too, didn't catch which day was chosen in time. Did anyone record it? 15:45:02 the resouce requires all resource_id/project_id/user_id present, and be in UUID format 15:45:07 llu-laptop, nsaje: yeah I think it was recorded 15:45:17 eglynn: great! 15:45:22 llu-laptop: yes, that's a problem for glance 15:45:34 but some existing metrics in ceilometer doesn't have project/user ID, some even don't have UUID resource_id 15:45:35 nsaje: https://www.youtube.com/watch?v=njqJleBt308#t=1302 15:45:44 idegtiarov: thank you! 15:45:55 eglynn: yes, it was useful! I think that q&a sessions about gnocchi will be needed once ore twice more 15:46:02 saved the link :) 15:46:06 nsaje: np! ) 15:46:18 llu-laptop: yep, and IIRC the glance-originated samples just have project ID and no user ID 15:46:40 llu-laptop: so I raised that issue on one of sileht's gnocchi patches 15:46:55 llu-laptop: we're gonna have to relax that requirement I think 15:47:24 (as we're not gonna get glance to shift to a user-oriented instead of tenant-oriented view of image ownership) 15:47:25 eglynn: yeah, and snmp metrics/some metrics from nova compute may not have resource_id in UUID format 15:47:49 llu-laptop: yeah, the NIC-related samples 15:48:36 another thing is that I don't know how to fit 'source' in ceilometer sample into gnocchi resource 15:49:15 llu-laptop: so source was a bit of a flawed concept I think in classic ceilo 15:49:38 llu-laptop: i.e. we'd the flexibility to multiple sources, but AFAIK never really took advantage of that 15:50:06 llu-laptop: so it introduced some unneccessary complexity in the storage drivers 15:50:25 llu-laptop: TBH I'm not sure if the lack of source was an oversight or a deliberate design decision 15:50:46 lets punt that question to jd__ 15:50:49 i'm not sure if any downstream is using source now, just a question 15:51:21 yeap, definitely worth asking and coming to a definite conclusion on whether we'd need to keep that concept 15:52:18 3rd question, current we only have genericResource, VMResource, SwiftResource, right? 15:52:33 llu-laptop: currently, yes 15:52:47 how to add other resource types? must doing coding in the API level? 15:53:25 llu-laptop: the idea would be expand this pretty quickly to include all the resources types that need strongly typed attributes 15:53:37 llu-laptop: ... and yes, this would require explicit code for each new type 15:54:07 I think the current code doesn't allow having other metadata (besides proejct/user_id) in the genericResource 15:54:23 llu-laptop: yep, exactly 15:54:52 llu-laptop: so once at least one strongly-typed resource attribute is needed, we add a resource-specific type 15:55:16 llu-laptop: the key idea is to move aware from large blobs of free-form resource metadata 15:56:12 so as mentioned on Monday, it would be great to widen the circle of people involved in gnocchi 15:56:24 (as a first step to merging the two core teams) 15:57:15 eglynn: is the design completed or it is possible to propose changes ... 15:58:09 fabiog: nope, the design is not cast in stone at this stage IMO ... so feel free to propose changes 15:58:26 k, time is against up again 15:58:31 #topic open discussion 15:58:33 eglynn: ok, thanks I will do a deeper dive in the following weeks 15:58:45 fabiog: thanks! 15:59:05 all, here it is the launchpad for the mid-cycle meeting: https://etherpad.openstack.org/p/CeilometerKiloMidCycle 15:59:25 please add your name to the dates/locations that works for you 15:59:30 fabiog: excellent, thanks! 15:59:49 eglynn: RBAC is pretty cooked and ready to go 15:59:57 fabiog: nice! :) 16:00:05 fabiog: I'll review today or tmrw 16:00:16 i created this bug: https://bugs.launchpad.net/ceilometer/+bug/1384874 feel free to chime in. 16:00:22 that is all. 16:00:49 eglynn: specs: https://review.openstack.org/#/c/112137/ 16:00:49 gordc: looking 16:00:54 thanks all for a productive meeting! 16:01:00 #endmeeting ceilometer