15:05:06 <cdent> #startmeeting ceilometer
15:05:07 <openstack> Meeting started Thu Jun 18 15:05:06 2015 UTC and is due to finish in 60 minutes.  The chair is cdent. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:11 <openstack> The meeting name has been set to 'ceilometer'
15:05:32 <fabiog> hello
15:05:37 <cdent> https://wiki.openstack.org/wiki/Meetings/Ceilometer#Agenda
15:05:38 <ityaptin> hi!
15:05:39 <jasonamyers> o/
15:05:41 <llu-laptop> o/
15:05:48 <_nadya_> hi
15:05:53 <prad> o/
15:05:57 <eglynn> o/
15:06:02 <cdent> #topic midcycle
15:06:04 <eglynn> (belatedly)
15:06:20 <cdent> these times and dates have been mooted: Cisco Dublin Office July 20th-22nd
15:06:22 <ildikov_> o/
15:06:51 <cdent> jd__, sileht you guys present and accounted for?
15:07:16 <ildikov_> do we have a target number to decide whether we will have the mid-cycle or not?
15:07:16 <idegtiarov> o/
15:07:47 <cdent> ildikov_: I was going to ask the same question. eglynn did you have some thoughts on the bare min number?
15:07:48 <ildikov_> etherpad with topic proposals: link# https://etherpad.openstack.org/p/ceilometer-liberty-midcycle
15:07:55 <eglynn> idegtiarov: yep, we need to avoid a last-minute cancelation this time 'round
15:08:05 <jasonamyers> Yes
15:08:13 <fabiog> cdent: last year we failed because we had less than 5
15:08:18 <jasonamyers> I really want to avoid that as well
15:08:21 <eglynn> cdent: not so much a raw number, but also the key contributors for the topics being discussed
15:08:24 <cdent> the etherpad is currently showing 8, but I think that's 8 maybes
15:08:30 <ildikov_> eglute: yeap, I kinda hope I can use my plane ticket now... :)
15:08:34 <eglynn> cdent: but yeah, last time we said absolute min of 5
15:09:25 <cdent> the next topic on the agenda is about topic for that meeting, perhaps narrowing that topic list will help determine if we have the "key" folk?
15:09:34 <cdent> #link https://etherpad.openstack.org/p/ceilometer-liberty-midcycle
15:09:39 <eglynn> cdent: fair point
15:10:03 <eglute> ildikov_ i assume you didn't mean me in that comment :)
15:10:40 <jasonamyers> I picked those dates because we had the most people say yes to the pool then
15:10:44 <cdent> Of those the two that are probably most important are the consequences and management of repo splitting and tieing a bow on gnocchi
15:11:15 <eglynn> jasonamyers: I think the range on the doodle was perhaps a tad on the late side
15:11:22 <eglynn> the date-range I mean
15:11:47 <jasonamyers> There is not way I can host prior to that
15:11:55 <jasonamyers> S/not/no
15:12:17 <ildikov_> eglute: sorry, auto completion... :S
15:12:19 <_nadya_> I'm still trying to find a participator from our team
15:12:33 <eglynn> jasonamyers: I meant that end of first week in August in only a week before traditional feature proposal freeze, 3 weeks before feature freeze for liberty
15:13:15 <jasonamyers> Nod
15:13:41 <eglynn> ... so would probably end up being more of a precursor for discussions at the M* summit, as opposed to a midcycle that would impact on decisions for liberty
15:13:59 <jasonamyers> Yeah that's not terribly useful
15:14:03 <ildikov_> eglynn: the currently possible date will allow us to sort out some things that are important and not in a good enough shape by that time
15:14:25 <jasonamyers> Should we scrap this one and I can work on the next mid cycle earlier in Dublin?
15:14:33 <ildikov_> eglynn: I mean more hacking than talking can be an option too
15:14:35 <jasonamyers> Or can someone else host earlier?
15:15:07 <prad> eglynn, cdent, could rtp be an option? we can check if redhat Annex is available
15:15:26 <cdent> prad not on this short notice, too pricey
15:15:27 <eglynn> ildikov_: yep, understood ... I'm not trying to dictate here at all, just throwing in some ideas
15:15:42 <jasonamyers> I offered that originally prad
15:15:50 <prad> if we're set in Dublin then fine
15:16:24 <prad> jasonamyers, yea we have multiple places to host in RTP.. but i guess that wont work for people on Europe
15:16:40 <ildikov_> eglynn: sure, I'm just not so sure that with all the prep needed we can bring it much earlier
15:16:58 <jasonamyers> I'd rather the face to face be useful than us just coding in a cola red fashion
15:17:12 <jasonamyers> Colocated
15:17:34 <prad> for some reason "cola red fasion" made sense :)
15:17:40 <cdent> So let's just do a quick survey:
15:17:43 <jasonamyers> Haha
15:17:54 <ildikov_> jasonamyers: +1
15:17:55 <cdent> #startvote Skip the mid-cycle this time? Yes, No
15:17:55 <openstack> Begin voting on: Skip the mid-cycle this time? Valid vote options are Yes, No.
15:17:56 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:18:07 <eglynn> jasonamyers: /me had a vision of coding powered by Red Bull for some reason :)
15:18:16 <cdent> (this is non binding, I just want to get a feel)
15:18:23 <cdent> #vote yes
15:18:32 <ildikov_> #vote no
15:18:42 <cdent> #showvote
15:18:43 <openstack> Yes (1): cdent
15:18:44 <openstack> No (1): ildikov_
15:18:47 <jasonamyers> #vote yes
15:18:59 <jasonamyers> But let's schedule the M mid cycle away
15:19:02 <jasonamyers> ASAP
15:19:10 <eglynn> #vote yes
15:19:12 <prad> #vote yes
15:19:28 <prad> yes conditionally
15:19:32 <prad> +1 jasonamyers
15:19:32 <cdent> jasonamyers++ because I think mid cycles can be more important than summits
15:19:45 <cdent> (if done at the right time :) )
15:19:50 <prad> yep
15:19:56 <eglynn> jasonamyers: ... and also yes to M* midcycle in Dublin :)
15:19:59 <jasonamyers> When is a good time after summit?
15:20:00 <prad> i think we're planning a bit late this time
15:20:09 <cdent> jd__ and sileht are not here, so that's a bit unfortunate
15:20:09 <jasonamyers> I will start on it right now
15:20:12 <ildikov_> eglynn: big +1 :)
15:20:18 <jasonamyers> If Dublin is still desired
15:20:28 <cdent> _nadya_: we started a vote on skipping the mid-cycle, just to get a staw poll, you have a vote?
15:20:33 <eglynn> jasonamyers: our one midcycle so far was first week in July of Juno cycle
15:20:51 <prad> that makes more sense
15:20:52 <eglynn> (approx 1-2 weeks after milestone-1)
15:20:56 <prad> egallen, early on is better
15:20:59 <ildikov_> the M* one is tricky because of Xmas
15:21:02 <prad> eglynn, ^^
15:21:08 <prad> darn auto complete
15:21:08 <eglynn> ildikov_: a-ha, yes
15:21:13 <eglynn> ildikov_: good point
15:21:20 <_nadya_> cdent: I'm not sure about our participation :( sorry for that
15:21:33 <cdent> #showvote
15:21:35 <openstack> Yes (4): cdent, eglynn, prad, jasonamyers
15:21:36 <openstack> No (1): ildikov_
15:21:44 <cdent> anybody else want to vote?
15:22:02 <cdent> #endvote
15:22:03 <openstack> Voted on "Skip the mid-cycle this time?" Results are
15:22:04 <openstack> Yes (4): cdent, eglynn, prad, jasonamyers
15:22:05 <openstack> No (1): ildikov_
15:22:34 <cdent> In that case that means that the topics on the etherpad still need to be addressed but in email/etc, yeah?
15:22:37 <jasonamyers> So what if we met dec 14-18 time?
15:22:44 <jasonamyers> Cdent yeah
15:22:57 <ildikov_> cdent: guess so
15:23:13 <prad> curious, what if we have a virtual meetup for a day or so this time .. to discuss pressing topics
15:23:19 <prad> may be over webex or something
15:23:27 <prad> if we decide no on in person meetup
15:23:41 <cdent> prad that seems like a reasonable idea, sort of chat over the top of
15:23:43 <cdent> #link https://etherpad.openstack.org/p/ceilometer-liberty-midcycle
15:23:53 <_nadya_> prad: I like it
15:24:10 <eglynn> cdent: or a g+ hangout
15:24:14 <eglynn> prad: ^^^
15:24:17 <eglynn> ... would need to standardize on a TZ
15:24:26 <prad> yep or g chat
15:24:28 <eglynn> mid-atlantic TZ? :)
15:24:40 <eglynn> UTC-2.5hrs
15:24:42 <llu-laptop> looks like I need to buy some VPNs
15:24:53 <ildikov_> jasonamyers: that can work, although would worth a vote or smth like
15:25:25 <ildikov_> jasonamyers: the question is that when is the last time to decide about it to be in time
15:25:25 <llu-laptop> g+ hangout is blocked by China, the same thing happends to review.openstack.org
15:26:01 <jasonamyers> November 1st from my side
15:26:07 <cdent> #agreed Have a virtual mid-cycle, when TDB
15:26:16 <eglynn> llu-laptop: a-ha, really ... gordc feels your pain now :)
15:26:28 <llu-laptop> he's in China?
15:26:46 <ildikov_> jasonamyers: so by the end of the next Summit the latest
15:26:52 <prad> eglynn, could we do bluejeans for external use?
15:27:00 <eglynn> prad: sure
15:27:14 <prad> cool, thats an option then
15:27:20 <jasonamyers> ildikov_: yes
15:27:31 <eglynn> prad: (it's not hidden behind the firewall, we often do external meetings with it)
15:27:42 <eglynn> prad: good idea actually
15:27:55 <prad> cool
15:27:57 <ildikov_> jasonamyers: ok, let's keep it in mind
15:28:18 <cdent> #action prad and jasonamyers figure out the virtual mid-cycle
15:28:31 <prad> haha
15:28:33 <jasonamyers> Haha
15:28:47 <cdent> that's what you get for opening your mouths :)
15:28:58 <jasonamyers> I only have webex to offer and it sucks on Linux
15:29:11 <prad> yea i'll look into bluejeans
15:29:24 <cdent> webrtc, we'll skip this entire cycle's work and right a simple webrtc tool
15:29:32 <cdent> shall we move on to the next topic?
15:29:34 <prad> date for virtual meetup? another doodle?
15:29:39 <_nadya_> jasonamyers: but it's possible :) after half-day tryings
15:30:05 <cdent> prad, seems right
15:30:44 <jasonamyers> I'm gonna doodle the Dublin dec on too because ... Ireland in the winter!!!
15:30:46 <prad> ok I'll try to set one up .. /me never done before
15:31:08 <cdent> right next topic
15:31:11 <prad> jasonamyers, can you set up a doodle for virtual meetup too then?
15:31:19 <cdent> #topic ceilometer splits, delete or deprecate
15:31:23 <jasonamyers> Haha okay
15:31:48 <cdent> this is on the aforementioned etherpad for the midcycle but as work has already started we probably need to resolve it:
15:32:23 <cdent> When we split code out of the ceilo repo to its own repo have we reached a consensus on whether we are going to keep the code around in the old repo as deprecated for a while or delete it?
15:32:40 <cdent> I seem to recall we had different opinions on this at summit and incomplete resolution?
15:33:34 <fabiog> cdent: if we keep it we need to make sure that nobody is pushing patches toward the deprecated code
15:33:43 <llu-laptop> is it possible to follow the oslo.xxx oslo_xxx convertion?
15:33:44 <cdent> ildikov_: I seem to recall you had some thoughts on this at summit, but don't remember?
15:33:47 <fabiog> cdent: the last thing we want is legacy code diverge from the new one
15:33:54 <cdent> yes, definitely fabiog
15:34:15 <fabiog> cdent: for this reason I am in the opinion of deleting it ...
15:34:25 <cdent> If we deprecate then we run some risk of people never using the new stuff.
15:34:30 <ildikov_> cdent: haha, I'm the one who likes the word deprecation the most :)
15:34:45 <ildikov_> cdent: but that's from usability PoV
15:34:50 <prad> :)
15:35:05 <_nadya_> cdent: maybe deprecation for 1-2 cycles then deletion
15:35:15 <cdent> If we delete we have issues with packaging for the distros that will need to be considered. We can't just let that be.
15:35:29 <llu-laptop> cdent: agreed
15:35:55 <prad> i vote for deprecation, better way to transition and distros can catch up mean while
15:35:58 <ildikov_> so the question here is that what will be broken from the backward compat buzzword point if view
15:35:59 <cdent> I wonder if deprecation means quite the same thing in this context. We aren't changing functionality, just putting it somewhere else.
15:36:20 <cdent> Yes ildikov_ . It's not immediately clear.
15:36:47 <cdent> I put this on the agenda not because I figured we would solve it today but rather because we're going to nee d to resolve it
15:36:53 <ildikov_> cdent: if it's not clear then I would vote on deprecation and figure it out in that two cycles
15:37:03 <cdent> If we have the virtual midcycle sooner than later it will probably be a very useful topic there.
15:37:13 <ildikov_> cdent: +1
15:37:38 <cdent> So basically, people will think about it. Hard.
15:37:46 <ildikov_> also we need to check the blueprints to target the right repo
15:38:39 <cdent> #action people will think about delete or deprecate in advance of virutal mid-cycle and come with an opinion
15:38:44 <llu-laptop> does the split means different gerrit/launchpad project?
15:39:24 <cdent> llu-laptop: that has been the case with gnocchi, ceilometermiddleware, and ceilometerclient
15:39:29 <cdent> so seems like a pattern
15:39:43 <cdent> moving on, to keep to time
15:39:54 <cdent> # topic ceilometerclient
15:39:57 <cdent> whoops
15:40:00 <cdent> #topic ceilometerclient
15:40:12 <cdent> anything on this? pretty quite there isn't it?
15:40:23 <prad> none afaik
15:40:24 <cdent> once
15:40:31 <cdent> twice
15:40:36 <cdent> boom
15:40:41 <cdent> #topic gnocchi
15:41:01 <cdent> gnocchi (and ceilo) were wedged in the gate because of keystonemiddleware interacting poorly with FakeMemcache
15:41:04 <cdent> I fixed it
15:41:43 <cdent> gnocchi needs to get its boots walking with regard to "production ready" (c.f. mailing list) but other than that, things are tickingover
15:41:45 <cdent> anyone else?
15:42:00 <_nadya_> one question
15:42:05 <prad> metricd is merged looks like .. we have updated the packaging for rdo, so delorean picks this up for rdo ci
15:42:17 <cdent> prad++
15:42:52 <cdent> prad: have you seen the multiple workers patch? I think it might need a kick to merge as cores are on walkabout
15:42:55 <cdent> _nadya_?
15:43:00 <_nadya_> we are working on schema for influxDB 0.9 driver . does it make sense?
15:43:12 <prad> cdent, i'll take a look
15:43:57 <_nadya_> cdent: I mean should we create some spec or somewhat like this to show that we are working on this?
15:43:58 <cdent> _nadya_: I don't know. There seems to be quite a few unresolved questions about how best to integrate gnocchi and influxdb.
15:45:08 <cdent> As far as I know gnocchi is not instrumented for doing a spec process, soI would say for now post something to os-dev as I think there are lot of people interested in this exact topic
15:45:14 <cdent> and would like to to see the ideas that people ahve
15:45:18 <cdent> (I certainly would)
15:45:18 <ildikov_> the patch for Influx is abandoned IIRC, I don't remember the exact issues though
15:45:30 <cdent> ildikov_: there are two
15:45:38 <cdent> (which adds to the confusion)
15:45:45 <ildikov_> cdent: a-ha, ok
15:46:16 <_nadya_> cdent: ok, let's move on
15:46:27 <cdent> cool
15:46:32 <cdent> #topic open discussion
15:47:05 <llu-laptop> some questions about the doc
15:47:22 <llu-laptop> now we have 2 places describing the measurement,
15:47:25 <ildikov_> llu-laptop: shoot :)
15:47:33 <llu-laptop> http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-measurements.html.
15:47:40 <llu-laptop> http://docs.openstack.org/developer/ceilometer/measurements.html
15:47:53 <llu-laptop> where should new metrics go?
15:47:53 <cdent> isn't the second one empty and just pointing the first one?
15:48:05 <prad> should be the first one..
15:48:07 <cdent> admin-guide
15:48:11 <ildikov_> llu-laptop: the first describes the user which are the available meters
15:48:27 <ildikov_> llu-laptop: the second one describes the develop how to add new ones
15:48:43 <llu-laptop> also, I find that the API reference is not consistent with the API listed on developer doc
15:48:50 <ildikov_> llu-laptop: and after adding new ones to the code s/he should describe them in the first doc :)
15:48:54 <prad> i thought first one points to second one now
15:49:05 <ildikov_> llu-laptop: the api reference doc is under change
15:49:19 <llu-laptop> got that thanks
15:49:39 <_nadya_> one question about aodh. What data it will process?
15:49:57 <ildikov_> llu-laptop: there is a patch on review, if we have interest to volunteer to participate in the trial process, I'm happy to raise it to Anne
15:50:17 <ildikov_> I wouldn't want to do double work, even if the point is very vaid
15:50:48 <ildikov_> prad: the pointer is for those, who got used to find the meters available in the Dev docs
15:50:49 <cdent> _nadya_: aodh will initially just process the same data it processes now: it will store alarms in a database, and use the ceilometer-api to do evaluation
15:51:12 <_nadya_> cdent:  Maybe there are some plans to let users to determine the service that provides data for processing?
15:51:26 <ildikov_> llu-laptop: do you have intention/bandwidth to look into the api reference things?
15:51:36 <cdent> _nadya_ yes, I think that's after the "intiially" part
15:51:52 <cdent> in fact being able to do that sort of thing is one main reasons for starting the splits
15:51:56 <cdent> to make that sort of thing easier
15:52:06 <_nadya_> cdent: ok, I see. Thanks!
15:52:18 <llu-laptop> ildikov_: i don't have myself. but i'll try to look for others in our teams to see if he/she has some
15:52:25 <cdent> I asked jd the same thing and he said he didn't plan to change functionality at first
15:52:54 <ildikov_> llu-laptop: ok, cool, I wanted to contact Anne anyway regarding to this, if I have some useful information I'll ping you
15:53:05 <llu-laptop> ildikov_: thx
15:53:23 <_nadya_> cdent: initial part will be finished at this cycle :)?
15:53:50 <cdent> that's the plan, and a big contributor on the question of whether to delete or deprecate.
15:54:30 <cdent> anybody or anything else?
15:54:34 <thorst> I have a BP ready for review:  https://review.openstack.org/#/c/192642/
15:54:40 <thorst> As people get time, could you take a peak and let me know if I'm on the right track.  Would love to get this into the release.
15:55:31 <llu-laptop> thorst: sure
15:55:34 <_nadya_> folks, what do you think, should we verify that all samples have resource_id?
15:55:35 <thorst> thx!
15:56:09 <_nadya_> I've faced with this problem and now we don't check that
15:56:15 <cdent> cool thorst. Have you seen this: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067283.html It won't have immediate impact on what you're planning, but probably eventually
15:56:32 <cdent> _nadya_: did we used to?
15:57:11 <_nadya_> cdent: afaik, no
15:57:26 <ildikov_> cdent: I don't think so, we were usually happy if the notifications didn't break our system that often... :(
15:57:30 <thorst> cdent: yeah, I just heard about that yesterday
15:57:39 <llu-laptop> _nadya_: why I remember we require resource_id?
15:57:50 <thorst> something that we'd support as that solidifies
15:57:59 <thorst> but seems to be post this release (maybe experimental this release)
15:58:01 <cdent> I don't reckon the people with historically informed opinions are all here, maybe post something to the mailing list _nadya_ ?
15:58:08 <cdent> thorst: yes, definitely very long term
15:58:22 <_nadya_> llu-laptop: it was in discovery code
15:58:36 <llu-laptop> thorst: what's the status of powervm support in nova?
15:59:06 <cdent> two minutes
15:59:30 <llu-laptop> _nadya_: I vaguely remember we require resource_id in mongoDB, maybe in v1 API?
15:59:30 <thorst> llu-laptop: We've been working with the nova core team.  Right now we're a separate stackforge project (same with Neutron).  We're building up our automation, but have provisioning, deletes, console, etc... working
15:59:47 <_nadya_> llu-laptop: I'll check, thank you
16:00:04 <thorst> llu-laptop: https://github.com/stackforge/nova-powervm/
16:00:10 <cdent> that's it, times up, thanks everyone
16:00:13 <cdent> #endmeeting