18:00:50 <stevemar> #startmeeting keystone 18:00:51 <openstack> Meeting started Tue Jan 10 18:00:50 2017 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:52 <knikolla> o/ 18:00:54 <openstack> The meeting name has been set to 'keystone' 18:00:57 <browne> o/ 18:01:02 <stevemar> hi everyone 18:01:07 <gagehugo> hi! 18:01:20 <dstanek> o/ 18:01:21 <spilla> o/ 18:01:24 <jaugustine> \o/ 18:01:29 <lamt> o/ 18:01:47 <stevemar> #link agenda for today https://etherpad.openstack.org/p/keystone-weekly-meeting 18:01:57 <bknudson> hi 18:02:03 <stevemar> hey bknudson 18:02:23 <stevemar> lets get going 18:02:25 <stevemar> #topic Announcements 18:02:30 <stevemar> Current week is R-6 -- 6 weeks until we release! 18:02:40 <rderose> o/ 18:02:53 <dolphm> \o 18:02:55 <stevemar> that means everything has to be done *well* before that :) 18:03:20 <stevemar> Game plan for library releases is the following... 18:03:24 <stevemar> R5 (next week) is the last week for client libs (keystoneauth, keystoneclient, keystonemiddleware, and pycadf) 18:03:30 <stevemar> I will release new versions of these libraries this week and only re-release if necessary. 18:04:05 <stevemar> so basically, if you don't have your patch merged into ksc/ksa/ksm by EOD, don't bet on it becoming part of the O release 18:04:28 <stevemar> the re-release part is only if we muck up and another project is hurt 18:04:42 <stevemar> (or a requirements bump) 18:04:57 <stevemar> Game plan for feature work is the following... 18:05:02 <stevemar> R4 (week after next -- Jan 23-27) is the last week of Ocata-3, all features must be implemented by mid-week. 18:05:06 <stevemar> Don't anticipate getting huge changes into the RC period 18:05:30 <stevemar> we bumped "role check in middleware" to Pike 18:05:50 <stevemar> there is only "shadow mapping" and "query for users with expired passwords" left to implement 18:05:56 <stevemar> i think those are do-able by next week 18:06:17 <stevemar> spilla / lbragstad you are the owners of those bps, do you agree? 18:06:17 <lbragstad> stevemar for sure - i'll have a new patchset up for shadow mapping today 18:06:22 <dstanek> short cycle during a holiday period. i sortof expected some delays 18:06:41 <stevemar> dstanek: yes, we definitely over-committed :) 18:06:43 <rderose> stevemar: also, extending user api to support federated attributes 18:06:53 <rderose> (left to implemented, but well underway 18:07:08 <spilla> I should be able to finish by next week 18:07:19 <lbragstad> stevemar dstanek and I broke that work into two separate pieces, the implementation should be finished with my patch but dstanek's patch has the magic that allows for getting projects into the mapped properties 18:07:34 <stevemar> rderose: get as much of that complete as you can, but theres a lot to do, we need to figure out what the criteria is for marking that complete, i expect some spill over into Pike 18:07:40 <lbragstad> dstanek's patch is really close, and I wouldn't be surprised if we couldn't get that merged within the next 48 hours 18:07:54 <stevemar> spilla: rgr, your stuff is close anyway 18:08:30 <stevemar> so if folks are looking to review things, review those BPs, bug rderose / lbragstad / spilla for links 18:08:51 <stevemar> or better yet 18:08:52 <stevemar> #link https://review.openstack.org/#/q/topic:bp/shadow-mapping 18:08:58 <lbragstad> yep ^ 18:09:02 <stevemar> #link https://review.openstack.org/#/c/403898/ 18:09:18 <stevemar> #link https://review.openstack.org/#/q/topic:bp/support-federated-attr 18:09:31 <stevemar> (the second one is query users for expired passwords) 18:09:48 <spilla> stevemar: ty 18:09:55 <topol> o/ 18:10:02 <stevemar> last of my game plans :) 18:10:08 <stevemar> Game plan for stable releases is the following... 18:10:16 <stevemar> Will be releasing mitaka and newton versions for: keystone, keystoneclient, keystonemiddleware, and keystoneauth either this week or next. 18:10:25 <stevemar> I had to fix the gate for KSA and KSM so that slowed me down 18:10:30 <dstanek> lbragstad: is there anything left to do to it? 18:10:34 <stevemar> but to everyone else: Propose any backports that you would like to see included! Otherwise I will propose to release from whatever is the latest commit. 18:10:53 <lbragstad> dstanek not sure - i need to follow up with you and samueldmq about your conversation from earlier, but we can do that after the meeting 18:10:54 <stevemar> this is for stable/mitaka and stable/newton 18:11:14 <stevemar> backports to stable/mitaka should only be security or performance related 18:11:18 <samueldmq> lbragstad: ++ 18:11:34 <samueldmq> lbragstad: just some differences from the spec, like creating the roles that do not exist 18:11:35 <stevemar> mitaka will be going EOL in a few weeks ~ months 18:11:45 <samueldmq> lbragstad: but they're minor things, looking great overall 18:11:55 <stevemar> mitaka EOL is 2017-04-10 18:12:29 <stevemar> last announcement 18:12:33 <stevemar> #topic PTG 18:12:39 <stevemar> Pike PTG etherpad is here: 18:12:44 <stevemar> #link https://etherpad.openstack.org/p/keystone-pike-ptg 18:13:10 <stevemar> a full list for all projects is here: 18:13:12 <stevemar> #link https://wiki.openstack.org/wiki/PTG/Pike/Etherpads 18:14:40 <stevemar> (the eventbrite page isn't loading for me) 18:14:44 <stevemar> but its here: https://www.eventbrite.com/e/project-teams-gathering-tickets-27549298694 18:14:56 <stevemar> i'll be buying my ticket today 18:14:59 <stevemar> have my hotel booked 18:15:05 <gagehugo> not loading for me either 18:15:17 <stevemar> it was a bit slow, loaded now 18:15:22 <stevemar> 146 tickets left 18:15:24 <dstanek> 146 remaining tickets 18:15:37 <knikolla> worth noting is that for the boston summit, there will be no ATC codes distributed. but you'll get a code through your PTG ticket. 18:15:42 <dstanek> they've been going slow 18:15:53 <stevemar> knikolla: that is correct 18:16:02 <topol> That RDU to ATL flight is brutal. Sometimes you dont even have time get a drink on the plane 18:16:05 <stevemar> going to the PTG will get you free pass for the boston summit 18:16:32 <stevemar> topol: my movie may not even finish in time 18:16:33 <lbragstad> also - i got a note in my personal mailbox about booking hotels at a discounted rate for the Atlanta PTG 18:16:53 <dolphm> topol: sounds like a challenge 18:17:10 <stevemar> anyone else know if they going / not going? 18:17:35 <knikolla> going. still need to book travel/accomodation. where are y'all staying? 18:17:36 <dolphm> you'll also only get a code for the summit/forum through your PTG ticket IF you actually show up to the PTG 18:17:43 <stevemar> knikolla: at the conference hotel 18:17:55 <stevemar> dolphm: that is also true 18:18:06 <stevemar> hopefully not too many people don't think they can abuse that :) 18:19:11 <morgan> o/ 18:19:12 <dstanek> stevemar: going..but not sure about hotel just yet 18:19:16 <morgan> sorry a little late 18:19:23 <stevemar> morgan: 5 demerit points 18:19:26 <knikolla> stevemar: conference hotel was on the expensive side 18:19:31 <morgan> 5 points from gryffindor 18:19:35 <topol> 10. he's like 20 mintues late 18:19:48 <morgan> with the sheraton discount it was about avg for atl "big" hotels 18:19:50 <stevemar> ++ 18:19:52 <morgan> topol: shush 18:20:05 <topol> are folks getting rental cars? 18:20:12 <knikolla> i'll probably end up on an airbnb as usual 18:20:21 <lbragstad> i was just planning getting an Uber if required 18:20:30 <rderose> uber 18:20:31 <topol> k 18:20:33 <gagehugo> uber ++ 18:20:35 <morgan> i'm just going to carpool with topol everywhere 18:20:36 <stevemar> topol: not really much point since the hotel and conference are at the same place 18:20:40 <morgan> the keystone uber driver 18:20:41 <morgan> ;) 18:20:42 <dolphm> morgan: ++ 18:20:50 <topol> I may just uber then 18:21:02 <dolphm> topol: uber will pay you, you know 18:21:09 <morgan> dolphm: ++ 18:21:14 <stevemar> alright, let's switch gears, the ptg will be very fun, everyone should come 18:21:15 <samueldmq> I haven't got travel approval yet 18:21:16 <morgan> i mean, we wont pay you 18:21:18 <morgan> but... 18:21:23 <samueldmq> but I heard at least the ticket is refundable 18:21:23 <stevemar> if you need reasoning for a manager, i'm here for you 18:21:28 <dolphm> *someone* will 18:21:31 <lbragstad> samueldmq ++ 18:21:36 <morgan> there is still money from the foundation i hear 18:21:40 <morgan> if you apply soon 18:21:43 <morgan> for financial assitance 18:21:51 <morgan> but that is a rumor i've heard through the grapevine 18:22:11 <dolphm> for foundation travel funding: https://wiki.openstack.org/wiki/Travel_Support_Program 18:22:15 * topol Lived in ATL for 9 years. Know some great restaurants 18:22:30 <rderose> topol: sweet! 18:22:34 <lbragstad> I totally wanna go back to Max's 18:22:41 <dstanek> topol: roscos chickena and waffles doesn't count 18:22:48 <morgan> dstanek: ++ 18:22:59 <stevemar> alrighty, really switching to next topic this time :) 18:23:07 <stevemar> #topic invalid query parameters [lamt] 18:23:07 <dolphm> #link apply for travel funding https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta 18:23:13 <stevemar> lamt: you're up 18:23:45 <lbragstad> #link https://launchpad.net/bugs/1654084 18:23:45 <openstack> Launchpad bug 1654084 in openstack-api-wg "Listing resources with invalid filters should result in a 400" [Medium,In progress] - Assigned to Ed Leafe (ed-leafe) 18:23:45 <lamt> thanks - stevemar. #link https://review.openstack.org/#/c/417315/5 18:24:29 <lamt> The bug is to correct the behavior when a user specifies an invalid parameter in the URL 18:24:45 <morgan> i like this change but it is an API contract break 18:24:46 <morgan> fwiw 18:24:51 <lamt> right now the code silently ignores the bad parameter, instead of returning 400 18:25:03 <morgan> so... without something like microversions or otherwise 18:25:07 <morgan> i have to be a -2 on this. 18:25:14 <morgan> it is a contract (implicit) break 18:25:21 <morgan> since we have historically ignored it 18:25:24 <morgan> sorry :( 18:25:27 <bknudson> I think the server should ignore invalid parameters since then new clients can work well enough with older servers 18:25:31 <morgan> i really do like being more explicit 18:26:18 <morgan> but if you can convince mr PTL is isn't really a contract break, I'll just continue on my way and not be against it 18:26:45 <stevemar> oh it is, i thought we were allowed to if fixing behaviour? 18:26:48 <morgan> likewise, if we add a simple param all clients can send "&strict_query" and that causes the 400 18:27:09 * lbragstad #link https://bugs.launchpad.net/keystone/+bug/1654084/comments/4 18:27:09 <openstack> Launchpad bug 1654084 in openstack-api-wg "Listing resources with invalid filters should result in a 400" [Medium,In progress] - Assigned to Ed Leafe (ed-leafe) 18:27:22 <morgan> stevemar: imo not really, we are allowed to do things like 400 -> better 4xx error 18:27:28 <morgan> or 500 -> proper non-500 error 18:27:36 <morgan> but changing a 200 to a 400 is not good. 18:27:43 <stevemar> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance 18:27:45 <lbragstad> morgan aha - that makes sense 18:27:46 <stevemar> bah 18:27:52 <stevemar> The change is the only way to fix a security bug. 18:27:52 <stevemar> Fixing a bug so that a request which resulted in an error response before is now successful. 18:27:52 <stevemar> Adding a new response header. 18:27:54 <stevemar> Changing an error response code to be more accurate. 18:27:57 <morgan> yep 18:28:09 <gagehugo> "unless the success reported previously was hiding an existing error condition" 18:28:20 <morgan> and this isn't hiding an error condition 18:28:21 <gagehugo> but then that's up in the air if it's really an "error" 18:28:26 <bknudson> this isn't saying we can't fix it. just that we can't change the behavior without a microversion. 18:28:29 <morgan> it's just ignoring input that is invalid 18:28:33 <morgan> bknudson: ++ 18:28:34 <morgan> exactly 18:28:51 <morgan> i am -2 on the change as is. with a api version (microversion or otherwise) we can totally move forward 18:29:18 <stevemar> sounds fair, sorry lamt, i got my rules mixed up 18:29:21 <morgan> also, it's about 50/50 on if an API rejects or ignores query params 18:29:24 <morgan> in the wild 18:29:28 <morgan> (non-openstack) 18:29:34 <stevemar> morgan: yaeh, its pretty weird 18:29:47 <stevemar> for web searches it's pretty much always ignore 18:29:48 <morgan> so i'm going to toss a -2 on it and comment on the bug again. 18:29:51 <lamt> :( okay - perhaps it builds a case for microversioning 18:29:58 <stevemar> lamt: definitely 18:29:59 <lbragstad> morgan the "strict" case is interesting 18:30:52 <morgan> lbragstad: yep possibly 18:30:58 <morgan> there are ways to slice this 18:31:03 <morgan> and i'm open to that 18:31:41 <lbragstad> but - would that make us one of the only projects that supports both? 18:31:42 <bknudson> what's the problem with microversioning? 18:31:54 <stevemar> bknudson: nothing, no one has done it yet :) 18:32:01 <stevemar> bknudson: but i think lamt is going to do it :P 18:32:26 <bknudson> I don't even see this as a bug. 18:32:33 <bknudson> what problem is it causing? 18:32:57 <lamt> stevemar : the spec is approved, perhaps something for Pike? 18:32:59 <stevemar> its for correctness i guess, HTTP spec (and the API working group) say it should be a 400 18:33:08 <stevemar> bknudson: ^ 18:33:16 <stevemar> lamt: totally, but ask whoever is PTL then :P 18:33:16 <lbragstad> stevemar ++ 18:33:24 <bknudson> ok, if the goal is to be consistent. 18:33:31 <morgan> ok 18:33:43 <morgan> commented on the bug and -2 on the review 18:33:48 <stevemar> thanks morgan 18:33:49 <lbragstad> if we're aiming for consistency, then i'd opt for the microversion 18:33:53 <bknudson> my understanding is that nova solved API consistency changes through microversioning 18:33:57 <morgan> happy to remove the -2 once we have a path forward that isn't breaking contract 18:34:05 <morgan> and i am 100% for a path forward (ftr) :) 18:34:09 <morgan> bknudson: yep 18:34:10 <stevemar> bknudson: you going to give up microversions? :) 18:34:12 <morgan> that is the plan. 18:34:15 <stevemar> give us* 18:34:43 <morgan> i'm fine with microversions, it's a lot of work, but would make some changes much easier 18:34:51 <lbragstad> ++ 18:34:53 <morgan> with a monotonic increase and clear support paths. 18:34:57 <stevemar> yep 18:35:05 <stevemar> something to think about for Pike 18:35:10 <morgan> but i don't want half-assed impl. 18:35:18 <morgan> i'll be very critical of the spec fwiw. 18:35:21 <morgan> and code. 18:35:25 <stevemar> morgan: the spec is already approved 18:35:31 <morgan> oh hah right 18:35:33 <bknudson> half-assed impl is a good description of keystone. 18:35:34 <stevemar> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/microversions.html 18:35:34 <morgan> then the code 18:35:41 <morgan> i think i helped approve the spec now that i think about it 18:36:04 <morgan> bknudson: half-assed key-value store via REST API that sortof manages identity information for openstack 18:36:10 <morgan> :P 18:36:19 * morgan stops being too snarky 18:36:31 <stevemar> bknudson: you need to fix it all 18:36:39 <morgan> stevemar: rm -rf 18:36:41 <morgan> stevemar: done 18:36:45 <morgan> fixed 18:36:48 <morgan> ;) 18:36:49 <stevemar> morgan: i think you mean rm -rf stevemar 18:36:54 <bknudson> just rewite it in go. 18:37:03 <morgan> bknudson: i hear we should do it in erlang 18:37:09 <morgan> bknudson: it's clearly the right choice. 18:37:10 <stevemar> alright, someone mentioned go, that means topic change 18:37:15 <bknudson> nice, then we could replace running code. 18:37:18 <lbragstad> just *go* rewrite it... 18:37:22 * lbragstad slaps knee 18:37:36 <rderose> :) 18:37:36 <morgan> bknudson: and it needs to use toml instead of json (*glances around to see if anyone barfs*) 18:37:45 <stevemar> #topic Adding domain_id to the user table [ rderose ] 18:37:56 <rderose> this may be a little early, but wanted to get this in front of you now 18:38:02 <morgan> rderose: is this instead of a FK-like implement? 18:38:03 <rderose> problem: need to add the domain for federated users 18:38:11 <stevemar> #link https://review.openstack.org/#/c/409874/ 18:38:15 <rderose> morgan: ? 18:38:17 <morgan> i mean... don't we already have domain_id in the user tablre? 18:38:24 <bknudson> I thought it was protocol buffers. 18:38:27 <rderose> yes 18:38:30 <morgan> bknudson: shush 18:38:34 <rderose> currently domain_id is in the local_user table and federated users don't have a domain defined 18:38:47 <morgan> hmm. 18:38:50 <rderose> the domain will now come from the idp domain, but we need to properly set it for federated users 18:38:56 <morgan> ah 18:39:01 <morgan> makes sense to me. 18:39:01 <rderose> solution: move domain_id up to the user table and create a foreign key relationship to the local user table, so that: 18:39:08 <rderose> "user.id, user.domain_id -> local_user.user_id, local_user.domain_id" (1:1) 18:39:20 <rderose> https://drive.google.com/file/d/0BxjKpg1oYSKRVXFPQXlWT2tDYzQ/view?usp=sharing (only before and after, ignore last 2 pages) 18:39:21 <stevemar> that line makes sense to me 18:39:26 <morgan> i wouldn't bother with the FK. just do it as a straight orm relationship 18:39:37 <rderose> the domain_id is still needed in the local_user table to ensure that the domain_id-name is unique 18:39:37 <morgan> it doesn't need to be a FK 18:39:46 <morgan> oh it does.. 18:39:47 <morgan> damn 18:40:11 <rderose> morgan: the fk constraint will ensure that the user will belong to a single domain and that the domain is in sync between the 2 tables. 18:40:12 <morgan> you can'd do FK(local_user || non_localuser) can you? 18:40:21 <morgan> in SQL 18:40:25 <rderose> morgan: why? 18:40:34 <morgan> just curious 18:40:38 <morgan> not syaing it's better 18:40:43 <lbragstad> that way we wouldn't need to duplicate it across tables 18:41:05 <morgan> it could make the FK from whichever is authoritative for the user object (local or non) 18:41:14 <lbragstad> and domain_id would always come from the user table, but be used in the localuser table for uniqueness 18:41:15 <morgan> but i mean thqt might be stupic complex 18:41:27 <rderose> lbragstad: it's not duplicate (well sort of), but it's needed in the tables to ensure domain/name uniqueness 18:41:36 <lbragstad> rderose right 18:42:17 <morgan> hm. 18:42:24 <rderose> :) 18:42:31 <morgan> ok i don't see an issue with moving it around. 18:42:45 <stevemar> rderose: yeah, do what you gotta do 18:42:46 <morgan> would non-local user also get the same FK entry? 18:42:54 <stevemar> rderose: you're the expert on all things shadow related now 18:43:01 <morgan> so you would see the data in either table 18:43:09 <morgan> i ask because that might be just convinent 18:43:13 <rderose> I should have the patch ready in a day or 2 for review 18:43:30 <rderose> but just wanted to get it in front of folks in case there were any strong objections 18:43:39 <rderose> morgan: yes 18:43:42 <morgan> cool 18:43:47 <morgan> then i think this makes a lot of sense 18:43:54 <rderose> stevemar: cool 18:43:57 <rderose> that's it then 18:44:05 <stevemar> #topic open discussion 18:44:07 <morgan> other stupid question... cna you have nonlocal user and local user for the same <user> record? 18:44:09 <stevemar> any takers? 18:44:19 <morgan> i think i saw code preventing that 18:44:20 <rderose> morgan: account linking 18:44:26 <morgan> ok cool 18:44:31 <morgan> just making sure. 18:45:08 <lbragstad> i don't think we've implemented account linking, but that sounds like it would make it possible to have a nonlocal user and a local user link to the same user reference 18:45:11 <morgan> stevemar: please give the backport stable link? 18:45:29 <morgan> anyone who wants to review stable, please look at the reviews 18:45:30 <stevemar> morgan: to what? open reviews? 18:45:32 <morgan> yeah 18:45:38 <morgan> the one you gave me yesterday 18:45:42 <morgan> i'm going to sweep through today 18:45:49 <rderose> lbragstad: we haven't implemented account linking, but part of the shadow user goals was to build a data model that would support it 18:45:50 <morgan> but if you have concerns, please take a look 18:46:03 <stevemar> https://review.openstack.org/#/q/project:openstack/keystone+branch:stable/newton https://review.openstack.org/#/q/project:openstack/keystone+branch:stable/mitaka 18:46:08 <lbragstad> rderose ++ 18:46:17 <stevemar> https://review.openstack.org/#/q/project:openstack/keystoneauth+branch:stable/newton and https://review.openstack.org/#/q/project:openstack/keystoneauth+branch:stable/mitaka 18:46:41 <stevemar> we need more people proposing backports to stable, keeping an eye on the gates, and reviewing patches 18:46:43 <morgan> only a couple of us have stable +2 rights. (mostly us crazy pendantic folks) 18:46:47 <morgan> but.... 18:47:00 <lbragstad> stevemar i'll make a note to look through today 18:47:05 <morgan> please propose the backports so us stable reviewes have an easier time landing 18:47:10 * dolphm needs to make a dashboard dedicated to stable branches 18:47:28 <morgan> if you have code that is indended to backport, please propose it yourself to the stable branches :) 18:47:37 <stevemar> its pretty easy to query... 18:47:53 <morgan> it really does make the few of us more capable of landing. if stevemar, dolphm, or I propose the backport, you're limiting who can review 18:47:56 <stevemar> yeah, theres a "cherry-pick" button in gerrit that makes it stupid easy 18:48:03 <dolphm> morgan: ++ 18:48:03 <lbragstad> dolphm i started using https://github.com/lbragstad/dotfiles/blob/master/dashboards/keystone-stable.ini 18:48:36 <dolphm> lbragstad: i'll share mine when it's ready :P 18:48:55 <stevemar> #link https://review.openstack.org/#/q/project:"^openstack/@keystone@" -project:openstack/charm-keystone is:open branch:"^stable/@" -project:openstack/puppet-keystone 18:49:18 <dolphm> not quite how that works ^ 18:49:36 <stevemar> oh we also need someone to make this same change in keystoneclient: https://review.openstack.org/#/c/418194/ 18:49:48 <stevemar> if someone is looking for easy work 18:50:42 <stevemar> alright, i think we're done here 18:50:46 <samueldmq> stevemar: I can change that in the ksc 18:51:17 <samueldmq> stevemar: that and backports, right ? 18:51:21 <stevemar> oh also Pike PTL nomination is from Jan 23 - Jan 27 18:51:28 <stevemar> samueldmq: yeah, the backports need love too 18:51:34 * samueldmq nods 18:51:51 <morgan> in short, don't make dolphm or myself come out of retirement... we like where we are 18:52:02 <morgan> and since stevemar is not running... 18:52:13 <morgan> step up :) 18:52:20 <samueldmq> morgan: ++ 18:52:22 <dolphm> lol 18:52:25 <morgan> dolphm: right?! 18:52:27 <morgan> :) 18:52:42 <stevemar> alrighty, hope to see everyone at the PTG in a few weeks! 18:52:53 <lbragstad> stevemar ++ i'm looking forward to it :) 18:53:07 <dolphm> go go nominations #notPTL 18:53:12 <morgan> i gotta book a planeflight. 18:53:21 <morgan> also #notPTL 18:53:30 <stevemar> #almostNotPTL 18:53:36 <stevemar> hehe 18:53:41 <lbragstad> dolphm morgan stevemar y'all sell the job so well! 18:53:51 <stevemar> its a lot of fun! 18:53:57 <lbragstad> ;P 18:54:01 * stevemar ends meeting before he's caught in his lie 18:54:01 <morgan> #FormerPTLsUniteAndJustBecomeThePenutGallery 18:54:02 <samueldmq> yeah, very inspiring 18:54:06 <stevemar> #endmeeting