15:01:07 <eglynn> #startmeeting ceilometer
15:01:07 <openstack> Meeting started Thu Mar  5 15:01:07 2015 UTC and is due to finish in 60 minutes.  The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:10 <openstack> The meeting name has been set to 'ceilometer'
15:01:42 <ildikov> o/
15:01:45 <idegtiarov> o/
15:01:50 <linuxhermit> o/
15:01:53 <_elena_> o/
15:02:01 <eglynn> hey folks
15:02:52 <jd__> o/
15:03:12 <_nadya_> o/
15:03:21 <eglynn> #topic kilo-3 status
15:03:26 <cdent> o/
15:03:43 <ityaptin> o/
15:03:52 <gordc> o/
15:03:56 <gentux> o/
15:04:06 <eglynn> #link https://launchpad.net/ceilometer/+milestone/kilo-3
15:04:31 <eglynn> so folks, the feature proposal freeze is supposed to be today, March 5th
15:05:26 <eglynn> the idea is to have initial patches proposed approx 2 weeks before the third milestone
15:05:36 <eglynn> to avoid the gate rush and review crunch
15:05:47 <ildikov> it seems to me that we are good on this part
15:06:13 <eglynn> so I think we're good apart from the config-db-api and conf-datastore-agents
15:06:33 <gordc> ityaptin: sorry to bother you again, but do you think you guys will have event bracketing work available?
15:06:57 <gordc> or i guess this will be a liberty feature.
15:07:22 <eglynn> gordc: is that currently targeted at k-3?
15:07:54 <gordc> eglynn: i was hoping but tbh, if we have no code today i'm guessing it'll be a liberty thing
15:08:25 <eglynn> gordc: yeap, seems likely ... though we could consider an exception/extension of a few days if it was close
15:08:26 <ityaptin> gordc: I think it's liberty feature. Today I won't finish even first patchset of it. Also we have several important questions about implementation.
15:08:39 <_nadya_> guys, what about a spec from Ironic guys? is it too late? searching for a link...
15:08:44 <gordc> ityaptin: sure.
15:09:05 <eglynn> ityaptin: OK, shout if an extension of a few days would help ... otherwise let's bump
15:09:16 <ildikov> _nadya_: it is only spec currently, right?
15:09:26 <_nadya_> #link https://review.openstack.org/#/c/130359/3
15:09:43 <_nadya_> ildikov: AFAIU, yes
15:09:49 <gordc> _nadya_: i'll vouch for the ironic item. it's actually relatively small (just adding a listener for their new format)
15:10:08 <gordc> only big issue i think is the naming change for existing meters
15:10:25 <eglynn> gordc: is the implementation started do you know?
15:10:25 <_nadya_> gordc: yep, agree
15:11:23 <gordc> eglynn: that i don't know. i think they were waiting for ceilometer spec approval
15:11:24 <ildikov> gordc: the backwards comptability again ;)
15:11:39 <eglynn> i.e. we could land the spec, but targeting a BP after FPF seems a bit too late unless the implementation is effectively done already and waiting to be proposed
15:11:46 <ildikov> gordc: eglynn: I think so too that there are only blueprints
15:12:24 <eglynn> ildikov: in that case, seems like the spec could be landed, moved to liberty directory, then impl target'd for liberty-1
15:12:31 <gordc> does ironic follow same release schedule? is there a concern to listening to a format that might not be implemented yet?
15:12:51 <eglynn> gordc: yeap same schedule since they garduated in juno
15:12:56 <ildikov> eglynn: it was my opinion too especially that we need to clarify how big issue the meter name change is...
15:13:16 <gordc> eglynn: ah ok. so we're really dependent on them.
15:13:24 <_nadya_> gordc: in the email they said that there are some k-targeter bps in ironic which depend on ceilo one
15:13:37 <gordc> i'll check with NobodyCam today
15:14:02 <eglynn> ok, thanks gordc
15:14:06 <gordc> _nadya_: weird cross dependencies. got it.
15:14:55 <ildikov> I don't really get why they depend on us
15:15:25 <ildikov> we only consume these notifications but any other tool can consume it too
15:16:10 <gordc> ildikov: based on yesterday's chat, NobodyCam wanted to confirm that the format was ok... basically the notification will be a list of meters which ironic defines and we just loop through
15:16:44 <ildikov> gordc: yeap, right, I forgot about that part, thanks
15:17:18 <gordc> ildikov: that could throw our measurements docs out of sync. not sure how we'd handle that.
15:17:37 <ildikov> gordc: the names you mean, or?
15:18:07 <gordc> right... or well we don't know what meters will be generated as they can add/remove meters as they please
15:18:20 <gordc> i guess something to ask on spec
15:18:52 <ildikov> gordc: yes, good point, I got stuck at the payload side
15:18:57 <cdent> long term we shouldn't own or care about meter names...
15:19:08 <cdent> but unfortunately long term is not now
15:19:30 <ildikov> cdent: it is hard to process metrics if you don't know what is collected
15:19:39 <gordc> cdent: i like the self dose of reality.
15:19:43 <eglynn> cdent: notification producer decides on the meter names?
15:19:52 <cdent> the deployer should know what names are being used in their environment
15:20:04 <cdent> the metric gathering subsystem should be able to deal with whatever
15:20:16 <cdent> if I want to count my ponies in ceilometer, I should be able to do that
15:20:21 <cdent> (I have very special ponies)
15:20:36 <ildikov> cdent: it is more difficult than this as billing systems or any other can rely on Ceilometer theorethically
15:20:37 <eglynn> so make the notification -> meter-name mapping effectively configurable?
15:21:26 <cdent> is billing systems need fixed names then having some kind of aliasing overlay probably makes sense
15:21:37 <cdent> but in the guts we should just accept what's given
15:21:38 <ildikov> cdent: but how distros and products are created metrics should be known earlier as deployment time IMHO
15:21:58 <cdent> and that should be up to the distros and products
15:21:58 <ildikov> cdent: and what will you alias on?
15:22:06 <cdent> ceilometer is overreachign by trying to own names
15:22:31 <cdent> it creates a coupling that doesn't have to be there
15:22:39 <ildikov> but I think we should move on as this is just a theorethical discussion
15:22:51 <cdent> (I think this is a debate worth having, but probably not how, perhaps at summit, or some other time0
15:23:10 <eglynn> cdent: some of the things we gather data on are derived from the primary measurements
15:23:11 <gordc> more discussion than i thought.lol i guess technically regardless if ironic (any other service) gives us meter names, we can still choose to remap them or not so i don't think it affects ironic's payload format.
15:23:20 <eglynn> ... i.e. via transformers
15:23:39 <eglynn> ... so the meter exists entirely withing the ceilometer space
15:23:46 <eglynn> *within
15:23:53 * cdent keeps his mouth shut for now
15:24:10 <eglynn> cdent: ok, perhaps a debate for another day
15:24:23 * jd__ nods
15:25:06 <eglynn> ok, let's move on and talk about releasing some delicious pasta
15:25:07 <ildikov> gordc: yeap, it's not about the format, but the fact that we don't know much about how many types of sensors exist, but let's bring this to the review on gerrit
15:25:37 <gordc> sounds good.
15:25:54 <eglynn> #topic gnocchi release plan
15:26:23 <eglynn> jd__: so I think it's fair to say that the thinking was evolved a bit on this topic
15:26:41 <jd__> I think so
15:26:50 <eglynn> previously we talked about "big tenting" gnocchi
15:27:03 <jd__> though it seems kinda useless, e.g. we don't want a new PTL
15:27:11 <jd__> or a whole different team of people
15:27:31 <eglynn> yeah, I had thought that the PTL requirement had been dropped during the governance gerrit reviews
15:27:42 <eglynn> ... but seemingly not from the wiki
15:28:02 <eglynn> #link https://wiki.openstack.org/wiki/Governance/NewProjectTeams
15:28:24 <jd__> I think Gnocchi is too close to Ceilo to require big tenting
15:28:34 <ildikov> I guess the plan is to have a close integartion between Ceilo and Gnocchi, so it makes sense to me to have almost the same group of people etc.
15:28:40 <eglynn> yeah, I'm tending to agree
15:29:01 <jd__> so I think the next step is to do a first gnocchi release around the k3 milestone releases
15:29:12 <jd__> then move gnocchi from stackforge/ to openstack/
15:29:25 <jd__> adding it to the Ceilometer list of projects in some governance repo I guess
15:29:31 * gordc looks forward to first release.
15:29:46 <jd__> and then doing a final release around Kilo, a 1.0 of Gnocchi, that would work with Ceilometer Kilo
15:29:49 <ildikov> jd__: so it will live under the Telemetry umbrella, right?
15:29:51 <jd__> and drink tons of champagne
15:29:59 <jd__> ildikov: yup
15:30:20 <ildikov> jd__: cool
15:30:27 <eglynn> should we reverse the ordering there, first move gnocchi from stackforge to the openstack namespace in git before releasing?
15:30:38 <ildikov> jd__: and also the plan is nice :)
15:30:40 <jd__> eglynn: before releasing around kilo-3? as you wish
15:30:53 <jd__> I can send the moving patches right now
15:30:54 <eglynn> i.e. so that the gnocchi releases all come from the same "source"
15:31:05 <jd__> sure
15:32:03 <eglynn> jd__ do you want to propose the governance patch or should I?
15:32:16 <jd__> eglynn: I'll do it
15:32:29 <eglynn> jd__: coolness, I'll +1 fwiw
15:32:51 <jd__> I wouldn't think otherwise
15:33:04 <eglynn> cool :)
15:33:10 <jd__> :-)
15:33:42 <eglynn> jd__: so the initial release around k-3 timeframe, should that be designated as alpha or some-such?
15:34:05 <eglynn> jd__: ... then do the gnocchi-1.0 around the time the 2015.1 tag is dropped?
15:34:13 <jd__> yeap
15:34:17 <jd__> 1.0a for k3?
15:34:23 <jd__> that sounds semver compliant
15:34:27 <jd__> 1.0a1 either
15:34:53 <eglynn> cool, yeah a1 seems to give more flexibility to have an a2, a3 ...
15:35:34 <ccrouch-afk> have we enumerated what the feature list target is for the gnocchi-1.0 release?
15:36:25 <jd__> we have a spreadsheet with the remaining missing features
15:36:26 <eglynn> ccrouch-afk: most of gnocchi work has been off-launchpad so lacks blueprints
15:36:43 <jd__> https://docs.google.com/spreadsheets/d/1ju8a4PVOJDzL_L-7d_E948cwmZeGugW3SkqN9p5fjtk/edit#gid=0
15:36:52 <jd__> other than that the documentation should cover the features we have
15:36:59 <jd__> (or we should be blamed and the doc should be updated)
15:37:33 <ccrouch> jd__: perfect, thanks for the link
15:38:16 <eglynn> also we could also provide release notes with a list of features, would be a useful pattern for the delta between a1/a2, a2/a3 etc.
15:38:53 <jd__> eglynn: I think no project ever did that, do you have an idea on how we should do that?
15:39:04 <jd__> a mail, a changelog file?
15:39:04 <eglynn> jd__: manually :)
15:39:35 <eglynn> like the release notes that we provide for integrated projects
15:39:52 <eglynn> manually written wiki pages
15:40:57 <ildikov> eglynn: yeap, docco does not believe in evolution...
15:40:58 <eglynn> jd__: do we need access to any tooling from the rel-mgmt folks to cut the release?
15:41:12 <eglynn> jd__: ... or just drop a signed tag?
15:41:18 <jd__> eglynn: I think we just need to push a tab and do some LP stuff but I'll find out
15:41:22 <jd__> s/tab/tag/
15:41:30 <jd__> I'm used to do Oslo lib releases
15:42:02 <eglynn> yeah, I've only done client/middleware releases, which is effectively just git tag -s
15:42:39 <eglynn> the other thing to consider is downstream packaging
15:43:11 <eglynn> once the a1 release is done, we'll scurry off and cook up some rpms for fedora
15:43:19 <eglynn> that'll be an interesting exercise
15:43:47 <eglynn> should smoke out some interesting transitive deps that aren't packaged or up to date
15:44:05 <eglynn> however there is the whole other world of deb/ubuntu packaging
15:44:50 <eglynn> so I think some reaching out to the ubuntu folks, Chuck Short et al, will be needed
15:45:15 <jd__> yup
15:45:19 <jd__> I'll check with zigo too
15:45:19 <eglynn> to give them a heads-up that they should look into .deb-ifying this thing
15:45:30 <eglynn> jd__: coolness, thanks
15:45:55 <eglynn> what about puppet?
15:46:13 <eglynn> should we be trying to generate some interest from the puppeteers?
15:46:23 <eglynn> in cooking up a puppet-gnocchi module
15:46:34 <eglynn> or extend puppet-ceilo?
15:46:55 <eglynn> if the latter, that kinda walks away from the standalon gnocchi usecase
15:47:03 <eglynn> *standalone
15:47:28 <cdent> I think both is probably right.
15:47:36 <cdent> there needs to be a gnocchi module to stand up a gnocchi
15:47:42 <eglynn> agreed
15:47:43 <cdent> but then it's also necessary to configure ceilo to use it
15:47:51 <eglynn> yeap, that makes sense
15:48:58 <eglynn> so is the bet here to try and drum up some interest in the openstack puppet "community"?
15:49:01 <eglynn> ... loosely defined as the openstack folks who do puppet
15:50:40 <eglynn> ok, that sounds like one for the back-burner
15:50:50 <eglynn> let's get the release and packaging done first
15:51:22 <jd__> there's already a gnocchi module AFAIK
15:51:25 <jd__> EmilienM worked on that
15:51:30 <EmilienM> o/
15:51:37 <eglynn> a-ha, coolness
15:51:48 <EmilienM> eglynn: jd__ : we (installer guys) are testing it currently
15:52:05 <eglynn> #link https://github.com/stackforge/puppet-gnocchi
15:52:09 <jd__> he's that good
15:52:10 <EmilienM> with Ceph & Swift backends
15:52:16 <eglynn> wowser! :)
15:52:20 <EmilienM> eglynn: do you need anything ?
15:52:22 <jd__> he's writing puppet for software we did not even wrote yet I'm sure
15:52:47 <EmilienM> jd__: ahah, it's true. At least we are on time when you release it ;-)
15:52:48 <eglynn> EmilienM: well you've already answered our need, I think :)
15:53:02 <EmilienM> cool, cheers
15:53:43 <eglynn> coolness, that is good news, ahead of the curve :)
15:53:56 <eglynn> anything else on that?
15:54:20 <eglynn> #topic open discussion
15:54:56 <ildikov> one thing from me quickly
15:55:01 <eglynn> shoot
15:55:27 <ildikov> if someone would not be aware the Measurements section has been moved to OpenStack Manuals: http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-measurements.html
15:55:41 <jd__> EmilienM: I'll have to talk to you about aodh then :p
15:55:59 <ildikov> this does not mean that no more documentation writing is needed, it will only go to another repo
15:56:00 <eglynn> ildikov: cool
15:56:04 <eglynn> ildikov: you mentioned before scripting the updates
15:56:11 <ildikov> it's not an issue if the commiter does not want to write it
15:56:53 <ildikov> so just a quick heads again on the DocImpact flag and on correcting the references in the specs
15:57:18 * gordc realises how useful the docimpact flag is
15:57:25 <ildikov> also if something does not seem to be straight forward then I would suggest to ask the author of a patch to clarify what a meter actually means in the commit message
15:57:29 <gordc> we should probably start enforcing that a bit more.
15:57:46 <ildikov> gordc: huge +1 :)
15:58:17 <eglynn> ildikov: so add the DocImpact on the implementation patch
15:58:21 <ildikov> so the more information is in the commit message the easier to write the docco in OS Manuals
15:58:22 <eglynn> ildikov: ... but can you explain "correcting the references in specs"?
15:59:04 <ildikov> sure, I saw some patches in ceilometer-specs, which includes the old page, which exists, but contains only a link
15:59:24 <ildikov> I think it is better to clarify at the beginning how the documentation impact has changed
15:59:58 <eglynn> ildikov: a-ha got it
16:00:02 <ildikov> and maybe point the imprtance of properly describing the new meter(s) in the commit message
16:00:54 <ildikov> especially in case of Libvirt meters there were some misunderstanding that which meter means what and it's ugly, when you have to serch for the domain stats in the Libvirt API reference to find the info
16:01:20 <eglynn> cool, we're outta time
16:01:29 <eglynn> thanks for your time!
16:01:33 <gordc> laters folks
16:01:33 <ildikov> that's all, thanks :)
16:01:35 <cdent> o/
16:01:39 <eglynn> #endmeeting ceilometer