15:01:28 <gordc> #startmeeting ceilometer
15:01:29 <openstack> Meeting started Thu Aug 27 15:01:28 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <openstack> The meeting name has been set to 'ceilometer'
15:01:37 <cdent> o/
15:01:51 <jasonamyers> o/
15:02:00 <llu-laptop> o/
15:02:10 <pradk> o/
15:02:11 <ildikov> o/
15:02:13 <fguillot> o/
15:02:20 <r-mibu> o/
15:02:47 <eglynn> o/ belatedly
15:03:15 <gordc> let's start here's the agenda: https://wiki.openstack.org/wiki/Meetings/Ceilometer#Agenda
15:03:29 <gordc> #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Ceilometer/RoadMap
15:03:48 <gordc> so last week (a bit less) before liberty-3 freeze
15:04:05 <gordc> we're doing pretty well in regards to remaining bps
15:04:16 <gordc> https://blueprints.launchpad.net/ceilometer/liberty
15:04:38 <gordc> since the gate is dying, i'd asked if we can put some priority on the specs (and big bugs)
15:05:06 <gordc> i think the remaining items are llu's SNMP work (which he just uploaded)
15:05:17 <gordc> the last patch of my mandatory limit work
15:05:26 <gordc> and dikonoor's event-rbac work
15:05:40 <gordc> are there any minor minor items we want to get into liberty?
15:05:59 <gordc> right now i'm probably going to request a FFE for SNMP work.
15:06:50 <cdent> it would be handy if we had some kind of shared thing that said "these reviews are the ones that matter most right now"
15:07:11 * gordc goes to grab ilnks
15:07:20 <gordc> https://review.openstack.org/#/c/199180/
15:07:26 <gordc> mandatory limit^
15:07:44 <gordc> declarative snmp: https://review.openstack.org/#/c/217667/
15:07:51 <gordc> + more to come.
15:08:15 <gordc> rbac: https://review.openstack.org/#/q/status:open+project:openstack/ceilometer+branch:master+topic:bp/events-rbac,n,z
15:08:24 <gordc> and that's pretty much it
15:08:40 <gordc> if there's something else to track. please holler now.
15:08:47 <pradk> gordc, i'm working on getting the doc update for declarative meters out today.. will share link on os-ceilometer later today
15:09:19 <gordc> pradk: cool cool. i think we can probably close your spec when the code patches merge though.
15:09:29 <pradk> that would be to os-manuals repo though
15:09:31 <pradk> cool
15:09:37 <llu-laptop> pradk: can you point me to the doc places? I believe my snmp work needs similar work
15:09:58 <ildikov> pradk: cool, tnx for docco, please add me to the review too
15:10:10 <pradk> llu-laptop, will do, watch out for link on os-ceilometer. getting the sphix tests to pass now
15:10:31 <pradk> ildikov, will do, thx
15:10:48 <ildikov> pradk: cool, tnx
15:11:04 <llu-laptop> pradk: thx
15:13:02 <gordc> llu-laptop: dikonoor: since you have the remaining bps, please keep us updated on work, if you run into any issues.
15:13:11 <gordc> carrying on.
15:13:16 <gordc> #topic recurring: ceilometerclient release?
15:13:39 <gordc> i don't think i've tracked anything in ceilometerclient recently.
15:13:46 <gordc> anyone else
15:14:05 <gordc> let's say no
15:14:16 <gordc> #topic recurring: Gnocchi status
15:14:37 <cdent> influxdb functional gate job is around, experimentally
15:14:44 <cdent> just trying it for the first time now
15:14:47 <cdent> no results yet
15:14:58 <gordc> cdent: cool. good start
15:15:04 <cdent> not much else huge going
15:15:37 <gordc> we can loop back to discussion of influxdb driver in openstack re: new spec for non-gnocchi influx
15:15:47 <gordc> let's move on.
15:15:57 <gordc> #topic Aodh release
15:16:10 <gordc> jd__: sileht
15:16:33 <gordc> since we've been discussing it. it looks like we're very close to release 1.0.0
15:16:42 * sileht waits for gate to merge it latest patch about integration tests
15:16:57 <gordc> we have the integration test merged to test basic ceiloemter+aodh+heat path
15:17:13 <gordc> does anyone have concerns for releasing aodh 1.0.0?
15:17:22 <cdent> neg
15:18:02 <gordc> cool. sileht, jd__, i'm comfortable with where we are.
15:18:24 <llu-laptop> gordc: so aodh won't follow  most openstack projects' release schedule, but much more like ceilometerclient in terms of release?
15:18:29 <gordc> sileht: i guess we can wait for your integration patch to merge and we can cut the first release.
15:18:42 <jd__> o/
15:18:46 <gordc> llu-laptop: yep. aodh will have it's own release cycle
15:18:53 <gordc> llu-laptop: similar to gnocchi
15:18:55 <jd__> I wanted to release 1.0.0 but I lack the permission in gerrit
15:19:02 <jd__> I asked -infra to fix that but didn't hear back yet
15:19:14 <gordc> jd__: there's a new release process
15:19:23 <gordc> aodh probably falls under that as well.
15:19:29 <jd__> gordc: which is?
15:19:37 <gordc> https://github.com/openstack/releases
15:20:00 <gordc> i don't know first releases work though so we might need to check with dhellmann
15:20:16 <jd__> gordc: I'll take a look but I'm not sure we'll follow that entirely
15:20:22 <jd__> I was planning to use the same process as Gnocchi
15:20:52 <gordc> ah i see... makes sense.
15:21:16 <jd__> that new process sounds a lot like someone engineered things without consulting what projects like us were doing
15:21:20 <gordc> i don't have any privileges either but let me know if you need me for anything
15:21:25 <jd__> e.g. splitting
15:21:59 <gordc> i think it's more tailored to libraries but i assumed it might cover services as well.
15:22:15 <jd__> gordc: yeah maybe – I'll see if we can fit
15:22:23 <gordc> seems it doesn't when i look at list of things it's covering
15:22:26 <jd__> if it can be less work for us to release, why not :D
15:23:00 <gordc> it's pretty simple process... edit yaml and let release mgmt team approve.
15:23:38 <jd__> hmmm ok
15:23:47 <jd__> why is there a release mgmt team and why and how they approve I wonder
15:24:33 <jd__> gordc: is it for stable branch only or all branches?
15:25:06 <cdent> jd__: I think the deal here is this is the process if you want the release:managed tag
15:25:13 <gordc> it's based on branches
15:25:17 <cdent> (or whatever the actual tag is)
15:25:32 <jd__> ah I see Ironic is in it for example so it might work
15:25:45 <jd__> cdent: what's the real upside on this process? :)
15:25:57 * cdent has no clue
15:26:00 <jd__> ok
15:26:04 <jd__> I'll gonna try and we'll see
15:26:10 <jd__> because it looks fun and lots of suprises
15:26:10 <llu-laptop> seems ironic is the only service project
15:26:10 <gordc> you share blame when if things in the fan.lol
15:26:17 <jd__> gordc: :))))
15:27:23 <gordc> if we want it to be completely managed by us, then we probably don't want it... but since Aodh is slightly tied to Heat we might want a more centralised release process
15:28:16 <ildikov> gordc: yeap, centralization makes sense from that perspective
15:28:46 <gordc> the basic process is you put a release request patch in, and if affected PTL approves, a release is made
15:29:32 <jd__> sounds like a corporate madness
15:29:46 <jd__> centralization supervised by people who have little clue what the project is doing, hm
15:29:53 <jd__> but I'm ok to give it a try nevertheless
15:29:54 * gordc looks at all our employers... no comment
15:30:17 * jasonamyers has no ideas about this employers comment :P
15:30:45 <gordc> jd__: cool cool. yeah we'll try it and i'm sure it's not like we're tied to process.
15:31:11 <jd__> yeah I'm not that worried
15:31:37 <gordc> jasonamyers: good answer, promotion! but first a few evaluations.
15:31:40 <idegtiarov_> o/
15:32:27 <jd__> gordc: https://review.openstack.org/#/c/217766/
15:32:31 <jd__> now let's wait'n see
15:32:41 <gordc> cool cool... anything else on Aodh release? we all content that we're not missing something after the last integration test merges? (and ildikov makes docco of changes)
15:33:05 <jd__> should be good, anyway we'd release 1.0.1 if we miss anything
15:33:19 <jd__> release early, release often
15:33:28 <gordc> jd__: true true... just ignore the blacklisted 1.0.0 :)
15:33:51 <ildikov> jd__: +1
15:34:13 <gordc> #topic open discussion
15:34:22 <fguillot> gordc: jd__ do you want to talk about the blueprint about timeseries I sent the other day?
15:34:36 <jd__> sure
15:34:38 <gordc> fguillot: sure
15:34:52 <gordc> #topic influxdb timeseries spec
15:35:03 <jd__> who shoots first? :)
15:35:18 <ildikov> fguillot: do you have a link handy?
15:35:35 <fguillot> so the spec is here: https://review.openstack.org/#/c/216838/
15:35:43 <ildikov> fguillot: tnx
15:36:39 <fguillot> jd__: no blood please :)
15:37:26 <jd__> hehe
15:37:50 <fguillot> is there any chance to include that in ceilometer or the only way for us is to contribute and improve gnocchi?
15:37:55 <jd__> so where I stand is that I'm ok having a dispatcher driver that feeds InfluxDB
15:38:15 <jd__> if that's enough for you, well no problem
15:38:18 <mbelanger> jd: in ceillometer or in gnocchi?
15:38:25 <jd__> in Ceilometer
15:38:30 <jd__> dispatcher driver for ceilometer-collector
15:38:33 <jd__> (to be clear)
15:38:34 <gordc> without any api support
15:38:40 <jd__> yeah without any API support
15:38:46 <jd__> if you want API support etc, that needs to be in Gnocchi
15:39:02 <fguillot> with or without the timeseries abstract layer?
15:39:02 <jd__> so clearly the InfluxDB support in Gnocchi is far from optimal and we'd be happy to have help!
15:39:12 <gordc> if there's no api support, does that really benefit the community?
15:39:29 <mbelanger> gordc: I do not think so
15:39:42 <gordc> mbelanger: same.
15:39:42 <jd__> gordc: that depends on the use case I'd say
15:39:59 <jd__> if you just want to use Ceilometer to poll data and feeds your InfluxDB, that's a valid use case
15:40:14 <fguillot> I agree
15:40:32 <jd__> fguillot: that's a good question, I'm not sure I'd be happy with a whole abstract layer right away, maybe some helper classes for future drivers
15:40:59 <jd__> fguillot: let's start small and if someone comes with OpenTSDB or whatever we can then factorize some code maybe?
15:41:08 <gordc> jd__: sure. but does that need to be in community? there are many different custom publishers/dispatchers out there that aren't in community because they are very specific to a certain use case
15:41:11 <jd__> so it really depends on what you want to achieve guys :)
15:41:51 <fguillot> for us we will mainly use influxdb
15:41:55 <jd__> gordc: I think it should be maintained because we can maintain it as InfluxDB is open source
15:42:11 <fguillot> so the abtract layer is not mandatory for us
15:42:29 <mbelanger> we want to achieve bandwidth billing in an efficient way and a TSDB is the perfect choice but ceillometer as all the data we need. Are we alone trying to acomplish taht^
15:42:32 <jd__> gordc: since I envision the dead of the v2 API it will have the same features as e.g. mongodb or sql
15:42:51 <jd__> fguillot: can you deal with having 0 API to access influxdb?
15:42:59 <llu-laptop> at least the dispatch driver without api support should be documented explicitly
15:43:04 <jd__> mbelanger: no, that's why we built Gnocchi
15:43:20 <cdent> if the goal is to create a dispatcher that uses influxdb, why does that need to be in ceilometer instead of just a stevedore plugin packaged separately?
15:43:39 <jd__> cdent: for maintenance and ease of distribution that's it
15:43:43 <gordc> right but i'm assuming there's different ways you can store data in influxdb (like all db)... and if you model it a certain way, it won't necessary mesh with another person's use case.
15:43:45 <jd__> it's not technical it's more political :D
15:43:52 <cdent> entry_points are pretty handy
15:43:57 <fguillot> jd__: yes we can live without an api, we can have our own api on the side
15:44:32 <jd__> so as cdent you can just write your own dispatcher with an entry point and be good with it already, sure
15:44:46 <jd__> then do we want to merge it in Ceilometer, that's a question, I'd say, but that's me :)
15:44:49 <jd__> s/say/say yes/
15:45:16 <mbelanger> What if we develop the driver in gnocchi but it really uses the influxdb indexes instead of indexes in a seperate db^
15:45:16 * cdent thinks we should have exactly one thing on each entry point and everything else should be external :)
15:45:33 <cdent> mbelanger: that would be really handy
15:45:39 <cdent> nadya and crew are talking about working on that
15:45:51 <gordc> mbelanger: ++
15:45:59 <fguillot> cdent: but if we create a separate plugin for that, can we publish the code it under the openstack repos as a new project?
15:46:30 <gordc> fguillot: yep... the powervm does that currently for their virt driver
15:46:39 <jd__> mbelanger: we'd love that
15:47:01 <cdent> fguillot: I'm not opposed to having it in ceilometer, just stating alternatives
15:47:04 <gordc> fguillot: https://review.openstack.org/#/q/project:stackforge/ceilometer-powervm,n,z
15:47:25 <mbelanger> jd: we would love to but we should have some discussion about the architecture (the way it is design)
15:47:49 <gordc> mbelanger: i think gnocchi is open to suggestion and contributions :)
15:48:03 <gordc> gnocchi team*
15:48:07 <mbelanger> I do not doubt that
15:48:15 <jd__> mbelanger: agreed
15:48:22 <ildikov> just to add my two cents it looks much better approach to me to improve what we have in Gnocchi rather than add a driver to Ceilometer without API support
15:48:42 <jd__> the current architecture in Gnocchi does not fit exactly what InfluxDB could do best, we may need to change that indeed
15:48:54 <gordc> ildikov: ++ that's my preference as well... of course, if there's reason why we can't i'm open to this dispatcher approach
15:48:58 <jd__> ildikov: yeah I'd prefer to have code pushed into Gnocchi than in Ceilometer too
15:49:08 <jd__> but I cannot force mbelanger and fguillot to do that ;)
15:49:38 <fguillot> jd__: what would be the best approach to contribute to gnocchi?
15:49:49 <fguillot> and propose some changes, write a blueprint?
15:49:50 <ildikov> well, if we does not support the Ceilometer direction that much, but we are open to accept Gnocchi improvements that hopefully helps :)
15:50:14 <gordc> mbelanger: fguillot: if you go the gnocchi route, you'll have more support as it offers a common api. but it's really up to your use case.
15:50:39 <idegtiarov_> afaik ityaptin  already start work on improvement driver for influxdb in gnocchi
15:50:51 <jd__> fguillot: write a blueprint, a mail with what you want to do exactly, whatever, I don't mind
15:51:02 <jd__> fguillot: just communicate and discuss with us before doing anything, it's safer :)
15:51:08 <gordc> jd__: you think it's good to have an email/meeting to just discuss things first? i don't know how well gerrit is for discussion
15:51:19 <jd__> I do prefer emails than gerrit honestly
15:51:31 <jd__> so a mail on openstack-dev with [gnocchi[ as subject and I'll be all set
15:51:46 <mbelanger> Skype or something is acceptable for you guys or not?
15:52:03 <gordc> mbelanger: i think we may be in different timezones.
15:52:27 <gordc> and mailing list will give people more time to think
15:52:37 <mbelanger> OK
15:52:39 <jd__> yeah I do prefer async
15:52:55 <jd__> fguillot: mbelanger: are you guys going to the next summit?
15:53:16 <fguillot> jd__: not sure, we have to talk to our boss :)
15:53:37 <mbelanger> Yeah, but with one commit the ticket is free ;)
15:53:47 <gordc> mbelanger: fguillot: maybe start with gnocchi mailing list and list out your use case and thoughts on what you want to change and we can all brainstorm. as cdent mentioned, nadya and mirantis team are interested in expanding influxdb paradigm
15:53:50 <jasonamyers> so many bugs in the bug list
15:53:58 <jasonamyers> for free tix
15:54:24 <gordc> please no spelling though... just me being picky
15:54:35 <mbelanger> ;)
15:55:19 <jd__> on a side note if you have things to share about the Swift driver since you tested it mbelanger and fguillot I'd be happy to have your feedback
15:55:35 <fguillot> gordc: jd__ ok let's try the gnocchi route, we will take some time to understand the existing code base and after that we will open a discussion on the mailing-list
15:56:04 <jd__> fguillot: cool!
15:56:10 <gordc> fguillot: awesome! and if gnocchi can't be changed we'll go the dispatcher route
15:56:23 <mbelanger> I'm ok with that
15:56:35 <fguillot> ok for me too
15:56:39 <gordc> if you ahve questions, feel free to ping for support
15:56:52 <mbelanger> Is gnocchi is use in production somewhere ?
15:56:56 <idegtiarov_> fguillot, good choice
15:56:58 <gordc> thanks for the cooperation folks
15:57:32 <gordc> mbelanger: it's being tested. i think many are waiting on influxdb support to adopt fully.
15:57:39 <idegtiarov_> mbelanger, afaik not yet
15:57:55 <mbelanger> OK thx
15:58:06 <fguillot> thanks everybody
15:58:26 <jd__> which is stupid since Carbonara is the best
15:58:29 <jd__> :-D
15:58:36 <gordc> cool cool, anything else? no time left
15:58:47 <jasonamyers> MidCycle
15:58:49 <jasonamyers> but out of time
15:59:00 <gordc> quick
15:59:11 <gordc> or openstack-ceiloemter better venue?
15:59:16 <jasonamyers> yeah
15:59:35 <gordc> ok. let's chat there. if you're interested in midcycle move to openstack-ceilometer
15:59:39 <gordc> thanks everyone!
15:59:47 <gordc> #endmeeting