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