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