15:00:21 <jd__> #startmeeting ceilometer 15:00:22 <openstack> Meeting started Thu Jun 27 15:00:21 2013 UTC. The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:25 <openstack> The meeting name has been set to 'ceilometer' 15:00:43 <eglynn> o/ 15:00:47 <jd__> hi everyone 15:00:51 <n0ano> o/ 15:00:51 <llu-laptop> o/ 15:01:22 <jd__> dhellmann and sandywalsh are excused 15:01:51 <litong> o/ 15:01:55 <shengjie> o/ long time no see , guys 15:02:00 <jd__> hi shengjie 15:02:05 <eglynn> hey shengjie 15:02:13 <jd__> #topic Review Havana-2 milestone 15:02:16 <apmelton1> 0/ 15:02:21 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-2 15:02:26 <shengjie> sorry being disappeared for a while, guys, some fires in Dell had to put off 15:02:37 <jd__> hehe 15:02:42 <jd__> "duty calls" 15:03:05 <jd__> so we're starting to be late for havana-2 15:03:15 <jd__> <-- :-( unhappy face 15:03:36 <jd__> dhellmann promised it'll tackle his bp next week 15:03:50 <jd__> eglynn: you seem to be back on track so that's nice :) 15:04:09 <eglynn> jd__: yep, nose back to the coding grindstone in a big way :) 15:04:24 <jd__> I don't have much news of other blueprints, so please update your bp status if needed 15:04:49 <llu-laptop> Since fengqian is not here, I'll update his 2 bps: https://blueprints.launchpad.net/ceilometer/+spec/pollster-runtime-configuration, https://blueprints.launchpad.net/ceilometer/+spec/paginate-db-search 15:05:05 <jd__> llu-laptop: did he start already? 15:05:18 <llu-laptop> He started both already. 15:05:23 <jd__> great 15:05:56 <jd__> #topic Release python-ceilometerclient? 15:06:05 <eglynn> yep, ceiloclient 1.0.1 is out 15:06:06 <llu-laptop> for pollster-runtime-configuration, it has 2 dependency for both oslo.config and oslo.incubator. The oslo.config patch is merged, ans the oslo.incubator patch is being reviewed 15:06:17 <eglynn> I must admit I made a bit of a dog's dinner of what should have been a fairly trivial task 15:06:19 <jd__> llu-laptop: sounds great! 15:06:27 <jd__> eglynn: hehe :)) 15:06:36 <eglynn> FYI, some notes I took of the my acculumated learnings ... 15:06:36 <jd__> eglynn: so next time will be a breeze right? 15:06:51 <eglynn> membership of ceilometer-ptl group is now required to push tags to ceiloclient: https://review.openstack.org/#/admin/groups/151,members 15:06:52 <eglynn> release tag MUST be GPG-signed, otherwise release seems to work but tarball is not uploaded to http://tarballs.openstack.org (causing a dangling link from pypi) 15:06:54 <eglynn> no need for the signing key to be exchanged, as no upstream GPG keyring maintained as yet 15:06:55 <eglynn> requirements versioning now centralized, need to propose version update to https://github.com/openstack/requirements/blob/master/tools/pip-requires first 15:06:57 <eglynn> need to wait on pypi mirroring for Jenkins builds to susceed, cron jobs run at 21:00-ish UTC daily: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/mirror.yaml 15:07:03 <eglynn> whoops sorry for the big paste!! 15:07:36 <jd__> :) 15:07:57 <eglynn> anyhoo, I'll know better next time 15:08:09 <jd__> (both eglynn and me are part of ceilometer-ptl for now, but if other people want to take the burden of doing release I can add ceilometer-core guys) 15:08:26 <jd__> anyhow thanks eglynn! 15:08:33 <gordc> naw, i'm ok letting you guys handle it :) 15:09:10 <jd__> #topic Mutiple dispatcher enablement 15:09:16 <jd__> litong: enlighten us 15:09:27 <litong> hi jd__, 15:10:14 <jd__> #link https://blueprints.launchpad.net/ceilometer/+spec/multi-dispatcher-enablement 15:10:24 <litong> the point of that blueprint is to allow multiple dispatchers(or publishers) so that metering data come out of the collector can go various places. 15:10:39 <litong> currently we can only make the data go to one database. 15:10:58 <eglynn> i.e. maintaining multiple metering stores? nice 15:11:19 <litong> we (IBM) have a need to allow metering data not only going to db but also call out to other systems. 15:11:44 <eglynn> selectively for certain meters, or everything goes everywhere? 15:11:47 <litong> so this effort will allow one to easily add new capabilities without touch ceilometer core. only configuration changes. 15:11:56 <shengjie> litong: like notification thing? 15:11:57 <llu-laptop> can the current multiple publisher meet the requirement? 15:11:59 <jd__> sounds cool 15:12:04 <jd__> I remembered we talked about it 15:12:12 <litong> @eglynn, can be both. 15:12:17 <eglynn> cool 15:12:18 <jd__> litong: I'll take time to review the patch 15:12:32 <litong> with Doug's suggestion go with the pipeline approach, that becomes a configuration issue. 15:13:07 <litong> jd__, the patch I put out there simply make record_metering_data as the new interface. 15:13:46 <litong> Doug has some concerns and very much like to go with pipeline approach. I am in the works of submiitting another patch. so we can compare which is a better implementation. 15:13:58 <jd__> cool, I'll wait that other patch then? :) 15:14:22 <litong> if you look at the one I already put up there and put some commenst on , that will be great. 15:14:38 <jd__> ok! 15:14:42 <jd__> I can do that tomorrow 15:14:48 <litong> problem with the pipeline approach is that the data has to be converted to Counter. 15:15:10 <litong> that means, the business (data structure) logic will have to be considered, I do not really like that. 15:15:27 <litong> Counter are the things the pipeline knows how to handle. 15:15:28 <jd__> I'm not sure about that, you could reuse the infrastructure without the plugins 15:15:40 <jd__> the pipeline doesn't really know about Counter I think 15:15:46 <jd__> it just passes data around 15:15:53 <jd__> or at lease we could modify it in this way 15:15:56 <jd__> (if needed) 15:16:06 <litong> I think it actually does, if I pass simple data, it blows up. 15:16:15 <jd__> maybe there's some adjustement indeed 15:16:20 <litong> right, that will be nice. 15:16:51 <gordc> litong, how far along is the pipeline impl? 15:16:59 <litong> I like the capability of pipeline filter thing, I think that can be quite useful down the road. so the meter can be selective. 15:17:00 <llu-laptop> I thinkt the problem for pipeline here is not in the polling metrics, but those metrics from noticitation 15:17:14 <llu-laptop> s/noticitation/notification/ 15:17:19 <litong> very close, wanted to submit before the meeting but had a little problem to solve first. 15:17:23 <litong> should be in today. 15:18:01 <gordc> cool cool, be cool to have a look. maybe a 2nd/3rd pair of eyes can spot any easy fix for your issue. 15:18:04 <litong> so I would like this blueprint to be approved if it is all possible. 15:19:14 <gordc> llu-laptop, do you mean the pipeline would miss meters from notification? 15:19:19 <jd__> litong: I can approve but you have to set a milestone 15:19:41 <litong> ok. the other implementation should be in today. 15:19:46 <llu-laptop> gordc: I don't think the pipeline supports notification metrics 15:19:58 <litong> so I hope I can make havana-2 or we already passed it. 15:20:14 <jd__> litong: havana-2 is in ~3 weeks, so that should be ok 15:20:33 <litong> ok. thanks. should be able to make it. thanks. 15:20:42 <jd__> here it is, you're in the roadmap now 15:21:06 <gordc> llu-latop, hmm.. that would suck. i'd need to take a look at code again. brain isn't working yet. 15:21:11 <litong> jd__, thanks folks. 15:21:27 <gordc> good stuff, litong 15:21:49 <litong> @gordoc, thanks. 15:22:01 <jd__> next topic then? 15:22:12 <jd__> #topic DB2 support 15:22:19 <jd__> #link https://blueprints.launchpad.net/ceilometer/+spec/ibm-db2-support 15:22:32 <jd__> (this one is scary) 15:22:50 <litong> @jd__, IBM very much like Ceilometer to support db2 as its backend. 15:23:04 <litong> currently we can try to use sqlachemy to do that. 15:23:22 <jd__> cool 15:23:46 <litong> but the problem is that after a lot of discussion, some of the developers in IBM think that using tables for metadata handling is really the wrong tool. 15:24:29 <eglynn> is the objection related to metadata querying? 15:24:34 <litong> the concern is really the query performance. w 15:24:44 <eglynn> k 15:24:49 <jd__> litong: yeah classic problem 15:25:20 <gordc> eglynn, no one on your end is looking at the sql metadata query bp right? 15:25:32 <litong> we think that the freelance (metadata) and where the real value is in the metadata. be able to aggregate and query metadata is very important. 15:25:33 <eglynn> gordc: nope 15:25:35 <llu-laptop> that seems to be the problem for all SQL DB, I think 15:25:53 <litong> @llu-laptop, totally agreed. 15:26:28 <eglynn> so is there an alternative approach being mooted? 15:26:36 <eglynn> (alternative to using tables that is ...) 15:26:41 <litong> ibm is working on some feature on db2 which will actually allow docs. 15:26:55 <litong> the point is that the implementation will not be based on sqlachemy. 15:26:57 <gordc> .... yeah. i get the feeling this is just going to get pushed. sql metadata query seems like serious stuff. 15:27:22 <litong> with relational database, no matter how hard you try, indexes, relationship, you can not really win at the end with freelance data. 15:27:56 <eglynn> "freelance data" == "free-form data" ? 15:28:08 <litong> @eglynn, yes, exactly. 15:28:10 <xingzhou> can be, no schema 15:28:22 <eglynn> k, understood 15:28:24 <shengjie> litong: as no-sql db, this is a win for HBase, dynamic columns, but we have other issues 15:29:10 <litong> @shengjie, yeah, it is always the word "other issues" get people concerned. 15:29:49 <litong> so I think that my question is are we (ceilometer team) allow vendor specific drivers to be in Ceilometer or not. 15:30:23 <jd__> I don't see the difference with something like the HBase driver 15:30:27 <jd__> what would it be? 15:30:28 <eglynn> hmmm, how would such a thing be tested? 15:30:41 <eglynn> (i.e. based on proprietary DB) 15:30:54 <jd__> eglynn: 'cause ya think we test HBase? 15:30:56 <jd__> :-) 15:31:03 <eglynn> LOL :) 15:31:10 <eglynn> ... but we could! 15:31:25 <eglynn> i.e. wouldn't be encumbered by software licensing etc. 15:31:29 * gordc is trying to fix hbase tests right now... isn't likely it already. 15:31:29 <litong> @eglynn, it will fall on the maintainer to test all the features. 15:31:30 <shengjie> yeah, Ceilo architecture doesn't stop u from doing that, having another driver :) 15:31:39 <jd__> eglynn: we support Oracle via SQLAlchemy, we don't test it 15:31:40 <gordc> s/likely/liking 15:32:14 <eglynn> jd__: true that, but I guess we still have a way of testing the sqlalchemy driver with OSS only 15:32:18 <jd__> gordc: fix hbase tests… you mean fix hbase :) 15:32:33 <litong> @jd__, I think it will fall on the shoulders of the parties who interested in these drivers to do the work. 15:32:38 <litong> both development and testing. 15:32:43 <jd__> eglynn: point taken, I'm trying to be the devil's advocate as usual 15:32:51 <eglynn> sure, understood 15:32:52 <jd__> litong: I agree 15:32:54 <litong> as of now, it will be me, gordon and ibmers. 15:32:55 <gordc> jd__, if that's what's needed, then i'm stopping my efforts now.lol 15:33:08 <jd__> gordc: haha I don't know really :) 15:33:37 <shengjie> litong: agree, whoever is using the driver should test the drivers themselves, as community effort, we test it at the unit-testing level 15:33:45 <jd__> to me HBase or DB2 is kind of the same, I'll never go and fix them anyway, being the database 15:33:49 <jd__> to me HBase or DB2 is kind of the same, I'll never go and fix them anyway, being the database free or not 15:34:06 <eglynn> so presumably at least the gluecode would be opensource? 15:34:30 <eglynn> (i.e. the clientside DB2 library, whatever the direct dependency would be ...) 15:34:40 <jd__> I hope it is already indeed 15:34:49 <jd__> that would be a blocker otherwise I think 15:34:55 <litong> @eglynn, exactly, so when interface changes etc, these drivers can be at least checked on. 15:35:05 <jd__> or we won't be able to at least declare a dependency on it 15:35:06 <eglynn> jd__: yep, agreed 15:35:12 <litong> @eglynn, the idea is that the driver will not introduce new dependencies. 15:35:21 <eglynn> litong: a-ha, OK 15:35:41 <litong> at least that is what I am aiming at. 15:35:50 <eglynn> fair enough 15:36:00 <jd__> yup. 15:36:24 <litong> approval of this blueprint will also encourage other vendors to be involved. if that is just a side effect. 15:38:20 <jd__> I'm ok to approve, what's the milestone you target? 15:38:36 <litong> havana-2 as well. 15:38:48 <jd__> done 15:38:50 <litong> I have something already working mostly. 15:38:58 <litong> thanks jd__ 15:39:04 <jd__> ok 15:39:14 <jd__> litong: update the status as you move on this :) 15:39:18 <jd__> and on the other one 15:39:36 <litong> will do 15:41:09 <jd__> #topic open discussion 15:41:41 <eglynn> just a quick heads-up on the HK summit 15:41:49 <eglynn> very early days still obviously, but apparently the conference hotel (marriott) is filling up v. fast 15:41:57 <eglynn> (in case anyone on the team is mulling whether to pull the trigger on booking) 15:42:06 <eglynn> cancellation policy is nasty tho' 15:42:18 <litong> @eglynn, there are not many hotels close to the conference location. 15:42:34 <eglynn> litong: yep, it's out by the airport right? 15:42:39 <litong> @eglynn, agreed. 15:42:49 <gordc> let's see if i get funding this time. 15:42:55 <litong> @eglynn, yes, it is far away from anywhere. 15:43:27 <litong> I lived in HK for two years, so I have a bit information about the area. 15:43:56 * jd__ booked already 15:44:01 <llu-laptop> litong: no easy public transport? 15:44:20 <eglynn> litong: taxis required to get anywhere? 15:44:24 <litong> public transportation is great here. you can go anywhere with bus or subway. 15:44:36 <litong> I mean great there. 15:44:44 <litong> it just takes time. 15:44:55 <litong> and a lot of walking. 15:44:59 <eglynn> cool 15:45:13 <eglynn> good for the cardio :) 15:45:22 <litong> @eglynn, totally. 15:45:45 <litong> HK is a great place, just not that particular location. 15:45:53 <dhandy> Hi all. I have a question about the Monitoring Physical Devices blueprint. 15:46:11 <dhandy> We have an interest in that. 15:46:12 <gordc> side topic - can someone quickly review this: https://review.openstack.org/#/c/33528 -- i'm cool, if you tell me to abandon it because it's not needed 15:47:02 <dhandy> The status for Monitoring Physical Devices is "needs code review" 15:47:08 <gordc> https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices 15:47:13 <dhandy> Is anyone planning on reviewing that? 15:47:59 <llu-laptop> dhandy: I think there is already some review comment on https://review.openstack.org/#/c/30700/ 15:48:12 <jd__> they did they will split it up in patches 15:48:18 <jd__> it's really big 15:48:57 <gordc> agreed - didn't look at it because i'm not an expert on it and 1300 lines was too much. :) 15:49:49 <llu-laptop> I guess the patch set 2 of https://review.openstack.org/#/c/30700/ is considered to be the first part of the splitting, comparing to patchset 1 15:50:29 <jd__> ok i'll take a look then 15:51:07 <jd__> #endmeeting