18:01:10 #startmeeting keystone 18:01:11 Meeting started Tue Jul 23 18:01:10 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:14 The meeting name has been set to 'keystone' 18:01:34 #topic Havana Milestone 3 18:01:38 congrats on m2 everyone :) 18:01:44 w00t 18:01:59 yay 18:02:13 i think that was one of the smoothest milestone releases in terms of bugs, etc, since like folsom 18:02:30 time for a vacation 18:02:35 exactly! 18:02:41 i'll be out beginning of next week lol 18:02:45 m-w 18:02:50 dolphm, that is cuz no other project was treating it as feature freeze and battling us for the commit queue 18:03:01 and our new deadline is milestone-3 - september 4th 18:03:15 thought it was aug21? 18:03:18 at that point, feature freeze for havana kicks in and then it bug fixing until summit 18:03:33 err 18:03:35 #link https://wiki.openstack.org/wiki/Havana_Release_Schedule 18:03:43 nothing is aug 21 18:03:58 Well, actually it is my folks anniversary 18:04:14 ayoung: congrats! 18:04:14 nothing steve cares about is aug 21 18:04:16 * ayoung ducks 18:04:19 that must be what stevemar was thinking of. 18:04:27 i might care about ayoung folks?! 18:04:32 i mean, i'll be there if there's food 18:04:40 me 2 18:04:51 nvm, i was looking at the dev list, it was nova related 18:04:55 whoops 18:05:05 nova's got their own problems. 18:05:32 cool 18:05:34 #topic High priority bugs or immediate issues? 18:06:15 one thing - could someone send me some guidance on doing a stable/grizzly patch? 18:06:23 henrynash: sure, ping me after 18:06:24 git cherry-pick 18:06:42 bknudson, only if he's lucky 18:06:46 dolphm, bknudson: thx 18:06:51 i'm assuming there's no major public issues, bugs have been quiet 18:07:03 none that I am aware of 18:07:12 no security reports lately! 18:07:19 okay, so from the off-list mail thread... 18:07:21 #topic Identity API v3.1 18:07:30 is now final, as of havana-m2 18:07:52 which means any changes proposed against the core api should be marked v3.2, and implemented in icehouse 18:07:56 the docs just need to match the code 18:07:56 or, merged in icehouse 18:08:19 dolphm, I assume that means that the focus is going to change to extensions until then 18:08:29 what about 4.0? 18:08:34 ayoung: ideally, the focus should be on stability 18:08:35 bknudson: yep, we're getting there: https://review.openstack.org/#/c/37000/ (but not done yet) 18:08:52 dolphm, and performance? 18:09:08 bknudson: if we have a reason to introduce major backwards incompatibilities to the api we'll have to bump to v4.0 18:09:19 dolphm, I meant that new features should get implemented as extensions, and they can become core later 18:09:30 bknudson: but other than fixing bad status codes and stuff, i don't see a viable reason to do a major version bump 18:09:43 yay stability 18:09:43 I think termie has already claimed 5.0 for himself 18:10:13 and then straight from the agenda- "API-impacting changes must be disabled by default (as optional middleware) or be limited to backwards-compatible bug fixes" 18:10:31 so, that should probably include SQL migrations 18:10:36 i know henrynash said he had some points he wanted clarified .. henrynash? 18:10:38 do 3.1 extensions turn into core 3.2? 18:10:46 bknudson: not necessarily 18:11:18 bknudson: if we see 100% of deployments enabling an extension and fussing over why it's not core, then it should become core 18:11:23 dolphm: it was the phrase "no new methods for core APIs"…or something like that in ayoung's proposed email 18:11:24 bknudson, I'd say it is more likely that nothing big can become core from here on out without being an extension first 18:11:54 having more things as extensions permanently makes sense to me 18:11:59 ayoung, why? 18:12:08 dolphm; are we saying we can't change the code inside a core API even if there is no API change? 18:12:19 henrynash, I was distinguishing between changing the params or input data for a URL/method and adding a whole new URL or method to an existing URL 18:12:21 the fundamental seperation between core and extensions is intended seperate portable, required and expected functionality and optional, deployment-specific features 18:12:37 so, not everyone has a use case for domains, so domains could/should have been an extension 18:13:02 dolphm, I did implemented domains as extension once :) 18:13:08 ayoung: both of those can be accomplished via extensions 18:13:09 in contrib 18:13:10 quick question, now that the api is at v3.1, is that supposed to be reflected in GET / ? 18:13:22 intriguing, so dolphm you feel the common subset of what everyone needs has been reached??? 18:13:24 gyee: yeah, i am glad it's a core concept though 18:13:26 dolphm, exactly. That was what I was trying to convey in my email 18:13:43 topol: i can't imagine that's the case lol 18:13:59 topol, more like the intersection, which is effectively the empty set 18:14:02 dolphm, thats how I interpreted your statement 18:14:23 topol: there are like 3 resources in the v2.0 core spec, only because that's all we could agree on as 'required, expected functionality' 18:14:41 create token, list tenants, validate token 18:14:47 :) 18:14:55 so, for extensions, we need to have separate migrations, which is the driving force behind this diff: https://review.openstack.org/#/c/36731/ 18:15:11 and that one needs alembic, which I have a WIP for 18:15:20 https://review.openstack.org/#/c/38295/ 18:15:36 so for example storing credentials. If you decide to do more in that space it would not be core additions? 18:15:39 jamielennox: yes... someone ran into a bug when they tried to change that though... i'll look around 18:15:43 ayoung: so I'll be pedantic…in my policy/protection bp, I am technically changing the parameters to a core function (it's just not visible or exposed via a url) - see identity/controller.py in https://review.openstack.org/#/c/38308/ 18:16:14 ayoung: this is kind of what I was concerned about 18:16:25 henrynash, _check_protection? 18:16:35 henrynash: what's a core function? 18:16:56 dolphm, I think he means he is changing the policy enforcement for core functions 18:17:11 i'm still not sure what a core function is 18:17:13 do we have a picture that shows what is declared core and what are extensions? 18:17:21 so ones that would have succeeded in the past would now fail a lociy check, or vice versa 18:17:36 topol: you mean like a diagram with pie charts and puppies? 18:17:37 when I see the 3.1 API I think all of that is core 18:17:44 young, dolphm: and pass an extra parameter into, say, get_user() - see line 611 18:17:48 dolphm a core function is a function of a controller that maps to a public URL 18:18:05 dolphm, core list on the left, extensions on the right :-) 18:18:08 topol: this defines core https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md 18:18:11 henrynash, you changing the query string filters? 18:18:14 topol: the entire doc 18:18:17 henrynash, I don't think that is going to fly 18:18:17 gyee: no 18:18:19 dolphm, perfect 18:18:33 so what API change are we talking about? 18:18:37 ayoung: why? 18:18:49 henrynash, is that going to change the public interface>? 18:18:54 dolphm, and we wont ever add to that doc again??? Im guessing of course we will 18:18:58 ayoung: no 18:19:18 Oh, ok, then the general approach is OK, 18:19:23 topol: we are -- we continued to add to it and maintain it after v3.0 -> v3.1 18:19:36 topol: we can do the same for v3.1 -> v3.2 so we don't have to maintain multiple docs 18:19:39 so ergo core will keep expanding 18:19:47 ayoung: ok, I think so too. 18:19:56 topol: yes, but a client may only implement v3.1, and v3.2 has to be compatible with such clients, etc 18:20:07 dolphm, agreed 18:20:18 and vice versa, a client may understand v3.2, but the server only speaks v3.1, and that needs to work too 18:20:20 +100 on backward compatibility 18:20:23 henrynash, You are just trying to get the attributes down to where the decision needs to be made. IN generla, that is OK. Lets discuss the mechanism after the meeting 18:20:37 ayoung: correct, and agreed 18:21:05 ayoung, henrynash, that would not be a core API change then 18:21:33 dolphm: do clients need to know if they're talking to v3.2 or v3.1? 18:21:36 henrynash: your change doesn't look like it affects the http api at all 18:21:36 as I was saying before, core devs, when reviewing extension changes, do not let in any more changes to the sql migrations from new extensions. 18:21:40 bknudson: yes 18:21:50 bknudson: well, they should 18:21:51 fixing old migrations is OK 18:21:52 dolphm: how do they know? 18:21:56 bknudson: GET / 18:22:01 bknudson, i would say yes if they want to use a 3.2 feature 18:22:02 bknudson: or GET /v3/ 18:22:05 ayoung, gyee: which is which I was trying to get clarification of exactly what the API was defined as (e.g. the one mapped to a url or the line of parameters in the controller function) 18:22:06 or extentions that already have migrations in the common 18:22:15 henrynash, the web API 18:22:21 URL/Method 18:22:25 henrynash: HTTP API 18:22:34 GET /v3/users 18:22:38 ayoung: Ok, fine. total agreement :-) 18:22:45 henrynash: the internal implementation-specific api's are completely up to us 18:22:52 so if a current API doesn't have, say, HEAD right now, adding that is a new method 18:23:00 ayoung: +1 18:23:04 ayoung, whats the issue with new sql migrations? 18:23:09 topol, a couple things 18:23:20 cant those be done and stay backwards compatible? 18:23:24 ayoung, not sure if I agree to no new migration for extensions 18:23:30 think along these lines: we want to be able to take an extension and deploy it in its own server. 18:23:49 most extensions require schema changes 18:23:55 gyee, exactly 18:23:56 gyee +1 18:23:57 gyee: should be schema additions 18:24:05 or, a new schema 18:24:06 gyee, and those should be in an extension specific repo 18:24:09 not in the common 18:24:21 that is the point of the first review I posted 18:24:26 so ayoung you are hiding the trash under the rug? 18:24:28 ayoung: does migration know what schema is being migrated? 18:24:29 No 18:24:38 is the extension passed in to keystone-migrate? 18:24:43 bknudson, yes 18:24:57 bknudson, the issue is that migrations do it differently than alembic 18:25:00 and I don' 18:25:08 t know alembic well enough yet 18:25:20 but for the current migration scheme, it goes into a separate row in the migrations table 18:25:25 ayoung: should extensions use alembic? 18:25:33 bknudson: i'd like them to 18:25:59 dolphm, ayoung, I think that's a fair statement, schema addition is allowed 18:26:03 #link http://paste.openstack.org/show/41431/ 18:26:06 ayoung: it would be good to have an example. 18:26:19 as long as extension can superimpose the new schema on the existing one, we should be fine 18:26:19 bknudson: the community is generally leaning towards alembic, and i'm certainly on board my self... if we're going to make a transition from sqlalchemy-migrate to alembic, i'd rather do it on one migration repository than 10 (9 of which we don't have yet today) 18:26:37 bknudson, so I made it work for simo's kds code, but it was using the current migration scheme, not alembic 18:26:44 still learning alembic. 18:27:30 K, so the benefits of Alembic and the new migration scheme are??? 18:27:40 gyee, so in the migrations table right now I have 18:27:56 #link https://alembic.readthedocs.org/en/latest/ FYI on Alembic 18:28:03 keystone | /opt/stack/keystone/keystone/common/sql/migrate_repo | 29 18:28:17 and to do an extension for kds it would be 18:28:31 kds | /opt/stack/keystone/keystone/contrib/kds/sql/migrate_repo | 1 18:28:44 Im assuming it solves an issue we have... 18:28:51 alembic's system is more like git, in that it usese hashes, paretns, etc 18:29:04 but I don't know if alembic will support multiple repos or not 18:29:04 topol: sqlalchemy-migrate is unsupported. 18:29:15 will the number or migration operations decrease??? 18:29:29 topol, also, it does all of the migrations ins a single commit 18:29:32 ayong: is an extension migration only run when it is enabled? 18:29:33 bknudson, THANKS for the explanation 18:29:45 unsupported -- bad 18:29:45 ayoung: is an extension migration only run when it is enabled? 18:29:48 ayoung, in which order the migration happens, core first, then contrib? 18:29:50 henrynash, good question 18:29:57 gyee, should be irrelevant 18:30:00 single commit -- good. Im on board 18:30:26 ayoung: I thought you said you had to pass the extension to keystone db_sync 18:30:27 gyee, an extension should not know about core tables and vice versa. They should only communicate via code 18:30:38 bknudson: topol: technically it's been unsupported, but it's now being run by our community 18:30:38 ayoung, what if contrib have dependency on core schema? 18:30:38 like foreign key or something 18:30:44 bknudson, that was dolphm 's suggestion, but we hadn't discussed it yet 18:31:03 ayoung: because otherwise how does db_sync know what extensions are enabled? 18:31:08 bknudson: the only catch with that is that db_sync already has an optional positional argument 18:31:08 parse the pipeline? 18:31:10 ayoung, amen brother! 18:31:12 (migration number) 18:31:51 dolphm, we could do a separate CLI param for extensions if needs be 18:31:55 db_sync_ext 18:31:57 use --extension 18:32:03 or something less horrible 18:32:05 or --extensions 18:32:09 bknudson, =1 18:32:10 +1 18:32:19 there's a lot of tooling today that's already calling db_sync and expecting everything to be done 18:32:43 ayoung, I think performance may such a little, but its a price worth paying in exchange for sanity :) 18:32:44 dolphm, so I would not mind it being done based on active extensions 18:32:47 maybe there's some paste.ini magic. 18:32:54 why would we do a seperate call? if it's in db_sync there is no problem running db_sync if the rest of the db is up to date 18:33:06 ayoung: keystone-manage has no idea what the deployment pipeline will look like 18:33:20 jamielennox, lets assume we want to deploy just kds. We should only get the KDS schema on that system 18:33:54 bknudson: you can have more than one paste file 18:33:55 ayoung, i'd suggest the cost of a number of empty tables that aren't accessed is pretty low 18:33:56 dolphm, would it be that wrong for manage to use the paste config? 18:34:22 not optimal, but easier for configurers 18:34:32 ayoung: if you can answer "which paste config" then perhaps not 18:34:48 dolphm, there is a function in keystone/config which sorts that out IIRC 18:35:08 https://github.com/openstack/keystone/blob/master/keystone/config.py#L39 18:35:16 ayoung: you have no guarantee that's the only pipeline that the backend is supporting 18:35:38 dolphm, how about adding the pipeline to db_sync? 18:35:45 what does that mean 18:35:47 extensions could have their own pipeline 18:35:55 * dolphm facepalm 18:35:58 heh 18:36:05 * ayoung 's work here is done 18:36:12 #topic Havana milestoen 3 blueprints 18:36:15 #link https://launchpad.net/keystone/+milestone/havana-3 18:36:29 #action ayoung to sort out the db_sync strategy for extensions 18:36:30 between now and next week, we need to revise this list 18:36:49 so if there are blueprints you plan on working during m3 which are not on this list, speak up! 18:36:52 register them 18:36:55 whatever 18:37:05 dolphm: there was the pagination one…let me find it 18:37:13 how do we request a blueprint goes into h3? 18:37:17 there's also a few blueprints on here we might want to untarget from m3 (like bp notifications) 18:37:22 dolphm, should I add the SQL migration thing as a blueprint? I was doing it as a prereq, but it seesm to have grown in scope 18:37:22 dolphm, I think fabio is working on the endpoint filtering bp 18:37:22 https://blueprints.launchpad.net/keystone/+spec/notifications 18:37:41 #link https://blueprints.launchpad.net/keystone/+spec/pagination-backend-support 18:37:42 yeah, wondering how we are going to go about hten since it is blocked my rpc-api-review work in oslo 18:37:42 fabio, please confirm 18:37:52 bknudson: poke me about it, if nothing else, i'm not sure what permissions people have on launchpad, but i can definitely help 18:38:16 dolphm: ok. I've been requested to implement some kind of translation blueprint. 18:38:17 dolphm, guessing that heckj is not going to have time to work on https://blueprints.launchpad.net/keystone/+spec/keystone-performance-benchmark 18:38:17 lbragstad: it's been on my wishlist all of havana, but i think we need to retarget to 'next' 18:38:33 yes I am working on the ep-filter 18:38:41 ayoung: agree, although we've had some activity around benchmarking recently... we might be able to rubberstamp it as completed out of band 18:38:51 dolphm, cool 18:38:52 dolphm, can you please add the endpoint filtering to the m3 list? 18:39:22 * topol who keeps filtering endpoint filtering out of the m3 list??? :-) 18:39:46 dolphm, so all of the extension blueprints should depend on https://blueprints.launchpad.net/keystone/+spec/multiple-sql-migrate-repos 18:39:51 dolphm: should we think about an implementation using the existing rpc stuff in oslo? 18:39:54 topol, we are not getting into my filter is bigger than your filter war are we? 18:40:09 that is KDS, endpoint filtering, OAuth, 18:40:09 Domain Quotas 18:40:14 lol. no I always lose those 18:40:29 lbragstad: i'm pretty sure someone did, and that got blocked too? 18:40:46 who's working on domain quota? 18:40:47 I thought the problem with notifications is we don't want to require eventlet? 18:41:05 Tiago Everton Ferraz Martins gyee 18:41:11 https://blueprints.launchpad.net/keystone/+spec/domain-quota-management-and-enforcement 18:41:12 there's two quota bp's in progress 18:41:16 they'll have to resolve their differences 18:41:22 dolphm: I think it is blocked because there are dependencies on eventlet in the rpc module of oslo. That's another thing I am working on in oslo for unified logging 18:41:25 one's from HP I think 18:41:39 lbragstad: ++ 18:42:32 this is the other one https://review.openstack.org/#/c/37545/ 18:42:37 quota storage 18:42:39 So I'm wondering if we should implement notifications on the current rpc stuff at least until the rpc api review has landed. Not sure when that is going to go in... 18:43:20 lbragstad: what's the current rpc stuff? is that different than oslo rpc? 18:43:21 lbragstad, what is "the current rpc stuff"?? 18:43:35 jinx 18:43:43 lbragstad: considering we're late to the notifications party already, i would think it'd be best to wait, but if you want to pursue it... 18:43:50 topol: bknudson sorry, right the current implemtation of the rpc module in Oslo-incubator 18:43:52 getting link 18:44:08 #link https://github.com/openstack/oslo-incubator/tree/master/openstack/common/rpc 18:44:16 dolphm, can we set aside a few minute to talke client issues 18:44:22 #link https://github.com/openstack/oslo-incubator/tree/master/openstack/common/notifier 18:44:22 at the end 18:44:38 ayoung: sure 18:45:38 my issue with the notifications stuff was that it was inherantly eventlet specific. I'm OK with us taking on some event deps so long as Keystone in Apache will continue to work in a non greenthread manner 18:46:07 entend dpes = "new eventlet dependencies" 18:46:11 ugh 18:46:19 event deps = "new eventlet dependencies" 18:46:28 ayoung: how do we show that? 18:46:30 try it? 18:46:38 bknudson, yes 18:46:58 bknudson, there is an open review for devstack support for Keystone running in HTTPD 18:47:05 that should take away some of the pain 18:47:14 lbragstad: so I think we know what we need to do? try it. 18:47:25 ayoung: have you ever thought about standing up apache as a reverse proxy to keystone? 18:47:28 bknudson: ok 18:47:42 that will require us to sync oslo to keystone 18:47:55 lbragstad: try it in a sandbox 18:48:05 (on your own system) 18:48:13 bknudson: yep 18:48:28 dolphm, "reverse" proxy meaning do SSL terminiation and stuff in httpd, and run keystone in eventlet? 18:48:37 dolphm, it has been done, there are some weird hacks around REMOTE_USER but it works 18:48:38 ayoung: yes to the first part 18:48:50 ayoung: and run keystone somewhere-else-it-doesnt-matter 18:49:17 why is that better than running keystone in HTTPD? 18:49:20 dolphm: what's the concern? run keystone-all by itself and have apache forward requests to it? 18:49:32 bknudson: i didn't say keystone-all, but sure 18:49:34 but it is better to just have it managed in the one place 18:49:41 i poked at running keystone in gunicorn yesterday 18:49:43 I thought the problem was keystone-all is problematic. 18:49:54 bknudson: i wasn't using keystone-all 18:50:03 don't you still have the security holes when running in reverse proxy mode? 18:50:17 topol, holes? 18:50:20 topol: do you know about some security holes? 18:50:25 topol: donuts? 18:50:58 so if keystone runs in apache we get all the benefits that Apache provides (SSl, etc) 18:50:59 #topic open discussion 18:51:00 haha 18:51:16 don't some of those go away in the other config? 18:51:17 topol: behind* apache is all that matters, i think 18:51:17 i wanted to raise the support of vw in non-keystone clients 18:51:32 v3? 18:51:36 vw? 18:51:48 topol: whether it's actually running via mod_wsgi, keystone-all, nginx+gunicorn, etc doesn't matter 18:51:49 Volkswagon? 18:51:50 bknudson: yes, v3 support in things like novaclient 18:51:51 so if the sandbox notifications work should we remove the bp that is a prereq for notification? 18:52:00 dolphm, need to verify that with the paranoid security folks 18:52:52 you guys aware of the KC changes to support pluggable auth? 18:53:10 dolphm: do we know the plan for getting v3 support in novaclient etc.? 18:53:12 like passing an auth object to the client 18:53:13 gyee: i haven't seen a reviwe yet 18:53:50 dolphm, I've thought about it. The short of it is that I think eventlet is a mismatch for Keystone, and working around it has proven problematic. I want to be able to remove eventlet from the equasion. I think the Apache benefits are, as your point out, mostly in doing better HTTP handling like SSL and Authentication. 18:53:57 henrynash: i'm not sure there's a hard plan anywhere :-/ getting v3 auth into keystone was a major step 18:54:01 yea, i like the strategy - my concern is we made him bring the auth plugins into keystone (where they belong), but how do we get the other clients to update keystone to the point where they can use those plugins? 18:54:20 henrynash: i think the next step is having keystoneclient own the options it wants other client to specify 18:54:24 we will need to do a global kc version bump to something not released yet 18:54:34 --os-user-domain-id, etc 18:54:44 so what are the steps 18:54:45 dolphm, https://review.openstack.org/#/c/36427 18:54:53 1. Make keystone client CLI work with the auth review 18:54:59 gyee: abandoned? 18:55:01 its trying to use the same mechanism as novaclient 18:55:16 ran out of time or decided not a good idea? 18:55:28 2. look at another client that already works with keystoneclient and make it auth clean. 18:55:31 the plugin should be common. 18:55:35 dolphm: when you mean own, you mean somehow do the parsing for those parameters? 18:55:41 bknudson, I was trying to figure out if its fundamentally different from the direction ayoung's going 18:55:42 jamielennox, is already working on makeing the auth_token middleware use requests 18:55:52 i think should be considered deprecated in favour of https://review.openstack.org/#/c/28043/ 18:56:18 jamielennox: that's a lot of code! 18:56:30 yea, but most of it is from oslo (or at least proposed) 18:56:46 henrynash: i'd like openstackclient, for example, to pass keystone a argparse parser, and have keystoneclient populate it with whatever options it expects 18:56:51 bknudson, no shit! 18:56:52 gyee, take a look at the reveiw that jamielennox posted. I think it handles the same things as your review. Alessio Ababilov's put a lot of effort into it, just submitted It to oslo first 18:57:00 but yes, and i think both subtly change how the client gets initiated 18:57:06 gyee +1 18:57:06 henrynash: i'm not sure that's the *best* way for keystoneclient to own that stuff, but it's an easy one 18:57:21 dolphm: understand your point 18:57:36 lets draw straws on who gets to review that 18:57:52 henrynash: if we can boil down the process to like 3 lines of boilerplate that other projects can include, we win 18:58:11 topol, I am going to be like termie, start that review with a -2 :) 18:58:15 dolphm: agreed…. 18:58:19 gyee, no you are not 18:59:21 I know termie is still alive because he "liked" one of my daughter's instagram photos. 1st time ever 18:59:25 gyee, work with Allesio on getting that sorted out. 18:59:36 i've had a look through, the code is pretty good as it has been through a dozen rounds of oslo already. It's just hard to say that it's doing everything the same and trying to figure out if it prevents us doing anything new 18:59:37 I think that you guys are headed in the same general direction 19:00:10 OK, times up 19:00:11 ayoung, I was half joking, just need to spend some time on it 19:00:30 * topol half joking... half 19:00:32 dolphm, you want to send out the feature freeze message? 19:01:07 http://paste.openstack.org/raw/41437/ 19:01:13 henrynash: ^ 19:01:46 dolphm, +1 19:01:49 dolphm: get the idea 19:02:00 https://blueprints.launchpad.net/python-keystoneclient/+spec/consolidate-cli-auth 19:02:02 dolphm: does it need the version? 19:02:10 oh, probably not 19:02:22 bknudson, probably at the packaging level, not here 19:02:33 bknudson: it would be up to keystoneclient to reach out to the auth url and find out what versions are available 19:02:34 for cli options, append anything to ^ 19:02:42 bknudson: and abstract that all away from both end users and other clients 19:03:12 how much code change in all the clients? 19:03:13 the goal being: never maintain auth code in other clients, own it in one client 19:03:22 topol: hopefully a lot of deletes 19:03:41 we're about to get kicked out 19:03:43 swift is always the oddball 19:03:44 ah 19:03:46 how good are we at getting them to update their client per our desires? 19:03:48 sorry guys! 19:03:50 #endmeeting