21:02:34 <jd__> #startmeeting ceilometer
21:02:35 <openstack> Meeting started Wed Jul 31 21:02:34 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:38 <openstack> The meeting name has been set to 'ceilometer'
21:02:47 <dhellmann> o/
21:02:48 <dragondm> \o
21:02:50 <apmelton> o/
21:02:51 <eglynn> o/
21:02:53 <terriyu> o/
21:02:54 <mrutkows> o/
21:02:55 <nealph> o/
21:03:08 <topol> o/
21:03:14 <jd__> hello everybody
21:03:24 <gordc> o/
21:04:01 <jd__> #topic dhellmann to set up a vote in place for #openstack-metering logging
21:04:02 <asalkeld> o/
21:04:05 <sandywalsh> o/
21:04:07 <litong> o/
21:04:32 <jd__> this has been done by dhellmann today
21:04:33 <dhellmann> I set up an online vote and included all of the core team members as voters
21:04:36 <thomasm> o/
21:04:42 <dhellmann> let me know if you didn't get the email with the link to your ballot
21:04:54 * jd__ got it
21:05:00 * gordc got it
21:05:15 <jd__> #topic dhellmann to setup a repository for pycadf
21:05:18 <asalkeld> I even voted yes
21:05:33 <jd__> asalkeld: :-)
21:05:37 <gordc> thanks jd__, dhellmann for setting this up
21:05:38 <dhellmann> jd__ started that, and I added some stuff based on feedback from jeblair
21:05:54 <gordc> i don't think we'll have any issues on this
21:05:55 <dhellmann> #link https://review.openstack.org/#/c/39225/
21:06:05 <mrutkows> jd__, dhellmann, +1 thanks both
21:06:17 <jd__> all good then :)
21:06:24 <dhellmann> he did ask to make sure we wanted it under "stackforge" and not "openstack" and I gave him some of the background
21:07:30 <gordc> we're letting the lawyers know about stackforge but they said it shouldn't be a huge issue after we explained it to them
21:07:41 <jd__> good lawyers
21:07:45 <gordc> :)
21:07:53 <mrutkows> dhellmann, have been working to expedite this with legal
21:07:54 <jd__> #topic close on audit middleware/pycadf direction (where/when to use CADF) - gordc
21:07:56 <dhellmann> good
21:08:00 <topol> they just asked for gordc's first born son. no biggie
21:08:05 <jd__> I think this kind of the same topic
21:08:18 <jd__> topol: business as usual.
21:08:18 <gordc> yep. kind of an expansion
21:08:29 <gordc> just an update/checkpoint to audit middleware item (https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats)
21:08:38 <gordc> we're branching out cadf data model to pycadf (thanks again dhellmann, jd__) but we still have to decide where/when to use CADF in ceilometer (or if we want a pluggable interface to work with other standards in future?)
21:09:04 <jd__> yeah we've been discussing it a bit with dhellmann
21:09:09 <dhellmann> I have pretty strong reservations against using multiple message, and therefore storage, formats
21:09:12 <gordc> realize it was just a few hours ago we discussed this but we had a good discussion and i wanted to answer any lingering questions/concerns we might have. ie. what goes into CADF and what stays in ceilometer
21:09:30 <gordc> mrutkows is resident expert on CADF/audit and topol is around if you have questions on how we use audit with our banking clients
21:09:42 <sandywalsh> I still think middleware is the wrong place for generating this. It should be translating existing notifications ... not making new/competing ones.
21:09:43 <dhellmann> (as would be implied by making it "pluggable")
21:09:44 <gordc> so yeah, they're here if you want a more detailed picture of audit rather than the x percent i know.
21:09:47 <jd__> I think for now having pycadf is a really good start anyway; where we plug the stuff is something we need to discuss
21:10:43 <dhellmann> I don't object to CADF, per se, but it feels like the CADF section of the notification is going to have redundant data in it (user and resource info)
21:10:54 <jd__> so CADF is about a data model, but doesn't really care about the format IIUC? it just needs some precise fields?
21:11:15 <dhellmann> sure, when I say "format" I mean "schema" or "model" or whatever -- I realize it's not XML or JSON or whatever
21:11:26 <mrutkows> if audit data needs to be signed and complete according to any spec. or std. it needs to be in that format from the start
21:11:34 <jd__> dhellmann: yeah that's why I'm thinking having notification directly emitted in CADF might be a better idea
21:11:35 <sandywalsh> agreed ... cadf is fine, definitely a market need, but the implementation shouldn't get in the way of the existing "openstack way" of using notifications
21:11:51 <dhellmann> right, sandywalsh, that's my point
21:11:59 <dragondm> yup
21:12:01 <topol> how is it getting in the way?
21:12:12 <sandywalsh> it breaks DRY
21:12:12 <dhellmann> mrutkows: if it's the same data, the "schema" for the data shouldn't matter to the signature, right? as long as the method of generating the signature is the same
21:12:29 <dhellmann> so far, notifications are fairly lightweight
21:12:30 <sandywalsh> we have two places where notifications/events are being created ... competing sources
21:12:45 <dhellmann> there's some wrapper info about the resource and event, and then a "metadata bag" for other stuff
21:13:07 <dhellmann> cadf is some of that data repeated, but a cadf message would not conform to the notification spec, so we would have to repeat the fields
21:13:29 <dhellmann> does someone have the link to that blueprint handy?
21:13:32 <gordc> sandywalsh, was wondering what we're doing currently? it seems notifications are a dump/grab bag of possibly required data.
21:13:38 <mrutkows> dhellmann, if you start with another format at time of creation and sign it you cant reformat it and resign it later, it voids audit
21:13:47 <dhellmann> #link https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats
21:13:50 <mrutkows> even if the schema is mappable
21:14:04 <dhellmann> mrutkows: why would it need to be resigned?
21:14:16 <sandywalsh> gordc, to an extent that's true. An event should gather as much context around the event as possible.
21:14:17 <dhellmann> that is, the signature should be about the data, not about the schema
21:14:37 <sandywalsh> gordc, it's an atomic/standalone piece of data
21:14:45 <mrutkows> dhellmann, that is you cant translate it and sign it for an auditor expecting CADF (or any standard format)
21:15:05 <gordc> sandywalsh, so cadf allows for that... it just stores it in a prescriptive way.
21:15:16 <mrutkows> dhellmann, maintaining the trust chain of the audit record gets voided
21:15:52 <dhellmann> mrutkows: that doesn't make any sense to me, but I guess I don't understand how the signing part works
21:15:57 <sandywalsh> gordc, that's fine, but within nova, it shouldn't come from two sources. We have the .notify() method for generating events. Now there is the middleware. People won't know where stuff belongs.
21:15:58 <jd__> I'm going to repeat myself, but what would be the problem with having a way to emit notifications directly in CADF?
21:16:19 <sandywalsh> it's like the InstanceFault table vs. ServerError table (or whatever it's called)
21:16:22 <dragondm> a new oslo notification driver?
21:16:33 <dhellmann> jd__: we would, at best, be able to attach cadf data to the notification
21:16:34 <jd__> dragondm: a new set of drivers for the format
21:16:36 <dhellmann> we need the other fields
21:16:44 <jd__> dhellmann: what about having translation drivers?
21:16:49 <sandywalsh> jd__, if it's optional that's fine
21:16:49 <topol> sandywalsh, how do we resolve the two source issue?
21:17:07 <sandywalsh> topol, a new notification driver that writes in CADF format
21:17:11 <jd__> sandywalsh: it would be a "format driver" that would translate the wire format
21:17:18 <jd__> sandywalsh: so yeah totally optional
21:17:18 <dhellmann> jd__: our one existing notification plugin has caused so much pain and hassle, I do not want to write another one unless it's added right to oslo
21:17:23 <gordc> sandywalsh, the middleware is optional path.
21:17:32 <topol> +1 on totally optional
21:17:45 <jd__> dhellmann: yeah that would be another layer of driver in oslo
21:17:48 <dhellmann> sandywalsh: it would only be optional if you didn't want to collect auditing data about the API
21:17:51 <gordc> sandywalsh, it will also hopefully be reuseable across all projects
21:17:52 <sandywalsh> gordc, optional isn't the issue, it's duplicating the capture of an event in two places
21:18:04 <dhellmann> because, from what mrutkows says, we have to keep the data in the same format as it moves around
21:18:04 <litong> folks, with the multiple dispatcher enablement, it does not have to be in the pipeline.
21:18:12 <dhellmann> which makes me wonder how we store the data, but that's another thing
21:18:15 <litong> it can be a totally independent dispatcher.
21:18:19 <sandywalsh> 1. in the middleware and 2. lower down where the activity is actually taking place
21:19:05 <dhellmann> sandywalsh: if we follow what mrutkows says, we have to create the CADF object in the middleware, and it has to stay the same as it moves all the way into ceilometer's database
21:19:06 <jd__> gordc, dhellmann ultimately I can try to build a small illustrated proposal out of that if you want
21:19:08 <sandywalsh> jd__, a new notification that simply translated on-the-wire would be fine (and encouraged :)
21:19:17 <sandywalsh> s/notification/notification driver/
21:19:28 <jd__> sandywalsh: nice to hear :)
21:19:38 <dhellmann> mrutkows: is that allowed?
21:19:49 <mrutkows> dhellmann, correct, pretty standard for auditing certifications
21:19:54 <jd__> dhellmann: that's in conformance with what sandywalsh did with the event recording stuff
21:20:03 * dhellmann is very confused
21:20:22 <gordc> sandywalsh, hmm, i hadn't really traced what activity nova sends out currently but the current middlware just tracks raw api request and grabbing relevant user/project info
21:20:35 <dhellmann> mrutkows: which is "correct"? that it is ok to create the data in one format in the middleware and then turn it into cadf inside the notification pipeline somewhere, or that we must not do that?
21:20:40 <sandywalsh> signing the event in the notification driver would be even better than doing it in the middleware.
21:21:08 <dhellmann> gordc: if we're going to do this, let's try to do it in a way that works for everything
21:21:12 <sandywalsh> https://wiki.openstack.org/wiki/SystemUsageData
21:21:15 <gordc> jd__, i think that'd be good. i think we have different visions right now that may or may not be closer than we think
21:21:15 <mrutkows> dhellmann, that "it has to stay in same format thru the system to the DB"
21:21:16 <dhellmann> even if we don't implement it for everything now
21:21:16 <sandywalsh> #link https://wiki.openstack.org/wiki/SystemUsageData
21:21:37 <dhellmann> mrutkows: right, ok, so that means that a notification transformer will not meet the auditing requirements
21:21:38 <jd__> dhellmann: middleware calls notify(data), oslo translates the data in a format (either our current native or CADF), sends it to a wire via its driver (e.g. RPC), ceilometer collector receives it and store it (and read it via a translation API to get data to build its Samples)
21:21:52 <dhellmann> no, jd__ , that's what I'm saying: the auditors will not accept that data
21:22:09 <jd__> for which reason?
21:22:12 <mrutkows> dhellmann, yes, a transformer would void they original record
21:22:13 <dhellmann> or rather, that's what mrutkows is saying
21:22:17 <gordc> dhellmann,  agreed. should work for everything but we need to do it in steps... question is what we consider is step 1, 2, 3..
21:22:37 <dhellmann> jd__: because the ORIGINAL version of the data is not in the CADF signed object
21:22:40 <sandywalsh> mrutkows, sounds fishy. The middleware has it in an intermediate format until it's turned into CADF. The payload would be the same intermediate format.
21:22:49 <jd__> dhellmann: but it didn't leave the software yet! :(
21:22:51 <dhellmann> this seems overly strict to me, too
21:22:55 <sandywalsh> jd__, +1
21:23:01 <dhellmann> I'm just trying to make sure I understand "the rules"
21:23:06 <jd__> mrutkows: is what dhellmann says right? :(
21:23:20 <mrutkows> sandywalsh, we are not signing today (not in scope of current blueprint), but is what we need to do
21:24:01 <sandywalsh> mrutkows, even without the signing, the notification mechanism would meet your criteria ... the event hasn't left the system yet.
21:24:05 <mrutkows> sandywalsh, any signing involves signing (using a hash of the record) against a canonical form
21:24:32 <sandywalsh> if you translated after it hit rabbit ... yes, I would agree.
21:24:40 <sandywalsh> but this would be before rabbit
21:25:14 <dragondm> before it left the originating process, even.
21:25:20 <sandywalsh> correct
21:25:23 <jd__> yup
21:25:44 <jd__> *everyone looks at mrutkows*
21:25:53 <dhellmann> mrutkows: what is the "canonical form" that goes into the signing?
21:26:15 <mrutkows> sandywalsh, not sure why you would create one format (TBD) and then translate to another, thenn sign it before putting on the notification bus?
21:26:47 <mrutkows> sandywalsh, recall that CADF is being added as "metadata" in the current event message
21:27:06 <sandywalsh> mrutkows, because there's an existing code base that uses this mechanism and introducing a new source of events would be duplicating efforts
21:27:11 <mrutkows> sandywalsh, and that we are making audit middleware pluggable to support more than one format
21:27:28 <dhellmann> so this is different from what I understood
21:27:33 <sandywalsh> if there's a missing event, add a new notification. Not need to decide "does this go in middleware or at the origin"
21:27:36 <dhellmann> mrutkows: are you saying then, that the entire notification would not be cadf?
21:27:42 <mrutkows> sandywalsh, what is the other source?  audit middleware is optional
21:28:27 <mrutkows> dhellmann, we did not want to suggest cadf or any format to replace the one in ceilomter already so we assumed, for this blueprint that we would fit in by putting it in metadata
21:28:34 <sandywalsh> mrutkows, but the code is called all the time. There may just be no plug in defined for it. In fact, the plan is to move more into notifications and away from logging (for .info and .error)
21:28:44 <topol> how does the other source get modified to optionally generate cadf? is there an extension point?
21:28:48 <dhellmann> mrutkows: interesting
21:28:52 <sandywalsh> and make the default notification driver the logging driver
21:29:22 <dhellmann> so the notification would include the data in some generic format, and then it would include the CADF payload as a duplicate, and that part of the payload would be signed separately from the rest of the notification?
21:29:26 <mrutkows> dhellmann, we wanted to be as non-invasive as possible in everything we did
21:29:52 <dhellmann> ok, this was not at all clear from the docs
21:30:00 <jd__> sandywalsh: interesting, I'm on the same page on this
21:30:15 <dhellmann> perhaps because the example shows how to map a sample to a cadf representation of the same data, I was confused
21:30:32 <sandywalsh> is this a nova notification or a CM notification ... from the code I thought the middleware was writing directly to the CM notification bus?
21:30:48 <gordc> dhellmann, right. we just append cadf to payload.
21:31:07 <dhellmann> gordc: ok, that makes things significantly different for me
21:31:15 <dhellmann> and it makes the idea of having it be pluggable make more sense
21:31:30 <mrutkows> dhellmann, sorry for semantic issues
21:31:37 <dhellmann> and it also makes the idea of a notification plugin make even more sense
21:31:38 <dragondm> basically it's a 'wrapper' notification driver, iiuc
21:31:51 <sandywalsh> when you say "payload" do you mean the nova notification payload? event['payload'] = { ... } ?
21:31:53 <dhellmann> all notifications could basically have the auditing data added to them, not just the api call notifications
21:32:08 <jd__> dhellmann: what about DRY?
21:32:12 <dhellmann> sandywalsh: yes, I think a new "audit" key in the payload dictionary would hold this data
21:32:25 <dhellmann> jd__: nothing would query into the audit field, so it would be treated as a black box
21:32:29 <gordc> sandywalsh, we mean olso.notifier... .notify(context, payload)
21:32:32 <mrutkows> dellmann, cool by me
21:32:37 <sandywalsh> how does api middleware have access to the notification?
21:32:38 <jd__> dhellmann: that's still storing twice the same things though
21:32:40 <topol> dhellmann +1
21:32:57 <jd__> dhellmann: but that's still inline with drivers in oslo
21:33:12 <dhellmann> true
21:33:13 <jd__> (in line in two words)
21:33:23 <mrutkows> jd___, there is some small overlap, but much is unique
21:33:23 <dragondm> sandywalsh, if I understand, it's implemented as a notification driver.
21:33:40 <jd__> mrutkows: ah ok -- I admit I lack information on what's in :)
21:33:46 <gordc> jd__, sandywalsh, is the preference to have the notifications be emit from nova, glance, etc... api code?
21:34:07 <jd__> gordc: would be, what's why I think it should target oslo notifier
21:34:13 <dhellmann> gordc: what we want is to have a notification plugin that adds cadf data to all notifications as they go out
21:34:19 <sandywalsh> gordc, I'm recalling the code review on this and I thought it was wsgi middleware
21:34:20 <jd__> gordc: so everything that's already calling notify() would benefit from it
21:34:30 <dhellmann> and then that plugin could be turned on or off, depending on whether the deployer wants it
21:34:41 <dhellmann> and all of the applications don't have to know about cadf or auditing
21:34:49 <jd__> yep
21:34:52 <sandywalsh> gordc, is this something new proposed, or perhaps I'm thinking of a different branch?
21:34:52 <gordc> sandywalsh, correct.
21:35:15 <dhellmann> gordc: and the best part of it is you could build that thing entirely in the pycadf library and other projects could consume it
21:35:36 <dhellmann> ceilometer wouldn't have to know about cadf at all -- the auditing data would just be an extra field in the metadata of every sample
21:35:37 <mrutkows> jd__, we are only attempting to audit APIs by allowing the middlewar filter to be enabled  by components, not sure if every notification needs to be audited (not enough knowledge)
21:35:43 <sandywalsh> gordc, if it's wsgi middleware, how does it get access to the .notify() calls (in other processes)?
21:35:53 <dhellmann> and your middleware could simply emit standard notifications
21:36:07 <dhellmann> and that could live in oslo or somewhere else to make it easy to share it
21:36:09 <jd__> mrutkows: I'm likely to say yes, we want audit everywhere
21:36:22 <dhellmann> yeah, there is really no point in building auditing only for the API calls
21:36:37 <jd__> and I think we'll have to switch to other topics now guys :)
21:36:38 <gordc> sandywalsh, the middleware is coded up as part of ceilometer egg. it has access to it then.
21:36:55 <sandywalsh> hmm, I'm confused
21:36:58 <dhellmann> yes, let's discuss this on the mailing list
21:37:01 <sandywalsh> yep
21:37:12 <gordc> dhellmann, jd__, yes. there is a lot of information being passed around right now
21:37:27 <mrutkows> dhellmann, it could, but I do not have the design of what other things follow that path to say those are all audit candidates, APIs was our only target for the near term
21:37:57 <topol> so just need to understand what is the minimum piece that goes in ceilometer to make this work.
21:38:04 <dhellmann> mrutkows: the notification system is the common way the openstack components record the fact that some event has happened
21:38:07 <gordc> so we would have the event listener in audit.api events in collector still?
21:38:09 <jd__> not sure there's any at this point :)
21:38:21 <topol> event audit listener is the only part, correct
21:38:30 <gordc> listen for audit api*
21:38:33 <mrutkows> dhellmann, since APIs represent "authenticated" requests from users and are essential to track for security audits
21:38:51 <jd__> #topic Last call for backports for 2013.1.3
21:39:01 <jd__> eglynn: around?
21:39:12 <eglynn> yep
21:39:15 <sandywalsh> sorry, for the sake of others on previous topic:
21:39:16 <sandywalsh> #link https://review.openstack.org/#/c/36213/
21:39:28 <eglynn> yeah, so last-call-for-alcohol on the upcoming 2013.1.3 release
21:39:36 <eglynn> (freeze is tmrw!)
21:39:43 <eglynn> here are the backports we got landed today ...
21:39:50 <eglynn> #link https://bugs.launchpad.net/ceilometer/+milestone/2013.1.3
21:40:01 <eglynn> if anyone reckons I missed something important, please shout in the next hour or so ...
21:40:12 <eglynn> otherwise let's go with that
21:40:25 <eglynn> release due to be cut on Aug 8th
21:40:37 <eglynn> I'll ask apevec to do the honours again
21:40:44 <dhellmann> eglynn: are there outstanding reviews you need help with?
21:41:06 <eglynn> dhellmann: nope, thanks, everything I proposed is now landed
21:41:30 <jd__> #topic Review Havana-3 milestone
21:41:39 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-3
21:41:53 <jd__> so everything should be started RSN now
21:42:01 <eglynn> RSN?
21:42:12 <jd__> really soon now
21:42:20 <jd__> :)
21:42:24 <eglynn> a-ha :)
21:42:32 <jd__> if you want to get merged on time
21:42:46 <jd__> 'cause there's a lot of stuff, a lot of potential conflict, rebase, war!
21:43:14 <jd__> and I need to stress that eglynn has a lot on his plate
21:43:18 <eglynn> I've got some stuff near ready to propose
21:43:23 <jd__> so eglynn if you want to share, don't hesitate
21:43:34 <eglynn> but not really prone to conflict & rebase
21:43:43 <jd__> ack
21:43:43 <eglynn> (as mostly new)
21:43:46 <eglynn> cool
21:43:52 <gordc> sorry folks, need to leave. thanks for (very) detailed discussion. will check logs later. jd__, dhellmann, sandywalsh, will checkpoint again later to see how to properly impl.
21:44:04 <jd__> cya gordc
21:44:09 <dhellmann> thanks, gordc
21:44:24 <jd__> #topic Release python-ceilometerclient?
21:44:28 <gordc> thanks for looking at it :), cheers,
21:44:34 <jd__> should be good on that I guess
21:44:35 <eglynn> no need I think
21:44:42 <sandywalsh> gordc, thanks ... later!
21:44:43 <eglynn> (given that we release last week)
21:44:45 <dhellmann> did we fix that client version pinning issue?
21:44:49 <jd__> dhellmann: yes
21:44:51 <dhellmann> ok
21:44:54 <jd__> #topic Hong Kong Summit: Who's going? (nealph)
21:44:58 <dhellmann> o/
21:44:59 <eglynn> o/
21:45:01 <jd__> o/
21:45:07 <mrutkows> o/
21:45:17 <eglynn> asalkeld's proxy: o/
21:45:28 <mrutkows> (at least I am on the list for now)
21:45:28 <jd__> sileht should be there too
21:45:38 <sileht> o/
21:45:43 <sandywalsh> o/
21:45:44 <jd__> see, told ya
21:45:50 <sandywalsh> (on my own dime)
21:45:50 <dhellmann> has anyone started thinking about topics?
21:45:53 <nealph> o/
21:45:57 <eglynn> sandywalsh: ouch!
21:46:02 <thomasm> Youch
21:46:05 <nealph> yes, we have a couple in the works...
21:46:05 <jd__> sandywalsh: rax doesn't send you/anyone?
21:46:11 <sandywalsh> yeah, haven't missed a summit yet, can't start now.
21:46:24 <sandywalsh> it's not decided who's going yet
21:46:30 <jd__> ack
21:46:32 <nealph> sandywalsh: that's the second part of this discussion topic.
21:46:38 <eglynn> sandywalsh: hit the foundation travel programme ;)
21:46:43 <terriyu> I'm applying to the travel fund, so if I get it, I'll be going
21:46:46 <dhellmann> indeed, that's what it's there fore
21:46:48 <nealph> Distance may be an issue for some...
21:47:24 <jd__> nealph: I don't see any difference as far as I'm concern :)
21:47:29 <sandywalsh> eglynn, good idea!
21:47:31 <nealph> Ha, true.
21:48:02 <terriyu> eglynn: : are you talking about the travel fund?
21:48:12 <eglynn> terriyu: yep
21:48:20 <terriyu> the application is due today.  I'm working on it right now :)
21:48:20 <nealph> travel fund?
21:48:34 <dhellmann> #link https://wiki.openstack.org/wiki/Travel_Support_Program
21:48:34 <eglynn> terriyu: are you covered anyway as an intern?
21:48:45 <terriyu> #link http://www.openstack.org/blog/2013/07/the-all-new-openstack-travel-support-program/
21:48:47 <herndon> o/
21:49:07 <terriyu> eglynn: my internship program only covers $500, probably not enough for Hong Kong ;)
21:49:08 <eglynn> IIRC all the women-in-openstack interns were in Portland last time round
21:49:25 <eglynn> terriyu: ah, I see :(
21:49:33 <nealph> Is it premature to discuss alternate meet-ups for those that can't swing the cost?
21:49:44 <dhellmann> alternate?
21:49:55 <jd__> counter-party^Wsummit?
21:50:03 <dhellmann> alternate-and-concurrent?
21:50:13 <jd__> are you working for CloudStack?
21:50:21 <nealph> perhaps not concurrent...
21:50:25 <jd__> ;)
21:50:42 <dhellmann> do we know what the remote participation system will be this time?
21:50:54 <jd__> dhellmann: I didn't hear anything about that
21:51:15 <nealph> dhellmann: well, that would ultimately be best.
21:51:46 <jd__> I *think* the travel program is meant to help required people to join rather than trying remote system
21:52:05 <jd__> since it seems remote systems aren't really easy to deal with
21:52:50 <asalkeld> well you could skype/g+
21:52:58 <asalkeld> that's not so hard
21:53:06 <asalkeld> if the network is functional
21:53:11 <nealph> did you guys attempt that for the ceilometer track discussions
21:53:12 <nealph> ?
21:53:13 <dhellmann> big if
21:53:23 <nealph> in Portland?
21:53:23 <asalkeld> yea
21:53:46 <dhellmann> not in portland, but in san diego I think we had webex or something in some of the rooms
21:53:48 <dhellmann> only for core projects
21:54:14 <dhellmann> or maybe that was san francisco
21:55:10 <nealph> I'm just nosing around for ways for non-attendees to get plugged in...
21:55:26 <jd__> nealph: it may be too soon anyway
21:55:35 <jd__> retry that in a couple of months :)
21:55:38 <sandywalsh> dhellmann, re: topics: I submitted one for our StackTach improvements (a lot) and how we're going to bring that to CM
21:55:41 <nealph> agreed. I'll circle back.
21:55:51 <dhellmann> sandywalsh: cool, looking forward to hearing about that
21:56:14 <jd__> #topic Open discussion
21:56:22 <jd__> a couple of minute left if you've anything
21:56:39 <jd__> I'll talk about my bp next week -- too tired for that today
21:56:53 <jd__> and so little time anyway :)
21:57:08 <dhellmann> I'll be out again next week. Please don't assign me any tasks. ;-)
21:57:35 <jd__> like we ever did that
21:57:45 * dhellmann remembers something about a vote...
21:58:09 <jd__> http://24.media.tumblr.com/2967bb33c37b7cca5235ebe4dbbca160/tumblr_mk59ikxWdo1s7g8g4o1_500.jpg
21:58:24 <dhellmann> lol
21:58:35 <mrutkows> omg
21:58:44 * nealph second time I've seen that rabbit today...popular bunny.
21:58:51 <mrutkows> will show my daughter that one
21:59:11 <jd__> #endmeeting