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