21:00:07 <nijaba> #startmeeting Ceilometer
21:00:07 <nijaba> #meetingtopic Ceilometer
21:00:07 <nijaba> #chair nijaba
21:00:07 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
21:00:07 <nijaba> ATTENTION: please keep discussion focused on topic until we reach the open discussion topic
21:00:08 <openstack> Meeting started Wed Jan 30 21:00:07 2013 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:11 <openstack> The meeting name has been set to 'ceilometer'
21:00:13 <openstack> Current chairs: nijaba
21:00:17 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting?
21:00:17 <nijaba> o/
21:00:19 <dhellmann> o/
21:00:20 <n0ano> o/
21:00:21 <yjiang5_home> o/
21:00:25 <eglynn> o/
21:00:25 <apmelton> o/
21:00:28 <danspraggins> o/
21:00:59 <jd__> o/
21:01:18 <sandywalsh> o/
21:01:26 <nijaba> nice showup! thanks.  asalkeld is at at linuxconf.au and may join us if he can.
21:01:34 <nijaba> #topic actions from previous meeting
21:01:42 <nijaba> #topic nijaba to specify draft policy on wiki for units
21:01:42 <nijaba> My deepest apologies, I still haven't been able to work on this
21:01:42 <nijaba> #action nijaba to specify draft policy on wiki for units
21:02:11 <nijaba> I won't leave to much time for others to blame me :)
21:02:14 <nijaba> #topic nijaba to untarget synaps bp for now
21:02:14 <nijaba> #info That was done.
21:02:34 <nijaba> #nijaba to propose a doodle for helthmon meeting
21:02:34 <nijaba> #info Done as well.  The meeting occured today and allowed good progress.  More to come at the summit.
21:02:39 <nijaba> comments on this?
21:02:47 <llu-laptop> o/
21:03:12 <nijaba> I guess not!
21:03:15 <dhellmann> the meeting went well, and I'm looking forward to seeing the blueprints that come from it
21:03:18 <sandywalsh> my gut says that healthmon, as proposed today, steps on a lot of other projects toes
21:03:26 <sandywalsh> so getting them in the fold is key
21:03:35 <dhellmann> sandywalsh: +1
21:03:35 <sandywalsh> and I think they'll span many projects
21:03:43 <dhellmann> +1 again
21:04:00 <nijaba> Good to see agreement!
21:04:19 <nijaba> sounds like some interesting sessions for the summit
21:04:22 <jd__> +1 too fwiw
21:04:42 <sandywalsh> yeah, the summit should be interesting ... lots of whiteboards :)
21:04:49 <nijaba> hehe
21:04:50 <nealph> good progress indeed...I was impressed by the open conversation. Look forward to hearing more.
21:05:42 <nijaba> moving on...
21:05:45 <nijaba> #topic nijaba to formaly start ml thread about core dev startus for yjiang5_home and llu-laptop
21:05:45 <nijaba> #info This was done. We'll discuss this is a moment
21:05:56 <nijaba> #topic sandywalsh to start a thread about adopting https://github.com/openstack/nova/blob/master/HACKING.rst
21:05:56 <nijaba> #info This was done and we'll vote on the adoption in a moment
21:06:08 <nijaba> That's it for last week's actions
21:06:22 <nijaba> #topic yjiang5 and llu-laptop are now core dev for ceilometer
21:06:28 <nijaba> I would like to formally congratulate both of them, even though they are certainly asleep at this time.  I just added them to the ceilometer driver's group.
21:06:28 <nijaba> #info congratulations
21:06:44 <sandywalsh> +1
21:06:46 <yjiang5_home> really thanks for your trust and will contribute more to the project :)
21:06:48 <dhellmann> it's nice to see the team continuing to grow
21:06:52 <sandywalsh> (or +2 I guess)
21:06:59 <jd__> that's good news
21:07:00 <nijaba> yjiang5_home: llu-laptop: good to see you around at such a late time for you
21:07:02 <eglynn> absolutely, welcome guys!
21:07:12 <llu-laptop> thanks, looking forward to contirubte more.
21:07:20 * jd__ needs more +2 on his patches :-)
21:07:33 * dhellmann needs more hours in the day
21:07:40 * nijaba too
21:07:47 * jd__ pats dhellmann
21:07:55 <jd__> nijaba: has the technical side of adding them been done already?
21:08:02 <nijaba> jd__: just did
21:08:07 <jd__> awesome!
21:08:49 <jd__> llu-laptop: yjiang5_home: feel free to turn your past +1 in +2 then :)
21:08:58 <yjiang5_home> jd__: :)
21:09:16 <nijaba> llu-laptop: yjiang5_home: please remember not to use the approve status unless you are the second one applying a +2 to a patch
21:09:32 <jd__> yeah, that can be tricky
21:09:46 <jd__> as soon as you set 'Approve' the patch is merged
21:09:54 <dhellmann> right, no matter what the other setting is
21:10:09 <yjiang5_home> nijaba: sure, thanks for reminding. we will learn the gerrit doc firstly.
21:10:09 <nijaba> llu-laptop: yjiang5_home: you know where to find us if you have any questions
21:11:04 <yjiang5_home> yes
21:11:11 <llu-laptop> looking in the gerrit, not find the +2 options :-(
21:11:40 <nijaba> llu-laptop: it may need some time for the group membership to propagate
21:11:47 <nijaba> unless I missed something
21:11:49 <dhellmann> I think there's a cron job that has to update that configuration setting.
21:12:22 <jd__> or maybe we were joking about adding you to the core team, you'll see
21:12:24 <nijaba> llu-laptop: you did receive and email with your new group membership, right?
21:12:43 <nijaba> s/and/an
21:12:57 <llu-laptop> nijaba: yes
21:13:14 <nijaba> llu-laptop: then it should propagate soon
21:13:28 <nijaba> let's move on?
21:13:34 <llu-laptop> nijaba: ok, i'll wait for that then :-)
21:14:02 <nijaba> #topic Vote on adopting the hacking guidelines
21:14:02 <nijaba> #link https://github.com/openstack/nova/blob/master/HACKING.rst
21:14:02 <nijaba> Any comments before we vote on the subject
21:14:23 <jd__> yep
21:14:23 <yjiang5_home> HACKING requires translation, I'm not sure if we are ready for that.
21:14:38 <yjiang5_home> others should be ok
21:14:54 <jd__> I'm really not confortable having rules that should be detected automagically by rules
21:15:09 <dhellmann> isn't there a tool for checking?
21:15:11 <eglynn> how much of the HACKING guidelines are enforcable via the pep8 checks?
21:15:22 <jd__> dhellmann: what I'm thinking is typically the import alphabetical order
21:15:31 <jd__> this is a PITA, there's no tool for that currently
21:15:38 <sandywalsh> there is hacking.py for checking
21:15:39 <jd__> and nitpicking in the review for that is going to make me cry
21:15:49 <jd__> sandywalsh: can we put it with tox?
21:15:56 <dhellmann> jd__: I thought hacking.py checked that
21:16:04 <dhellmann> #link https://github.com/openstack/nova/blob/master/tools/hacking.py
21:16:10 <sandywalsh> jd__: I don't see why not
21:16:10 <jd__> I don't know hacking.py, I only saw HACKING.rst :)
21:16:28 <jd__> ok
21:16:28 <eglynn> +1 for enforcement
21:16:33 <llu-laptop> jiang5_home: the transaltion framework is already done. What we need to do is to annotate those strings to be translated with _(), and did the actual translation on transifex.com. All others will be done by jenkins.
21:16:37 <sandywalsh> +1
21:16:41 <sandywalsh> (it's the openstack way)
21:16:45 <dhellmann> if we do adopt it, we should only have hacking.py turned on non-voting in jenkins until we get it passing
21:16:53 <sandywalsh> dhellmann: +1
21:16:55 <jd__> well as long as we can have tools helping us follow any hacking guide and not having humans nitpicking manually, I'm all good
21:17:00 <dhellmann> I don't want to stop everything else just to fix style issues
21:17:05 <jd__> dhellmann: +1
21:17:18 <yjiang5_home> dhellmann:  +1
21:17:21 <nijaba> ready to formally vote then?
21:17:27 <jd__> yes
21:17:42 <nijaba> #startvote adopt the hacking guidelines? yes, no, abstain
21:17:43 <openstack> Begin voting on: adopt the hacking guidelines? Valid vote options are yes, no, abstain.
21:17:44 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:17:51 <dhellmann> #vote yes
21:17:52 <jd__> #vote yes
21:17:53 <eglynn> #vote yes
21:17:53 <llu-laptop> #vote yes
21:17:54 <yjiang5_home> #vote yes
21:17:55 <sandywalsh> #vote yes
21:17:59 <nijaba> #vote abstain
21:18:00 <n0ano> #vote yes
21:18:02 <danspraggins> #vote yes
21:18:25 <nijaba> look like a done deal
21:18:33 <nijaba> #vote no
21:18:37 <nijaba> just because I can
21:18:40 <sandywalsh> haha
21:18:44 <jd__> anyone wants to take #action for importing hacking.rst and hacking.py into our git and add this to a non-voting check in jenkins? (can be 2 #action)
21:18:53 <apmelton> #vote yes
21:18:58 <sandywalsh> thanks guys, it'll make code reviews cause less neck twitches
21:19:00 <nijaba> #endvote
21:19:00 <openstack> Voted on "adopt the hacking guidelines?" Results are
21:19:01 <openstack> yes (9): apmelton, n0ano, sandywalsh, jd__, eglynn, llu-laptop, dhellmann, danspraggins, yjiang5_home
21:19:02 <openstack> no (1): nijaba
21:19:35 <sandywalsh> #action sandy will integrate hacking.py
21:19:42 <nijaba> thanks sandywalsh
21:19:49 <sandywalsh> (since he caused this mess :)
21:20:01 <jd__> thanks sandywalsh :)
21:20:11 <dhellmann> yes, thanks!
21:20:19 <nijaba> #topic Approve http://wiki.openstack.org/NewCeilometerAgent ?
21:20:19 <nijaba> SandyWalsh would like to see this blueprint approved.
21:20:39 <nijaba> That seems a big change for me, late in the cycle
21:20:58 <jd__> We can approve without targetting at G, right?
21:21:03 <sandywalsh> nijaba: the proposal is to do it in parallel, without upsetting the current agent
21:21:17 <dhellmann> before we schedule it, let's discuss whether we want it at all
21:21:27 <sandywalsh> branches may land, but have no effect (it's like a experimental branch)
21:21:35 <sandywalsh> *an
21:21:38 <jd__> dhellmann: to me, we want it if Nova offers the mechanism to do it
21:21:40 <nijaba> sandywalsh: do you have the ressources to deliver it before g3?
21:21:47 <sandywalsh> nijaba: I'm working on it now
21:22:00 <jd__> sandywalsh: will it get into Nova for g3?
21:22:04 <dhellmann> jd__: I do have a couple of issues
21:22:11 <sandywalsh> jd__: we'll make sure nova will have what it needs
21:22:14 <jd__> dhellmann: raise, raise then :)
21:22:20 <nijaba> sandywalsh: so, your proposal is to add this as a new mechanism, not to replace?
21:22:27 <sandywalsh> nijaba: correct
21:22:34 <dragondm> Yup, I'm working on nova for this too.
21:22:36 <sandywalsh> nijaba: we can decide later on the best approach
21:22:40 <dhellmann> well, for starters, the blueprint assumes that the only information we are interested in collecting from the hypervisor is information that nova is (or will) collect
21:22:43 <nijaba> mmmh...  that removes some of my objections then
21:22:57 <dhellmann> when we tried to extend the hypervisor API in nova before to collect more data, we were rebuffed
21:23:18 <dhellmann> so I'm not sure what will be different about that this time
21:23:23 <sandywalsh> dhellmann: myself and dragon have done a lot of stuff in those layers before
21:23:32 <dragondm> yes.
21:23:41 <dhellmann> sandywalsh: the objection was in principle, not over any specific patch or implementer
21:23:44 <jd__> dhellmann: yeah that's the point I raised to sandywalsh, but he seems confident to change things on Nova side :)
21:23:47 <yjiang5_home> dhellmann: Will ceilometer monitor more host information like host utilization etc?
21:23:54 <dhellmann> that is, they didn't want nova collecting the data
21:24:05 <dhellmann> yjiang5_home: that is a long-term goal, yes
21:24:42 <sandywalsh> dhellmann: the precedent is already set on the xen side
21:24:53 <yjiang5_home> dhellmann: then we have two point for this bp: a) will nova provide the instance information, b) will ceilometer need more information that possibly out of nova scope?
21:24:56 <llu-laptop> dhellman: in that case, I dont think nova will provide enough information in a long-term goal.
21:25:00 <nijaba> sandywalsh: you mean xcp?
21:25:02 <sandywalsh> i mean, there is a chance we'll be rebuffed again, but it will make for a wonderful debate :)
21:25:10 <dhellmann> sandywalsh: I would have to go look at that email thread again to see what was being added before. eglynn may remember.
21:25:25 * nijaba takes it that sandywalsh loves a good debate
21:25:37 <asalkeld> hi
21:25:43 <asalkeld> (sorry late)
21:25:45 <nijaba> hey asalkeld
21:25:53 <eglynn> dhellmann: I need to refresh my memory also
21:25:56 <nijaba> asalkeld: hope the conf is good
21:26:01 <dhellmann> if we do win the debate over the nova changes, that still leaves the issue of collecting data not related to instances
21:26:05 <asalkeld> yea, thx
21:26:22 <dhellmann> nova does some of that for the scheduler, and we've discussed the idea of moving that into ceilometer
21:26:34 <sandywalsh> I think we've already determined that there is still a need for another agent. This proposal is the 90% we can cover ... the most common deploys
21:26:48 <dhellmann> we could leave it in nova, except that then we have 2 projects doing data collection still
21:27:05 <sandywalsh> if there are situations where we can't get everything we need we may have to use an agent again, but I think they are very special cases
21:27:09 <sandywalsh> and deployment specific
21:27:23 <dhellmann> I'm not sure how collecting scheduler data is deployment specific.
21:27:56 <sandywalsh> it's not related to the scheduler
21:28:09 <sandywalsh> the stuff the scheduler needs is what's there now (ram + disk, cpus, etc)
21:28:15 <sandywalsh> (I put it there :)
21:28:31 <asalkeld> we were going to be the data collector for scheduler at some point
21:28:41 <asalkeld> or some suggested it
21:28:50 <jd__> this can be an argument for sandywalsh
21:28:51 <sandywalsh> sure, no reason why you still can't be ... depends on latency really
21:29:01 <nijaba> asalkeld: vishy did
21:29:06 <sandywalsh> the scheduler needs very timely data
21:29:15 <sandywalsh> CM could be too slow for it
21:29:16 <dhellmann> right, vishy and I discussed it briefly at the grizzly summit
21:29:37 <asalkeld> sandywalsh, just how timely
21:29:46 <sandywalsh> asalkeld: near real-time
21:29:49 <asalkeld> second/minute?
21:30:07 <sandywalsh> the longer the delay the more over allocations will occur
21:30:12 <dhellmann> collecting the data in a separate process elimintes issues with nova operations affecting the timed process
21:30:25 <sandywalsh> although some of that may be fixed with belliot's allocation code
21:30:55 <sandywalsh> that's why we were using the fanout queues from the compute nodes to all the schedulers
21:31:16 <sandywalsh> broadcast updates
21:31:46 <asalkeld> that change is not a simple one
21:31:47 <sandywalsh> but, perhaps this is a discussion for another topic ... the core premise I think is still sound
21:31:55 <n0ano> one issue, are we talking about going from a push (nodes send data to scheduler) to a pull model (scheduler asks CM for info)?
21:32:06 <dhellmann> n0ano: not necessarily
21:32:14 <sandywalsh> being: we can do most all we need with notifications and a simpler agent model
21:32:24 <dhellmann> the mandate for this project is to collect and distribute this sort of data
21:32:47 <sandywalsh> n0ano: there can be different schedulers do things different ways
21:33:00 <n0ano> in some respects I like CM pushing data as it could send data about multiple nodes in a single message
21:33:01 <sandywalsh> n0ano: it's just how they update their HostInfo records
21:33:25 <dhellmann> sandywalsh: does this plan also include some alternate solution for the instance delete event notifier plugin (mentioned in point 1 of the blueprint)?
21:34:07 <sandywalsh> dhellmann: it's just another event in the stream, shouldn't be any different than any other message
21:34:30 <dhellmann> receiving that event is not, but the reason for the notifier is the race condition between generating it and the instance being deleted
21:34:42 <dhellmann> we want to collect final stats on the instance *before* it is deleted
21:34:51 <dhellmann> and we don't want to charge users for the time it takes us to delete the thing
21:34:57 <eglynn> we need to capture the last dying breath of the instance ;)
21:35:13 <dhellmann> so the plugin blocks the operation, collects stats and sends them to the bus, then continues
21:35:35 <sandywalsh> dhellmann: in that case, nova should send the additional information in the delete notification. This would require a patch to nova, which we are willing to add.
21:35:44 <sandywalsh> (in the .start event)
21:35:53 <jd__> sounds great
21:36:04 <eglynn> yep, reasonable solution
21:36:17 <apmelton> I think that's basically already there, if we want to change only up until the user tries to delete it, then timestamp on the start should suffice
21:36:18 <dragondm> yah, we can always add data to a notification.
21:36:20 <dhellmann> that would be fine. again, we had some of those sorts of changes rejected early on
21:36:56 <sandywalsh> apmelton is working on adding this to stacktach currently :)
21:37:21 <sandywalsh> I think this is a low-impact BP overall
21:37:26 <sandywalsh> with great upside
21:37:50 <nijaba> I am not sure we have a consensus though
21:38:10 <nijaba> should we hava a core-dev only vote to check?
21:38:12 <sandywalsh> I'm happy to ease your troubled minds :)
21:38:12 <jd__> I think we agree that Nova needs to have some code before this blueprint is doable
21:38:19 <yjiang5_home> dhellmann: sandywalsh: can we take a step-by-step method ? If anything changed successfully in nova, we can remove the corresponding code in ceilometer, and in the end possibly the compute agent will have nothing to do.
21:38:25 <sandywalsh> jd__: I agree with that
21:38:31 <jd__> yjiang5_home: yeah totally.
21:38:36 <dragondm> sounds good.
21:38:36 <sandywalsh> jd__: they can be done in parallel
21:38:38 <eglynn> +1
21:38:50 <nijaba> now that sounds more like one
21:38:51 <dhellmann> yjiang5_home: that makes sense
21:38:56 <sandywalsh> yjiang5_home: the new agent is so small it hardly makes sense. it's easier to cut-and-run
21:38:56 <jd__> sandywalsh: sure, but we won't merge anything in Ceilo until Nova has the parts we need though
21:39:17 <jd__> nijaba: see how I can build a consensus by stating the obvious! :-)
21:39:26 <nijaba> jd__: great job!
21:39:32 <asalkeld> we used to support older versions
21:39:42 <yjiang5_home> sandywalsh: can current notification code be used for your agent temply?
21:39:43 <asalkeld> is that not an issue anymore
21:39:45 <nijaba> asalkeld: until g2
21:39:52 <sandywalsh> this is sort of how we got zones/cells going, we merged the new functionality in but it was all disabled by default
21:39:58 <sandywalsh> people could play with it if they wanted
21:40:05 <sandywalsh> but otherwise had no idea it was there
21:40:07 <nijaba> asalkeld: that's whart we agreed
21:40:13 <asalkeld> ok
21:40:20 <sandywalsh> yjiang5_home: for a lot of it yes
21:40:29 <sandywalsh> yjiang5_home: the delete scenario might need some fix
21:40:48 <sandywalsh> yjiang5_home: and the libvirt side might need some tweaks (dragondm is looking into that)
21:40:56 <nijaba> jd__: care  to write up the (#)agreed ?
21:41:03 <jd__> nijaba: sure
21:41:37 <yjiang5_home> sandywalsh: so would it be possible that: a) change nove b) add to current notification code, c) in the end, remove compute agent, d) update the notification code as the type you suggested?
21:41:42 <jd__> #agreed sandywalsh & cie to work on implementing feature in Nova in order to deprecates the Ceilometer compute agent in favor of notifications consuming
21:42:06 <nijaba> perfect, thanks
21:42:07 <jd__> does that cover enough for you sandywalsh?
21:42:56 <sandywalsh> yjiang5_home: how about I get an agent working that stuffs all the current events into CM as they stand today (as a proof of concept) and in parallel we work on the nova changes?
21:42:57 <sandywalsh> "_
21:42:58 <sandywalsh> :)
21:43:04 <sandywalsh> jd__: cie?
21:43:11 <nijaba> & co
21:43:17 <sandywalsh> ah :)
21:43:19 <asalkeld> so we can still use the compute agent, just not needed?
21:43:19 <jd__> yeah sorry
21:43:20 <dragondm> :->
21:43:26 <nijaba> french...
21:43:28 <jd__> cie is probably French :D
21:43:34 <asalkeld> (thinking of montoring)
21:43:36 * jd__ mixed up
21:43:45 <sandywalsh> asalkeld: yes, everything stays the same, this will be an alternative agent
21:43:49 <dhellmann> sandywalsh: if nova generates the notifications, the existing collector should receive them without any major changes
21:43:57 <dhellmann> although we need to make it listen to the error events
21:43:57 <dragondm> yup
21:44:01 <asalkeld> ok, cool with that
21:44:25 <jd__> next topic?
21:44:29 <nijaba> yup
21:44:40 <yjiang5_home> sandywalsh: dhellmann: yes
21:44:44 <sandywalsh> jd__: your summary looks good to me
21:44:45 <nijaba> #topic A note about https://blueprints.launchpad.net/ceilometer/+spec/use-new-rpc-messsage
21:44:45 <nijaba> jd__ wanted to bring up somethinkg about this: you have the floor.
21:44:53 <asalkeld> (I need to head off to keynote)
21:44:58 <asalkeld> later guys
21:45:01 <nijaba> asalkeld: have fun
21:45:05 <eglynn> asalkeld: see ya
21:45:06 <jd__> yeah, I've removed the target on this blueprint actually
21:45:14 <sandywalsh> later asalkeld ... good questions
21:45:17 <jd__> it seems to me that the implementation for nova has been retargeted too
21:45:19 * dhellmann waves to asalkeld
21:45:47 <jd__> https://blueprints.launchpad.net/nova/+spec/trusted-messaging has no goal/milestone target anymore
21:45:56 <jd__> so I think we won't have this for G
21:46:07 <dhellmann> yes, that seems unlikely
21:46:18 <nijaba> mmmm..  We should talk with Eric Windish....
21:46:25 <jd__> so I just wanted you guys and our dear PTL to be aware
21:46:46 <dhellmann> I'm going to try to finally get to the notifications listener api next week, but I don't see us moving our meter messages away from rpc in time
21:46:49 <jd__> nijaba: I can take care of that
21:47:04 <nijaba> jd__: sure.  care to action yourself?
21:47:07 <llu-laptop> do we know the reason of untarget for G?
21:47:13 <llu-laptop> in nova
21:47:32 <nijaba> llu-laptop: no, this is why we should talk to Eric
21:47:34 <dhellmann> oh, wait, I'm confused, this is just about the new signing code?
21:47:36 <jd__> #action jd__ contact Eric Windisch about nova's trusted-messaging blueprint status
21:47:48 <jd__> dhellmann: yes that's it
21:47:59 <jd__> dhellmann: though it's not really far of what you talk about anyway
21:48:07 <dhellmann> I think they're still trying to figure out which part of the library is supposed to do the serialization
21:48:29 <dhellmann> there was some discussion about that today, maybe in a bug report
21:48:37 <dragondm> iirc, there was issues with double serialization
21:49:10 <jd__> ok, we'll clear it up with Eric I guess, anyway
21:49:25 <nijaba> jd__: yep, that sounds like the right thing to do
21:49:40 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2013-January/005200.html
21:50:04 <dhellmann> jd__: +1
21:50:27 <nijaba> let's move to open discussion?
21:50:36 <jd__> yup
21:50:40 <nijaba> #topic Open discussion
21:50:59 * eglynn wonders whether we/I should refer to the new emerging "agent-less" architecture at FOSDEM this weekend?
21:51:14 <eglynn> (or stick to the existing architecture?)
21:51:15 <dhellmann> eglynn: let's not "sell futures"
21:51:23 <jd__> eglynn: stick to current :)
21:51:29 <eglynn> dhellmann: that's a good way of putting it
21:51:36 <eglynn> fair enough, sounds reasonable
21:52:00 * sandywalsh is still waiting for his flying car
21:52:30 * eglynn never got his hover-bike from Santa ...
21:52:40 <yjiang5_home> anyone working on Hyperv/VMWare support?
21:52:50 * dragondm thinks if sandywalsh had a flying car, he'd have to spend all his time de-icing it...
21:53:04 <sandywalsh> hah! no kidding
21:53:25 * nijaba does have his folding bike that only flies when on a plane
21:53:40 <sandywalsh> oh, and thanks to all you guys for putting up with my questions over the last week ... thanks for being patient!
21:53:50 <dragondm> yup. ditto.
21:54:12 <jd__> you're welcome :)
21:54:43 <yjiang5_home> I have submit the patch for  https://blueprints.launchpad.net/ceilometer/+spec/publisher-counters-frequency and hope more feedback on the implementation.
21:55:22 <jd__> yeah we need more review
21:55:34 <dragondm> I'd be happy to look.
21:55:42 <jd__> though I think multi-publisher is going to be merged soon now that we've more +2-able folks on board
21:56:21 <yjiang5_home> jd__: :-)
21:57:06 <yjiang5_home> dragondm: thanks
21:57:26 <nijaba> any final words before I close the meeting?
21:57:33 <jd__> banana
21:58:04 <nijaba> ok. thanks everyone for another great meeting
21:58:11 <sandywalsh> thanks y'all!
21:58:14 <dragondm> thx
21:58:14 <sandywalsh> o/
21:58:20 <nijaba> tty next week, and see some of you this we at fosdem!
21:58:34 <eglynn> thx & bye!
21:58:36 <nijaba> #endmeeting