15:00:56 <eglynn> #startmeeting ceilometer 15:00:56 <openstack> Meeting started Thu Nov 13 15:00:56 2014 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:00 <openstack> The meeting name has been set to 'ceilometer' 15:01:01 <jd__> o/ 15:01:17 <ildikov> o/ 15:01:17 <eglynn> all safely back from summit? 15:01:49 <jd__> a few hiccups with the metro, but pretty good otherwise 15:01:51 <jd__> :p 15:01:56 <mmester> sadly i didnt get to go :( 15:02:15 <idegtiarov> o/ 15:02:17 <_elena_> o/ 15:02:29 <ityaptin> o/ 15:02:43 <eglynn> let's start with the summit topic 15:02:47 <eglynn> #topic Kilo summit retrospective 15:03:17 <eglynn> anyone got any feedback on the "contributor's meetup" format change? 15:03:44 <eglynn> (the foundation folks are considering something similar for next time) 15:04:36 <jd__> the Friday? 15:04:41 <eglynn> yeah 15:04:49 <jd__> definitely not that useful for us I think 15:04:53 <jd__> under-used I'd say 15:05:03 <ildikov> eglynn: well, I was a bit tired on the last day, so it could be reserved for keynotes maybe ;) 15:05:09 <jd__> haha ildikov :) 15:05:09 <eglynn> was a full too long? 15:05:18 <eglynn> (in the sense that we all seemed to run outta steam by 3pm) 15:05:31 <jd__> definitely 15:05:41 <ildikov> eglynn: in ATL we used the pod area pretty much 15:06:07 <eglynn> ildikov: yeah, but this time the "pod" was practically non-existent 15:06:09 <ildikov> maybe this full day, which is the last day is not the best combination 15:06:16 <eglynn> yeah, fair point 15:06:47 <ildikov> eglynn: I know, I just meant that the space is useful to have, but the format this time did not work that good IMHO 15:07:27 <eglynn> one other change that was mooted ... 15:07:42 <eglynn> switch to much smaller rooms for the design sessions 15:08:09 <eglynn> to avoid the problem of 200 folks in the room, but only 10 people involved in the discussion 15:08:28 <eglynn> don't think we had that issue with the ceilo track TBH 15:09:04 <eglynn> k, let's move on 15:09:09 <eglynn> #topic TSDaaS/gnocchi status 15:09:38 <eglynn> jd__: looks like nice progress on the dict->list change for get_measures 15:10:17 <eglynn> ... also some ongoing debate on the back_window logic 15:12:03 <eglynn> also a new gnocchi contributor in the form of gentux (Romain) :) 15:12:44 <eglynn> jd__: anything else to add on the gnocchi stuff? 15:13:07 <jd__> I'm trying to push the doc at gnocchi.rtfd.org 15:13:39 <jd__> as you mentioned I fixed a bunch of problem in Carbonara computing, now it should be pretty solid 15:13:47 <eglynn> nice :) 15:13:54 <ityaptin> jd__: gnocchi.rtfd.org -> 404 status now 15:13:57 <jd__> I'm still adding more stuff in the API and all 15:14:06 <jd__> ityaptin: *trying* I said ;) 15:14:08 * eglynn notices the added 'f' in readthedocs 15:14:18 <eglynn> LOL :) 15:14:20 <ityaptin> jd__: :) 15:14:42 <jd__> I think it's fair to ask ceilometer-core to start reviewing code too 15:14:54 <eglynn> agreed 15:14:58 <jd__> it sounds like the plan we discussed at the summit was to move gnocchi to ceilo pretty soon now 15:15:13 <jd__> so it'd be nice to have more reviewers but that means people should get familiar with the code 15:15:33 <ityaptin> eglynn: I'm researching issue with context with ceiloemter + custom dispatcher with directory calls of indexer and storage 15:15:45 <eglynn> jd__: yeap, it would be good for the cores to start reviewing now to get familiar with the code in advance of that change 15:16:37 <eglynn> ityaptin: cool, chatting with DinaBelova at summit we noticed that the indexer connect/disconnect is unecessary in a lot of cases 15:17:16 <ityaptin> We didn't talk after the summit yet :( 15:17:30 <ityaptin> Dina is at vacation 15:18:28 <ityaptin> I added fix for indexer connect/disconnect in last patchset at https://review.openstack.org/#/c/131482/ 15:19:03 <jd__> sileht had a few interesting inputs too, I think he should write them on that patchset I guess 15:19:27 <eglynn> ityaptin: a-ha, k, I see the connect/disconnect has now been removed, cool 15:19:50 <eglynn> anything else on gnocchi? 15:20:33 <eglynn> k, moving on ... 15:20:35 <eglynn> #topic Kilo blueprints 15:21:35 <eglynn> so we discussed at summit loosening the detailed spec requirement for the "simpler" BPs 15:21:47 <eglynn> by default a ceilo-specs proposal would be needed 15:22:13 <eglynn> but please use your judgement for stuff that particularly simple, or already discussed at lenght 15:22:46 <eglynn> let's try to get specs filed as early as possible in kilo-1 also 15:23:09 <sileht> o/ 15:23:17 <fabiog> eglynn: do you have a list of candidates for Kilo1? 15:23:59 <eglynn> fabiog: I'm awaiting proposals ... let's give it till next week's meeting 15:24:22 <fabiog> eglynn: sure, no problem 15:24:23 <eglynn> fabiog: but I'm particularly interested in your RBAC BP :) 15:24:44 <fabiog> eglynn: yes. I would like to have that landing in Kilo1 15:25:00 <fabiog> eglynn: as well as any project scoping we want to change 15:25:01 <eglynn> fabiog: great, I was gonna ask is that something that you'd be confident of landing for kilo-1? 15:25:17 <fabiog> eglynn: yes. I should be able to 15:25:24 <eglynn> fabiog: great, thanks! 15:26:10 <eglynn> fabiog: if it lands early enough, it's something that some juno-derived distros might consider carrying as an extra patch 15:26:50 <eglynn> (even if not directly suitable for an upstream backport due to stable branch policy) 15:27:05 <eglynn> BTW kilo-1 is Dec-18 15:27:12 <eglynn> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 15:27:36 <eglynn> k, moving on 15:27:47 <eglynn> #topic liaison with stable-maint and API WG 15:28:14 <eglynn> so as a result of summit discussion on stable management, some changes are afoot 15:28:19 <eglynn> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050390.html 15:29:04 <eglynn> TL;DR: we're moving from single cross project stable-maint team, to project-specific reviewers 15:29:22 <eglynn> we need a stable-maint liaison from each project team 15:29:57 <eglynn> I've no problem doing it, but if anyone else wants to step up? 15:30:43 <eglynn> ... don't all shout at once :) 15:31:40 <eglynn> k, guess it defaults back to me 15:31:59 <eglynn> slightly more exciting is the API WG liaison 15:32:03 <eglynn> https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Guidelines 15:32:34 <eglynn> a-ha, I see jd__ has already volunteered for that 15:33:04 <jd__> uh? only for Oslo 15:33:38 <eglynn> jd__: a-ha, I see wrong link, my bad 15:33:50 <eglynn> I meant ... 15:33:52 <eglynn> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Guidelines 15:34:39 <fabiog> eglynn: is being core a requirement for the API guidelines 15:34:52 <eglynn> fabiog: yeah cdent is willing to do it, but the wiki implies a preference for a core 15:35:11 <eglynn> fabiog: ... but I don't know if that's a *strict* requirement 15:35:22 <eglynn> fabiog: ... I'll follow up with jay on that point 15:35:35 <ildikov> eglynn: these topics would require the half core team already... :( 15:35:37 <fabiog> eglynn: well, I spent a lot of time around pecan ... so I think I can volunteer if I can 15:36:31 <eglynn> fabiog: cool, thanks! 15:36:40 <eglynn> fabiog: maybe you and Chris can cover it together since he's already involved in reviewing the API WG patches? 15:36:43 <ildikov> eglynn: if we count the active cores, then even more of that so maybe we do not have to follow that rule that strictly... 15:37:32 <eglynn> ildikov: yeah, we're suffering from liaison proliferation :) 15:37:56 <eglynn> ... liaisons are the new silver bullet :) 15:38:11 <ildikov> eglynn: LOL :) 15:38:13 <eglynn> k, let's move on 15:38:18 <eglynn> #topic do we need mid-cycle for Kilo? 15:38:35 <fabiog> +1 15:38:45 <ildikov> +1 15:38:45 <eglynn> fabiog: has suggested a mid-cycle at the HP site in Sunnyvale, CA or Galway, IRE 15:39:44 <eglynn> it's no secret that there's been some pushback against the proliferation of mid-cycles (in addition to design summit travel) 15:40:08 <eglynn> so we need to be clear on why we think we need one for kilo 15:40:47 <eglynn> IMO the Juno midcycle was very useful for teasing out some gnarly issues with the core gnocchi design esp. with pauldix in attendence 15:41:10 <eglynn> also for whiteboarding other scenarios, like central agent scale-out 15:41:22 <fabiog> eglynn: agree 15:41:36 <eglynn> so what would we be aiming for with a kilo mid-cycle? 15:41:41 <ildikov> eglynn: I prefer F2F meetings if we can have more, like this mid-cycle 15:41:59 <eglynn> teasing out the remaining gnarly issues with gnocchi/ceilo integration? 15:42:27 <ildikov> maybe the Ceilo-Gnocchi integration and the in-tree testing will give us enough topics 15:42:28 <eglynn> (e.g. migration of datastores, coverage of all existing use-cases) 15:42:36 <fabiog> eglynn: I think we should have an overview of Gnocchi arch, so people can come up to speed .... 15:42:56 <fabiog> eglynn: also integration would be an interesting topic 15:43:10 <fabiog> eglynn: and co-existance/plans/strategies 15:43:32 <mmester> +1 15:43:36 <eglynn> fabiog: yeah jd__ gave a very useful gnocchi walk-thru as a g+ hangout during juno, he might be persuaded to do the same again early in kilo :) 15:43:54 <eglynn> (to bootstrap a wider involvement in reviewing etc.) 15:44:26 <jd__> I could 15:44:37 <eglynn> jd__: thank you sir! :) 15:44:40 <fabiog> eglynn: yes. I also feel that we should really dig into the batching and deletion aspects, because these are real performance boosts/detractors 15:44:50 <eglynn> fabiog: yeap 15:44:51 <jd__> if there's at least a few folks interested 15:45:18 <eglynn> jd__: I expect there would be 15:45:32 <jd__> someone wants to doodle that? 15:45:51 <fabiog> jd__: topics or date and place for event? 15:46:06 <jd__> date and people of the event 15:46:17 <fabiog> jd__: I will do it 15:46:23 <jd__> thanks fabiog 15:46:38 <eglynn> re. dates, we spoke briefly of Feb 3-5 at the contributor's meetup 15:46:52 <fabiog> eglynn: right 15:47:00 <jd__> http://gnocchi.readthedocs.org/en/latest/ is online 15:47:01 <eglynn> I realized afterwards that'll clash with the kilo-2 milestone 15:47:14 <eglynn> kilo-2 == Feb 5 15:47:20 <ildikov> eglynn: kilo-2 is Febr 5 15:47:28 <eglynn> so the week before seems more reasonable? 15:47:45 <eglynn> as the week after clashed with some US holiday, amiright? 15:47:58 <jd__> fabiog: eglynn: i was talking doodle for the G+ hangout, not for mid-cycle, just to be clear 15:48:23 <eglynn> jd__: cool, that's what I understood also 15:48:31 <fabiog> eglynn: I think the week before is good 15:49:04 <eglynn> (let's do the hangout soon as poss to get folks bootstrapped on gnocchi) 15:49:10 <fabiog> eglynn: it will also give an opportunity to review patches and make a final push for Juno2 15:49:12 <fabiog> Kilo2 15:49:18 <ildikov> eglynn: I think so too (mid-cycle) 15:49:33 <eglynn> fabiog: cool, so Jan 27-29 15:49:36 <eglynn> ? 15:49:48 <fabiog> eglynn: I will start planning for that :-) 15:50:24 <eglynn> fabiog: BTW I mentioned it to Stuart McLauren, who's based in HP Galway 15:50:43 <eglynn> fabiog: he wasn't so sure about the scope for a multi-project meetup 15:51:11 <fabiog> eglynn: that's OK, it was just exploratory 15:51:11 <eglynn> fabiog: but did offer to give you a local contact for admin issues 15:51:34 <fabiog> eglynn: great I will get in touch with him, thanks 15:51:44 <eglynn> fabiog: cool 15:52:19 <eglynn> so from the European perspective, obviously Galway would be more do-able from a travel budgeting PoV 15:52:56 <eglynn> anyhoo, let's see what group preference the doodle reveals 15:53:31 <eglynn> anything else on mid-cycle? 15:53:54 <eglynn> #topic Open discussion 15:54:23 <ityaptin> Folks, one questions with bug https://bugs.launchpad.net/ceilometer/+bug/1392326 15:54:24 <uvirtbot> Launchpad bug 1392326 in ceilometer "Ceilometer trusts notifications are not obtained" [Undecided,In progress] 15:54:33 <ityaptin> wow 15:55:35 <eglynn> that's a nasty one :( 15:55:45 <ityaptin> Our resource_type of keystone trust notification do not match keystone trust notifications type. identity.trust.* instead identity.OS-TRUST:trust.* in keystone 15:56:25 <eglynn> yet another reason why we need more integration tests 15:56:39 <eglynn> (in-tree inthe future, as opposed to in-tempest) 15:56:50 <ityaptin> commit message to keystone looks like "append extension name to trust notifications" and doesn't contains nothing about with changing 15:57:54 <fabiog> ityaptin: the OS-TRUST means that this is/was an extension. if that has graduated in the main code the OS- namespace must be removed 15:59:03 <eglynn> ityaptin, fabiog: the point is that the event_type is part of the *implicit* contract for the notification 15:59:24 <eglynn> ityaptin, fabiog: ... so changing that automatically breaks all consumers of the notification 15:59:37 * cdent sighs 15:59:41 <cdent> time zone fail again 15:59:45 <cdent> actually calendar fail this time 15:59:54 <fabiog> eglynn: I know, that is why we need to have the json-schema ... 15:59:56 <eglynn> yet another reason why we need the notification schema discussed with sandywalsh at summit 16:00:15 <eglynn> fabiog: coolness 16:00:31 <eglynn> ityaptin: well spotted in any case, thanks for bring this up 16:00:35 <eglynn> *bringing 16:00:50 <eglynn> k, beaten by the shot clock again 16:00:55 <ityaptin> no problem ;) 16:01:08 <eglynn> thanks folks, lets call it a wrap 16:01:13 <eglynn> #endmeeting ceilometer