14:02:32 <jorgem> #startmeeting neutron-lbaas 14:02:33 <openstack> Meeting started Thu Sep 4 14:02:32 2014 UTC and is due to finish in 60 minutes. The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:34 <rm_mobile> Lol 14:02:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:35 <jorgem> there we go 14:02:36 <openstack> The meeting name has been set to 'neutron_lbaas' 14:02:38 <sbalukoff> Yep! 14:02:46 <sballe> cool! 14:02:49 <dougwig> no hypen x2 14:02:53 <jorgem> #chair dougwig 14:02:54 <openstack> Current chairs: dougwig jorgem 14:03:19 <sballe> What's the agenda? the agenda on the LBaaS wiki aren't updated 14:03:19 <jorgem> its been a while since I've been on time! 14:03:26 <jorgem> I don't think much 14:03:28 <dougwig> i think our only listed topic is blogan's driver status thing. 14:03:40 <jorgem> I'm guessing incubator status 14:03:43 <sbalukoff> And, if Kyle or Mark are here, an update on incubator 14:03:47 <sballe> perfect 14:03:48 <rm_mobile> So this might be a quick one? 14:03:51 <sbalukoff> jinx 14:04:00 <jorgem> rm_mobile: most likely 14:04:05 <sbalukoff> If only it were later in the day. XD 14:04:05 <sballe> blogan, can you resent the link to your driver? 14:04:10 <rm_mobile> K 14:04:21 <sballe> rm_mobile, it never is ;-) 14:04:26 <blogan> hello all 14:04:28 <rm_mobile> Lpl 14:04:29 <dougwig> #topic entity status and drivers 14:04:36 <rm_mobile> *lol 14:04:49 <dougwig> blogan: take it away. 14:04:55 <jorgem> blogan just got here 14:05:12 <blogan> sorry just got here, talking about my email? 14:05:17 <dougwig> yes 14:05:23 <blogan> oh okay 14:06:00 <blogan> so I just wanted to guage interest in whether people think that drivers being responsible for setting the status of the entities is an issue 14:06:16 <blogan> to me it is, because it leads to inconsistencies and really isn't something a driver should have to worry about 14:06:34 <sbalukoff> You said you had an idea on how to deal with asynchronous drivers 14:06:40 <sbalukoff> Did you want to share that? 14:07:01 <blogan> well it was an idea, but i haven't done much with it 14:07:25 <blogan> but basically it would make the neutron lbaas API always asynchronous, and there would be an async driver interface, and a sync driver interface 14:08:01 <sbalukoff> How would the asynchronous driver interface work differently than the one now? 14:08:05 <blogan> I haven't worked it out totally because I'm not sure if anyone thinks it is worth investigating 14:08:12 <sbalukoff> (That seems like the crux of the problem, to me.) 14:08:18 <xgerman> I am also wondering what happened to our plan of using exceptions? 14:08:28 <sbalukoff> xgerman: +1 14:08:35 <sballe> xgerman, +1 14:08:43 <blogan> sbalukoff: actually it wouldn't be an interface it would be an abstract class that would handle the polling of the async driver methods to get the status 14:08:46 <a2hill> o/ 14:08:54 <blogan> xgerman: what happened was having async drivers and sync driversr 14:09:07 <blogan> xgerman: since we have async drivers they can't throw exceptions 14:09:17 <blogan> xgerman: well they can it would just be uncaught 14:09:26 <sbalukoff> Hmmm... 14:09:29 <xgerman> if we are planning to poll the async driver will appear synchronous anyway 14:09:33 <jorgem> isn't that what the ERROR status is for? 14:09:45 <xgerman> unless you think we want to do event=ing 14:10:05 <sbalukoff> blogan: I suspect the people who should weigh in on that would be the authors of the asynchronous driver interfaces-- whether they would prefer things to work that way, or as they do now. 14:10:06 <dougwig> xgerman: even with sync, there's a wrinkle in that plane w.r.t. fatal vs non-fatal exceptions. since you can get an LB object that triggers creating a bunch of child objects, you could end up in a halfway state. 14:10:33 <blogan> sbalukoff: yes and their input is what I was hoping to get today too 14:10:53 <sbalukoff> I don't suppose any of them are present? 14:11:03 <xgerman> dougwig, throwing exceptions doesn't a driver preclude from cleaning up 14:11:04 <sbalukoff> (I'm only seeing Octavia crew here that are active.) 14:11:06 <dougwig> in really really short, if we want to support auto-magic, even with synchronous, we need three exit results from driver interfaces, not just "had an exception" or "did not have an exception". 14:11:25 <xgerman> well, we could have different exceptions 14:11:31 <blogan> dougwig: we can have custom exceptions that will tell the plugin what to do, even complex exceptions 14:11:37 <xgerman> +1 14:11:40 <blogan> that would require more investigation though 14:11:55 <sballe> blogan, +1 14:11:59 <xgerman> I think a good error/exception model would be worth it 14:12:07 <dougwig> well, with our current models, you'd actually need to be able to communicate multiple errors at once, possibly. 14:12:08 <sballe> +10000 14:12:11 <blogan> are the radware guys here today? 14:12:22 <xgerman> dougwig, you can chain exceptions 14:12:23 <sbalukoff> samuel? 14:12:27 <blogan> dougwig: custom exception can have many fields to communicate that 14:12:44 <sbalukoff> I don't see Samuel. Avishay? 14:12:50 <sballe> Based on my past experience not putting enough time in getting a good error/exception model is an issue. it always comes back and bit 14:12:54 <evgenyf> blogan:I'm here 14:13:02 <sbalukoff> Oh yay! 14:13:03 <blogan> evgenyf: do you have an opinion on this? 14:13:04 <dougwig> yep. i'm just saying that it's not as simple an interface as it sounds, which i suspect is why the statuses are in there. 14:13:22 <evgenyf> Are we talking LBaaS v1 or v2? 14:13:27 <blogan> I think the reason the statuses are there is because of async drivers not going through an agetn 14:13:38 <blogan> evgenyf: v2 14:14:16 <blogan> evgenyf: nothign should be added to v1 14:14:28 <evgenyf> I think it should remain as it is now, in v2 we have all these active/fail/defer functions in mixins 14:14:55 <blogan> evgenyf: true but the alternative is not having those at all 14:15:43 <evgenyf> blogan, can you elaborate on your idea with async plugin API please? 14:16:33 <evgenyf> sbalukoff: Sam and Avishay are not here 14:16:40 <blogan> evgenyf: basically the driver does not set the status of entities at all, it will just throw exceptions 14:17:06 <sbalukoff> Netsplit 14:17:08 <blogan> evgenyf: then the plugin sets those based on the exception thrown 14:17:09 <blogan> ah net split! 14:17:09 <sbalukoff> Awesome. 14:17:18 <jorgem> woah mass exodus 14:18:04 <blogan> evgenyf: how this is done to support both async and sync drivers I have an idea about but need more time to hash it out 14:18:10 <dougwig> we can prototype it, but given the multi-error issue, we're just going to replace one set of glue with another set that has to wrangle and chain the exceptions or setup the error fields before re-raising. the bar here should be whether it results in simpler driver code. 14:18:29 <evgenyf> blogan: Radware's driver has separate thread dealing with operations success/fail 14:19:29 <blogan> dougwig: doesn't it make sense to have a separation of concerns though? the driver only has to tell the plugin what entities are affected and then the plugin decides for all drivers what to do? 14:19:33 <blogan> that seems simpler to me 14:19:52 <blogan> evgenyf: correct and a solution to this problem would handle that 14:20:22 <sbalukoff> blogan: Are you talking about entities shared between drivers? 14:20:31 <sbalukoff> Does v2 in its current form allow that? 14:20:34 <blogan> sbalukoff: no not at all 14:20:39 <dougwig> if the separation results in one line per method becoming 3, then we're just re-arranging deck chairs. 14:21:00 <sbalukoff> Heh. 14:21:10 <blogan> we'd be putting deck chairs in the proper location 14:21:32 <dougwig> or even 1. if it's truly a useless thing for drivers to be doing, we should be able to get rid of it and reduce driver code. if that doesn't happen,w e're not really insulating anything. 14:21:32 <TrevorV> like on a deck 14:21:56 <xgerman> dougwig +1 14:22:02 <dougwig> i'm not sure that drivers updating status is "improper". 14:22:15 <blogan> maybe its a philosophical difference 14:22:22 <blogan> which is why i wanted people to give their opinions 14:22:24 <xgerman> it's not a good separation of concerns 14:22:26 <blogan> with a bit of a debate 14:22:42 <blogan> xgerman: i'm confused are you for or against it? 14:22:53 <xgerman> I am for exceptions 14:23:02 <sbalukoff> blogan: Is the concern that the current system leads to more inflexible spaghetti code? 14:23:35 <blogan> sbalukoff: i wouldn't say its spaghetti code, the driver interface dougwig creates does improve teh status management in the driver 14:23:44 <blogan> over v1 14:23:47 <xgerman> well, if everybody updates statuses then it's hard to make changes/updates without everybody changing code 14:24:01 <sballe> xgerman, +1 14:24:09 <sbalukoff> xgerman: That was what I was getting at. 14:24:30 <blogan> the main problems I have with it are that it will lead to inconsistent statuses across drivers, and to me it doesn't seem like the drivers' responsibility 14:24:35 <xgerman> good so we are at teh same page :-) 14:24:47 <blogan> and what xgerman said 14:25:04 <dougwig> xgerman: err, it's even harder if you pull them out, because now the driver can't make the decision of how to do transactions/locking, and you can have drivers running in parallel. you can't wrap those operations at the plugin level. 14:25:39 <dougwig> (the complex ones, not the status ones) 14:25:58 <blogan> to me it seems odd the driver has to worry about transactions/locking when it should be the db layer that does 14:26:20 <dougwig> it's part and parcel of having two sources of truth. 14:26:21 <blogan> unless you're talking about not the lbaas db 14:27:06 <blogan> two soruces of truth being the lbaas db and the driver's own db? 14:27:33 <blogan> or whatever the vendor's storage mechanism is 14:27:39 <dougwig> correct. we don't have things setup for atomic replacements of entire trees. 14:28:20 <dougwig> which means, hello hard cs problem #2. 14:28:28 <blogan> naming things? 14:28:30 <blogan> lol 14:28:35 <sbalukoff> Haha 14:28:47 <dougwig> i knew you would reply with that. :) 14:29:13 <blogan> can you give a specific example dougwig? im not totally following? 14:29:26 <blogan> that last sentence should just be a statement 14:30:41 <dougwig> can we talk later in channel? it's way early, and this is going to take awhile. 14:30:46 <blogan> lols ure 14:30:55 <blogan> its not mean to be solved today at all 14:31:11 <sballe> dougwig, please pin me if I am available. Would love to be part of that chat 14:31:15 <sballe> s/ping 14:31:19 <dougwig> sballe: ok 14:31:39 <blogan> okay so that will be sidelined until later today 14:31:47 <sbalukoff> Sounds good. 14:32:03 <blogan> anyone have anything else? 14:32:11 <sballe> Is mestery on the IRC? 14:32:13 <sbalukoff> Are markmcclain or mestery here? 14:32:16 <sballe> lol 14:32:24 <sbalukoff> :) 14:32:26 <mestery> sballe sbalukoff: o/ 14:32:31 <evgenyf> Dougwig: could you please summarize your conversation results in ML after, please 14:32:32 <dougwig> #topic incubator update 14:32:37 <dougwig> evgenyf: yes 14:32:40 <blogan> mestery: the obligatory ask for an update on the incubator 14:32:45 <mestery> blogan: Absolutely sir! 14:32:45 <sbalukoff> :D 14:32:51 <dougwig> i can take this one. 14:32:54 <dougwig> it should be done this week. 14:32:57 <dougwig> right? :) 14:32:58 <blogan> lol 14:33:02 <mestery> So, the update is that now that we're past Juno FF, we will get infra to set the repository up by tomorrow. 14:33:10 <mestery> We were holding off given their focus on holding hte gate togehter this week 14:33:22 <mestery> markmcclain has worked with the TC and infra on the plan and they are both on board. 14:33:31 <mestery> Any questions? 14:33:36 <mestery> :) 14:33:45 <blogan> mestery: by tomorrow do you mean two weeks from now? or actually tomorrow? 14:33:50 <sbalukoff> Heh! 14:33:51 <mestery> blogan: :P 14:33:51 <jorgem> Is there a document with info somewhere? 14:33:51 <sballe> I would like to understand a little more abotu the governance of the incubator proect 14:34:02 <mestery> Tomorrow is the plan, markmcclain should have the review out today for repo creation 14:34:06 <jorgem> sballe: me too 14:34:12 <sbalukoff> mestery: Any changes in how incubator is going to be run, or is the wiki still the source of truth on this? 14:34:15 <sballe> Based on the ML discussion we had there is a lot of confusion 14:34:21 <mestery> I think the governance should be documented on the wiki, let me find the link. 14:34:32 <mestery> sbalukoff: The wiki is still the source of truth at this point 14:34:33 <blogan> mestery: can you make sure it gets put on the ML so we can all look at it? 14:35:03 <mestery> blogan: Ack, will do 14:35:15 <blogan> mestery: thanks a bunch 14:35:15 <markmcclain> the wiki has pending revisions that I have not posted to clarify feature-branch vs incubator criteria 14:35:36 <dougwig> #link https://wiki.openstack.org/wiki/Network/Incubator 14:35:39 <sballe> mestery, Do we have any timeline for the first project to enter the Neutron incubator project 14:35:40 <xgerman> ok, can you send an e-mail once we are supposed to look 14:36:15 <mestery> sballe: Once it's up, you can post blogan's patch series there right away. 14:36:41 <markmcclain> sballe, mestery: I'll ping blogan when it is ready and help get the patches in 14:36:50 <mestery> markmcclain: Awesome sir! 14:36:52 <xgerman> awesome, thanks! 14:37:27 <dougwig> is devstack getting modified at the same time? 14:37:56 <markmcclain> dougwig: not sure… I have work w/QA team 14:38:04 <sballe> mestery, I am looking forward to seeing this whole Neutron Incubator project working and hoepfully it will work well. We are kind of counting on this to be able to move forward 14:38:21 <markmcclain> the gate is still seriously backed up 14:38:22 <sballe> We == HP 14:38:36 <dougwig> the gate needs some fiber, for sure. 14:38:37 <mestery> sballe: ++, I agree, I expect this to really be super helpful as well! 14:38:54 * mestery feeds the gate some whole grain 14:39:06 <markmcclain> haha 14:39:07 <blogan> sballe: i think everyone wants to see it succeed 14:39:32 <sbalukoff> Yep 14:39:37 <sballe> mestery, you should give it some Red Bull instead 14:39:52 <xgerman> I think we just bring in Chuck Norris as a "gate opener" 14:40:09 <mestery> sballe: hahhahahahaha 14:40:10 <dougwig> it's only 72 deep today. 14:40:15 <dougwig> that's light and breezy 14:40:46 <dougwig> any other incubator questions or updates? 14:41:03 <sballe> I would like to have this topic on the agenda for next week again. 14:41:13 <rm_work> sballe: +1 14:41:13 <dougwig> ok 14:41:16 <sballe> We need a weekly status on how this is working for us 14:41:25 <sbalukoff> sballe: +1 14:41:32 <xgerman> sballe +1 14:41:35 <dougwig> mestery, markmcclain - thanks for the update 14:41:37 <mestery> sballe: Lets use the neutron meeting for that 14:41:45 <sballe> ok when is that? 14:41:47 <mestery> I'd like the broader team to hear the update on the incubator as well 14:41:58 <mestery> #link https://wiki.openstack.org/wiki/Meetings#Neutron_team_meeting 14:42:02 <rm_work> dougwig: I have a topic when we wrap up the incubator topic and whatever else was on the official agenda 14:42:30 <dougwig> #topic rm_work's topic 14:42:35 <rm_work> heh 14:43:02 <a2hill> wonderful topic 14:43:06 <sballe> mestery, when is the next Neutron meeting Monday or Tiesday: Mondays at 2100 UTC and Tuesdays at 1400 UT 14:43:08 <rm_work> So, for TLS, we are "registering" with Barbican to get the user's certificate data 14:43:20 <mestery> Tuesday 14:43:22 <sballe> thx 14:43:30 <rm_work> to do this, we need to auth with barbican using our own keystone user that is an "admin" 14:43:31 <mestery> sballe: I sent email on this, and if you go here (https://wiki.openstack.org/wiki/Network/Meetings) you can see it 14:43:52 <rm_work> I don't know if there is precedent for Neutron having its own "service user". Is there? how would this be handled? 14:44:15 <xgerman> that should potentially be the same as us needign a nova user for Octavia 14:44:17 <a2hill> or maybe itll be an 'operator' admin user? 14:44:45 <rm_work> xgerman: yeah, i think very similar 14:45:07 <xgerman> I know security looks down on passwords stored in config files 14:45:19 <dougwig> i'm thinking that there must be a standard "openstack" way of handling this. we can't be the first to need a backdoor account into another project. 14:45:26 <sballe> xgerman, you can have a Octavia tenant with admin privs for the variosu services or advsrv role in the case of Neutron 14:45:31 <rm_work> Yeah... not sure how else to handle it -- we can't exactly store the password in Barbican <_< 14:45:58 <sballe> we do this all the time wirh our platform services 14:46:24 <rm_work> right, so we just need a tenant with a couple specific keystone roles, and marked as "admin" (whatever that means exactly to Keystone, i'm still not 100% clear) 14:46:44 <xgerman> well, name, pwd, etc. should all be configurable 14:46:45 <sballe> rm_work, yeah and we migth not even need admin privs. 14:46:48 <rm_work> So, I think this needs to be owned by Neutron, not Neutron-Lbaas, since the code that uses it will be in /common/ 14:46:54 <sballe> it will depend on whta we need to do 14:47:36 <rm_work> well, I am currently very concerned with security on this, and I am going to need to discuss with Barbican about how we'll do this 14:47:45 <blogan> rm_work really just needs to know if neutron alreayd has one set up for this or if one will have to be created 14:47:56 <dougwig> maybe an ML query on how other projects have done this? 14:48:00 <sballe> blogan, can you elaborate? 14:48:03 <blogan> markmcclain: does neutron use service accounts to communicate with other openstack projects? 14:48:05 <sbalukoff> rm_work: Could ask on the ML to see if anyone there knows the "OpenStack" way of doing this. 14:48:10 <xgerman> mestery? 14:48:15 <sbalukoff> dougwig: Jinx 14:48:51 <sballe> blogan, I am not sure what yu are asking about? 14:49:11 <dougwig> blogan: it does, for nova. 14:49:25 <dougwig> i think you put endpoint/user/pass into neutron.conf 14:49:30 <rm_work> ok 14:49:31 <xgerman> ok, then use that one? 14:49:34 <blogan> sballe: if neutron already has a service account set up that can talk to barbican, really 14:49:34 <rm_work> so we could hook into that 14:49:41 <a2hill> Yea, we do store other 'secure' info in the configs 14:49:43 <sballe> we need to check this 14:49:45 <blogan> xgerman: maybe but not sure if it also can talk to barbican 14:49:48 <a2hill> not sure why this would be much different 14:49:54 <blogan> will require some testing for sure 14:49:54 <dougwig> https://www.irccloud.com/pastebin/bvLCzij1 14:49:56 <markmcclain> blogan: yes a service account in the recommended way to deploy 14:50:02 <rm_work> I mean, if it's a keystone tenant, then it's just a role issue 14:50:25 <sballe> rm_work, That's what I am getting at... It all depend on wht we want to do 14:50:25 <blogan> markmcclain: so if we need to retrieve keys from barbican, is there already a service account we can use? 14:50:43 <blogan> markmcclain: or is that something a deployer does themselves and puts in the config? 14:51:13 <markmcclain> yes.. there should be credentials that we use for hte Nova callback 14:51:20 <rm_work> though I am still thinking maybe we want to hijack the user's token to set up the original trust -- just because maybe allowing the service-account access to literally anyone's data in Barbican is a little scary 14:51:48 <rm_work> I may be getting into the weeds here, but I would like people to have some idea what's going to be happening in the background with regard to this 14:52:03 <rm_work> so if there are concerns with the security of the whole thing, they can be voiced 14:52:24 <sbalukoff> It sounds like storing credentials in a config file is no worse than current practice. 14:52:24 <rm_work> and people with more security experience than myself can chime in :) 14:52:24 <sballe> rm_work, there is something in keysone called Trusts maybe taht would be useful. It allows a service to do somethign as a user 14:52:25 <markmcclain> rm_work: I agree wanting to limit trust 14:52:35 <markmcclain> so you could reuse the current context 14:52:48 <rm_work> sballe: right, the plan is that we set up a trust between our service account to the user 14:52:59 <rm_work> but allowing the service-account to actually set up a trust with any user is a bit risky 14:53:13 <markmcclain> but we'll need to be careful that something else in the callstack has not elevated the privileges 14:53:17 <rm_work> rather, maybe would be good to as markmcclain is saying, re-use the user's original context to initiate the trust the first time 14:53:35 <rm_work> then rely on the trust from then on 14:53:41 <blogan> doesn't this have implications for octavia too? 14:53:43 <sballe> agreed 14:53:46 <rm_work> blogan: yes 14:53:50 <sbalukoff> blogan: Yes. 14:53:54 <sbalukoff> Same problem, really. 14:53:56 <dougwig> what about later, when you need to do maintenance on the LB, and need to re-fetch the cert. user context will be gone. 14:54:07 <rm_work> dougwig: but at that point the Trust will be set 14:54:15 <rm_work> so the service account has access to the user's Barbican data 14:54:22 <dougwig> ahh, i see. do trust's exist in keystone yet? 14:54:54 <dougwig> (or are they at the barbican level?) 14:54:59 <sbalukoff> Well, again, there is also the problem of the ticking-time-bomb if the user nukes his barbican data and Octavia / LBaaS needs to access it afterward. 14:55:02 <rm_work> dougwig: yes 14:55:07 <rm_work> dougwig: they are in keystone now 14:55:19 <rm_work> sbalukoff: at some point we can't protect them :/ 14:55:20 <sballe> https://wiki.openstack.org/wiki/Keystone/Trusts 14:55:20 <xgerman> sbalukoff, let's not open that can of worms 14:55:27 <rm_work> sbalukoff: if they go in and remove our trust... tough :/ 14:55:34 <dougwig> #link https://wiki.openstack.org/wiki/Keystone/Trusts 14:55:49 <sbalukoff> We already discussed this, and I think the solution was to have Octavia store its own copy of the secrets. 14:55:50 <sbalukoff> :/ 14:55:59 <sbalukoff> That's where I recall the discussion went last time. 14:56:03 <dougwig> not octavia, just haproxy. 14:56:14 <dougwig> but heck, i don't remember the final resolution. 14:56:14 <rm_work> sbalukoff: right, for Octavia that's the case 14:56:19 <rm_work> not for Neutron-Lbaas 14:56:23 <sbalukoff> dougwig: Right. Because vendors keep their own copy of the secrets anyway. 14:56:34 <rm_work> *Octavia* would copy the keys into its own Barbican store 14:56:35 <sbalukoff> Yep. 14:56:41 <sballe> +1 14:56:47 <rm_work> but for Neutron-Lbaas, we're relying on the original 14:56:55 <sbalukoff> rm_work: True. 14:56:57 <rm_work> thus Consumer Registrartion 14:57:01 <rm_work> *Registration 14:57:23 <rm_work> anyway, I'll work up an email with a better overview and maybe some pictures / diagrams :P 14:57:28 <rm_work> since we are just about out of time 14:57:32 <sbalukoff> Fancy! 14:57:34 <xgerman> rm_work +1 14:57:47 <sballe> +1 14:58:02 <dougwig> #action rm_work send writeup on barbican/trust stuff to ML 14:58:07 <dougwig> #topic Open discussion 14:58:29 <rm_work> open discussion for 2 minutes GO 14:58:39 <sbalukoff> Ok, going back to bed for a half hour. See you at 10:30, sballe! 14:58:45 <rm_work> hah sbalukoff 14:58:50 <blogan> enjoy 14:58:51 <sballe> sbalukoff, Perfect. 14:58:53 <rm_work> that's a great plan, too bad i have sprint planning <_< 14:58:53 <dougwig> rm_work: in your writeup, remember that we need to call out to barbican for every SSL negotiation. people loved that. 14:58:57 <jorgem> see you guys 14:59:07 <sballe> bye 14:59:09 <jorgem> got a meeting to attend 14:59:13 <xgerman> bye 14:59:14 <dougwig> jk 14:59:15 <dougwig> later 14:59:20 <rm_work> dougwig: hahahaha no. 14:59:21 <rm_work> T_T 14:59:31 <rm_work> I remember that though >_< 14:59:38 <rm_work> \o 14:59:42 <dougwig> #endmeeting