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