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