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