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