18:02:58 <morganfainberg> #startmeeting Keystone
18:02:58 <openstack> Meeting started Tue Jun  9 18:02:58 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:01 <gyee_> \o
18:03:02 <openstack> The meeting name has been set to 'keystone'
18:03:03 <morganfainberg> hey everyone!
18:03:20 <henrynash> the cores come rolli’ in….
18:03:21 <morganfainberg> so uhm. yeah lets get rolling
18:03:29 <morganfainberg> #topic Spec Proposal Freeze
18:03:36 <ayoung> Keep them dogies rollin Rawhide!
18:03:48 <morganfainberg> #info June 23 is SPF
18:04:02 <morganfainberg> Please post / review / etc specs
18:04:10 <henrynash> morganfainberg: and for this spec needs to approved, I assume?
18:04:14 <morganfainberg> yes.
18:04:15 <ayoung> morganfainberg, yeah...way too soon
18:04:16 <amakarov> wow, meeting!
18:04:30 <morganfainberg> anything post L1 will need a SPF-Exception
18:04:32 <morganfainberg> most should be easy
18:04:37 <bknudson> seems like posted should be good enough.
18:04:42 <ayoung> morganfainberg, We just have people starting to pay attention again post summit
18:04:48 <david8hu> 23rd is only 2 weeks away
18:04:55 <morganfainberg> bknudson: we can evaluate next meeting if we want to just say "posted by"
18:05:10 <dolphm> bknudson: posted and completely fleshed out* if we're going that route
18:05:19 <morganfainberg> bknudson: but please please please try and get the specs in at least the general form they should be merged in
18:05:20 <ayoung> we are going to get to the point where spec proposal freeze for P is before the N summit
18:05:28 <morganfainberg> we can worry about bikeshedding at that point
18:05:40 <morganfainberg> ayoung: hate to break it to you, but SPF for M is tomorrow.
18:05:41 <ayoung> so...yeah, posted
18:05:51 <ayoung> morganfainberg, I figured I had already missed it
18:05:55 <morganfainberg> ayoung:  :P
18:05:57 <morganfainberg> ok anyway
18:05:59 <samueldmq> lol ahh
18:06:18 <morganfainberg> Post the specs. review ones that are ready
18:06:21 <morganfainberg> lets land what we can
18:06:57 <browne> speaking of specs, do i need one for https://blueprints.launchpad.net/keystone/+spec/role-descriptions.  Its on the agenda
18:07:00 <morganfainberg> #action Next meeting discuss where we are on specs and handling the specs that are posted but not approved / don't look like they will land by L1
18:07:18 <morganfainberg> browne: i'll have an answer post meeting at the latest for you
18:07:35 <browne> morganfainberg: ok thanks
18:07:36 <morganfainberg> #topic Midcycle
18:07:39 <ayoung> OK...
18:07:40 <morganfainberg> #info Reminder that Keystone Midcycle is July 15-17. Send note to ayoung if you are attending.
18:07:46 <ayoung> So I need to get a head count
18:07:53 <ayoung> trackign on trello
18:08:02 <bknudson> I thought we had a lot more than 7
18:08:06 <morganfainberg> ayoung: I recommend using the wiki.
18:08:09 <dstanek> are we tracking what hotels people are going to?
18:08:19 <gyee_> henrynash, https://review.openstack.org/#/c/187045/
18:08:25 <ayoung> it *is* possible to get a parking pass, but only ask if you really really need it.
18:08:39 <dolphm> topol: ^
18:08:40 <ayoung> morganfainberg, I can do that
18:08:50 <morganfainberg> ayoung: easier since everyone already has access for the wiki
18:08:51 <ayoung> topol, is staying close enough to walk.
18:08:55 <henrynash> gyee: yep, I’ll respond to the comments
18:08:56 <morganfainberg> and we have a table for that
18:09:07 <ayoung> morganfainberg, OK  I'll do that
18:09:31 <morganfainberg> if we have someone who needs a parking pass, we can possibly have them pickup a group of people who otherwise would need a parking pass.
18:09:39 <morganfainberg> i expect to be staying ~walking distance
18:09:48 * morganfainberg hasn't booked hotel yet
18:09:49 <ayoung> I'd recommend that
18:09:52 <dstanek> ayoung: is there a close train stop?
18:09:56 <bknudson> I think it would be faster for me to walk than drive
18:10:09 <ayoung> if you need cheap housing, the dorms are avaialble, but need to know soon...they need at least 2 weeks lead time
18:10:22 <ayoung> dstanek, Green Line MBTA is right in front
18:10:48 <morganfainberg> #action morganfainberg to try and source sponsorship for a day's food from HP at MidCycle
18:10:50 <ayoung> dstanek, but depends on where you are staying how long it will take.
18:10:51 <dstanek> i have to look for a hotel now
18:11:05 <ayoung> hotel list is on trello as well
18:11:21 <bknudson> boston must be a popular place because I wasn't seeing a lot of hotels in our booking tool.
18:11:35 <morganfainberg> ayoung: make sure at least to put the trello link in the wiki for the midcycle
18:11:44 <dstanek> bknudson: not in ours either
18:11:52 <ayoung> morganfainberg, will do....looking for old Midcycle wiki links now
18:12:21 <morganfainberg> https://wiki.openstack.org/wiki/Sprints/KeystoneLibertySprint
18:12:50 <morganfainberg> ok we can continue midcycle info/updates offline
18:13:01 <morganfainberg> #topic Re-enable DB2 CI posting?
18:13:06 <morganfainberg> bknudson: o/
18:13:28 <bknudson> we have a team in china that has set up CI for DB
18:13:30 <bknudson> DB2
18:13:38 <bknudson> and they've been working on stabilizing it lately
18:13:39 <ayoung> #link https://wiki.openstack.org/wiki/Sprints/KeystoneLibertySprint
18:13:51 <bknudson> and they say it's stable now, so they asked if I could request turning it back on.
18:13:56 <morganfainberg> bknudson: looks good to me
18:13:59 <bknudson> and have it report on all changes in keystone master
18:14:15 <bknudson> non-voting of course...
18:14:16 <dolphm> bknudson: the concern before was that it was completely unmaintained when it starting failing, not that it didn't have a team behind it when it started
18:14:19 <bknudson> I don't think you can make it voting.
18:14:39 <morganfainberg> if you think it is stable / will remain so - and the logs adhere to the requirements for 3rd party CI i'm ok with it
18:14:52 <morganfainberg> but if it goes off the rails and no one is watching it, we will need to cut it out again
18:15:30 <morganfainberg> bknudson: i don't want it a voting job until it's shown it is stable for a bit [we can evaluate that later if we feel like it should be voting]
18:15:36 <morganfainberg> it can't be a gate job
18:15:41 <morganfainberg> but it could be a voting check job
18:15:42 <bknudson> I can't make any promises that the china team will be more responsive than last time.
18:15:43 <dolphm> bknudson: do we have an official contact person / mailing list for when it fails in the future?
18:15:52 <morganfainberg> dolphm: ++
18:15:56 <bknudson> y, the contact person is on the CI wiki page ...
18:16:03 <dolphm> last time it was like communicating with /dev/null
18:16:08 <morganfainberg> we can try it with the contact
18:16:47 <lbragstad> yanfengxi@cn.ibm.com
18:16:48 <morganfainberg> like i said, if it goes off the rails again - we'll have to have it no longer post and I wont be as open to re-enable reporting again
18:17:06 <lbragstad> bknudson: ^ I assume that's still the correct contact?
18:17:16 <bknudson> https://wiki.openstack.org/wiki/IBM/IBM_DB2_CI
18:17:20 <morganfainberg> but i'm ok with allowing it if you think it is currently stable. you know it better than I do.
18:17:26 <lbragstad> bknudson: do you know if they are in IRC?
18:17:45 <bknudson> I actually can't vouch for how stable it is.
18:18:08 <lbragstad> bknudson: how have they been verifying it?
18:18:12 <dstanek> bknudson: you're not selling this well
18:18:12 <bknudson> If you got any issues of this DB2-TEST CI, please contact "yanfengxi@cn.ibm.com"
18:18:25 <bknudson> ^ from the wiki
18:18:33 <dolphm> bknudson: it'd be nice if it posted that in gerrit comments when it failed
18:18:37 <dolphm> just sayin'
18:18:38 <bknudson> dstanek: this is why I'm not in sales.
18:18:40 <lbragstad> ++
18:19:02 <bknudson> I think the message it posts has a link to the wiki ?
18:19:06 <lbragstad> yanfengxi@cn.ibm.com should probably be the one pushing to have it turned back on :)
18:19:09 <bknudson> although I haven't seen a failure so I don't know.
18:19:34 <bknudson> yanfengxi@cn.ibm.com is pushing to have it turned back on... but the meeting time is not convenient for someone in beijing.
18:20:05 <dolphm> that's understandable
18:20:17 <dolphm> although an IRC nick would be nice to have on hand
18:20:47 <lbragstad> I'd be will to hop on at night and visit with them about it, if they want to meet in -keystone
18:21:28 <bknudson> I can definitely return with feedback and tell them to provide more info
18:22:10 <bknudson> or we can try to set up a time when they can present their own story about the stability of the system.
18:22:15 <morganfainberg> bknudson: sure.
18:22:27 <dolphm> maybe setup a daytime meeting for beijing in #openstack-keystone where we can follow up with questions sometime before the next keystone meeting?
18:22:43 <bknudson> I will do that.
18:23:35 <dolphm> 1 AM UTC is 9am in beijing, and 8pm for me in texas
18:23:37 <lbragstad> 10 am Beijing time is around 9 pm central
18:23:46 <lbragstad> dolphm: beat me to it
18:24:10 <bknudson> so try for some time at 8pm Central time?
18:24:16 <dolphm> bknudson: ++
18:24:18 <bknudson> some day
18:24:19 <lbragstad> works for me
18:24:28 <morganfainberg> if it's central thats easy for me to make it to
18:24:38 <morganfainberg> 6pm is normally [when i'm not on GMT+2]
18:24:49 <dolphm> morganfainberg: when do you get back to PST?
18:24:54 <morganfainberg> june 17
18:25:02 <dolphm> oh
18:25:17 <dolphm> you're probably closer to beijing time now lol
18:25:33 <morganfainberg> dolphm: it's 20:35 right now
18:25:35 <ayoung> OK...next item?
18:25:46 <dolphm> bknudson: setup a meeting! we'll be there
18:25:51 <morganfainberg> #topic Reseller Scope
18:26:05 <morganfainberg> raildo, htruta, rodrigods o/
18:26:12 <raildo> \o
18:26:15 <htruta_> o/
18:26:27 <raildo> I think many of you saw the thread in the mailing list about this subject. We have some ideas, from henrynash, ayoung and others keystone cores, to define how do handle with project name with the reseller implementation
18:26:53 <ayoung> jamielennox is not here...he wanted to punt on it
18:26:57 <raildo> (and how to get a project scoped token for this project)
18:27:03 <dolphm> ayoung: punt to what?
18:27:17 <morganfainberg> ayoung: i am a fan of what jamie said. keep the artifical project is unique in a domain requirement for now
18:27:25 <morganfainberg> so we can establish HMT workflows
18:27:26 <ayoung> dolphm, bascially say that you can only scope a token by project name if it was directly under the domain
18:27:29 <morganfainberg> and then loosen that up
18:27:38 <raildo> I think that the first questions that we need to answer is: should project name only be unique within parent project?
18:27:43 <ayoung> if you are doing anything deeper, scope by project ID
18:27:45 <morganfainberg> raildo: for now, yes.
18:27:55 <dolphm> ayoung: oh that's interesting
18:27:57 <morganfainberg> raildo: it's easier to loosen that than close it back up
18:28:08 <htruta_> ayoung had a proposal that: if a conflict happens, always give the token to the project
18:28:15 <ayoung> raildo, and we came up wiht the hack that to get the domain-as-project scoped token you pass in a project name of   ""
18:28:30 <htruta_> since we are not making it restricted only in the parents, it seems like a good approach
18:28:37 <henrynash> ayoung: no  you can scope to any project in a hierarcy
18:28:47 <ayoung> henrynash, not what I am saying
18:28:48 <dolphm> htruta_: like, scope to the smallest match?
18:28:58 <henrynash> ayuong: just have to allow is_domain = True/False in auth scope
18:29:10 <morganfainberg> dolphm: i worry about fancy matching breaking our current auth mechs
18:29:12 <rodrigods> henrynash, if we add is_domain to the request
18:29:16 <ayoung> henrynash, if you need a token scoped to the domain as-a-project, you can pass in domain_name="Blah"  projc_name = ""
18:29:20 <rodrigods> if want to loose the constraint later
18:29:25 <rodrigods> it won't work anymore
18:29:28 <htruta_> dolphm: having a is_domain project A and a non is_domain called A, requesting project scoped token to A, would return the project
18:30:07 <htruta_> ayoung ++
18:30:09 <morganfainberg> henrynash: i'd rather disallow a domain from getting a project scope"
18:30:24 <morganfainberg> henrynash: i really do not like the "is_domain" prospect
18:30:42 <dstanek> htruta_: i like that - i find it confusing that Project<is_domain=True> can act as a project and a domain
18:30:47 <dolphm> strange solution: since we require explicit role assignments on the project, we can drastically reduce the available matching scopes by filtering against the available role assignments? there are weird consequences of that, but it'd make for a nice user experience
18:30:51 <henrynash> morganfainberg: when domains are represented by projects, surely we need to allow them to get a project tokne to the project that is acting as a domain (if they want)
18:31:01 <morganfainberg> we still can collapse projects and domains into a single table to get the HMT heirarchy to be easier
18:31:08 <morganfainberg> rather than nasssty joins etc
18:31:27 <htruta_> morganfainberg: but wasn't the point of making the domain acting as a project to make it better to other services?
18:31:29 <ayoung> henrynash, that is exactly what I was proposing
18:31:34 <raildo> henrynash, ++
18:31:49 <ayoung> if both the domain and a project under it share a name, the project wins
18:31:58 <morganfainberg> htruta_: more so to make the hierarchy esier to manae
18:32:01 <morganfainberg> manage*
18:32:21 <ayoung> the domain name is only its name as a domain....it has no name as a project.  Kind of like unit "/"  for root directory
18:32:24 <rodrigods> ayoung, ++
18:32:30 <ayoung> unit-> unix
18:32:32 <htruta_> dstanek: actually, it does not remove the domain as a project capabaility... it only avoids it in case of conflict
18:32:58 <henrynash> ayoung: my divergence to that is that the I propose is_domain defaults to “False” in requests (auth scope of list projects)…unless it is explictly specified
18:33:02 <ayoung> "the domain as a project must not be named"
18:33:36 <rodrigods> henrynash, but is_domain=True won't work if we change the constraint to consider just the parent_id
18:33:39 <dstanek> ayoung: but how can that be true if you need to use it?
18:33:52 <ayoung> dstanek, you have to declare the domain name
18:33:55 <henrynash> rodigods: not sure i undestand that, sorry!
18:34:12 <dstanek> ayoung: i thought those is_domain projects can be used just like any other project
18:34:21 <htruta_> rodrigods means that if, in the future we want to make projects unique only below parents
18:34:27 <ayoung> dstanek, yep....they just won;'t have a"project" name...
18:34:34 <htruta_> we would need to drop the "is_domain" attribute from token
18:34:39 <htruta_> henrynash ^
18:34:42 <ayoung> dstanek, Or, we could say that their name is /
18:34:43 <dstanek> ayoung: so the end user will see the name and not be able to use it?
18:34:54 <rodrigods> htruta_, ++
18:34:55 <raildo> in resume, have some options:1- add a  is_domain=True/False flag in the token request and a project name will be unique in a domain 2- use a delimiter and inform the hierarchy name, like A.B.C, 3- handle with the name as a list like: ['A', 'B', 'C']
18:35:38 <ayoung> dstanek, think of it from the horizon perspective.  you do a list projects for user, and use the result ot make a dropdwon.  The dropdwon has the domain name:: project name
18:35:40 <morganfainberg> raildo: i think we need to use the heirarchy representation (or delimiter)
18:35:40 <henrynash> I believe in the future, the domain API will be deprecated…and everything we know about domains will be attributes of a project….hence introcuing the use of being able to do all domain actions via teh project API (by specifying the appropiate attributes) seems like thwe way to go
18:35:54 <ayoung> for the parent proejct it would just show the domain name, no project name
18:36:03 <rodrigods> morganfainberg, if we use the hierarchy representation why keep project names unique in a domain?
18:36:05 <ayoung> so  If I Had a redhat domain with a redhat p[roejct I would see
18:36:08 <ayoung> redhat::
18:36:11 <ayoung> redhat::redhat
18:36:12 <morganfainberg> ok so.. what if...
18:36:14 <morganfainberg> what if...
18:36:24 <morganfainberg> if you want to scope to the domain you use it's parent.
18:36:27 <raildo> rodrigods, morganfainberg yes, that is the question...
18:36:31 <morganfainberg> or no parent [if it's the root]
18:36:46 <ayoung> morganfainberg, does not really work
18:36:47 <morganfainberg> otherwise the project wins. since you've said "in this namespace"
18:36:52 <dstanek> morganfainberg: that's sort of what i was saying the other day
18:37:00 <morganfainberg> dstanek: yeah i think i'm coming around to it
18:37:04 <ayoung> morganfainberg, when requesting a token, we explicitly request a domain stanza for the project
18:37:18 <morganfainberg> a domain is in a domain
18:37:18 <ayoung> so all I am adding is that the root project has no explicit name
18:37:30 <morganfainberg> always [root being magical maybe]
18:37:30 <dstanek> iiuc the ambiguity is that the is_main and the project it contains point to the same id (maybe domain di) when doing the lookup
18:37:58 <ayoung> dstanek, scope by ID works already...it doesn't need the domain ID
18:38:05 <ayoung> what we need is a way for Horizon to show this to the end users
18:38:19 <morganfainberg> if you're scoping to a name of a domain you have to specify it's namespace
18:38:21 <htruta_> root is always an is_domain, btw
18:38:31 <ayoung> and just dropping the name is the least surprise
18:38:50 <morganfainberg> if you specify the domain and the name - it *must* be a project under that domain
18:38:53 <htruta_> morganfainberg: aren't domain names unique across the cloud?
18:39:02 <morganfainberg> always Namespace(project) where project is subordinate
18:39:07 <ayoung> morganfainberg, what you are saying makes sense to us. It will not make sense to end users
18:39:22 <morganfainberg> ayoung: we are bound by our current contract(s) though
18:39:27 <morganfainberg> and the way auth works
18:39:28 <ayoung> it means that default::redhat   will show up in my dropdown now
18:39:36 <ayoung> morganfainberg, this fits our current contract
18:39:40 <morganfainberg> ayoung: we can special case "root"
18:39:51 <morganfainberg> but yes, you will need to have the namespace
18:39:57 <ayoung> morganfainberg, that is, essentially, what I am saying, but saying that all domains are "root"
18:40:12 <rodrigods> ayoung, ++
18:40:14 <ayoung> morganfainberg, the domain name remains as the namespace
18:40:19 <morganfainberg> if domains are globally unique sure
18:40:21 <morganfainberg> thats easy
18:40:36 <morganfainberg> we can start with keeping globally unique names
18:40:42 <morganfainberg> and work to address that down the line
18:40:57 <morganfainberg> when we have things like the ability to version (microversion?) our api via flask
18:41:27 <morganfainberg> we don't want to try and do microversion(ing) now.
18:41:50 <ayoung> it would look like this http://paste.openstack.org/show/278495/
18:42:18 <ayoung> and that works now, since we don't allow the project name to be blank when creating a project
18:42:33 <henrynash> (needs to see the auth API spec of what we are really proposing )
18:43:28 <raildo> ayoung, I like this idea
18:43:30 <htruta_> ayoung: ++, once we have: 1) domains name unique across cloud and 2) projects name unique in a domain
18:43:36 <dstanek> ayoung: so as user outside of horizon i have to know that the project is special when using it? i can't just specify the name like to do now?
18:43:52 <rodrigods> dstanek, only if we have a conflict
18:44:08 <rodrigods> dstanek, a domain that contains a project with the same name
18:44:15 <dstanek> rodrigods: so the user has to know there is a conflict before submitting that request?
18:44:32 <rodrigods> dstanek, that's the confusing part of it :(
18:44:34 <dolphm> that's terribad
18:44:34 <htruta_> dstanek: if you are trying to use the is_domain project, yes
18:45:04 <gyee_> ++terribad
18:45:07 <morganfainberg> we have 15min
18:45:08 <rodrigods> let's use hierarchies and do not constraint project names in a domain
18:45:13 <raildo> dstanek, no, if we find a conflict we can raise a exception and ask to the user request in this way
18:45:14 <rodrigods> :)
18:45:18 <morganfainberg> 5 more min on this btw max
18:45:21 * morganfainberg is timeboxing it
18:45:29 * gyee_ is learning new engrish everyday
18:45:32 <ayoung> rodrigods, I think, No, not only for conflict
18:45:37 <dstanek> raildo: so no more automatically picking the project?
18:45:43 <ayoung> I think we say this is hiow you get domain scoped tokens across the board
18:45:45 <ayoung> er
18:45:53 <ayoung> proejct scoped tokens for domains
18:45:53 <htruta_> dstanek: i guess we are still picking the project
18:46:09 <gyee_> why not call it a domain?!
18:46:18 <htruta_> if you do specify the project name A in the domain id A, you'll get the project
18:46:19 <rodrigods> we need to figure this out because the L1 deadline
18:46:25 <henrynash> I’m sticking with proposing is_domain=True in the request if you want the project that is acting as the domain, otherwise it is ALWAYS a proejct that is not acting as a domain
18:46:28 <bknudson> we could call them tenants
18:46:32 <dstanek> htruta_: so the user just wouldn't know that they are getting the wrong thing?
18:46:42 <rodrigods> bknudson, lol
18:47:00 <gyee_> bknudson, hey now
18:47:31 <rodrigods> i liked dstanek's idea of having "/A/B/C"
18:47:32 <htruta_> dstanek: you mean, in a existing deploy that will be migrated?
18:48:01 <dstanek> will the user always know that they are asking for a project vs. a project<is_domain=True>?
18:48:08 <htruta_> if so, the answer is no, once if we get the token in the same way we do today, we'll get the regular project
18:48:24 <dolphm> we could also just not support names deeper than the top two levels in the hierarchy.
18:48:56 <henrynash> dolphm: ha!
18:49:02 <dstanek> i was hoping that is_domain projects would only act as domains name not projects - this issue would be way easier
18:49:15 <gyee_> dolphm, ftw!
18:49:59 <morganfainberg> dolphm: not a bad idea
18:50:03 <htruta_> dstanek: if we do have a conflict, and the user passes the project name, he'll be able to get the token to the project the same way he does today
18:50:10 <gyee_> ayoung, I was going to suggest LDAP DN style
18:50:14 <ayoung> gyee_, this is your fault for not listening to me, and my fault for not making you, back when you were pushing domains.  I said "why don't we just make projects hierarchical?"
18:50:15 <gyee_> but I thought better of it
18:50:19 <htruta_> that means, the token goes to the usual project
18:50:19 <ayoung> gyee_, no you were not
18:50:47 <gyee_> ayoung, because there's a clear difference between projects and domains
18:50:57 <dstanek> htruta_: i think is there is an ambiguity we have to tell the user and can't just give then something
18:51:02 <morganfainberg> ok
18:51:08 <ayoung> both  "/A/B/C"  and ["A","B","C"] should work
18:51:09 <morganfainberg> lets continue this in -keystone
18:51:17 <morganfainberg> we have another couple topics to hit
18:51:36 <henrynash> dstanek: I guess that is what I am suggesting….project request via out APIs assume is-domain=False unless you explicitly specify otherwise…e.g. Get /projects woud not shown and is_domain projects, unless you did GET /projects?is_domain=True
18:51:53 <morganfainberg> please simmer on what has been tossed out as a suggestion
18:52:12 <henrynash> (e.g. Get /projects woud not show any is_domain projects, unless you did GET /projects?is_domain=True)
18:52:12 <morganfainberg> i think the discussion has been good and presenting some interesting ideas.
18:52:34 <raildo> morganfainberg, sure
18:52:56 <morganfainberg> #topic  Handling auth plugins that uses other auth plugins
18:53:02 * gyee_ is trying to figure out how to turn a goose into a duck
18:53:12 <morganfainberg> rodrigods, marekd o/
18:53:19 <morganfainberg> since marek isn't here we can defer
18:53:21 <morganfainberg> if needed
18:53:30 <bknudson> I assume this means auth plugins for keystoneauth and not auth plugins for keystone
18:53:34 <rodrigods> I synced with him prior the meeting
18:53:40 <rodrigods> bknudson, yes
18:53:47 <ayoung> I wonder if what he means is that we really want to remove X509 and JKerberos from auth plugins
18:53:50 <rodrigods> so... in k2k auth plugin we need to be logged in two clouds at the same time: local cloud and remote cloud. So we are building a plugin that uses another plugin: https://review.openstack.org/#/c/188581/
18:53:56 <ayoung> and make them factes we enable on the session
18:54:17 <bknudson> how does the library know which plugin to use?
18:54:22 <rodrigods> we want to figure out how to pass this "extra" plugin to OSC so it will be able to build the plugins correctly.
18:54:32 <rodrigods> bknudson, that's the question :)
18:54:42 <ayoung> even big plugins have little plugins upon their backs to bitem
18:54:57 <rodrigods> marekd proposal (which makes much sense to me) is something like: openstack --os-auth-plugin=password --project-id=<local_project> --os-remote-auth-plugin --os-remote-projectid=<remote_plugin> remote token issue/remote server list is a good UX, so we are basically ties to a local cloud and with command like remote we are bursting.
18:55:09 <bknudson> it would be based on the region?
18:55:21 <gyee_> what is a region?
18:55:27 <rodrigods> region?
18:55:38 <rodrigods> it is based in the service_provider
18:56:04 <gyee_> lets get some consensus on the meaning of region
18:56:45 <rodrigods> region is a set of openstack services, service_provider is a remote trusted cloud
18:57:07 <rodrigods> which may have several regions as well
18:57:29 <gyee_> but IIRC, that's not how our service catalog says
18:57:41 <gyee_> not how Horizon is using it
18:57:48 <rodrigods> service providers aren't listed inside the catalog
18:57:51 <bknudson> the openstack command will be something like openstack server create , right?
18:58:04 <rodrigods> bknudson, yes
18:58:13 <bknudson> so how does it know that you're server is on local cloud or remote cloud?
18:58:29 <rodrigods> bknudson, we right now can specify plugins dinamically
18:58:36 <gyee_> bknudson, the namespace idea got me thinking, actually
18:58:38 <rodrigods> so if we also specify a "remote-auth-plugin"
18:58:43 <bknudson> I'm not talking about the auth plugin here.
18:58:48 <bknudson> this is after the auth plugin.
18:58:49 <morganfainberg> 2m
18:58:56 <bknudson> how does it know where to send the boot request?
18:59:05 <bknudson> isn't that the region?
18:59:29 <bknudson> after it gets the token
18:59:46 <rodrigods> bknudson, the remote cloud token contains its regions
19:00:21 <bknudson> how does the openstack command know what the remote cloud is?
19:00:28 <dolphm> bknudson: you go to talk to the remote cloud the entire time
19:00:36 <rodrigods> dolphm, ++
19:00:44 <dolphm> bknudson: service providers are in the token resopnse, but not in the catalog exactly
19:00:44 <bknudson> except for the first request which goes to local keystone
19:01:14 <morganfainberg> ok that is time
19:01:16 <dstanek> ... over time
19:01:17 <morganfainberg> please move this to -keystone
19:01:22 <morganfainberg> thanks all
19:01:25 <rodrigods> ok, thanks!
19:01:34 <morganfainberg> browne will discuss in -keystone
19:01:35 <morganfainberg> #endmeeting