18:00:44 <dolphm> #startmeeting keystone
18:00:45 <lbragstad> hi
18:00:45 <openstack> Meeting started Tue Jan  7 18:00:44 2014 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:45 <dolphm> #topic Reminder: Hackathon January 15-17th @ Rackspace in San Antonio, TX
18:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:48 <openstack> The meeting name has been set to 'keystone'
18:00:51 <dolphm> NEXT WEEK ^^
18:00:54 <stevemar> yay!
18:00:59 <topol> o/
18:01:02 <dolphm> #link https://gist.github.com/dolph/5cfa70c02f5b141060c5
18:01:02 <stevemar> flight and hotel booked
18:01:05 <ayoung> dolphm, Red Hat is sending me + 1.5 others
18:01:13 <topol> I assume its warm in San Anton
18:01:17 <dolphm> hopefully everyone interested is booked up by now
18:01:26 <dolphm> topol: it's COLD this week :(
18:01:33 <dolphm> topol: 15-17 F this morning
18:01:36 <henrynash> dolphm: I'm 50-50 right now, I'll confirm in the next 48 hrs
18:01:39 <dolphm> supposed to be 70 by end of week
18:02:04 <ayoung> two people from Dogtag development team.  One is going to be coding with us, one half with us, and also working wirth Barbican folks
18:02:05 <topol> find us good places to eat and I'll be fine
18:02:09 <dolphm> #link https://www.google.com/search?q=weather+78259&oq=weather+78259
18:02:10 <dolphm> weather ^
18:02:11 <stevemar> dolphm, i'm at -17F today, it'll be a welcome change
18:02:15 <ayoung> We have space for how many people?
18:02:57 <stevemar> gyee, are you in?
18:02:59 <dolphm> ayoung: working on getting a room finalized today/tomorrow... wednesday is apparently a really busy day for this kind of thing
18:03:07 <topol> whats the dress code at rackspace. Yes Im always the nerd who asks that question
18:03:11 <gyee_> stevemar, no, I don't have the approval
18:03:17 <ayoung> topol, pants are required
18:03:18 * gyee_ is sad
18:03:19 <dolphm> topol: tshirt and jeans?
18:03:25 <stevemar> any hp folk coming?
18:03:27 <dolphm> snuggies
18:03:29 <ayoung> This is texas.
18:03:33 <ayoung> Jeans are formal wear
18:03:34 <stevemar> pants are always a good call
18:03:37 <dolphm> ayoung: ++
18:03:46 <ayoung> Spurs optional.
18:03:47 <gyee_> stevemar, none from our team
18:03:57 <stevemar> gyee_, boo
18:04:34 <ayoung> Minimum belt buckle size requirements have been relaxed for out-of-towners, though.
18:04:44 <dolphm> we'll have some PhD students from university of texas san antonio dropping in -- they're interested in contributing ABAC
18:04:55 <topol> ayoung, /me thank god!
18:05:23 <dwchadwick> hi everyone
18:05:33 <kwss> hi
18:05:53 <ayoung> dwchadwick, kwss we are just getting through the Hackathon admin things first...
18:06:35 <ayoung> is everyone staying at the Courtyard ?
18:06:57 <topol> ayoung,  I am. And will have a rental
18:06:59 <ayoung> http://www.marriott.com/hotels/travel/satca-courtyard-san-antonio-airport/
18:07:00 <dolphm> #action if you're attending for sure, and haven't already, give me a poke so i have a rough head count / list of names to leave at the front desk
18:07:28 <dolphm> it sounds like we'll have a room right at the main entrance, so it'll be VERY easy for everyone to find
18:08:27 <dolphm> i'll keep the gist up to date with anything new
18:08:36 <ayoung> dolphm, got an estimated head count?
18:09:35 <dolphm> ayoung: a LOT of people are planning on dropping in at some point... i need to put together a list of everyone that will be here all 3 days though
18:10:28 <dolphm> #topic Changes to keystone-core
18:10:36 <dolphm> Our review queue is painfully long, I think that's a given!
18:10:53 <topol> one rule at the hackathon. No one is allowed to mention Army has lost to Navy 12 years in a row
18:11:16 <dolphm> in reviewing the current members of keystone-core, we've got several people that haven't participated lately, so I'll be cleaning them out in favor of some new names
18:11:24 <ayoung> topol, mention it away.  I've come to acceptance on that point.
18:11:34 <dolphm> to be removed: Andy Smith (termie), Devin Carlen, Gabriel Hurley, and Joe Heck
18:11:45 <topol> ayoung, no. I refuse.  Im on the Army side
18:12:10 <dolphm> and the fun part...
18:12:27 <dolphm> after discussing with keystone-core, effective today...
18:12:35 <dolphm> (and with unanimous support!)
18:12:46 <henrynash> drum roll
18:12:50 <dolphm> i'll be adding Steve Martinelli (stevemar), Jamie Lennox (jamielennox), and David Stanek (dstanek)!
18:12:59 <gyee_> w00t!
18:12:59 <dolphm> welcome to keystone-core!
18:13:07 <stevemar> woot woot
18:13:09 <marekd> cool!!
18:13:12 <henrynash> yeee Haaa!!
18:13:13 <lbragstad> congrats!
18:13:18 <stevemar> congrats jamielennox and dstanek :)
18:13:25 <ayoung> This should come as a surprise to no one.  They are all doing great things.
18:13:36 <dolphm> unfortunately dstanek is teaching a python class somewhere in the frozen north today lol
18:13:36 <gyee_> amen brother!
18:13:39 <dolphm> ayoung: ++
18:13:42 <henrynash> ayoung: seconded
18:13:49 <topol> stevemar,  jamielennox, dstanek EXTREMELY WELL DESERVED.   CONGRATULATIONS
18:14:03 <ayoung> Note that the addition of core members is a very selfish decision.  It is an Ack that we need more help.
18:14:28 <jamielennox> ah, shucks guys
18:15:53 <ayoung> I see it as a fait-accompli, as I've treated opinions from these guys bascially like core for a while now.  But good to have the public acknowledgment.  And the +2 / -2 ability.
18:16:12 <dolphm> it'll take me a bit to make the changes in a few places, but if you don't have +2 / -2 by end of day, give me a poke
18:16:18 <dolphm> because i probably did something wrong
18:17:06 <dolphm> #topic Federation
18:17:17 <dolphm> ayoung: (i believe you added this today) floor is yours
18:17:18 <topol> dolphm, can you send a formal email regarding the new core members.  It helps for me to send those notes around
18:17:29 <dolphm> topol: of course
18:17:30 <ayoung> Yeah, lates last week
18:17:48 <ayoung> OK, so Federation is getting a lot of attention, and we need to get it right.
18:17:59 <ayoung> the biggest issue is the public APIs
18:18:02 <gyee_> topol, just give stevemar that bonus he deserves! :)
18:18:07 <ayoung> heh
18:18:13 <stevemar> gyee_ ++
18:18:17 <ayoung> lets start with this
18:18:39 <atiwari> ayoung, not just public API but some data model changed needed
18:18:44 <ayoung> https://review.openstack.org/#/c/62417/
18:19:16 <ayoung> atiwari, its all important, but API definitions are going to be froZen in i2 Time
18:19:28 <ayoung> so we need to clear this up now.  Fixes can come after that
18:20:06 <atiwari> ayoung, that is true I have requested to add optional domain_id in IdP API
18:20:18 <ayoung> kwss, dwchadwick we've had the side conversation about the "method" = federated
18:20:22 <ayoung> versus
18:20:28 <ayoung> "method" = SAML etc
18:20:51 <dwchadwick> correct. And we propose a common method for all federated protocols
18:20:55 <gyee_> ayoung, federation deals with authentication
18:20:56 <ayoung> Pretty certain method=federated is based on some bad assumptions
18:21:01 <ayoung> first
18:21:25 <ayoung> I think that we can say that all of the federated API docs follow the same rules
18:21:38 <gyee_> authn plugin deals with authentication
18:21:42 <ayoung> there is not going to be a "SAML" implementation that is *not* federated
18:21:43 <dwchadwick> first bad assumption of ayoung. Federation = auth. No. federation = authn + authz
18:22:05 <ayoung> commonality of functionality is at the implementation level, not the API
18:22:10 <gyee_> dwchadwick, authz is is openstack-specific
18:22:12 <ayoung> dwchadwick, I didn't say that, gyee_ did.
18:22:31 <ayoung> in this case, federation is an way of getting in authZ attributes
18:22:38 <dwchadwick> correct
18:22:39 <ayoung> authentication is a subset of that.
18:22:42 <gyee_> federation establishes an identity and that's it
18:22:46 <ayoung> gyee_, nope
18:22:46 <dwchadwick> correct
18:22:56 <dolphm> ayoung: i don't think they're "bad" assumptions - just slightly too specific for the API layer (?)
18:23:06 <ayoung> it also provides additional attributes used to make authZ decisions, and that is critical to understand
18:23:08 <dwchadwick> and an identity (= set of attributes) is used for authz by Openstack services
18:23:35 <dolphm> it's also a superficial issue, IMO
18:23:35 <atiwari> dwchadwick, I think Authz can be derived from federation
18:23:45 <dwchadwick> agreed
18:24:00 <ayoung> dolphm, my ideal would be to do Federation without any new APIs
18:24:01 <dolphm> atiwari: i don't think anyone disagrees there
18:24:04 <dwchadwick> but federation is essentially about managing trust in third parties
18:24:11 <atiwari> good
18:24:11 <ayoung> and I think that it is possible to do that
18:24:37 <dolphm> ayoung: that's my train of thought as well -- but i haven't thought it all the way through yet
18:24:44 <ayoung> for example, if we front Keystone with mod_auth_mellon, what we end up with is just a new set of attributes passed to the keystone layer
18:24:48 <dwchadwick> so we have one method for managing the trust, and it is called federated but we can call it something else if the name bugs you
18:24:52 <atiwari> question, what about openId connect which has Authz as based component
18:25:06 <topol> So I have been talking to lots of customers on this topic.   We need to work with saml and openid connect as both are pervasive
18:25:13 <ayoung> atiwari, good question, but can you hold it for a moment?
18:25:21 <ayoung> let me talk through SAML first, and then we'll talk openid
18:25:22 <topol> atiwari ++ exactly
18:25:25 <atiwari> sure
18:25:28 <dwchadwick> topol - agreed
18:25:47 <ayoung> agreed, and I think the answers to one will cover the other
18:25:53 <dwchadwick> topol - plus you need to allow for the next big protocol as well (such as ABFAB maybe)
18:26:20 <dwchadwick> ayoung - disagree. Dont talk about SAML only
18:26:26 <ayoung> I've been critical of the token request format for a while.  I'd like to
18:26:35 <ayoung> dwchadwick, we will, one thing at a time
18:26:57 <ayoung> I'd like to focus on using the existing mechanism of the web for authentication where possible
18:27:04 <ayoung> SAML  kindof blurs that
18:27:32 <ayoung> in that it sort of does cryptographically secure authentication.  But we don't want to implement that in Keystone.  Too hard to get right.  What we want
18:27:34 <ayoung> is to consume it
18:27:35 <dwchadwick> but we are not talking simply authn (as un/pw does that)
18:27:44 <ayoung> dwchadwick, understood.
18:27:46 <dwchadwick> we are talking federation which includes authz as well
18:27:59 <gyee_> we talking about the one-line impl?
18:28:26 <ayoung> so ideally we would configure Apache (or other) to do all of the SAML work, and then Keystone responsibilites would start at the mapping layer
18:28:29 <dwchadwick> gyee - the one line implementation is that is needed on top of the trust management
18:28:35 <ayoung> which is why I wanted to focus on that BP first
18:28:51 <dwchadwick> ayoung - wrong. Mapping comes after trust management
18:29:07 <ayoung> So, first question, do we absolutely even need a new API for token request?
18:29:17 <gyee_> no
18:29:23 <gyee_> not with the apache approach
18:29:27 <ayoung> dwchadwick, trust setup would happen before token request
18:29:28 <dwchadwick> agreed
18:29:38 <atiwari> +2
18:29:55 <dwchadwick> trust setup = setting trust policies
18:29:58 <gyee_> that setup would be just like an external auth
18:30:14 <ayoung> now, there is a question about how dynamic the apache approach would be.
18:30:17 <dwchadwick> trust setup does not equal validating the attributes that you are presented with
18:30:34 <ayoung> dwchadwick, define trust set up, please?
18:30:48 <gyee_> keystone trust IdP
18:30:48 <dwchadwick> configuring the IDPs that you trust
18:30:50 <ayoung> Or, actually
18:30:52 <ayoung> ok
18:30:58 <marekd> ayoung: afaik not as dynamic as we would like to have, but sufficiently dynamic for now :-)
18:30:59 <dwchadwick> configuring the attributes you trust IDPs to issue
18:31:01 <ayoung> so we have APIs for those progressing, right?
18:31:08 <atiwari> I think it is meta data needed at ST for trust IdP
18:31:13 <dwchadwick> configuring the mapping of these attributes into keystone authz properties
18:31:39 <ayoung> https://review.openstack.org/#/c/62604/
18:31:48 <ayoung> for example.  Now, that is specific to SAML.
18:32:12 <dolphm> the apache + mod_shib/mod_melon + IdP + protocol + mapping approach effectively creates a new route to produce openstack tokens
18:32:17 <dwchadwick> Ayoung - what do you trust Apache front end to do. That is the 1000 dollar question
18:32:22 <gyee_> if we are using apache approach, all those APIs are not required
18:32:33 <dolphm> so, it's a new API, but there's no "identity API" spec for the request, beyond the URL that apache is protecting
18:32:55 <stevemar> gyee_ i believe so
18:33:23 <gyee_> apache + mapping, and we are done with the first round
18:33:26 <dwchadwick> gyee. they are not required if you trust apache to do everything. you dont even need attribute mapping
18:33:40 <gyee_> you still need attribute map
18:33:51 <gyee_> apache will return attributes in env vars
18:33:51 <ayoung> dwchadwick, dolphm, I would guess it would need to work something like this:  Apache is set up to accept a broad band of authentication sources (IdPs) and validate that the documesnt are authenticat (all the crypto heavy lifting) and then Keystone would take the aenv vars it is passed and say "yes, these pass my policy"  or "no, we don't accep[t from that IdP"
18:33:55 <atiwari> guys, that is why I was asking for an architectural diagram so that every know what we are working on
18:34:09 <stevemar> gyee, that is what i thought
18:34:16 <topol> atiwari ++
18:34:22 <ayoung> atiwari, I feel your pain.  But that is what we are trying to nail down here.
18:34:45 <dolphm> in the mod_mellon case, you'd just configure mod_mellon to protect GET /v3/OS-FEDERATION/identity_providers/cern/protocols/saml2 with a configuration for cern + saml2, and keystone then knows what mapping to apply to the response, and output an authz'd token
18:34:52 <dolphm> mod_shib works similarly
18:34:54 <dolphm> https://code.google.com/p/modmellon/wiki/GenericSetup
18:35:22 <gyee_> yep
18:35:24 <ayoung> dolphm, so adding a new IdP would be a change to Apache config.  It would require an apache restart
18:35:32 <bknudson> how does keystone know? is the mapping in a config file or keystone api?
18:35:50 <ayoung> bknudson, mapping API is also under review.
18:35:51 <dwchadwick> Noone has yet answered the 1000 dollar question. Come on guys. What do you trust Apache to do
18:35:52 <dolphm> ayoung: yes
18:35:55 <gyee_> bknudson, in theory, mapping can be just middleware
18:36:09 <ayoung> #link https://review.openstack.org/#/q/status:open+project:openstack/identity-api,n,z
18:36:09 <atiwari> ayoung +1, it has to be dynamic
18:36:10 <dolphm> gyee_: it's in review as middleware today
18:36:16 <dolphm> atiwari: eventually
18:36:35 <gyee_> dolphm, alrighty then
18:36:35 <dolphm> dwchadwick: why not trust an existing implementation to take care of a bunch of fragile work?
18:36:41 <ayoung> atiwari, I hear you.  Its just that I don't think we can get there in Icehouse
18:36:42 <dolphm> dwchadwick: why NOT leverage that?
18:36:50 <dolphm> ayoung: ++
18:37:11 <ayoung> dwchadwick, I trust Apache to validate a SAML assertion and provide the attributes to Keystone.
18:37:11 <dwchadwick> you can if you are sure that it does the job properly.
18:37:21 <dwchadwick> ayoung. That is not enough
18:37:23 <marekd> dwchadwick: in general i trust  every parameter mod_shib provides me with...
18:37:26 <bknudson> I'd trust existing and deployed apache code over code that hasn't been written.
18:37:34 <atiwari> ayoung and dolphm at least we can add optional domain_id in IdP config
18:37:50 <ayoung> dwchadwick, agreed.  That is why we take those attributes and post process them in the mapping layer.
18:37:58 <atiwari> so that other use case can be supported
18:38:08 <dwchadwick> today I can send attributes from my trusted IDP to apache and have it trust them even though it should not
18:38:13 <kwss> so we move the trust management and call it on all methods of authn removing the need for a specific plugin?
18:39:21 <ayoung> dwchadwick, if Apache sends along a variable that says "these attributes were verified by IdP=X  we can then have the mapping layer say "but IdP=X can't assert those variables"
18:39:23 <marekd> dwchadwick: by default apache modules let you configure a very simple map of accepted attributes.
18:40:06 <ayoung> dwchadwick, understand, we've shifted a bit from a "eventual design" to "what can be done in icehouse time" mindset here.
18:40:14 <ayoung> We can always do more in the future.
18:40:27 <gyee_> that's the slogan
18:40:30 <gyee_> :)
18:40:32 <ayoung> what is the term MVP?  Minimal Viable Product?
18:40:45 <dwchadwick> Given that we have already implemented the current design, then why dont you think it can be ready for icehouse
18:40:48 <gyee_> "We can always do more in the future."
18:41:13 <bknudson> dwchadwick: is the implementation posted somewhere?
18:41:25 <dwchadwick> yes has been for about a week now
18:41:51 <dwchadwick> its about 700 lines long. Its the first proof of concept
18:41:56 <dolphm> bknudson: ++
18:42:09 <dwchadwick> I think the team here  can easily make it perfect for icehouse
18:42:14 <kwss> https://review.openstack.org/#/c/64454/
18:42:30 <gyee_> perfect is a big word
18:42:39 <dwchadwick> good enough then
18:43:39 <dwchadwick> your MVP requires an Apache front end, which some institutions have already rejected
18:44:07 <dwchadwick> e.g. Brazil has an operational system based on our design and a mixture of their own code and ours
18:44:14 <atiwari> dwchadwick ++
18:44:42 <marekd> but this code stil relies that the input is a JSON request, something like https://review.openstack.org/#/c/62604/, right?
18:44:48 <dolphm> dwchadwick: out of curiousity, rejected on what basis?
18:44:49 <jamielennox> dwchadwick: i think apache is more about what we can use now - if there becomes a wsgi  middleware for handling all this then it can be added to the mix later
18:45:15 <dolphm> jamielennox: ++
18:45:18 <dwchadwick> on a basis of trust management and hops in the chain. Apache is an overhead they dont want
18:45:58 <atiwari> Apache need static configuration which is not scalable
18:46:01 <ayoung> dwchadwick, in your review above, how is the SAML document validated?
18:46:14 <ayoung> kwss, that question is actually for you
18:46:53 <dwchadwick> It uses pySAML code, which was not written by us but it publicly available
18:47:09 <kwss> the saml protocol handing module is not in that review, only the apache2 module which expects prevalidated attributes from the apache module
18:47:38 <marekd> kwss: module like mod_mellon, mod_shib?
18:47:44 <kwss> yes
18:47:44 <ayoung> right...so pySAML is doing crypto in Python?  Or calls to the OpenSSL librarites?
18:48:03 <dolphm> ayoung: pySAML uses m2crypto
18:48:10 <gyee_> ha
18:48:15 <ayoung> dolphm, is that acceptable?
18:48:25 <marekd> kwss: so, why would you need some parameters like phase {negotiation, validation} and so on? mod_shib does everything as far as i am concerned.
18:48:46 <ayoung> dwchadwick, there are performance issues around crypto and python, exacerbated by Eventlet.
18:48:48 <dwchadwick> marekd - correct if you have the apache front end
18:49:14 <kwss> the other phases are for using the same mechanism for other protocols
18:49:18 <dwchadwick> we have published performance results in our paper, and pySAML works perfectly well
18:49:18 <marekd> dwchadwick: kwss mentioned she expects validated attributes from apache module...maybe i am misunderstandind something..
18:49:19 <dolphm> ayoung: that's your ball park :P
18:49:41 <dolphm> it's not a blocker for me
18:50:01 <dwchadwick> marek. If Apache does the saml protocol, then it simply passes the attributes to Keystone for trust management
18:50:05 <dolphm> but i'm easily edumacatable
18:50:19 <dwchadwick> if pysaml does the saml protocol, then we dont need an Apache front end
18:50:29 <ayoung> OK...so we would want to make it transparent to the user.  They should know that they are using SAML, but not know what Keystone is doing
18:50:33 * gyee_ looks up the word edumacatable
18:50:43 <ayoung> the request should look the same regardless
18:50:52 <topol> ayoung +1
18:50:52 <dolphm> gyee_: http://www.urbandictionary.com/define.php?term=edumacated
18:50:56 <ayoung> so there should not be an explicit apache2
18:51:07 <gyee_> haha
18:51:17 <dwchadwick> the request will always look the same to the end user since they will be talking to their own IDP to authenticate
18:51:36 <dwchadwick> end users dont see underlying protocol exchanges
18:51:44 <ayoung> dwchadwick, I mean the JSON document that is passed to keystone to get a token.
18:51:53 <ayoung> dwchadwick, yes they do
18:52:10 <atiwari> ayoung, JSON comes between apache and keystone
18:52:29 <dwchadwick> the JSON doc is standardised to be the same regardless of the federation protocol or whether Apache is in the picture or not
18:52:31 <atiwari> user will not see the JSON
18:52:44 <ayoung> dwchadwick, remember, that we can't even say for certain that the user is using the python-keystoneclient.  All of these APIs need to be acallable from third party implementations
18:52:58 <dwchadwick> this is the feature of our design - its protocol independent federation
18:53:06 <dolphm> where does JSON come into play? in the apache + mod_shib / mod_mellon case, there's no JSON at all
18:53:10 <ayoung> ain't no such critter
18:53:37 <ayoung> dolphm, there would still be a JSON document passed to the auth controller.
18:53:45 <dwchadwick> Its simple. There is an Apache page that converts the headers into a json doc in the standard format
18:53:45 <ayoung> I mean, I would love to get rid of that
18:54:05 <ayoung> dwchadwick, ahhh
18:54:17 <ayoung> mod_rewrite type logic....
18:54:24 <dwchadwick> yes
18:54:27 <dolphm> ayoung: okay i think i follow... but it would never be serialized JSON.. it's just a python dict being passed to auth?
18:54:33 <dolphm> or to the token backend?
18:54:40 <marekd> dwchadwick: so you want to make apache httpd communicate with standalone keystone over the network, right?
18:54:54 <ayoung> dolphm, up until now I was thinking env vars passed through.
18:54:56 <dwchadwick> i thought it already did that
18:55:10 <ayoung> dwchadwick, "over the network" no
18:55:16 <ayoung> its assumed to be a local call
18:55:16 <dolphm> ayoung: ++ they do. the mapping picks up env vars and converts them into something that existing code can produce a token based on
18:55:23 <dolphm> ayoung: like, a pre-auth'd auth request
18:55:39 <dolphm> EXTERNAL_USER-style
18:55:45 <dwchadwick> Kristy is just now getting an APache front end up so that we can learn more about using it, as it is not something we have used so far
18:56:19 <dwchadwick> we use Apache to run SAML IDPs and SPs, but not to front Keystone
18:56:39 <dwchadwick> Sorry I must go now for my personal appointment
18:56:46 <ayoung> dolphm, dwchadwick I think I need a bit to process this, but I'm not certain it changes anything.  I don't love the mod_rewrite approach.
18:56:52 <dolphm> dwchadwick: same sort of advantage when you're fronting keystone, not to mention the performance gains over keystonea-ll
18:56:57 <ayoung> dwchadwick, thanks for your time....
18:57:32 <dolphm> ayoung: ++ i'd like to review both side by side in the mean time -- they're both viable approaches and if we have a head start on a better long term solution, it certainly deserves consideration for icehouse
18:57:41 <dolphm> let's evaluate in review, and pick it up next time!
18:57:49 <dolphm> (< 1 min left)
18:57:49 <topol> dolphm ++
18:58:08 <ayoung> dolphm, still don't need moehod=federated
18:58:10 <ayoung> method
18:58:24 <ayoung> kwss, can you stick around in #openstack-dev?
18:58:38 <kwss> ayoung: yea no problem
18:58:42 <gyee_> dolphm, ++, we like the Republican's, a big tent
18:58:50 <dolphm> #endmeeting