15:01:08 <gordc> #startmeeting telemetry
15:01:09 <openstack> Meeting started Thu Dec  3 15:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:13 <openstack> The meeting name has been set to 'telemetry'
15:01:16 <nijaba> o/
15:01:22 <ildikov> o/
15:01:30 <llu> o/
15:01:33 <r-mibu> o/
15:01:52 <jd__> o/
15:02:11 <cdent> o/
15:02:13 <gordc> lets' start
15:02:22 <gordc> cdent: welcome back
15:02:29 <cdent> thanks
15:02:41 <gordc> #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Telemetry/RoadMap
15:02:58 <gordc> just a quick update, Mitaka-1 is in processed of being tagged
15:03:24 <gordc> https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
15:03:34 <gordc> this is your release cycle in case you're interested
15:03:59 <gordc> we should probably get started on reviewing specs so people can start working on them.
15:04:29 <gordc> make sense?
15:04:43 <r-mibu> ack
15:04:58 <ildikov> yeap
15:05:00 <jd__> k
15:05:12 <gordc> cool. feel free to mention any spec related items as we run through each project
15:05:28 <gordc> #topic aodh topics
15:05:39 <gordc> any aodh topics we want to address?
15:05:49 <gordc> i know there's a thread relating to vitrage
15:05:59 <gordc> i assume that's still being discussed but no issues?
15:06:01 <jd__> indeed
15:06:02 <pradk> o/
15:06:08 <ildikov> I'm still reading it
15:06:25 <Guest51944> o/
15:06:49 <r-mibu> yeah, it's interesting
15:07:13 <gordc> jd__: it's weird regarding 1 min alarm creation
15:07:25 <jd__> gordc: it's just the cache ttl
15:07:37 <ildikov> yeah, it's the time for creating an alarm
15:07:42 <gordc> ah, yeah. that makes sense.
15:07:56 <r-mibu> yeah, that's my bad explanation though
15:07:59 <gordc> i assume it was related to polling
15:08:27 <gordc> cool. i should mention aodh mitaka-1 release is also being tagged today
15:08:42 <r-mibu> ok
15:09:08 <gordc> did we have an owner for aodhclient? i can't remember if we had volunteer from summit
15:09:11 * jd__ sighs
15:09:47 <r-mibu> i will try after tempest
15:09:47 <idegtiarov> o/
15:09:55 <gordc> jd__: we'll track it for now. start worrying in the new year
15:10:15 <gordc> any other aodh related topics?
15:10:42 <r-mibu> no, i guess
15:10:45 <gordc> cool
15:10:50 <gordc> #topic Monasca publisher blueprint discussion
15:11:00 <gordc> rohit_: i assume this is you :)
15:11:40 <rohit_> Thx gordc
15:11:56 <gordc> #link https://review.openstack.org/#/c/249406/
15:12:08 <gordc> fo reference
15:13:15 <rohit_> Question on the v2 api - I assume it's not deprecated now?
15:14:07 <_nadya_> no, it's not
15:14:32 <gordc> v2 metering api is basically in maintenance.
15:14:34 <fabiog> _nadya_: and the process hasn't even started yet, right?
15:14:52 <_nadya_> fabiog: AFAIK, no, it's not
15:15:11 <gordc> i don't want to say deprecated because it seems people are using it (to what success i'm unsure)
15:15:35 <gordc> rohit_: were you looking to add somehting?
15:15:45 <_nadya_> rohit_: why you cannot improve the current kafka publisher?
15:15:51 <fabiog> gordc: there are companies like CloudCruizer and Talligent that can use the API
15:16:22 <fabiog> gordc: they wrote code against it
15:16:29 <ildikov> gordc: 'in maintenance' means no new features but fixing issues if any?
15:16:37 <gordc> fabiog: yep. "people are using it"
15:17:16 <gordc> so the general openstack decision on api is that they will basically never be removed.
15:17:24 <gordc> ^i don't have a link for that
15:17:45 <rohit_> Gordc: yes the api adapter for minasca api
15:17:56 <fabiog> _nadya_: we are publishing to the Monasca API, so sending to Kafka does not address the problem
15:18:04 <gordc> ildikov: that's basically what i imagine.
15:18:24 <ildikov> gordc: ok
15:18:43 <gordc> rohit_: does that require some sort of plugin?
15:18:47 <_nadya_> fabiog: so Monasca cannot read directly from its transporter?
15:18:55 <ildikov> gordc: so the v2 API and the corresponding backends are in maintenance
15:19:37 <rohit_> Gordc: yes, a  storage driver plugin
15:19:41 <gordc> ildikov: yeah. people are welcome to fix them and improve them. but clearly the community is spending less and less time on it.
15:19:54 <ildikov> gordc: ok, cool, tnx
15:20:01 <fabiog> _nadya_: trsnsporter? It can read from Kafka bus, but you will loose the authentication of the source and the extra data the API adds before sending to Kafka. Moreover, is bad to expose the guts of a service like that
15:20:30 <gordc> rohit_: so it could be a plugin similar to sql/mongo
15:20:38 <gordc> rohit_: that's good
15:20:42 <jd__> a dispatcher
15:20:53 <fabiog> _nadya_: going through the API means keeping independence on the internal format and other potential chages
15:21:00 <gordc> rohit_: basically teh comments on the patch are that we should make it pluggable, and it should be maintained in it's own tree
15:21:07 <jd__> a dispatcher means RabbitMQ I don't think they want that
15:21:38 <fabiog> jd__: if you are going to an external source, why should you re-publsih to the rabbit?
15:21:40 <gordc> rohit_: as i mentioned in patch, it's not ideal ot have ceilometer devs (unfamiliar with a backend) to properly review something
15:21:52 <gordc> fabiog: that's the point he was making
15:22:13 <gordc> fabiog: the spec is to avoid the republishing
15:22:41 <gordc> rohit_: were there issues with setting up testing in it's own repo?
15:22:45 <jd__> fabiog: it's not always re-publish (polling does not read from rabbit) and rabbit offloads the work so if your external source is down, you can have a backlog
15:23:22 <jd__> gordc: so that's why it should be a publisher no?
15:23:54 <gordc> jd__: isn't that what the spec says?
15:24:10 <jd__> it is, but you talked about a dispatcher
15:24:17 <jd__> [16:20:30]  <gordc>	rohit_: so it could be a plugin similar to sql/mongo
15:24:18 <jd__> :p
15:24:42 <gordc> jd__: oh, that was because they have a translator from monasca -> v2api
15:25:01 <jd__> ah ok for reading more then
15:25:06 <gordc> right
15:25:35 <gordc> i actually don't mind either dispatcher or publisher
15:26:00 <gordc> reason we had dispatcher was to avoid having the write load affecting pipeline processing
15:26:39 <_nadya_> I'm ok with Monasca publisher as well
15:26:44 <fabiog> gordc: but Monasca has a Kafka bus that acts like the Ceilo topic, that why it would be redundant to have it as a dispatcher
15:27:00 <rohit_> gordc: we have some basic tests running in monasca-ceilometer now
15:27:05 <fabiog> gordc: and in this way we put less stress on the common rabbitmq
15:27:28 <gordc> fabiog: understood. i just wanted to point out reasoning for dispatcher vs publisher
15:27:59 <gordc> it was mainly for http dispatcher which is synchronous and could slow your processing quite a bit
15:28:20 <gordc> fabiog: i've been told writes to monasca are wicked fast so it's a non-issue
15:28:59 <gordc> rohit_: cool.
15:29:24 <fabiog> gordc: not sure I understand what you suggest. You want use to use the http dispatcher?
15:29:26 <gordc> rohit_: so is the discussion whether we need it in tree still?
15:29:39 <rohit_> gordc: but yes, it needs more funtional type tests
15:29:53 <gordc> fabiog: no. i'm just pointing out why there's dispatcher vs publisher. you can ignore this.
15:30:22 <gordc> fabiog: as i said, i don't really have an opinion on you using publisher or dispatcher
15:30:52 <gordc> rohit_: why does that require it to be in celiometer gate?
15:31:14 <gordc> rohit_: we need to address that gap i think
15:31:15 <rohit_> gordc: i was referring to including the storage driver as well
15:31:46 <gordc> rohit_: the idea is we want drivers to be managed appropriately (by correct people) and be tested properly
15:32:01 <gordc> rohit_: it seems to be doable since powervm is doing it in their own gate
15:32:39 <gordc> you just need to pull in ceilometer repo when testing monasca publisher+storage
15:32:43 <jd__> it definitely is
15:33:24 <gordc> rohit_: it's similar to how neutron tests it drivers.
15:34:02 <rohit_> gordc: sure, we wanted this to be in-tree as an endorsement/acceptance
15:34:02 <gordc> i don't think you want a bunch of people not familiar with a driver to review it.
15:34:11 <gordc> rohit_: ah i see
15:34:28 <gordc> rohit_: so that's what i suggested we do same thing as powervm
15:34:29 <rohit_> i understand your point on the maintenance issue with drivers residing in-tree
15:34:52 <gordc> it'll be officially under 'telemetry' team alongside ceilometer+aodh+gnocchi+powervm
15:35:03 <gordc> it'll just be managed by people that actually understand it
15:35:14 <rohit_> ok
15:35:42 <gordc> rohit_: i think the main reason i'm pushing for this path is right now i'm reviewing a bunch of libvirt code
15:35:57 <gordc> and full disclosure, i don't understand anything about libvirt
15:36:48 <gordc> rohit_: if there are testing issues, definitely raise them, and we can work with infra or change ceilometer code abit to accommodate
15:37:32 <rohit_> gordc: there a process to bring a repo under telemetry
15:37:41 <gordc> this will hopefully be faster for monasca in the long run. we already had a few drivers die in review stage because we didn't have appropriate reviewers
15:38:16 <gordc> rohit_: i think collectively we just need to sign off on it.
15:38:43 <rohit_> gordc: sounds good
15:38:45 <gordc> i'll dig up governance patch for powervm
15:39:12 <gordc> https://review.openstack.org/#/c/245894/
15:39:19 <gordc> rohit_: ^
15:39:59 <gordc> you just need ptl, but i've generally just polled everyone beforehand to make sure we have agreement
15:40:08 <rohit_> gordc: cool
15:40:36 <gordc> but it seems like we do? everyone cool with monasca interface project living under telemetry at some point?
15:40:48 <fabiog> rohit_: that should be easy because monasca-ceilometer is already under the big tent, so it is just a change of root project
15:41:12 <ildikov> gordc: +1
15:41:29 <gordc> fabiog: yep. i don't think it's much issue but you can ask throst from powervm team to see
15:42:02 <gordc> they bsaically asked me on a friday and then by the next week had it being reviewed
15:43:15 <gordc> rohit_: i'll work with you guys to make sure we can plug in appropriately
15:43:22 <rohit_> fabiog: +1
15:43:30 <gordc> should start soon i guess so we have time to make changes in ceilometer if needed
15:43:55 <gordc> sound good?
15:43:57 <rohit_> gordc: k, sounds good
15:44:03 <gordc> rohit_: :)
15:45:01 <gordc> #topic gnocchi topics
15:45:30 <gordc> jd__: anything? i assume we are not doing a release
15:45:34 <sileht> aodh and ceilometer patch to use gnocchiclient are ready to review
15:45:48 <gordc> sileht: right. will start looking
15:45:54 <sileht> (and depends on the keystoneauth1 review)
15:45:56 <jd__> not much
15:46:15 <gordc> jd__: cool cool. we'll give time to ildikov
15:46:20 <gordc> let's move on.
15:46:27 <gordc> #topic DocImpact flag updates (ildikov)
15:46:37 <ildikov> gordc: tnx, I don't need much
15:46:53 <ildikov> the docs team updated a bit the concept and mechanism
15:47:17 <ildikov> so when you add the DocImpact tag it has to have an explanation too
15:47:57 <ildikov> and the bug will land at the project as opposed to openstack-manuals
15:48:03 <ildikov> so we can track it better
15:48:27 <gordc> ildikov: i've never understood why it landed at openstack-manuals
15:48:31 <ildikov> I hope later on we can move back documentation parts too and the docs itself can live closer to the code also
15:48:46 <gordc> what's an example of the new tag?
15:48:50 <ildikov> gordc: for Nova and I think 4 more project it still does
15:49:07 <gordc> i guess they have dedicated docs people
15:49:16 <ildikov> yeah, most probably
15:50:05 <jd__> ildikov: cool
15:50:11 <jd__> that's going in the right direction
15:50:17 <ildikov> examples: #link http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html#examples
15:50:56 <ildikov> jd__: I totally agree
15:51:20 <gordc> ildikov: so docimpact <stuff that should already be in your commit message but people like me (and others) don't write proper commit messages>
15:51:38 <pradk> this takes effect for Mitaka? so if we fix something in stable/liberty this wont apply?
15:51:41 <ildikov> so basicly these are the changes, as much as I saw the patches are already merged
15:52:56 <gordc> ildikov: cool cool. i will continue to rely on you to yell 'docimpact!' :)
15:53:32 <ildikov> gordc: you can add pointers into the description like wiki page or etherpad or explicit notes like Install guide update needed, etc.
15:54:16 <ildikov> gordc: lol :)
15:54:38 <gordc> i see.
15:54:58 <gordc> cool. any other questions/comments relating to docs?
15:55:09 <ildikov> pradk: I think it's regardless of the branches, but I will check
15:56:07 <pradk> ildikov, k thx
15:56:12 <gordc> #topic open discussion
15:56:54 <gordc> i should mention if someone wants to be a cross project spec liaison, let me know
15:57:03 <gordc> you just read openstacks-specs apparently.
15:57:44 <gordc> ^ if that interested you, that may or may not exist soon (see last crossproject meeting log)
15:58:13 <gordc> i'll close this in a few, if no one hsa anything
15:59:02 <gordc> thanks folks.
15:59:05 <gordc> #endmeeting