15:00:40 #startmeeting telemetry 15:00:41 Meeting started Thu Nov 19 15:00:40 2015 UTC and is due to finish in 60 minutes. The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:44 The meeting name has been set to 'telemetry' 15:00:57 first telemetry meeting. 15:01:24 o/ 15:01:31 o/ 15:01:50 o/ 15:01:55 o/ 15:01:57 o/ 15:02:01 o/ 15:02:30 o/ 15:02:35 o/ 15:02:35 o/ 15:02:44 nadya_: good to know who you are 15:02:48 let's start 15:02:50 :) 15:03:09 #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Telemetry/RoadMap 15:03:14 so i updated 15:03:27 (most) of the ceilometer wiki to point to telemetry 15:03:42 i also updated the list of roadmap items that currently don't have owners 15:04:00 feel free to add items you think i missed 15:04:06 or grab an item yourself 15:04:43 if you noticed i missed any ceilometer->telemetry items, please let me know as well. 15:05:00 o/ 15:05:06 gordc: the spec repo 15:05:12 and i guess last note is please review specs already up https://review.openstack.org/#/q/project:openstack/ceilometer-specs,n,z 15:05:27 jd__: you mean move that to telemetry-specs? 15:05:34 gordc: would make sense I guess 15:06:15 i left it unchanged currently because all our bp still are under ceilometer launchpad 15:06:47 jd__: shall we open up bp links for aodh and gnocchi? 15:06:58 if needed 15:07:05 if we have specs for these projects 15:07:34 jd__: you know how easy a repo rename is? 15:07:48 what happens to the docs it publishes? 15:09:10 err, i'll look into it i guess... for now keep it pointing to ceilometer-specs 15:09:30 any other items? 15:10:03 #topic aodh topics 15:10:29 nothing listed, but just a reminder, if someone wants to step up and be a lead for aodh, please do so 15:11:24 gordc: what means 'lead'? 15:11:40 anyone else have aodh items? anyone take a look at this? http://lists.openstack.org/pipermail/openstack-dev/2015-November/079614.html 15:11:42 gordc: ptl-helper responsible for aodh? 15:11:48 nadya_: basically. 15:12:08 nadya_: just keep track of any important work items. 15:12:19 nadya_: track aodh bugs 15:12:36 nadya_: i'm basically trying to get others to do my job :) 15:13:03 gordc: yep, I see :) 15:13:52 ok so we can move on. 15:14:17 take a look at that list if you have opinions on vitrage or root cause analysis. 15:14:29 #topic ceilometer topics 15:15:01 no real updates here, i released ceilometerclient 2.0.1 this week 15:15:12 errr... that's really it. 15:15:43 any one else? 15:15:43 one question, do we need release notes for client? 15:15:44 or we'll just jump into ityaptin spec discussion 15:16:06 I'm fighting to get ceilometer working with keystoneauth1 15:16:08 llu: i ask dhellmann it's for services currently 15:16:21 llu: but they'll probably be applied to libs/clients later 15:16:31 sileht: we need a new ceilometerclient? 15:16:54 gordc, perhaps I'm not sure yet 15:17:03 i'm really hoping we can get that gnocchiclinet patch in... i'm watching that. 15:17:12 me too 15:17:47 cool cool. let us know if you hit any blockers. 15:17:52 Does anyone has a experience with a libvirt? We met with this issue in our deployments https://bugs.launchpad.net/ceilometer/+bug/1457440 15:17:52 Launchpad bug 1457440 in Ceilometer "Compute agent virDomainGetBlockInfo error for instances with RBD backend" [Medium,Triaged] 15:17:52 I have some issue on gate only :( 15:18:33 ityaptin, looks like a kvm/libvirt issue not a ceilometer one 15:18:33 Nobody wants to fix it :-( 15:18:52 sileht: delete the tests 15:18:52 ityaptin: i saw that, was going to look at it yesterday but got distracted 15:18:53 ityaptin: you try asking on openstack-nova? 15:19:06 ityaptin: i think nobody knows how. 15:19:28 Yes, I wrote a letter to openstack dev 15:19:30 ityaptin: Something to do with Libvirt prob. the version of libvirt. 15:19:32 ityaptin: let me try pinging kvm person after this 15:19:47 ityaptin, try to see if a more recent version of libvirt or kvm fix the issue 15:19:50 gordc: re: repo rename, it's not that hard, but it requires a downtime so they do that once every 2 weeks or something on Saturday usually IIRC 15:19:59 gordc, thanks! 15:20:06 ityaptin, if not perhaps this is just not implements for rbd backend 15:20:18 dguitarbite: cool. thanks for pointer 15:20:36 sileht: that's what i thought too... but was too lazy to install everything and verify 15:20:52 jd__: ack. i'll check with infra 15:21:12 #action gordc message infra to change ceilometer-specs to telemetry-specs 15:21:20 sileht: If rbd doesn't support it, I will write a doc entry and update the bug 15:22:17 ityaptin, I guess it doesn't support it, I have the latest kvm with the cloud-archive libvirst for trusty and got: 15:22:19 virsh domblkinfo c04b85f2-aa2f-47d5-b412-2ad67c250e56 vda 15:22:21 error: internal error: missing storage backend for network files using rbd protocol 15:24:07 sileht: ok. so, I suggest additionally catch this issue in virt inspector and put "%s is not supported in rbd" instead of trace 15:24:36 ityaptin, looks good 15:24:55 ityaptin: I will do. 15:25:00 ityaptin: no problem with it either but i'll see if it's something wrong our end. 15:26:23 cool let's move on to spec. 15:26:36 #topic spec for new project with polling and notification (ityaptin) 15:26:40 ityaptin: go for it. 15:26:49 https://review.openstack.org/#/c/246314/3 15:27:43 ityaptin: my main question was trying to figure out what exactly is being split 15:28:33 gordc: polling + notifications. Because notificaton agent is responsible for transforming now 15:29:09 gordc: and it seems difficult to break pipeline.yaml 15:29:39 nadya_: so collector is remaining service in ceilometer? 15:29:47 yep 15:30:28 the new service will publish messages somewhere. and collector may be configured to catch them 15:31:09 hmm.. what functionality does collector have without polling+notification agents? 15:31:44 storage. put and get 15:32:59 gordc: In ceilometer we will still have an api for getting data and a collector for recording. 15:33:15 nadya_: but it only understands polling/notification sample/event models 15:33:39 ityaptin: i see. 15:34:48 so i think originally the discussion at summit was that we could configure the notification agent build data in any pluggable model 15:35:19 i think right now the polling/notification code is pretty separate already no? any other opinions? 15:35:51 gordc: collector will be used if users want to use Ceilometer storages. If they want to publish to Kafka or whatever, then they probably don't want collector 15:36:39 gordc: it is. but the same story was about alarming code 15:37:31 gordc: the idea about "the notification agent build data in any pluggable model" may be implemented as well during refactoring 15:38:05 * jd__ agrees with nadya_ and ityaptin, he thinks 15:38:41 i'm pretty indifferent 15:39:23 the remaining collector+api code will be pretty sparse 15:39:39 especially if you consider the metering api to be in maintenance mode. 15:41:14 gordc: I'm afraid it's evolution :( People uses Ceilometer for collection mostly. External storages is very common solution 15:42:43 nadya_: understood. just pointing out the packages are already like this. 15:43:31 gordc: yeah then we need to move out the event part… and we're pretty done 15:43:32 i'm pretty sure this is going to be moving 90% of code and keeping 10%. 15:43:54 jd__: i think that's what we originally discussed 15:44:09 that's what I wanted to do this cycle 15:44:17 but if we do this one I'm not sure it's wise to do all in one cycle 15:44:59 jd__: agreed 15:46:38 nadya_: i'm indifferent, i don't think this will help much from a user or dev pov but i'm an old man and don't like change. 15:47:29 but tbh, if it ends up being a 90/10 split in code, i don't see the value. unless we plan on adding functionality to that 10% 15:47:54 gordc: ok, I see your point. We may just start doing this and evaluate the results 15:48:42 and discuss events separation with jd__, because it's not clear how it may be done 15:49:03 nadya_: yeah, that'd be good. give it a try. 15:49:18 gordc: if the 10% are the ones deprecated I don't see the problem moving them out anyway? 15:49:25 nadya_: i'm not sure how to split that and make it pluggable either 15:49:50 jd__: are we moving the 10% because if we move collector/api, that requires new endpoint no? 15:49:58 i think we're moving the 90%. 15:50:11 yeah 15:50:18 so it's better? 15:50:29 Why are you whining then? :p 15:50:33 also, we only really deprecrating the metering, events api we need to keep (or make better) 15:50:45 gordc: yeah we need to split that, I said 15:51:06 we deprecating metering? come on! 15:51:43 err. so to formalise, the idea is: move out polling+notification agent? 15:52:05 sounds like it 15:52:14 gordc: yep! metering deprecation is another topic 15:52:34 then we deprecate OpenStack 15:52:42 nadya_: give it a try. 15:52:48 I just haven't heard about this yet :) 15:52:56 gordc: ok! 15:53:00 jd__: write a spec 15:53:09 gordc: we deprecated spec already. 15:53:27 btw, Monasca should be at this meeting :)? 15:53:29 jd__: damn. we must move forward then. 15:53:36 nadya_: is this a question? 15:53:44 jd__: yep 15:53:49 nadya_: why should they? 15:53:50 they are telemetry 15:54:04 and this is telemetry meeting 15:54:12 nadya_: we don't manage them... 15:54:23 and we don't own telemetry space... just the name.lol 15:54:32 they're not part of the telemetry project team 15:54:32 changing to open discussion 15:54:37 they never requested to join AFAIK 15:54:38 #topic open discussion 15:55:06 gordc: I thought you may become their PTL accidentally 15:55:12 lol 15:55:16 hahahah! 15:55:28 nadya_: man, people would be soooo angry. 15:55:53 :)) 15:56:06 :) 15:56:25 you're such a troll nadya_ 15:56:46 nadya_: you will get me in trouble. 15:57:28 sorry ;) 15:57:35 nadya_: our official response is we will listen to all ideas and are always open to integration. 15:57:57 i learned politics from eglynn. 15:58:13 ok we all good? 15:58:33 yep, I think so 15:58:59 thanks everyone. 15:59:06 #endmeeting