15:00:10 <eglynn> #startmeeting ceilometer
15:00:11 <openstack> Meeting started Thu Jan 29 15:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:15 <openstack> The meeting name has been set to 'ceilometer'
15:00:16 <sileht> o/
15:00:18 <ildikov> o/
15:00:24 <_elena_> o/
15:00:35 <fabiog> o/
15:00:40 <idegtiarov> o/
15:00:47 <cdent> o/
15:01:15 <DinaBelova> o/
15:01:41 <llu-laptop> o/
15:01:55 <eglynn> hey folks, I've been on semi-PTO all this week so only partially around
15:02:05 <eglynn> #topic Kilo-2 status
15:02:06 <mmester> lucky you
15:02:17 <eglynn> LOL :)
15:02:22 <eglynn> #link https://launchpad.net/ceilometer/+milestone/kilo-2
15:02:44 <eglynn> so we've got a fair few BPs yet to land before next week
15:02:45 <ildikov> mmester: from the PTO PoV for sure :)
15:02:52 <eglynn> most are in pretty good shape
15:03:22 <eglynn> except the hyper-V related BPs are showing a great deal of progress
15:04:05 <eglynn> I'm planning to punt these to kilo-3 if we don't see something my EoW
15:04:11 <eglynn> *by EoW
15:04:41 <eglynn> any other concerns for kilo-2?
15:04:55 <fabiog> eglynn: the conf store bp will be addressed by 3 patches, 1 in kilo2 and 2 in kilo3
15:05:09 <fabiog> eglynn: the kilo 2 is ready for review https://review.openstack.org/#/c/142592/
15:05:38 <eglynn> fabiog: so you've taken over shepharding from nealph_afk?
15:05:39 <cdent> Is the base gabbi/http-test stuff enough to say phase one is done or should I lay in a few more tests?
15:06:01 <fabiog> eglynn: yes
15:06:31 <eglynn> cdent: the more tests the better, but what's proposed is prolly enough to declare vistory for k2 I think
15:07:09 <eglynn> fabiog: so I'll target this to kilo-2 in LP? ... https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-configuration-via-data-store
15:07:23 <cdent> I've moved on/over to gnocchi for the moment to see what issues a different evironment reveals.
15:07:32 <fabiog> eglynn: we are going to have 3 patches
15:07:34 <eglynn> cdent: coolness, makes sense
15:07:46 <fabiog> eglynn: the first is storage and we would like to land it in K2
15:08:05 <fabiog> then API and Agents and these will land in K3
15:08:12 <fabiog> makes sense?
15:08:23 <DinaBelova> eglynn, and API stuff will be implemented by idegtiarov for kilo-3
15:08:29 <DinaBelova> with client-side
15:08:47 <eglynn> fabiog: yep ... so when we discussed with this Phil before, IIRC we decided to have 2/3 blueprints in launchpad for tracking purposes
15:09:08 <eglynn> fabiog: the first BP was to capture what was planned for kilo-2
15:09:20 <eglynn> fabiog: the other one or two BPs were to capture what was planned for kilo-3
15:09:44 <fabiog> eglynn: ok, do I need to do something or these bp are already aligned?
15:09:47 <eglynn> fabiog: so is https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-configuration-via-data-store currently the only LP BP registered for this?
15:09:59 <fabiog> eglynn: I think so
15:10:10 <fabiog> the patch partially implements it
15:10:16 <nealph> eglynn, fabiog: https://blueprints.launchpad.net/ceilometer/+spec/configdb-api is registered for the api work.
15:10:37 <eglynn> nealph: was there a specific LP BP intended for the kilo-2 work?
15:11:18 <nealph> eglynn: as you noted, the thought was to have the original bp targeted for Kilo-2
15:11:19 <eglynn> nealph: e.g. ceilometer-configuration-via-data-store==>kilo-2, configdb-api==>kilo-3?
15:11:28 <nealph> that ^^^. :)
15:11:33 <eglynn> nealph: coolness
15:11:38 <fabiog> eglynn: can we use https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-configuration-via-data-store and create another one for the agents?
15:12:22 <eglynn> fabiog: yep, I've just targeted ceilometer-configuration-via-data-store tp kilo-2
15:12:49 <fabiog> eglynn: ok, but there is the agent specific work that will go to Kilo-3 and it is dependent on the API
15:12:51 <eglynn> fabiog: ... and yes, please register a fresh one for the agents if it's a standalone tranch of work
15:12:57 <fabiog> eglynn: got it
15:13:01 <fabiog> thanks
15:13:25 <eglynn> fabiog: cool ... once you've registered the agents BP, I'll target to kilo-3
15:13:31 <eglynn> fabiog: thank you sir!
15:13:51 <eglynn> anything else for kilo-2?
15:15:01 <eglynn> cool enough, moving onwards ...
15:15:04 <eglynn> #topic gnocchi status
15:15:31 <eglynn> fabiog did an interesting g+ hangout earlier in the week on gnocchi measure batching
15:15:41 <eglynn> ... was that recorded BTW?
15:16:40 <fabiog> eglynn: not sure, I think it wasn't
15:16:49 <fabiog> but I posted the deck
15:16:52 <DinaBelova> jd__, eglynn - sadly I should mention I'm kind of stolen a little bit to one more Mirantis project for now, so I'll slow down work on gnocchi a little bit. I'll finish for sure my current patches, but I suppose that lots of my ideas will be going through ityaptin :)
15:17:19 <DinaBelova> I hope that's not more than for one month
15:17:21 <eglynn> fabiog: fair enough, yeah the slides will be good for anyone who missed to catch up
15:17:39 <DinaBelova> fabiog, I'm having going through them in my TODO
15:17:40 <fabiog> eglynn: http://www.slideshare.net/FabioGiannetti/gnocchi-batching
15:17:48 <ityaptin> fabiog: Thanks!
15:17:49 <ildikov> the slides: http://www.slideshare.net/FabioGiannetti/gnocchi-batching
15:17:49 <eglynn> DinaBelova: fair enough, thanks for the heads up on that
15:17:57 <eglynn> fabiog, ildikov: thanks!
15:18:50 <eglynn> DinaBelova: I saw the mid-point reviews were due for the OPW, all good on that score?
15:18:56 <DinaBelova> fabiog - possibly you may take a look on one my gnocchi change (wip for now, hope to finish debugging to eow) - https://review.openstack.org/#/c/148271/
15:19:14 <fabiog> DinaBelova: will do ;-)
15:19:35 <DinaBelova> eglynn, yes - and we've decided to focus on KairosDB driver
15:19:40 <cdent> I have generic testing-related question that has come up as a result of prodding at gnocchi: to what extent is it important for the internal wsgi/pecan app to be robust in the face of missing data that can only be missing if keystonemiddleware is either not there or for some reason broken
15:19:43 <DinaBelova> that's enough module-maintaing thing
15:19:48 <DinaBelova> good research, etc.
15:19:54 <cdent> for example if the x-user-id header has not been produced
15:20:02 <DinaBelova> I've spoken with opw folks, they are ok with this task
15:20:08 <DinaBelova> even if it was delayed
15:20:16 <eglynn> DinaBelova: coolness, thanks
15:21:59 <eglynn> cdent: I'm not sure I understand the question ... if x-user-id is not set, then the auth token verification would have failed, in which case the dispatch path should be cut short and rejected with a 403?
15:22:22 <eglynn> cdent: ... a-ha you mean if the keystone authtoken m/w is completely absent?
15:22:28 <cdent> yes
15:22:43 <cdent> because when testing the internal app you don't want to also be testing keystone
15:22:57 <DinaBelova> cdent, yeah...
15:22:58 <gordc> DinaBelova: does kairosdb make justinb's cassandra work useless?
15:23:13 <gordc> from metering pov
15:23:21 <DinaBelova> gordc, not fully, actually.... but - there is kind of intersection for sure
15:23:23 <eglynn> cdent: so for the first few months of its existence, the default mode for gnocchi was no keystone IIRC
15:23:45 <eglynn> cdent: ... and I don't remember that being problematic
15:23:51 <DinaBelova> gordc, anyway usage of kairosdb will need lots of efforts due to the same problems we're facing with opentsdb
15:24:00 <DinaBelova> (speaking about data retention, etc.)
15:24:00 <cdent> the current concrete problem that I'm encountering eglynn, is that a sqlalchemy exception reaches the surface if you provide not x-user-id when creating a resource
15:24:20 <gordc> DinaBelova: ok. i'll keep that in mind next time i speak with justinb
15:24:20 <cdent> it seems that should be transformed to something less data layer exposing
15:24:38 <cdent> but since it is "impossible" by some defintions, it may not be that relevant
15:24:52 <DinaBelova> gordc, yeah - so possibly in the neasrest future kairosdb driver will have the limited functionality, comparing with justinb directly-ceilo solution
15:25:02 <DinaBelova> that does not face pre-aggregation issues, etc.
15:25:31 <gordc> DinaBelova: i see.. (i'll try to dig into it when i find some time)
15:25:38 <eglynn> cdent: a-ha, got it ... the created_by fields etc. were added *after* the keystone intregration was done, and that logic is probably not tolerant to the x-{user|project}-id headers being missing
15:25:51 <DinaBelova> gordc, yeah, feel free to ping me or ityaptin about this
15:26:25 <gordc> DinaBelova: will do.
15:26:26 <cdent> exactly eglynn so my question boils down to: do we regard that to be a bug
15:26:27 <eglynn> DinaBelova: kairosdb has no native downsampling support?
15:26:48 <DinaBelova> eglynn - it has the same big-table concept underlaying
15:27:02 <ildikov> DinaBelova: I'll may ping you too, as I'm just about the help eglynn to get the Influx driver in shape, so I thought to try to get more knowledge about OpenTSDB too, to see what are the common things
15:27:04 <DinaBelova> and all things like compaction are supposed to be done periodically
15:27:15 <DinaBelova> ildikov, yeah, for sure :)
15:27:47 <DinaBelova> eglynn ^^ and out of concrete storage layer
15:27:59 <eglynn> cdent: yes, I think it should be possible to work without keystone
15:28:02 <DinaBelova> cassandra and hbase have much in common in this case
15:28:18 <DinaBelova> eglynn, cdent - yep, otherwise it'll be the complete hell to test it
15:28:25 <DinaBelova> :(
15:28:27 <ildikov> DinaBelova: I was just wondering if there are some common behaviors of these DBs, then we might not want to rewrite them, but anyway, let's chat about that some time and then we will see :)
15:28:49 <DinaBelova> ildikov, yeah. let's do that
15:29:27 <ildikov> DinaBelova: cool, thanks in advance :)
15:29:36 <eglynn> ok, cool
15:30:08 <fabiog> ildikov: DinaBelova please include me in DB related discussions when you have one :-)
15:30:21 <DinaBelova> fabiog, ok, sure :)
15:30:35 <ildikov> fabiog: I planned to have it on the channel, will ping you then
15:30:57 <fabiog> ildikov: I can offer a phone bridge, if that helps ...
15:30:58 <eglynn> notable patches that landed this week include a new capability API to expose support aggregation methods and a simple carbonara CLI
15:31:01 <eglynn> https://review.openstack.org/#/q/status:merged+project:stackforge/gnocchi,n,z
15:31:02 <ildikov> fabiog: and of course we will schedule it to fit your TZ too :)
15:31:28 <ildikov> fabiog: the channel has the advantage of logging
15:31:42 <eglynn> and the devstack plugin is nice addition, anyone using that regularly?
15:31:43 <fabiog> ildikov: sure
15:32:19 <ildikov> fabiog: and I'm also in learning phase as for InfluxDB, so maybe we will not need voice at this stage, but thanks, it can be useful later, when we have some progress for sure
15:34:13 <eglynn> anything else on the gnocchi work?
15:35:14 <eglynn> k, moving onwards ...
15:35:33 <eglynn> #topic open discussion
15:36:41 <eglynn> who'd have thunk that Lemming-gate would blow up like that?
15:37:17 <cdent> teapots
15:37:36 <gordc> lemming-gate?
15:37:38 <idegtiarov> eglynn: one question: where  new api features should be added in v2 or in v3
15:37:48 <eglynn> gordc: http://lists.openstack.org/pipermail/openstack-dev/2015-January/055338.html
15:37:55 <ildikov> eglynn: I was on a soft-skill traning in the last two days, I'm braindead ;)
15:38:15 <gordc> ah one of those tl;dr emails
15:38:36 <eglynn> idegtiarov: well, the v2 API is going to be around for a while, so you can continue to improve it in incremental ways
15:38:52 <idegtiarov> eglynn: got it, thanks
15:38:57 <eglynn> ildikov: ... i.e. no need to consider it frozen as yet
15:39:12 <eglynn> gordc: yeah, drama-of-the-week
15:40:05 <nealph> a quick note from me....
15:40:14 <cdent> gnocchi doesn't appear to have its own launchpad setup, so where does one report bugs?
15:40:21 <ildikov> eglynn: I meant that no thoughts should be expected from me, but reading it back it's really not that funny :)
15:40:37 <eglynn> nealph: the floor is your's sir!
15:40:56 <nealph> just wanted to note that I'll be stepping away from ceilometer. :(
15:41:03 <DinaBelova> cdent, directly to jd__ ))))
15:41:22 <cdent> nealph: :(
15:41:28 <eglynn> nealph: well thank you for your contributions up to now
15:41:42 <nealph> certainly...have appreciated working with all you folks!
15:41:49 <DinaBelova> nealph, I was really happy to work with you on this project :)
15:41:50 <fabiog> nealph: Phil, thanks for all the hard work you put on the project. We really appreciate it!
15:42:04 <cdent> who will be getting the benefit of your skills now?
15:42:30 <nealph> cdent: still within HP, away from OpenStack I'm afraid.
15:42:31 <ityaptin> nealph: It was cool to work with you on ceilo :)
15:43:05 <cdent> I shall miss grousing with you when everyone else is at summit.
15:43:09 <ildikov> nealph: :(
15:43:18 <nealph> cdent: ha, yes.
15:43:35 <nealph> keep up the good work, all. :)
15:43:41 <ildikov> nealph: wish you luck and joy on the new area!
15:43:58 <nealph> ildikov: thank you much!
15:45:17 <eglynn> cdent: a proper launchpad footprint will be required once jd__ has big-tented gnocchi under the openstack namespace
15:45:34 <eglynn> cdent: ... in fact, it should really have it now even under stackforge
15:45:52 <eglynn> (IIRC other stackforge projects such as tooz and packstack do)
15:47:26 <eglynn> anything else anyone?
15:48:05 <mmester> is there any plans to get OVS stats into ceilometer?
15:49:07 <eglynn> mmester: I don't know of any specific plans, nothing on our immediate roadmap at least
15:49:35 <eglynn> mmester: how are these stats surfaced by ovs?
15:50:30 <mmester> eglynn: not sure exactly.  :/
15:50:57 <mmester> eglynn: ill work on it and put up a BP so at least we have a record of it somewhere
15:51:05 <eglynn> mmester: excellent, thank you sir!
15:51:43 <eglynn> k, let's close a few mins early so if there's nothing else
15:51:48 <eglynn> thanks folks!
15:51:54 <eglynn> #endmeeting ceilometer