15:01:05 <jd__> #startmeeting ceilometer
15:01:06 <openstack> Meeting started Thu Oct 17 15:01:05 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:10 <sileht> o/
15:01:10 <openstack> The meeting name has been set to 'ceilometer'
15:01:16 <dhellmann> o/
15:01:19 <llu-laptop> o/
15:01:36 <eglynn> o/
15:02:07 <sandywalsh> o/
15:02:17 <thomasem> o/
15:02:22 <lexx_> o/
15:02:25 <jd__> hi everyone
15:02:27 <nprivalova> o/
15:02:29 <gordc> o/
15:02:41 <jd__> #topic Release python-ceilometerclient?
15:03:04 <eglynn> no need as far I know
15:03:17 <jd__> I think we're good on this one
15:03:20 <eglynn> global requirements not yet updated to 1.06 BTW
15:03:34 <eglynn> pending https://review.openstack.org/49696
15:03:46 <lsmola> o/
15:04:04 <sileht> eglynn, heat stack-update is currently broken I think due to this
15:04:26 <eglynn> sileht: due to needing 1.0.6?
15:05:04 <sileht> eglynn, heat stack-update with a CM alarm won't work with ceilometerclient 1.0.5
15:05:32 <eglynn> sileht: k, we need to get that global requirements change landed asap so
15:05:39 <dhellmann> does heat specify an upper bound for the client?
15:05:54 <sileht> dhellmann, no
15:06:00 <dhellmann> we really only need that requirements change in a hurry if something specifies an upper bound, right?
15:06:40 <dhellmann> +2 approved anyway
15:06:52 <eglynn> dhellmann: thanks!
15:07:09 <sileht> dhellmann, thx
15:07:24 <eglynn> so latest would be picked up in a totally *fresh* build, right?
15:07:32 <terriyu> o/
15:07:47 <eglynn> (but not where there's a preexisting virtualenv with 1.0.5 installed)
15:07:50 <sileht> eglynn, yes
15:07:59 <eglynn> cool, got it ...
15:08:06 <dhellmann> yes, that's right
15:09:42 <jd__> #topic Open discussion
15:09:50 <jd__> we're out of topic
15:09:52 <jd__> :-)
15:10:18 <jd__> I think we released Havana today though I've been busy and didn't check
15:10:19 <jd__> so congrats anyway! :)
15:10:22 <thomasem> Wahoo!
15:10:26 <lsmola> \o/
15:10:30 <eglynn> break out the cigars & champagne!
15:10:37 <thomasem> eglynn, +1
15:10:38 <sileht> :D
15:10:43 <terriyu> yay!
15:10:46 <lsmola> :-)
15:11:16 <gordc> i had a quick question
15:11:19 <llu-laptop> jd__: I remembed you mentioned merge the hardware agent with central agent. How to resolve the issue of multiple central agent?
15:11:46 <lexx_> by the way, what with monitoring physical devices? how discussion with Ironic guys?
15:11:57 <lsmola> llu-laptop, jd__ it should be just by configuration, right?
15:12:11 <gordc> does any remember what the conditions for api access were? do you just need to be a member to query api or do you need to be admin... seems like you just need to be a member but that raises security concerns.
15:12:33 <jd__> llu-laptop: we're writing a blueprint about it
15:12:47 <dhellmann> gordc: admins can query for any resource, regular users can only query for resources owned by the tenant they belong to
15:12:50 <jd__> I think discussion with Ironic will be at the summit
15:13:00 <vvechkanov2> Hello all. Open discussion so quikly? I have again the same question as 2 weeks ago? Are yuo planning to add different notifications plugins for sms and so on, or it will be realised not in ceilometer?
15:13:05 <dhellmann> gordc: assuming you mean ceilometer's api
15:13:47 <lsmola> lexx_, ndipanov from Nova is starting working on that
15:13:53 <gordc> dhellmann: yeah, that's roughly what i remember as well.
15:13:54 <dhellmann> gordc: although with the changes in keystone's model, we probably need to rethink those rules to account for groups
15:14:08 <lsmola> lexx_, but seems that IMPI inspector is already in progress
15:14:14 <lsmola> https://blueprints.launchpad.net/ceilometer/+spec/ipmi-inspector-for-monitoring-physical-devices
15:14:23 <gordc> dhellmann: i guess the only way to make it admin only is to make some coding changes on the side.
15:14:28 <lsmola> lexx_, we will probably add ironic_ipmi_inspector then
15:15:02 <thomasem> vvechkanov2, I would think Oslo would be the authoritative place for notification plugins.
15:15:34 <lsmola> llu-laptop, btw. in a week or so, I will have time to help you with anything on the agent, if you will need it :-)
15:15:36 <dhellmann> gordc: why would you want to do that?
15:15:38 <thomasem> vvechkanov2, That way all projects could benefit from such a thing
15:16:01 <lexx_> lsmola_, Can I do something in this moment? I complete with IPMI inspector for Ceilometer
15:16:15 <thomasem> vvechkanov2, https://wiki.openstack.org/wiki/Oslo
15:16:32 <vvechkanov2> thomasem, we both mean the same? Alarm notifications?
15:16:33 <gordc> dhellmann: sort of ties back to audit work. in some cases the data ceilometer captures may be priveliged
15:16:51 <dhellmann> gordc: ok, I can see that
15:16:59 <gordc> privileged data* ( i should learn to spell)
15:17:11 <nadya> just an update about HBase. We started to testing it but Ceilometer still cannot put data to it because of a bug. Continue working :)
15:17:13 <llu-laptop> Ismola, thanks, let's see how this going.
15:17:21 <thomasem> vvechkanov2, Not absolutely certain there. One of these other folks would probably know more about alarming than me.
15:17:51 <sandywalsh> vvechkanov2: it would be nice to see alarm publishers unified with sample publishers
15:18:11 <eglynn> wechkanov2: I was hoping Marconi/Foghorn will give us SNS-style notifications
15:18:16 <gordc> dhellmann: i guess the question is how we make certain data 'privileged' and other data open to members.
15:18:39 <llu-laptop> One more question about the Ironic/ceilometer. With Ironic, could we monitor physical machines other than those used like nova-compute node?
15:18:53 <dhellmann> gordc: that sounds like a potentially large discussion
15:19:08 <gordc> dhellmann: agreed.
15:19:21 <lsmola> lexx_, I see it's -2, well you will have to wait for the Ironic API I guess, try to ask Ironic guys if you can help in that area
15:19:25 <vvechkanov2> eglynn, do you speaking with marconi's community about it? They have such things in plans?
15:19:33 <gordc> dhellmann: i'll create a bp topic for it
15:19:49 <eglynn> there's a session proposed for summit
15:20:06 <eglynn> wechkanov: ^^^ intending to discuss it there
15:20:13 <dhellmann> gordc: good idea
15:21:33 <eglynn> FYI latest stable/grizzly release almost ready to fly https://launchpad.net/ceilometer/+milestone/2013.1.4
15:21:36 <eglynn> (pending https://review.openstack.org/52348 ...)
15:22:09 <nadya> guys, just a quick question about data-processing. Did you think about more complicated statistics besides min, max? Maybe about filtering?
15:22:18 <lsmola> llu-laptop, with tripleo, every hardware will be a nova instance, it is using nova-baremetal (ironic) for hardware management
15:22:33 <lsmola> llu-laptop, so it's not only for compute :-)
15:23:36 <terriyu> nadya: I think there's a blueprint that mentions something about that
15:24:07 <lsmola> llu-laptop, they call it Undercloud, it's another openstack for managing the openstack :-)
15:24:36 <llu-laptop> eglynn: just +2 and approved 52348
15:24:45 <eglynn> llu-laptop: thank you sir!
15:25:09 <terriyu> nadya: look at https://blueprints.launchpad.net/ceilometer/+spec/api-v2-improvement
15:25:49 <nadya> terriyu, thanks!
15:26:10 <llu-laptop> lsmola: thanks for the information, I'll look at those.
15:26:58 <lsmola> llu-laptop, you are welcome
15:27:38 <lsmola> llu-laptop, I use this for setting up a development environment http://docs.openstack.org/developer/tripleo-incubator/devtest.html
15:27:52 <terriyu> hey everyone, just wanted to mention that OpenStack is participating again in the open source internship program
15:27:53 <lsmola> llu-laptop, for hardware agent testing
15:27:57 <terriyu> the link is https://wiki.gnome.org/OutreachProgramForWomen/2013/DecemberMarch
15:28:15 <terriyu> feel free to publicize it in Twitter / blog / email / etc
15:29:02 <lsmola> terriyu, will do
15:29:19 <terriyu> thanks lsmola !
15:29:46 <terriyu> the deadline for the internship application is Nov 11
15:30:25 <dperaza> hello all, also want to ask a question I filed this bug: https://bugs.launchpad.net/ceilometer/+bug/1240994
15:30:27 <uvirtbot> Launchpad bug 1240994 in ceilometer "Havan rc2 acl scenarios failing due to timezone assumption (dup-of: 1238529)" [Undecided,In progress]
15:30:28 <uvirtbot> Launchpad bug 1238529 in ceilometer "keystoneclient 0.4.0 breaks Ceilometer" [Critical,Fix released]
15:30:51 <dperaza> but it shows as dup of this: https://bugs.launchpad.net/ceilometer/+bug/1238529
15:31:01 <dperaza> which shows it has a fix release
15:31:12 <dperaza> what do I do there
15:32:06 <dperaza> continue working 1240994 or switch to 1238529 that is already in fix state?
15:32:07 <gordc> just for reference, i also see the same issue as dperaza.  the timezone issue seems to affect us in North America.
15:33:31 <gordc> sileht: dperaza bug relates to this patch.
15:33:35 <gordc> https://review.openstack.org/#/c/52182/2
15:33:41 <eglynn> dperaza: are you thinking 1240994 isn't really a duplicate of 1238529?
15:33:54 <dperaza> I think is an additional issue
15:34:10 <dperaza> 1238529 did fix some things
15:34:25 <sileht> Perhaps I have miss something ?
15:34:28 <dperaza> they are both casue by keystoneclient 0.4 move
15:35:00 <eglynn> dperaza: in that case you can remove the duplicate setting
15:35:02 <gordc> sileht: i think you guys in Europe can't see it. :)
15:35:20 <sileht> gordc, oh
15:35:36 <eglynn> dperaza: (then propose a separate fix for 1240994)
15:35:48 <dperaza> I did already
15:35:57 <sileht> dperaza, sorry
15:35:58 * eglynn refreshes ...
15:36:06 <dperaza> but, my concern was the the bug show as dup
15:36:08 <gordc> dperaza: i think it's safe to keep going with what you have.
15:36:21 <eglynn> dperaza: did already remove the duplicate status?
15:36:28 <eglynn> dperaza: or did already propose a patch?
15:36:41 <dperaza> did already proposed a patch
15:36:43 <eglynn> dperaza: a-ha, I see it now
15:37:01 <eglynn> dperaza: (launchpad slow to update bug)
15:37:11 <gordc> dperaza: we'll have one of the Europe ppl to test that it works for them as well. i think it's a good idea to get rid of datetime.datetime.now() reference to begin with.
15:37:46 <sileht> dperaza, I have removed my -1 and I will really review it so
15:37:54 <eglynn> should we be using the olso timeutils version across the board?
15:38:10 <eglynn> (i.e. instead of datetime.now() called directly ...)
15:38:33 <sileht> eglynn, I think it always better because it allows to mock the time easyly
15:38:36 <gordc> eglynn: that seems to be safer. been seeing a lot of timezone issues with datetime.now()
15:38:45 <gordc> sileht: agreed
15:38:46 <eglynn> sileht: yep, agreed
15:38:46 <llu-laptop> eglynn: agreed
15:38:50 <eglynn> cool
15:38:59 <dperaza> I do thing using utcnow whenever possible is good idea yes
15:39:00 <dragondm> yah, OS times should *always* be utc.
15:39:13 <thomasem> dragondm, +1
15:39:48 <dperaza> if someone needs timezone dates they can always conver before showing
15:39:54 <thomasem> yep
15:39:58 <dragondm> bingo.
15:40:03 <dperaza> but backend should store utc
15:40:07 <thomasem> yep
15:40:16 <dragondm> local times should only be used for user display.
15:40:48 <thomasem> I don't care if it's redundant for me to say it, but that's how much I agree. +1000
15:41:08 <lsmola> thomasem, +1001
15:41:15 <thomasem> Whoaaaaa price is right over here
15:41:21 <lsmola> hehe
15:41:23 <thomasem> :P
15:41:23 <gordc> thomasem: you're breaking DRY.
15:41:34 <thomasem> gordc, you caught me
15:41:48 <gordc> thomasem: lol you've taught me well.
15:41:53 <thomasem> LOL
15:42:12 <dragondm> Rule #1 of programming: Don't Repeat yourself.
15:42:18 <dragondm> Rule #2 of programming: Don't Repeat yourself.
15:42:28 <gordc> dragondm: :)
15:42:30 <thomasem> I thought it was don't talk about fight club?
15:42:46 <thomasem> D=
15:43:15 <jd__> should I close the meeting? :)
15:43:36 <gordc> jd__: works for me.
15:43:37 <lsmola> dragondm, unless you write tests, then DAMP :-)
15:43:48 <eglynn> jd__: yep, I think we're done
15:44:06 <jd__> :-)
15:44:08 <jd__> #endmeeting