18:01:20 <stevemar> #startmeeting keystone
18:01:20 <openstack> Meeting started Tue Feb  2 18:01:20 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:23 <openstack> The meeting name has been set to 'keystone'
18:01:29 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda
18:01:37 <stevemar> light-ish agenda today
18:01:54 <stevemar> #topic DocImpact
18:02:02 <marekd> o/
18:02:15 <stevemar> there's going to be a change in the way docImpact works now
18:02:31 <notmorgan> oh good i wont ever use it now >.>
18:02:33 <notmorgan> oh wait...
18:02:33 <stevemar> we'll be opening bugs against the keystone project, not the docs team
18:02:36 <notmorgan> j/k
18:02:48 <lbragstad> \o/
18:02:59 <ayoung> will we be responsible for the docs repo?
18:03:03 <notmorgan> stevemar: does it auto tag the bug as "Doc"?
18:03:05 <bknudson> are we supposed to clean it up and reassign it to docs?
18:03:18 <notmorgan> stevemar: because if it just randomly create doc bugs, i think they'll get lost-ish
18:03:23 <henrynash> (hi)
18:03:39 <stevemar> i figured there were going to be a bunch of questions, i dont have the answers, but i can forward to lana
18:03:41 <notmorgan> bknudson: no we're supposed to do the documentation i think or verify... it
18:03:53 <notmorgan> but to be fair, i don't see a benefit for a docimpact bug.
18:03:57 <notmorgan> never did see the benefit
18:04:15 <bknudson> yes, who needs accurate docs.
18:04:20 <stevemar> notmorgan: bknudson i think the plan is have them auto tagged with 'docs'
18:04:23 <stevemar> or doc
18:04:33 <ayoung> bknudson, just buy the O'Reilly book
18:04:40 <notmorgan> bknudson: opening a random bug that says "hey this is a docimpact" vs before merging require the docs to be written
18:04:55 <stevemar> notmorgan: which is what we've been doing
18:04:57 <bknudson> I could write my own orieilly book to cash in on the lack of community involvement in docs.
18:05:00 <notmorgan> bknudson: if the bug was in a team not keystone, it made sense, but this seems like it's pointless.
18:05:45 <notmorgan> anyway, just my $0.02, if we already enforce docs written, the DocImpact flag is fine... but i wouldn't wnat it to open a bug
18:05:52 <stevemar> notmorgan: plus, we've been enforcing reno now, which is nice
18:06:25 <notmorgan> i can see the flag as useful to look at the log and see what was doc impacting. but anyway... i've voiced my opinion
18:06:36 <ayoung> notmorgan, so, I could see there being a benefit if the workflow was something like this:
18:06:45 <ayoung> 1. Docimpact, assign bug to origianly developer
18:07:03 <ayoung> 2.  Dev fills in the necessary info into the bug and assignes to the doc team to integrate in the right place
18:07:06 <stevemar> i think the only question is the identity upgrade and install bits that are owned by the docs team
18:07:18 <notmorgan> ayoung: i don't think anything goes to the doc team here.
18:07:32 <ayoung> lets try it for a while and see what happens.  I've never built the docs myself.
18:07:46 <topol> o/
18:07:46 <ayoung> maybe we'll like it.  We seem to enjoy writing anyway
18:07:51 <bknudson> I think at the last summit (or maybe last 2 summits) the docs team was saying they'd like to move the docs to the dev teams.
18:07:57 <notmorgan> bknudson: right.
18:08:16 <bknudson> But I haven't heard that that's happened
18:08:17 <notmorgan> bknudson: hence the reason i don't see a benefit for a bug to be opened. but *shrug*
18:08:37 <notmorgan> bknudson: and if the bug is opened and the docs team still owns it all, i don't see a win for us to have bugs against keystone.
18:08:42 <stevemar> notmorgan: i think it's just a way to migrate for folks that were using the tag in the first place
18:08:43 <samueldmq> bknudson: what docs ? api-ref ?
18:09:05 <notmorgan> stevemar: anyway my $0.02 of input
18:09:12 <bknudson> samueldmq: all the docs -- admin guide, user guide, config guide, install guide, ... whatever else we have
18:09:20 <stevemar> yep
18:09:21 <notmorgan> once it's all over to us i'd like to revisit disabling the "auto open a bug against keystone".
18:09:27 <samueldmq> bknudson: got it
18:09:36 <notmorgan> and just make sure we have docs when we merge the stuff.
18:09:37 <henrynash> (has always thought we should be writing our docs anyway, but hey….)
18:09:51 <ayoung> Where are our docs anyway?
18:10:02 <notmorgan> ayoung: almost 100% in our repo atm
18:10:02 <stevemar> henrynash: your wish is now coming true
18:10:12 <notmorgan> just not the admin/upgrade guides
18:10:17 <ayoung> notmorgan, openstack/keystone/docs
18:10:20 <lbragstad> fwiw the thing i like about have docs owned by a separate team is that it ends up being more consistent across projects
18:10:22 <notmorgan> ayoung: yeah.
18:10:24 <bknudson> http://docs.openstack.org/
18:10:27 <henrynash> (oh yes, I remember the saying now: be careful for what you wish for….)
18:10:30 <ayoung> repo?
18:10:38 <notmorgan> ayoung: in the main keystone repo.
18:10:46 <notmorgan> and specs repo for the cannonical specification [as you know]
18:11:07 <henrynash> lbragstad: I think that’s a good point…I’ve also though that sperate team should craete the style, order etc….but not the content
18:11:10 <stevemar> ayoung: tox -e docs!
18:11:14 <notmorgan> lbragstad: i think we'll see a drastic reduction in doc consistency and quality, but i know the doc team doesn't scale
18:11:21 <ayoung> http://git.openstack.org/cgit/openstack/openstack-manuals/
18:11:31 <notmorgan> ayoung: that is all being shuffled around afaik
18:11:39 <ayoung> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone.rst
18:11:46 <notmorgan> ayoung: so, let steve ask lana
18:11:50 <ayoung> ++
18:11:55 <lbragstad> notmorgan agreed - but from an u-x perspective, it's nice to see the consistency when referencing docs from different projects
18:12:04 <ayoung> put a follow up item for next weeks meeting...next topic?
18:12:14 <stevemar> yep
18:12:20 <stevemar> #topic ISO27001 Compliance
18:12:23 <stevemar> ayoung: g'head
18:12:59 <bknudson> I can't afford access to ISO standards
18:13:06 <ayoung> OK...so,  do we need to comply ?
18:13:07 <notmorgan> bknudson: lol
18:13:11 <notmorgan> ayoung: long term, yes
18:13:13 <ayoung> And is there any way to avoid it
18:13:18 <dstanek> bknudson: me either
18:13:19 <ayoung> I think I agree
18:13:27 <notmorgan> ayoung: but this will follow into the HIPPA/PCI-DSS type convos
18:13:38 <ayoung> I think we need to have a set of requirements for the SQL backend, because you cannot deploy without them
18:13:55 <notmorgan> which i'm headed to Seattle to start collecting info on thursday.
18:14:05 <ayoung> there will always be service users in the SQL backend, and I think a best p[ractice there is to try and not do password for those users
18:14:20 <notmorgan> it's all similar vein and requires concerted effort to move that way/document/etc
18:14:20 <bknudson> why can't service users go in the LDAP backend?
18:14:20 <dstanek> notmorgan: PCI stuff Thursday?
18:14:20 <ayoung> the use case, though, that I think clinches it is Public Cloud Customers
18:14:38 <ayoung> bknudson, for some cases, you don't have write access
18:14:42 <notmorgan> dstanek: going to talk w/ bluebox on what they're doing
18:14:55 <ayoung> bknudson, but they could go in a deployment specific LDAP
18:14:57 <notmorgan> dstanek: and what they've had to change / are changing to meet the requirements
18:15:06 <dstanek> notmorgan: nice, i can't wait to hear
18:15:17 <ayoung> so, could we do a deployment with all users in LDAP, only if we don't care about adding new customers, I think
18:15:35 <ayoung> so,  let me throw this in the Lap of the RAX folks:  how do you need this to look?
18:15:46 <dolphm> bknudson: many enterprises are not willing / able to let you touch their LDAP server just to deploy openstack
18:16:00 <ayoung> My assumption has been that provisioning on new customers is done through a systemn outside OPenStack.
18:16:37 <ayoung> dolphm, so, two distinct things.  You are right about Corporate LDAP, but if a place need compliance today, they could run a separate LDAP server (with compliance guaranteees) just for service users
18:17:04 <ayoung> YOu could, in theory, run OpenStack with no users in SQL at all.
18:17:11 <bknudson> lazy customers are king, I guess.
18:17:21 <ayoung> but that avoids a real use case:  how do  I add customers to my cloud?
18:17:35 <bknudson> if somebody signs up to do the work then let's go ahead.
18:17:56 <ayoung> bknudson, well, I am more asking from a "it was proposed and Adam kneecapped it.  Was Adam right?"
18:18:00 <ayoung> perspective
18:18:23 <bknudson> I think you are right, doesn't mean we can't support it now.
18:18:24 <ayoung> what I am saying is, I think I am not longer opposing compliance in the SQL backend, provided we can show it is required....
18:18:29 <bknudson> just for fun
18:19:10 <ayoung> gyee is not here, this was his issue.  Lets move on.
18:19:19 <bknudson> I also agree. We tried pushing onto ldap / saml but that didn't work.
18:19:36 <henrynash> ayoung: ++ agreed, I think we look at the requirements…if it is needed to hel to continue accelerating momentum of OpenStack, we shoudl do it…..it is perspiration, not inspiration to do this
18:19:36 <bknudson> who's signing up to do the work?
18:19:44 <stevemar> adding users to a sql backend, in the same of a public cloud, doesn't seem outrageous
18:19:48 <dstanek> what has to be done to support it?
18:20:14 <ayoung> stevemar, the thing is, the user abstraction in Keystone does not seem to be sufficient for an actual user database
18:20:19 <bknudson> since nobody can afford the standard it's tough to tell.
18:20:25 <ayoung> There is no contact info ,etc
18:20:43 <dolphm> dstanek: ++ is there a spec that outlines the impact on / proposed changes to keystone?
18:20:45 <ayoung> bknudson, forget the actual standard, I'm also referring to the request for passwrod rotation etc
18:21:17 <marekd> dolphm: true, at cern our ldap is a single source of truth about users, shared accross many services. our cloud is just one of many.
18:21:37 <dstanek> i like the SQL backend and don't want it to become a forgotten step child
18:21:38 <ayoung> marekd, and you do not add new users via Horizon
18:22:13 <marekd> ayoung: not really
18:22:14 <stevemar> dstanek: a lot of people like the sql backend, and i think would just like to see more capability in it
18:22:30 <dstanek> ayoung: most of the password "features" are trivial to implement and maintain
18:22:32 <ayoung> dstanek, So I think that it has the potnetial to be "used because it is there" which is not a great option
18:22:42 <notmorgan> so i have a real case I was asked about
18:22:47 <notmorgan> domain admin in SSO / IDP
18:22:51 <dstanek> i wrote many of them in 2014 :(
18:22:56 <notmorgan> each user for the domain after that is SQL based
18:22:59 <marekd> ayoung: users will have projects created given they are in a specific e-group but it requires manual interaction (somebody validating request and running the script)
18:23:03 <ayoung> dstanek, do you guys need that?
18:23:03 * lbragstad thanks dstanek
18:23:04 <stevemar> dstanek: restore patch
18:23:33 <bknudson> is this for M? We could probably get it done.
18:23:43 <bknudson> if dstanek has the code all ready
18:23:50 <dstanek> stevemar: sure. was planning on doing that on to of rderose's work
18:23:54 <notmorgan> dstanek: how does this play witht he shadowusers
18:24:14 <stevemar> notmorgan: looks like dstanek has already thought about that :)
18:24:16 <dstanek> bknudson: lots of rut, but should not be terrible to revive
18:24:20 <notmorgan> hehe
18:24:33 <ayoung> I'm less worried about the complexity of the Password code than giving the wrong impression.  I think a lot of people use SQL because they think they are supposed to, and then have this silo of identity.  My real question is whether there is a must have use case for SQL Identity, and, if so, what are the requiremetns
18:24:45 <lbragstad> dstanek https://review.openstack.org/#/q/status:abandoned+project:openstack/keystone+branch:master+topic:bp/password-rotation
18:25:15 <henrynash> ayoung: I’m not so sure they use it because they think they are supposed to….
18:25:16 <stevemar> ayoung: if we run a public cloud, and have customers that aren't huge enterprises, how do they sign up?
18:25:19 <dstanek> lbragstad: there are a few other patches too that i showed Ron at the Midcycle
18:25:28 <bknudson> Identities as a Service
18:25:29 <ayoung> stevemar, and that is the $1000000 question
18:25:32 <henrynash> ayoung: if they have a corpaorate directory already, they’ll use that
18:25:34 <ayoung> because you can't bill from Horizon
18:25:41 <lbragstad> dstanek gotcha - those seemed to be the ones with a common topic
18:25:43 <henrynash> ayoung: if they don’t, then they’ll use SQL
18:25:44 <ayoung> henrynash, and yes to that, too
18:26:03 <dstanek> public cloud seems to be the use case
18:26:04 <henrynash> ayoung: setting up LDAP is hard compared to our SQL backend
18:26:17 <stevemar> ayoung: they don't want to federate, and they dont have an ldap handy... sql is the only option
18:27:02 <henrynash> ayoung: there are a lot more sql admins than there are LDAP admins in enterproses
18:27:04 <bknudson> there will be bugs and they'll probably be security vulnerabilities, but whatever.
18:27:12 <ayoung> stevemar, we show how to do LDAP with devstack.  THat is not a real barrier to acceptance
18:27:13 <notmorgan> and SQL is already needed for most of openstack
18:27:16 <notmorgan> and keystone
18:27:25 <notmorgan> so, it's a tech they have the resources to maintain internally
18:27:27 <notmorgan> and consume
18:27:29 <ayoung> henrynash, but the SQL admins know nothing about passwords or compliance ,either\
18:27:35 <notmorgan> adding LDAP or SSO is often harder.
18:27:40 <bknudson> seems like any org already has a way to do identities
18:27:56 <bknudson> can I just create users with POST /v3/users on rackspace?
18:27:57 <notmorgan> but public cloud tends to be the main driving use-case
18:28:00 <dolphm> bknudson: yes
18:28:06 <henrynash> ayoung: no….but they are comforatble running and maintaining an SQL server…and backing it up, restoring it when disaster strikes etc.
18:28:11 <ayoung> My position thus far has been SQL for Proof of concept, LDAP for enterprise deployments
18:28:20 <stevemar> keystone now has three difficulty levels, easy:sql, medium:ldap and hard:sso
18:28:32 <ayoung> now, with Writable LDAP gone, we have no story for secure creation of new identities
18:28:40 <notmorgan> stevemar: med-hard, multi-ldap with SQL
18:28:50 <stevemar> hehe
18:28:55 <henrynash> notmorgan: :-)
18:29:04 <stevemar> ayoung: i think public cloud has a use case here
18:29:27 <ayoung> stevemar, I suspect that it is the case, but I also suspect that, if you push at it, they are really using a more complex customer management system
18:29:43 <notmorgan> this is mostly a public cloud use case... or an org that uses cloud-local users except for domain admin
18:29:55 <notmorgan> where domain-admin is locked down to things like LDAP or SSO
18:29:56 <dolphm> and isolated private clouds
18:29:59 <stevemar> ayoung: like a different ldap?
18:30:19 <samueldmq> henrynash: this is basically what domain-specific backends support in a context of public cloud
18:30:20 <ayoung> stevemar, there are CRM apps out there,  Some LDAP, some SQL
18:30:31 <ayoung> some opensource, and many, I suspect, custom
18:30:37 <samueldmq> henrynash: you can attach an LDAP server if you have one, or just share SQL if you don't have anything
18:30:39 <henrynash> samueldmq: yep
18:30:44 <ayoung> CRM= Customer Relationship Management
18:31:10 <bknudson> ok... does anyone think we must not improve the identity SQL backend to support stronger passwords/etc.?
18:31:15 <ayoung> My unstated assumption thus far is CRM is another WebSSO integration
18:31:21 <samueldmq> henrynash: maybe we should allow mapping SQL backends (vc only LDAP backends ) ?
18:31:21 <bknudson> It would be nice if there was a spec saying all that was being added.
18:31:23 <ayoung> bknudson, I'm still not sold
18:31:29 <notmorgan> bknudson: there was a spec
18:31:37 <stevemar> bknudson: dolph has a spec up
18:31:37 <notmorgan> bknudson: "make SQL a full Identity manager" or some such
18:31:42 <lbragstad> bknudson wouldn't that fall under the pci-dss spec?
18:31:44 <ayoung> so, in that spec, please justify Why the SQL backend needs to be improved
18:31:44 <notmorgan> was abanded a while ago...or something
18:31:55 <dolphm> #link https://review.openstack.org/#/c/272396/2/specs/newton/pci-dss.rst
18:31:55 <samueldmq> why not allowing mapping SQL backends (for domain-specific backends) as we do for LDAP ?
18:31:59 <ayoung> because I need to that to turn around and explain it to my org, which is very Enterprise Focused
18:32:03 <samueldmq> ayoung: ^
18:32:05 <henrynash> samueldmq: I’d love to support mapping multiple SQL backends, but our current sqlamlchemy support doesn’t support it (last time I checked)
18:32:18 <samueldmq> henrynash: I think that should be doable
18:32:19 <ayoung> henrynash, I bet we can make that happen
18:32:26 <notmorgan> henrynash: i have some improvements around that i plan on working on shortly
18:32:27 <dolphm> henrynash: true
18:32:37 <henrynash> ayoung, samueldmq: me too….and I think we should try and do that
18:32:41 <ayoung> OK...lets move on to policy
18:32:42 <stevemar> ayoung: send your org this link: https://review.openstack.org/#/c/272396/2/specs/newton/pci-dss.rst
18:32:45 <notmorgan> henrynash: it's all based around moving to the new-sql-[non-old-style] facades
18:32:55 <stevemar> #topic Policy and RBAC
18:33:05 <stevemar> ayoung is on a tear today!
18:33:06 <samueldmq> henrynash: ayoung: yes and if we get it, no need to make our sql schema more powerful right ?
18:33:09 <stevemar> typing up a storm
18:33:24 <samueldmq> we provide the basics and if you want more power, make your own and map it to keystone
18:33:45 <ayoung> OK...so,  jamielennox and dolphm have been moving the discussion along on a standard set of roles
18:33:54 <stevemar> i need to make a tally for all the times we've talked about policy in keystone meetings :)
18:33:55 <ayoung> please read the X proj spec,
18:34:11 <notmorgan> stevemar: every meeting always
18:34:23 <samueldmq> #link https://review.openstack.org/#/c/245629
18:34:28 <samueldmq> the spec in X proj ^
18:34:29 <ayoung> Thanks
18:34:43 <ayoung> so...I want to talk about the ramifications of this and the is_admin_project change
18:35:12 <dolphm> and then i threw together an example to show the impact on keystone's policy, which needs some work:
18:35:14 <dolphm> #link https://review.openstack.org/#/c/274168/
18:35:17 <ayoung> I tried adding an is_admin_project check to cloudsample, no problem
18:35:33 <ayoung> dolphm, thanks.
18:35:50 <henrynash> ayoung: yep, and it works…I added tests to show that it does (test_v3_protection)
18:36:00 <ayoung> and you can see that our unit tests will need tsome massaging to accept dolph's changes
18:36:13 <ayoung> henrynash, so the question is, what do we do about default policy
18:36:22 <ayoung> and samueldmq had an ideaa.....
18:36:35 <henrynash> (drum roll)
18:36:36 <samueldmq> move scope checks to the code
18:36:50 <samueldmq> and only leave role checks in the policy, i.e true RBAC there
18:36:52 <stevemar> (readies the gong for the big finale)
18:37:00 <henrynash> samueldmq: ok, so can you be more explicit….
18:37:01 <samueldmq> hehe
18:37:11 <ayoung> So, this will work for Keystone, because in the code we can read the keystone config
18:37:24 <ayoung> so we could check in code to see if admin_porjecr_id is even set
18:37:31 <ayoung> but this won't work for, say, Nova or Glance
18:37:34 <ayoung> and for that...
18:37:42 <henrynash> samuedlmq, ayoung: I still want some more clarity on this…even for keystone
18:37:48 <samueldmq> henrynash: project_id:%(project_id)s is removed from policies, they will live in the code, when a request arrives, always check scope
18:37:48 <ayoung> https://review.openstack.org/#/c/242852/
18:38:09 <ayoung> henrynash, agreed, but I think the short is that is clarification, but all the options are technically feasable
18:38:12 <samueldmq> henrynash: if you need global, use project_admin option ayoung implemented
18:38:37 <ayoung> so thingee just pinggedmee with a request to be at the X proj meeting abouit that
18:38:37 <henrynash> samuedlmq, ayoung: so how does a policy line like:  rule:cloud_adomin or (role:xyz and project_id:%(project_id)s) work in this new arrangemnt?
18:39:05 <ayoung> henrynash, so, lets define cloud_admin first
18:39:08 <ayoung> I think that is
18:39:18 <ayoung> role:admin and proejct_id=admin_project_id right?
18:39:29 <henrynash> ayong: ok
18:39:31 <ayoung> so we would be checking a separate role based on the scope of the token?
18:39:52 <bknudson> the last comment on the spec from dhellmann indicated he expected to have a global administrator
18:40:08 <samueldmq> if we want global admin, use admin_project
18:40:10 <ayoung> henrynash, yeah, global admin is kindof a firm requirement
18:40:16 <ayoung> I've been told that a few times
18:40:19 <henrynash> ayoung: but the scope might be different in the different clauses of the poliy line….matched to a different role
18:40:27 <ayoung> right..
18:40:28 <dolphm> i wish we had named it root
18:40:32 <henrynash> ayoung: I don’t understand how we do that in code and not lose flexibility
18:40:40 <ayoung> henrynash, How about this
18:40:52 <stevemar> dolphm: then you've have people asking for a sudo command
18:40:52 <ayoung> we perform the role check only on the proejct specific
18:40:59 <samueldmq> henrynash: define something like global_roles=[], those ignore scope checks ?
18:41:04 <dolphm> stevemar: fine by me
18:41:06 <notmorgan> dolphm: hehe
18:41:16 <ayoung> when we get to the scope check, we can say "don't care if the role check failed"  and then make that check both is_admin+_proejct and role
18:41:28 <ayoung> role:admin
18:42:22 <ayoung> actually, the scope check could also accept and "is_cloud_admin" param set earlier, and we could do the whole cloud_admin check in the role layer
18:42:26 <ayoung> that probably makes more sense
18:42:35 <henrynash> samuedlmq, ayoung: and this makes it all easier?
18:42:47 <ayoung> henrynash, it makes it easier to customiZE AND TO SCALE
18:42:59 <samueldmq> henrynash: I think this makes our policy more consistent with what others do (eg nova)
18:43:28 <henrynash> (remains unconvinced until sees examples of v3cloudsample, not our niddy policy.json)
18:43:36 <samueldmq> henrynash: and is a necessary step towards policy
18:43:39 <ayoung> henrynash, we 've coded what "cloud_admin" means in the policy file, but that has to be run after the database call to fetch objects.  I'd like the role check to preceed that, and be customizable by end deployers
18:44:24 <ayoung> so cloud_admin could be soemthing that we check in the role, still, and we then just need to let the scope check have enough information to process either with or without cloud admin
18:44:31 <bknudson> if you could put names in the policy file you wouldn't need to update cloud_admin.
18:44:42 <ayoung> bknudson, what kind of names?
18:44:51 <ayoung> usenames?
18:45:00 <ayoung> user
18:45:01 <henrynash> ayoung, samueldmq: you guys probably have this all thought out, but I’m not sure we even agree on the nomenclature in the things you are describing
18:45:26 <stevemar> henrynash: ++
18:45:27 <bknudson> cloud_admin uses admin_domain_id -- so domain name
18:45:34 <ayoung> henrynash, so...I think we can duplicate the cloud_admin check in the role check and scope check and it will work.
18:45:50 <ayoung> bknudson, yeah, that was henrynash '
18:45:51 <henrynash> what’s a role check? what’s a scope check?
18:45:51 <samueldmq> henrynash: btw I thought we didn't want cloud_admins to be able to touch a given project without rescoping right ?
18:45:54 <ayoung> s origianl approach
18:45:56 <ayoung> and that still works
18:46:09 <ayoung> but people have asked us not to force them to edit upon deployment
18:46:15 <samueldmq> henrynash: only the global admin which is available using the admin_project should be enough, shouldn't it ?
18:46:26 <ayoung> so we need 1) backwards compatible, 2)non editing 3)secure
18:46:33 <bknudson> if you're doing more than 1 deployment then automate it.
18:46:40 <ayoung> henrynash, I think for startes we duplicate the check
18:46:54 <ayoung> so,  for, say,  compute:create_server
18:47:10 <samueldmq> henrynash: role check is 'role:service', scope check is 'project_id:%(project_id)s'
18:47:16 <ayoung> the role check would be role:compute_server_write or rule:cloud_admin
18:47:20 <ayoung> and the scope check would be
18:47:39 <ayoung> project_id:server.project_id or rule:cloud_admin
18:47:52 <samueldmq> yes, and in nova the check is in the code
18:47:55 <ayoung> if we can find a way to make that clean....
18:48:02 <lbragstad> 12 minute warning
18:48:04 <samueldmq> deployers can only change the role part of the check, which is in the policy
18:48:14 <ayoung> the scope checks are likely to move into the code, as samueldmq suggested,.  The Nova team is already moving this way
18:48:38 <stevemar> thanks lbragstad
18:48:42 <samueldmq> ayoung: I think they've been always this way
18:48:47 <stevemar> gotta cut this one off in 2
18:48:53 <henrynash> ayoung: still don’t see how this works for complex ploicy rules where more than one role check is involved and needs to be matched top a specific scope check
18:49:24 <henrynash> ayoung: we need a real spec, with real reasons of why to do this, and explaining how we are not losing the flexibility we give deployers today
18:49:26 <samueldmq> perhaps ayoung and I should work more with henrynashon this and come back next week
18:49:31 <samueldmq> as we're running out of time
18:49:44 <stevemar> probably
18:49:47 <samueldmq> and we still have another topic to cover
18:49:55 <stevemar> lets switch gears to devstack
18:49:58 <samueldmq> henrynash: ++
18:50:06 <stevemar> #topic Devstack, identity v3, and breaking the world
18:50:11 <henrynash> samueldmq, ayoung: happy to
18:50:16 <samueldmq> ++
18:50:26 <stevemar> so, we broke a lot of things on friday
18:50:27 <ayoung> henrynash, I can write that up.  I only know realized the solution was to duplicate the admin override check at both layers, and I need to think through the ramifications
18:50:36 <stevemar> sdague covered it here: http://lists.openstack.org/pipermail/openstack-dev/2016-February/085497.html
18:50:37 <bknudson> I like the responses in the email that said "tough"
18:50:39 <henrynash> ayoung: ok
18:50:53 <stevemar> bknudson: yeah, gordc was representing :]
18:51:06 <ayoung> one last thing:  please approve the Implied Role Spec
18:51:20 <ayoung> OK, I'm done
18:51:24 <stevemar> ayoung: thanks
18:51:25 <bknudson> I guess it's difficult to write scripts that work with v2 and v3.
18:51:41 <bknudson> since apparently things broke when the v3 change was reverted.
18:51:55 <notmorgan> bknudson: almost all was clients [aka novaclient] and things that use tempestlib
18:51:55 <stevemar> bknudson: yeah - i was wondering / hoping, folks had any bright ideas on how we could make sure this doesn't happen again
18:52:18 <stevemar> i created an etherpad to jot down ideas: https://etherpad.openstack.org/p/v3-only-devstack
18:52:18 <bknudson> if we never change anything it'll never happen again.
18:52:30 <htruta> doesn't a try v3, fail and fallback to v2 make sense?
18:52:30 <dolphm> so, let's require v3 every friday in the gate until people adapt?
18:52:31 <notmorgan> basically we need to make changes (use http://codesearch.openstack.org/ ) to fix the issues
18:52:31 <raildo> the first problem is that the tempest tests doesn't covered that behavior
18:52:44 <notmorgan> and set a date where we flip over, knowing we'll have fallout/cleanup
18:52:45 <stevemar> bknudson: oh we'll keep that as a backup idea
18:52:47 <ayoung> before that change (and after the revert) do we even produce a V3 rc file?
18:52:56 <stevemar> ayoung: yep
18:52:59 <stevemar> we do so now
18:53:04 <htruta> ayoung: we did
18:53:08 <htruta> in the reverted change
18:53:09 <bknudson> devstack creates a cloud.yaml file
18:53:22 <bknudson> with different clouds -- one of them is v3
18:53:28 <notmorgan> almost everything that broke is stuff not on KSA or things that encode bad habits directly
18:53:40 <notmorgan> if we set a date for change over [early N?]
18:53:41 <bknudson> should be --os-cloud devstack-admin-v3
18:53:52 <notmorgan> knowing we will break things, and will do clenaup
18:53:58 <notmorgan> i think that is correct
18:54:07 <notmorgan> and we do our best to cleanup the last things between now and then
18:54:22 <notmorgan> coordinate with sdague and mtreinish on that front.
18:54:23 <stevemar> we should try and fix all the projects now so the switch over in early N is less kablamo
18:54:24 <ayoung> So, what was the actual change made?
18:54:32 <ayoung> cloud.yaml is like, newish
18:54:33 <notmorgan> ayoung: devstack defaulting to v3.
18:54:43 <notmorgan> there are a number of things not using OCC/KSA
18:54:52 <stevemar> ayoung: https://review.openstack.org/#/c/271508/
18:55:08 <notmorgan> getting everyone off ksc.session will be a big win
18:55:20 <stevemar> notmorgan: how is the migration to ksa going for all the projects?
18:55:21 <htruta> notmorgan: ++
18:55:34 <notmorgan> getting the clients to use OCC/KSA for constructing is the other hurdle
18:55:42 <stevemar> i think some folks were interested in helping out?
18:55:44 <notmorgan> so. nova is on KSA, neutron is on ksa,
18:55:47 <htruta> stevemar: I've senn magnum, for example, and it has a bug saying that it should use ksa
18:55:51 <htruta> seen*
18:56:00 <notmorgan> htruta: assume the projects can't/wont do that change
18:56:19 <notmorgan> because largely they don't have the bandwidth or time to ramp up on the internals to know how to make the change over non-painful
18:56:33 <stevemar> htruta: yeah, the other projects may not have the knowledge to do the change, we may have to do it for them
18:56:42 <notmorgan> http://codesearch.openstack.org/?q=from%20keystoneclient%20import%20session&i=nope&files=&repos=
18:56:51 <notmorgan> that is everything using keystoneclient.session
18:56:55 <notmorgan> #link http://codesearch.openstack.org/?q=from%20keystoneclient%20import%20session&i=nope&files=&repos=
18:57:25 <bknudson> this is all pretty ridiculous -- why do you need to specify the version.
18:57:29 <htruta> stevemar, can't we teach them too? Some blog post or stuff like that
18:57:43 <raildo> ironic are doing this now.... https://review.openstack.org/#/c/236982/
18:57:47 <notmorgan> htruta: we've tried. if we want this, we need to do this
18:57:50 <notmorgan> ourselves.
18:57:58 <stevemar> htruta: what he said ^
18:57:59 <notmorgan> some projects are going to beat us to the punch
18:58:15 <htruta> notmorgan: heh. makes sense
18:58:24 <stevemar> bknudson: we can look into that
18:58:33 <notmorgan> so, getting us to KSA everywhere and using OCC for client construction will mean version specification will become less of an issue
18:59:07 <stevemar> we're at time
18:59:14 <stevemar> thanks for attending everyone
18:59:15 <notmorgan> and that will help aleviate problems excpet in cases like heat where the project needs v3 keystone APIs
18:59:22 <notmorgan> but heat isn't a problem
18:59:29 <notmorgan> (vs. just auth)
18:59:31 <stevemar> #endmeeting