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