18:05:03 <morganfainberg> #startmeeting Keystone
18:05:03 <openstack`> Meeting started Tue Jan 27 18:05:03 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:04 <openstack`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:05:06 <openstack`> The meeting name has been set to 'keystone'
18:05:42 <morganfainberg> hm, jeblair ^ is that someone camping the name? why openstack is named openstack` ?
18:05:58 <morganfainberg> anyway
18:06:03 <morganfainberg> Hi! welcome back
18:06:08 <morganfainberg> post mid cycle
18:06:32 <angelamolock> is that better :)
18:06:35 <morganfainberg> aha
18:06:54 <morganfainberg> so we have lots of things to go over
18:07:07 <morganfainberg> but for the most part if the patch isn't in gate this week it wont land for k2
18:07:24 <morganfainberg> so review code for BPs and Bugs for this milestone
18:07:40 <morganfainberg> #link https://launchpad.net/keystone/+milestone/kilo-2
18:07:54 <morganfainberg> so here we go
18:08:10 <morganfainberg> #topic The best way to solve name clashing in domain -> project migration.
18:08:16 <morganfainberg> raildo o/
18:08:20 <raildo> o/
18:08:37 <raildo> In the reseller spec we are proposing that a domain will be a project with some more features( user and groups managemnt). so when hen creating a domain, keystone will also create a project	that has the same id.
18:09:18 <raildo> and we a proposing for all existing domains, a sql migration will create a project with an id	that matches the domain_id, but we have a problem in this migration. We can find some clashing names between domains and project, we can't change the domain name in this migration because we have domain specific config file that use this domain name.
18:09:45 <raildo> So the question is: What is the best way to solve the clashing name problem in the domains sql migration?
18:10:01 <rodrigods> might have domain-specific files using the name
18:10:05 <henrynash_> raildo: (well, we *might* have domain specifc config files if the cloud provider is using that feature)
18:10:08 <morganfainberg> well 2 things. duplicating data in the project table is probably wrong.
18:10:16 <atiwari> I think we have agreed to migrate all domain to project
18:10:28 <atiwari> all existing one
18:10:42 <morganfainberg> and 2: the "domain" doesn't own itself in it's project list, so there should be no name-constraint issues
18:10:44 <dolphm> If namespacing is preserved, what's the scenario where a conflict can be introduced?
18:11:16 <rodrigods> morganfainberg, 2: it doesn't?
18:11:23 <morganfainberg> names are unique within a domian, no conflict can occur if you're not adding the "domain-project" to an already existing domain [since domains aren't nested no conflicts]
18:11:31 <morganfainberg> aren't nested today
18:11:34 <raildo> dolphm, maybe if we can get a token for a domain or a project, with the same name?
18:11:47 <morganfainberg> rodrigods, if i ask what projects are in domain X, does domain X end up in that list? i think not
18:11:59 <morganfainberg> since domain X is not in itself a project within the domain.
18:12:14 <rodrigods> morganfainberg, I thought they would be returned
18:12:25 <rodrigods> since they are just a project with the domain feature
18:12:48 <morganfainberg> rodrigods, ok but then the domain-project X doesn't show up under it's parent's project list?
18:13:04 <dolphm> but, a project is not a child of itself
18:13:04 <Haneef> What is there is an existing installation with project name = domain name?
18:13:05 <rodrigods> morganfainberg, it appears in both lists?
18:13:16 <morganfainberg> rodrigods, no a project is not a child of itself
18:13:27 <rodrigods> morganfainberg, ok, didn't get right the question
18:13:33 <morganfainberg> dolphm, beat me to it ;)
18:13:36 <dolphm> haneef: namespacing should be preserved, so it doesnt matter
18:13:56 <henrynash_> morganfainbeg: that was the tack I was on (and if that were true, then we don’t have a clashing issue)….it depends with the project that represents a domain is a fully fledged project in its own right
18:14:28 <dolphm> henrynash_: as opposed to..?
18:14:38 <morganfainberg> henrynash_, it needs to be a fully fledged project, not sure what it would be otherwise
18:14:55 <morganfainberg> but that doesn't change the namespace
18:15:10 <henrynash_> morgainberg: so if it IS a fully feldged project, how come it’s not returned in a project list?
18:15:13 <rodrigods> morganfainberg, root projects are always domains?
18:15:18 <rodrigods> right?
18:15:19 <morganfainberg> henrynash_, becasue it isn't a child of itself.
18:15:30 <morganfainberg> rodrigods, yes.
18:15:33 <raildo> rodrigods, right;
18:16:23 <henrynash_> morganfainberg: so I can get_project on it……but not list it (if my only permission visibility is my domain)
18:16:45 <morganfainberg> henrynash_, if you ask for projects in domain X, domain X does not itself end up in that list
18:17:22 <henrynash_> morganfainberg: agreed…this is a good conversation, since I’ve been arguing your position up to now!
18:17:25 <morganfainberg> henrynash_, the same as it works today.
18:17:29 <bknudson> if you ask for projects in project X, project X does not itself end up in that list
18:17:44 <morganfainberg> correct
18:18:09 <rodrigods> morganfainberg, ok... imagine the following hierarchy
18:18:13 <bknudson> can I have a project named X in project X?
18:18:39 <morganfainberg> bknudson, yep, same reason it works today with domains, but you cannot have 2 projects named X in the parent X
18:18:47 <henrynash_> morganfainberg: so my proposal earlier this week was that we could indeed avoid any name clashes since the uniquness of the project table would be: (‘name’, ‘domain_id’, “domain-ness-flag’)
18:18:52 <morganfainberg> it can be X all the way down.
18:19:28 <bknudson> -- only if the project is a domain.
18:19:34 <morganfainberg> bknudson, sure.
18:19:57 <jamielennox> i don't think you need the domain-ness-flag as part of that unique constraint
18:20:14 <raildo> henrynash_, and I liked this proposal :)
18:20:21 <morganfainberg> jamielennox, yeah i think you're right
18:20:31 <rodrigods> why do we need the domain-ness flag and domain_id fields at all?
18:20:47 <rodrigods> ahh, domain-ness flag for domains that aren't root
18:20:48 <jamielennox> rodrigods: because a name is only unique within it's parent
18:20:49 <rodrigods> right?
18:20:58 <raildo> maybe we can remove the domain-ness flag
18:21:05 <morganfainberg> rodrigods, even if they are root, they need the flag
18:21:12 <morganfainberg> it is for compat with v3 api, what are my domains
18:21:16 <morganfainberg> get_domains
18:21:20 <morganfainberg> needs to return soemthing sane
18:21:33 <rodrigods> morganfainberg, if they are root, they are domains (just see if they parent_id=None)
18:21:49 <jamielennox> morganfainberg: are we going to flatten that out in response?
18:21:50 <henrynash_> so we need to be able to store a project named “Test” in domain “Test”…so something must differentiate between the two
18:22:00 <jamielennox> henrynash_: parent_id
18:22:07 <morganfainberg> jamielennox, i think the standard v3 call only returns top-level
18:22:12 <jamielennox> morganfainberg: ++
18:22:29 <morganfainberg> rodrigods, but parent_id would be set if a domain X was under domain Y
18:22:30 <morganfainberg> both are domains
18:22:38 <morganfainberg> don't rely on parent_id being unset
18:22:55 <morganfainberg> domain-flag is still going to be needed to limit things such as tying an idp to a domain etc.
18:22:56 <rodrigods> morganfainberg, true, that was before I realized why we need the domain-ness flag
18:23:02 <jamielennox> morganfainberg: but in which case do we need the flag at all or is the top level of the tree always domains?
18:23:18 <morganfainberg> jamielennox, top of the tree is domains, but domains can be nested under domains
18:23:30 <henrynash_> don’t we need the flag on every project entry that is a domain?
18:23:31 <rodrigods> ++
18:23:33 <jamielennox> right - but do we need the flag further down
18:23:51 <morganfainberg> jamielennox, lets keep it consistent and always use the flag for a domain
18:23:56 <morganfainberg> jamielennox, even at the top
18:23:58 <jamielennox> henrynash_: that was the decision from summit - it's early and i'm trying to wrap my head around it again
18:24:00 * topol we can afford the bytes lets use the flag :-)
18:24:12 <henrynash_> jamielennox:….otherwise how do you know which child is a proejct vs a domain
18:24:31 <rodrigods> so we are going to drop the domain_id column ?
18:24:36 <morganfainberg> rodrigods, no.
18:24:40 <morganfainberg> rodrigods, you can't
18:24:43 <jamielennox> henrynash_: beyond compatibility with GET /v3/domains do we care?
18:24:50 <bknudson> actually allowing NULL for the field will cost a byte
18:24:56 <dolphm> morganfainberg: (in the backend you can - it's just an implementation detail)
18:25:10 <rodrigods> morganfainberg, ah, ok it is an easy way to figure out which is some project's domain without the need to find the root
18:25:13 <bknudson> a byte per row
18:25:18 <morganfainberg> dolphm, we could have a separate table but eh.
18:25:32 <morganfainberg> rodrigods, you still need to tie a project to it's domain.
18:25:40 <morganfainberg> or a domain to it's parent domain
18:25:56 <rodrigods> ++
18:25:57 <morganfainberg> where parent_id may match domain_id in that latter case, but make the lookups consistent
18:26:11 <morganfainberg> and nullable domain_id makes sense for top-level projects
18:26:22 <morganfainberg> or root domains
18:26:28 <raildo> morganfainberg, ++
18:26:37 <henrynash_> the only (minor) question I had was whether that null domain_id WAS teh domain_ness flag
18:26:50 <morganfainberg> henrynash_, i think not.
18:26:59 <morganfainberg> henrynash_, make the is_domain flag explicit
18:27:01 <rodrigods> henrynash_, because the domains hierarchy
18:27:03 <samueldmq> henrynash_, no, we need domain-ness flag for subdomainss
18:27:09 <henrynash_> and I’m absolutelyy fine with that
18:27:12 <bknudson> if the projects domain id matches the project id then it's a domain.
18:27:28 <rodrigods> bknudson, can't be true for subdomains
18:27:42 <gyee> if it quack like a duck, then it must be a duck
18:28:05 <samueldmq> bknudson, think it works
18:28:05 <dolphm> wait, we're not inventing new project IDs for every existing domain, are we?
18:28:15 <jamielennox> gyee: you're a duck
18:28:24 <morganfainberg> dolphm, no we can't
18:28:25 <gyee> quack, quack
18:28:26 <samueldmq> bknudson, and for subdomains we use the parent_id as usual
18:28:27 <morganfainberg> dolphm, domain_id -> project_id
18:28:31 <dolphm> ++
18:28:38 <morganfainberg> the chance for collision should be *very* small
18:28:50 <dolphm> i'm willing to accept the risk
18:29:02 <rodrigods> dolphm, \o/
18:29:05 <bknudson> When it fails I'll tell them dolphm will fix it.
18:29:06 <morganfainberg> if there is a collision there there is nothing programatic we can do, operator will need to handle because "which one wins" isn't a quest i want to answer
18:29:25 <morganfainberg> some cases project should win. some cases domain should.
18:29:41 <raildo> morganfainberg, yes, and if happens we can change the domain_id and update every user, group and project to point to this domain, but as you say, this chance is really very small
18:29:54 <dolphm> morganfainberg: you're getting way too edge casey :P
18:30:08 <morganfainberg> dolphm, it should be a near zero risk
18:30:31 <dstanek> domain and project ids are specified by the end user right? they are not guid
18:30:34 <morganfainberg> dolphm, which means... i don't think we need to answer - just protect against it and tell the operator what happened if it breaks
18:30:42 <morganfainberg> dstanek, uuid4
18:30:46 <rodrigods> dstanek, uuids
18:31:00 <samueldmq> morganfainberg, it's the same case to create a new project and get an existing id from the ids generator
18:31:00 <morganfainberg> in oooooold deployments project could be set by the user
18:31:07 <morganfainberg> project_id
18:31:12 <morganfainberg> like... diablo and essex i think
18:31:13 <rodrigods> so...
18:31:20 <rodrigods> we don't care about name clashing
18:31:25 <rodrigods> but we should add a new constraint
18:31:25 <morganfainberg> but domains have always been uuid
18:31:27 <rodrigods> which will be...
18:31:52 <dstanek> hmmm...i thought we used ids if provided and if not provided then generated
18:32:01 <dolphm> "the extinction of all life on earth will occur long before you have a collision, even on a version 4 UUID"
18:32:03 <morganfainberg> dstanek, in most cases we run ._ensure_unique_id
18:32:18 <morganfainberg> dstanek, which replaces with uuid4
18:32:35 <morganfainberg> anyway
18:32:37 <dstanek> morganfainberg: i'm thinking v2 projects - other seem fine
18:33:02 <morganfainberg> ok we need to move on
18:33:04 <bknudson> a 'default' project / domain will need to be created.
18:33:06 <morganfainberg> lots to cover.
18:33:17 <morganfainberg> we can discuss this more in -keystone and in review
18:33:26 <dolphm> morganfainberg: even in diablo, i think we just used str(uuid4) instead of .hex
18:33:44 <dolphm> and eeearly diablo used auto inc ints for tenant IDs
18:33:48 <morganfainberg> #topic IDP and relationship with domains and projects-that-are-domains
18:33:54 <morganfainberg> ayoung, raildo o/
18:34:23 <rodrigods> different spec than reseller, right? ^
18:34:30 <raildo> Idp are the domain's container(or should be) and now that we are changing how the domain will works, ayoung have a concern about that, maybe we need to change something in this implementation.
18:34:40 <raildo> So I think that this discussion is out of scope of the reseller spec, but we really need to define better this relationship between Idp and project domain-ness (domain).
18:34:54 <morganfainberg> raildo, i think we covered this at the mid-cycle
18:35:03 <raildo> morganfainberg, great
18:35:19 <raildo> I just don't know the answers :)
18:35:29 <morganfainberg> an IDP can be tied to a domain. which means that users from that IDP can be mapped to that domain's groups (and only that idp's users)
18:35:33 <gyee> IdP is indirectly tied to domain via group mapping, but that'll change with directly user mapping
18:35:47 <morganfainberg> if a domain doesn't not have a relationship to the domain, any idp can map to the groups (as we allow today)
18:36:02 <morganfainberg> this also opens the door to directly map federated users to an exissting user in keystone
18:36:05 <morganfainberg> same restriction
18:36:39 <rodrigods> marekd's spec?
18:36:47 <raildo> morganfainberg, great, so I  think that I don't need to explain nothing about that in the reseller spec, right?
18:36:51 <morganfainberg> i think marked has a spec.
18:36:52 <rodrigods> https://review.openstack.org/#/c/149071/
18:37:01 <dolphm> morganfainberg: many federated users mapping to a single identity is going to be a common use case
18:37:02 <rodrigods> great
18:37:05 <morganfainberg> raildo, yep should have no impact on reseller directly
18:37:27 <raildo> morganfainberg, ok, thanks :)
18:37:29 <morganfainberg> dolphm, we can always loosen the restriction of number of IDPs to a domain
18:37:49 <dolphm> morganfainberg: ++
18:37:50 <morganfainberg> dolphm, but we started with 1 idp per domain to make sure we get it right. iirc
18:38:00 <morganfainberg> ok next topic
18:38:01 <gyee> sounds reasonable
18:38:02 <dolphm> yep
18:38:13 <morganfainberg> #topic Review Client Release Blockers - ETA on Release Feb 1
18:38:16 <morganfainberg> jamielennox, o/
18:38:24 <gyee> morganfainberg, but conversely an IdP can map to multiple domains right?
18:38:24 <morganfainberg> this also applies to keystonemiddleware
18:38:38 <morganfainberg> gyee, yes. no restriction there [today's usecase]
18:38:42 <jamielennox> right - so we want to bump keystoneclient and keystonemiddleware up to a 1 month release cycle
18:38:48 <gyee> sounds good
18:38:50 <jamielennox> so at the start of every month we do a release of both
18:39:23 <jamielennox> this means that people need to get back into doing client reviews as the first one of these is planned for 3 days time
18:39:24 <bknudson> why not weekly?
18:39:48 <rodrigods> \o/ have two changes in the client
18:39:49 <morganfainberg> jamielennox, the only exception is RC for the named release there may be an extra release in there or a late release - so we have a clear "this release is the one we released along side of the named openstack release"
18:39:55 <rodrigods> to implement basic HMT handling
18:39:58 <jamielennox> bknudson: because no one will take me seriously when i push them for reviews every week
18:40:09 <jamielennox> morganfainberg: sure
18:40:19 <bknudson> I didn't realize we were waiting for release boundaries to do reviews.
18:40:34 <gyee> jamielennox, are you doing another rev on this one? https://review.openstack.org/#/c/149071/
18:40:38 <samueldmq> bknudson, ++
18:40:50 <morganfainberg> bknudson, we aren't really. just ksc has been slower so this is more of a lets do more consistent releases - this one being the bigger one since we have some stuff backed up
18:40:56 <dolphm> bknudson: ++
18:41:03 <jamielennox> bknudson: it's partially to just increase the cadence rather than wait for some big feature, but also to set goals for each release
18:41:05 <morganfainberg> bknudson, if there is no new code, no release is needed
18:41:21 <jamielennox> there is new code ....
18:41:39 <jamielennox> and much more stuck in reveiw
18:41:42 <morganfainberg> jamielennox, there may be a month there isn't. it is unlikely but we're not releasing for the sake of releasing :P
18:41:50 <dolphm> conversely, if there is a high priority bug fix, it should be released immediately instead of waiting for a scheduled release
18:41:55 <morganfainberg> dolphm, always
18:41:59 <jamielennox> dolphm: ++
18:42:22 <jamielennox> morganfainberg: i'm looking forward to that time
18:42:27 <gyee> is there a way to query reviews based on bug priority?
18:42:35 <gyee> maybe using dolphm's next-review?
18:42:41 <morganfainberg> gyee, look at LP, next-review, bugday
18:42:48 <morganfainberg> gyee, plenty of options
18:42:48 <bknudson> There's 66 open reviews in python-keystoneclient
18:42:49 <jamielennox> anyway - there are a bunch of things that have yet to see review in client that have been around since december
18:42:51 <gyee> k
18:42:56 <dolphm> gyee: http://status.openstack.org/reviews/
18:43:05 <jamielennox> major ones are marked in the gist in the channel home pages
18:43:20 <gyee> dolphm, ah, thank
18:43:30 <jamielennox> i'll be around for the next few hours (and in general) if anyone wants to dicuss any of them
18:43:33 <morganfainberg> so, review code, review more code, please review code
18:43:47 <gyee> yes, yes, yes
18:43:47 <bknudson> I don't want to have to check all sorts of places for reviews... we've already got launchpad with the bugs and blueprints
18:44:13 <morganfainberg> bknudson, the only reason to look beyond lp and review.o.o is if you want different sorting metrics
18:44:49 <morganfainberg> need to keep moving here.
18:44:57 <morganfainberg> #topic Domain roles APIs addition
18:44:59 <rodrigods> https://review.openstack.org/#/c/115770/ is almost in the bottom =(
18:45:06 <dolphm> Reviews Guarantee Citizenship
18:45:06 <samueldmq> o/
18:45:08 <morganfainberg> henrynash_, samueldmq, o/
18:45:13 <samueldmq> just a bit of context ...
18:45:23 <gyee> dolphm, nice :)
18:45:23 <samueldmq> a domain role is a list of one or more roles and/or other domain roles, and is name-spaced to a domain
18:45:37 <samueldmq> domain roles can be used as part of an assignment, in the same was as you can assign a global role, it's proposed at #link https://review.openstack.org/#/c/133855
18:45:46 <samueldmq> and I think the general idea is agreed over the community, right?
18:46:07 <samueldmq> but regarding the API changes, #link https://review.openstack.org/#/c/139531
18:46:12 <samueldmq> i) we need a new CRUD for domain-roles, making possible to create and handle domain-role members
18:46:20 <samueldmq> this first point is a requirement, as it is a new entity
18:46:26 <samueldmq> ii) to use a domain-role wherever we use a global role, we can create new API for handling assignments or reuse the existent ones for global roles
18:46:39 <gyee> samueldmq, only issue I have with domain roles is to explain to people the difference between roles and domain roles
18:46:52 <samueldmq> for instance, add PUT /projects/{project_id}/groups/{group_id}/domain_roles/{domain_role_id}  in addition to PUT /projects/{project_id}/groups/{group_id}/roles/{role_id}
18:46:55 <gyee> people = support, customers, doc writers, etc
18:47:04 <stevemar> gyee, ++
18:47:18 <stevemar> i have enough trouble explaining roles
18:47:37 <samueldmq> well, henrynash_ may correct me if I'm wrong, domain roles will be scoped to domains and then used by domain admins
18:47:43 <Haneef> gyee: previous name role_groups was better
18:47:55 <gyee> yes
18:48:08 <henrynash_> gyee, stevemar: domain_roles are the customer-centric roles that domain admins can create, that mean something to THEIR customers….and typically domain admins haev no ability to change the policy file
18:48:10 <samueldmq> that allow domain admins  to create roles with custom names ..
18:48:45 <dolphm> if we don't domains anymore, these just become projects roles which will be super awesome to disambiguate from "roles"
18:49:03 <gyee> henrynash_, but we have have ducks!
18:49:06 <gyee> sorry I mean roles
18:49:15 <samueldmq> dolphm, ++
18:49:49 <morganfainberg> dolphm, ++
18:49:56 <henrynash_> gyee: how does a domain_admin who works for customer X which is being hosted on a public cloud get to makea global role have impact on policy
18:50:08 <gyee> can project roles inherit to other projects?
18:50:20 <morganfainberg> henrynash_, *handwavey, timey, wimey, future*
18:50:38 <henrynash_> morganfainberg: really?
18:50:40 <dolphm> morganfainberg: sad ++
18:50:50 <samueldmq> gyee, yes
18:50:54 <morganfainberg> dolphm, yeah i know
18:50:56 <morganfainberg> dynamic policy
18:51:00 <samueldmq> gyee, you can use it as the same as global roles
18:51:05 <morganfainberg> that is how people change policy who are not global.
18:51:11 <morganfainberg> perproject/perdomain/perwhatever
18:51:19 <morganfainberg> ayoung has a bunch of specs on it ;)
18:51:20 <raildo> gyee, yes, we implementing this for HMT
18:51:31 <dolphm> henrynash_: i think domain admins should be able to define their own additional policy (morgan's dynamic policy) first, and then it makes much more sense to discuss additional role definitions
18:51:35 <lbragstad> ~9 minutes left
18:51:41 <gyee> global roles? I haven't heard of that since KSL :)
18:52:00 <bknudson> gyee: you haven't heard of the admin role?
18:52:14 <morganfainberg> ok we are strapped for time
18:52:15 <henrynash_> morganfainberg, dolphm: so this is something we agreed at the summit, no?
18:52:29 <morganfainberg> henrynash_, pretty much-ish just inverting the priority
18:52:29 <gyee> bknudson, but it's not "global roles"
18:52:41 <gyee> I am sure dolphm can fill you in on the history of "global roles"
18:52:47 <morganfainberg> do dynamic policy then defined roles vs inverse
18:53:00 <morganfainberg> ok we can do history lessons later
18:53:04 <morganfainberg> we need to move on
18:53:13 <morganfainberg> #topic Functional testing changes
18:53:16 <morganfainberg> dstanek, o/
18:53:33 <dstanek> this should be quick
18:53:41 <morganfainberg> (skipping role inheritance, sorry, we'll come back to it if we have time at the end)
18:53:44 <dstanek> i wanted to show everyone this: http://paste.openstack.org/show/162858/
18:53:56 <samueldmq> morganfainberg, np
18:54:06 <dstanek> and just make sure the side effects were acceptable so i can let others know
18:54:13 <bknudson> whew, it's safe for work.
18:54:33 <dstanek> bknudson: next one might not be
18:54:35 <morganfainberg> dstanek, i think that is ok.
18:54:55 <morganfainberg> dstanek, since we can "not move" until we're sure coverage is comparable
18:55:20 <gyee> dstanek, I would love to test it out with the SSL authz stuff
18:55:28 <bknudson> what's needed for "our side" ?
18:55:39 <dstanek> yep, ok - it's very similar to the message i had at the mid-cycle, but wanted to make it explicit
18:55:45 <bknudson> anything need to be reviewed?
18:55:53 <gyee> only problem is how to get FreeIPA in there to give me some certs
18:56:05 <jamielennox> gyee: do you have a client plugin side for that?
18:56:06 <dstanek> bknudson: the second part of the spec we ripped in half and then updating the changeset to match
18:56:35 <morganfainberg> dstanek, i chatted with jeblair about this and gave him a heads up we'd track him down for some specifics
18:56:41 <dstanek> bknudson: there are a few things i just pushed, but nothing critical - those were config updates
18:56:42 <gyee> jamielennox, for SSL authz, we just need a dummy adaptor for token_auth
18:56:56 <morganfainberg> dstanek, of what we can/can't put in the keystone repo etc
18:57:00 <morganfainberg> vs. devstack
18:57:07 <jamielennox> dummy adapter?
18:57:08 <morganfainberg> vs. *other places*
18:57:26 <morganfainberg> gyee, we're strapped for time, IPA can be discussed outside of this meeting.
18:57:28 <lbragstad> bknudson: dstanek #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/functional-testing,n,z
18:57:29 <lbragstad> ?
18:57:34 <jamielennox> gyee: oh - you just want to fake out the auth part and you make the session handle the certs?
18:57:34 <morganfainberg> jamielennox, cc ^
18:57:47 <gyee> jamielennox, precisely
18:57:54 <gyee> since there are no tokens involved
18:57:55 <bknudson> merge conflict as soon as it was posted.
18:57:59 <morganfainberg> ok so we're going to move on here
18:58:05 <morganfainberg> i want to get breton his couple minutes
18:58:11 <morganfainberg> #topic Alembic Status and Blockers
18:58:18 <morganfainberg> breton, o/
18:58:24 <breton> Though the spec is not yet accepted, I've almost finished Alembic stuff. It can be found here https://review.openstack.org/#/c/147548/ and here https://review.openstack.org/#/c/150057/ and another patch will arrive soon.
18:58:28 <breton> it required some collaboration with oslo_db team, because no one was using their migration_cli feature and we found and fixed some bugs.
18:58:31 <breton> for example, this — https://review.openstack.org/#/c/134885/9 .
18:58:33 <breton> my patches could work without the patch above, but that would require dirty hacks like line 184 on https://review.openstack.org/#/c/147548/8/keystone/tests/test_sql_upgrade.py
18:58:37 <breton> But the hacks are (almost) all in tests.
18:58:40 <breton> it will take some time to have:
18:58:42 <breton> 1. required oslo_db's features merged
18:58:45 <breton> 2. oslo_db released
18:58:47 <breton> 3. the new oslo_db landed to keystone
18:58:50 <breton> What should I do: Wait for the new oslo_db to land in Keystone and remove the hacks or
18:58:53 <breton> leave the hacks and remove them in follow-up patches?
18:59:15 <bknudson> my preference is wait for oslo_db.
18:59:43 <morganfainberg> i would rather wait for oslo_db. if it is going to be before k3 (should be doable)
18:59:55 <dstanek> mine too - don't like the idea of monkey patching
19:00:12 <breton> ok, got it
19:00:16 <morganfainberg> i'd like this support in kilo but it honestly could wait until L if we can't hit k3, we're still chugging along w/ SQL-A Migrate
19:00:31 <morganfainberg> but waiting is a better bet
19:00:36 <morganfainberg> annnnnnd that is time.
19:00:39 <morganfainberg> thanks everyone
19:00:43 <morganfainberg> #endmeeting