18:00:22 <stevemar> #startmeeting keystone
18:00:22 <MaxPC1> 0/
18:00:24 <openstack> Meeting started Tue Jan 19 18:00:22 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:28 <stevemar> sure has been a crazy week!
18:00:28 <lhcheng> o/
18:00:29 <openstack> The meeting name has been set to 'keystone'
18:00:32 <ayoung> MaxPC1, !
18:00:49 <stevemar> thanks everyone in advance for all the review and code they've been pushing :)
18:00:57 * notmorgan is lurking.
18:01:03 <notmorgan> *LURK*
18:01:10 * stevemar insists notmorgan sits in the front
18:01:13 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda
18:01:30 <stevemar> lots of stuff on the agenda today, so expect short discussions
18:01:44 <stevemar> #topic midcycle details
18:02:06 <stevemar> I sent out an email to all the folks coming to the midcycle, i got names from the wiki
18:02:13 <david8hu> \o
18:02:24 * dstanek is likely to get lost if there are over 900 buildings!
18:02:37 <stevemar> no real changes there, just that we'll get "badges" (stickers) the day of and they'll be ready with our names on it
18:02:45 <stevemar> #link https://etherpad.openstack.org/p/keystone-mitaka-midcycle
18:02:57 <bknudson> is there a bus from the hotel?
18:03:10 <stevemar> dstanek: there are only 7 buildings, and and we'll be using the same one every day :)
18:03:18 <stevemar> bknudson: nope, carpool or drive
18:03:28 <topol> bknudson stay at the same hotel as me and I can give you a ride
18:03:32 <stevemar> bknudson: well, not that i know of...
18:03:48 <ayoung> will there be telepresence?  I'd like to participate
18:03:51 <bknudson> they probably have uber there
18:03:52 <dstanek> stevemar: i'm in walking distance
18:04:01 <dstanek> bknudson: uber and lyft i believe
18:04:01 <stevemar> dstanek: no bus for you then
18:04:11 <stevemar> ayoung: i can ask about that
18:04:31 <bknudson> at the security meetup they set up google hangout and a couple of people remoted in
18:04:34 <stevemar> #action stevemar to setup video for midcycle
18:04:37 <bknudson> seemed to work ok
18:04:42 <dolphm> telepresence hasn't worked too well for the midcycles that have tried it, unless they go 100% remote, and then you have a whole different set of problems
18:04:56 <samueldmq> anyone staying at Home2 Suites ? :)
18:05:03 * notmorgan hasn't booked hotel yet
18:05:04 <stevemar> samueldmq: i think dstanek is
18:05:06 <notmorgan> will be doing that today
18:05:09 <ayoung> stevemar, something like that would work fine.  When we did the summer one, we did the remote demo for dynamic policy that way
18:05:11 <samueldmq> I decided it was better ot just walk
18:05:20 <samueldmq> stevemar: nice!
18:05:23 <dstanek> stevemar: nope. some lonestar place i think
18:05:51 <stevemar> dstanek: i thought home2 was the only one in wakling distance, oh well
18:05:59 <stevemar> ayoung: yep, i'll see what we can do
18:06:09 <stevemar> ayoung: worst case, hangouts like bknudson said
18:06:20 <stevemar> any other q's about the midcycle?
18:06:37 <ayoung> Agenda for topics to discuss?
18:06:41 <ayoung> At midcycle, that is?
18:06:56 <stevemar> ayoung: no agenda yet, but i added topics and timeslots to the etherpad: https://etherpad.openstack.org/p/keystone-mitaka-midcycle
18:07:02 <samueldmq> ayoung: yes it worked :)
18:07:33 <samueldmq> stevemar: are we also supposed to use https://etherpad.openstack.org/p/keystone-mitaka-midcycle-meetup ?
18:07:41 <samueldmq> stevemar: in addition to this one you said ^?
18:07:54 <topol> notmorgan is actually coming???
18:07:59 <stevemar> samueldmq: i don't know who created that one
18:08:09 <stevemar> samueldmq: just squash the content into https://etherpad.openstack.org/p/keystone-mitaka-midcycle if possible?
18:08:11 <dstanek> we just need to make sure we have enough time to come to a resolution on topics that need it
18:08:16 <stevemar> since one has much more content
18:08:18 <samueldmq> stevemar: me neither, sure!
18:08:45 <stevemar> dstanek: agreed
18:09:11 <stevemar> we can take a vote on topics that need discussion the first morning we get there
18:09:20 <bknudson> some of these are work items and not something we need to discuss
18:09:33 <samueldmq> stevemar: done
18:09:34 <ayoung> You guys are going to get so much done without me there to derail
18:09:38 <dolphm> stevemar: are we supposed to fill in the schedule?
18:09:40 <samueldmq> bknudson: nice, I will add 2 sections
18:10:05 <bknudson> why 2 sections?
18:10:14 <stevemar> dolphm: no, lets fill it in the morning of
18:10:22 <stevemar> dolphm: or i'll make that call
18:10:26 <dolphm> stevemar: "will be populated from topics & todos" ?
18:10:50 <samueldmq> bknudson: list of topics to be discussed vs only worked on
18:10:53 <stevemar> dolphm: yes, it will be
18:11:13 <bknudson> ok... seems like we can put everything in 1 section
18:11:25 <samueldmq> wfm
18:11:25 <bknudson> as in, things people want to do at the midcycle
18:11:36 <stevemar> bknudson: right
18:11:52 <stevemar> can't we can divide that up in the first morning there?
18:12:20 <stevemar> there's discssion, then there's work items folks want to accomplish
18:13:14 <stevemar> fill in topics and things to do, i'll massage it a bit
18:14:23 <notmorgan> topol: yes. but...
18:14:24 <stevemar> seems like a good time for the next topic
18:14:34 <stevemar> #topic API working group liaison
18:14:40 <notmorgan> ayoung: i promise to derail things in your absence
18:14:47 <ayoung> notmorgan, thanks
18:15:08 <stevemar> so dolphm has stepped down as the API working group liaison, anyone want to pick up and run with it?
18:15:18 <stevemar> dolphm: can you mention some of the responsibilities?
18:15:30 <gyee> that defcore work?
18:15:33 <dolphm> sure-
18:15:36 <stevemar> dolphm: or more importantly, time commitment
18:15:38 <notmorgan> gyee: not exactly.
18:16:14 <dstanek> dolphm: yes, what is the time commitment like?
18:16:16 <dolphm> from my perspective, the job is mostly to maintain awareness of, if not participate in, the API Working Group, and to come back to keystone and review API-impacting keystone-specs reviews accordingly, raise awareness of new standards/conventions/etc
18:16:49 <dolphm> dstanek: it's just a shift in code review focus in my book, so... zero ;)
18:17:00 <stevemar> btw, this is open to anyone, not just cores
18:17:14 <bknudson> do they have a weekly meeting to attend?
18:17:15 <gyee> what's the pay like?
18:17:21 <gyee> :)
18:17:32 <dolphm> bknudson: https://wiki.openstack.org/wiki/API_Working_Group
18:17:36 <lbragstad> gyee the occasional coffee/beer at summits
18:17:36 <dstanek> yes, yep
18:17:49 <dolphm> https://wiki.openstack.org/wiki/Meetings/API-WG
18:17:59 <dolphm> but honestly, all the important stuff is in gerrit
18:18:04 <dstanek> don't all jump in at once! i'd be interested
18:18:07 <dolphm> and there's been a tiny bit on the mailing list
18:18:51 <dstanek> i already watch the evening meeting - so it would just mean participating
18:18:53 <stevemar> dstanek, cool with me, i think you're already a liaison for something, but as long as you're sure you can handle it
18:19:24 <stevemar> dstanek: y, you are QA liaison, but above comment still applies
18:19:47 <dstanek> stevemar: yes, i don't mind
18:19:51 <samueldmq> ++ for dstanek, however I'd be able to take it no-core is able to
18:20:01 <samueldmq> dstanek: nice then :)
18:20:06 <stevemar> dstanek: thanks, dude.
18:20:13 <henrynash> ++ to dstanek
18:20:15 <dolphm> #startvote Elect a new API-WG liaison? dstanek
18:20:16 <stevemar> dstanek: i'll let the right folks know
18:20:17 <openstack> Only the meeting chair may start a vote.
18:20:17 <dolphm> #vote dstanek
18:20:19 <dolphm> #endvote
18:20:22 <bknudson> thanks dstanek
18:20:22 <raildo> lol
18:20:23 <stevemar> lol
18:20:24 <dolphm> dstanek: woo, congrats!
18:20:30 <samueldmq> haha
18:20:33 <lbragstad> that was trickery
18:20:39 <stevemar> you guys are gonna love this next topic...
18:20:47 <stevemar> #topic Cross-Project liaison
18:20:47 * dstanek feels like he was just thrown into a fire pit
18:20:58 * dolphm hugs dstanek
18:21:12 <stevemar> this is *new* position
18:21:20 <stevemar> the cross-project liaison
18:21:21 <bknudson> I'm already watching x-project for security, and I also attend because of oslo
18:21:31 <stevemar> responsibilities are here: http://docs.openstack.org/project-team-guide/cross-project.html#cross-project-specification-liaisons
18:21:45 <gyee> sounds like a punching bag position
18:21:45 <bknudson> So I'll volunteer.
18:21:48 <dolphm> #startvote Elect a new cross project liaison? bknudson
18:21:49 <openstack> Only the meeting chair may start a vote.
18:22:05 <stevemar> bknudson: that works for me
18:22:08 <dolphm> #vote bknudson
18:22:09 <dolphm> #endvote
18:22:09 <bknudson> of course I'd be happy to see someone else on it.
18:22:10 <dolphm> woo
18:22:18 <stevemar> bknudson: i'll help out where i can
18:22:26 <stevemar> i also watch the x-project specs
18:22:27 <lbragstad> i see a pattern forming
18:22:45 <topol> bknudson, now thats a nomination I can get behind!
18:22:55 <shaleh> Looks like a sham democracy to me :-)
18:22:56 <bknudson> there are already a couple of x-project specs that keystone should be following
18:23:09 <bknudson> request IDs from the python API
18:23:16 <bknudson> and the service catalog standardization
18:23:16 <samueldmq> stevemar: core-only for this one ?
18:23:23 <dolphm> in all seriousness, cross-project awareness and communication is a growing issue in openstack, and i'd openly encourage & welcome anyone that wants to step up
18:23:27 <ayoung> I don't like the other projects
18:23:39 <shaleh> ayoung: they relly dont like us :-)
18:23:41 <bknudson> and there's some proposed also -- for using the CLI (which we're already done with)
18:23:50 <bknudson> for using openstack CLI
18:23:53 <stevemar> samueldmq: preferred, for the reasons dolphm just said, but please please participate, it's very important
18:23:55 <dolphm> samueldmq: no reason to restrict liaisons to existing -core at all
18:24:07 <dolphm> stevemar: disagree!
18:24:19 <samueldmq> cool, I'll volunteer too
18:24:19 <amakarov> dolphm, maybe there should be more than just a single person for x-project communication?
18:24:30 <bknudson> my vote is for samueldmq then.
18:24:35 <dolphm> liaisons priority is communication-first, not necessarily reviewer-first
18:24:42 <lbragstad> I was just going to ask, does it have to be restricted to one person?
18:24:52 <stevemar> dolphm: i did say *preferred*, no required
18:25:02 <gyee> bknudson, link for the SC standardization patch?
18:25:11 <dstanek> one person needs to be responsible, but i see no reason why others can't get involved
18:25:21 <bknudson> gyee: it's merged already... let me find it!
18:25:30 <dolphm> one of the other functions of liaisons is to have externally-facing project contacts, so there's no harm in having a list of people willing to be contacted
18:25:32 <ayoung> when is the X proj meeting?
18:25:37 <stevemar> gyee: it's here: http://specs.openstack.org/openstack/openstack-specs/
18:25:48 <stevemar> ayoung: just after this one? or two hours after?
18:25:56 <ayoung> I can take it.
18:25:59 <bknudson> gyee: https://review.openstack.org/#/c/181393/
18:26:03 <lbragstad> dstanek agreed, as long as the people acting a liaisons stay up on communication with each other
18:26:03 <stevemar> now everyone wants to do it!
18:26:09 <ayoung> I've been pushing X proj specs enough
18:26:26 <samueldmq> lbragstad: ++
18:26:37 <ayoung> I said "can" not "want to"
18:26:42 <ayoung> will do if needed
18:26:52 <dolphm> there are also working group meetups at the summits - while not strictly required, i'd sincerely hope the liaison can/will attend
18:26:53 <stevemar> ayoung: let's let samueldmq have it :)
18:27:03 <bknudson> samueldmq sounds like he wants to.
18:27:16 <samueldmq> I'd be glad, will do my best :)
18:27:20 <stevemar> done
18:27:27 <stevemar> samueldmq you are the new x-project dude
18:27:29 <gyee> #vote for samueldmq
18:27:33 <bknudson> thanks samueldmq!
18:27:47 <dstanek> samueldmq!
18:27:48 <amakarov> samueldmq, congrats!
18:27:48 <topol> thanks samueldmq
18:27:50 <dolphm> #vote samueldmq
18:27:51 <ayoung> works for me
18:27:59 <topol> speech speech speech
18:28:01 <samueldmq> thanks hehe
18:28:03 <stevemar> hehe
18:28:17 <stevemar> #topic keystone user survey
18:28:24 <samueldmq> bknudson: might need to get a bit more details with you after meeting
18:28:33 <bknudson> samueldmq: no problem
18:28:49 <stevemar> so, i was asked if we want to provide new questions about keystone for the user survey
18:28:56 <stevemar> anyone can add questions here:  https://etherpad.openstack.org/p/keystone-mitaka-user-survey
18:29:26 <stevemar> the previous keystone related questions for the user survey i saw were pretty bad
18:29:58 <stevemar> they didn't discriminate between the resources and backends, it was just "do you use ldap, y/n?"
18:30:32 <stevemar> if you have a few minutes, add a question, i figured if everyone adds one, then that's good enough
18:30:55 <stevemar> otherwise, i'll add a bunch on my own
18:31:41 <gyee> stevemar, when do you need them by?
18:32:24 <stevemar> gyee: Due Jan 21, 2016
18:32:48 <stevemar> i can polish the question, if folks want to write it in short form
18:33:08 <stevemar> here's an example question from last year: Which OpenStack Identity Service (Keystone) drivers are in use?
18:33:22 <stevemar> the options are LDAP/SQL/AD/PAM/Templated/KVS ....
18:33:40 <stevemar> https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
18:33:58 <stevemar> that's pretty much our own insight into users and operators that is metric based ...
18:34:01 <stevemar> and kinda sad
18:34:34 <stevemar> so, if we're actually serious about operator feedback, then take a few minutes to add a question, i think it'll be worthwhile
18:34:54 <gyee> #1 Do you use Keystone? Yes/No
18:35:31 <shaleh> gyee: actually valid, right? Could be a Swift only shop
18:35:32 <stevemar> gyee: i think that's already asked :)
18:35:53 <stevemar> all this silence isn't good, i think i lost folks :(
18:36:05 <raildo> stevemar: all of us can suggest some questions, right?
18:36:11 <stevemar> raildo: for sure
18:36:11 <htruta> let's ask if they use v2. If so, why?
18:36:16 <stevemar> htruta: yep
18:36:22 <notmorgan> there is also more nova deployments than keystone deployments
18:36:23 <samueldmq> I'm here o/
18:36:27 <notmorgan> as an interssting datapoint
18:36:32 <notmorgan> as of the last survey
18:36:41 <samueldmq> notmorgan: ++
18:36:45 <stevemar> notmorgan: could just be people filling out data incorrectly
18:36:48 <topol> o/ ack
18:36:54 <samueldmq> #link http://www.openstack.org/software/project-navigator
18:36:54 <ayoung> meh...people are not interested in Keystone.  Either it works for them or they work around it
18:36:59 <samueldmq> keystone has 96% adoption
18:37:12 <raildo> ayoung: :(
18:37:29 <ayoung> raildo, Implied roles is the first step to fix that
18:37:33 <amakarov> samueldmq, how this can be measured?
18:37:33 <stevemar> help out if you can
18:37:37 <shaleh> Identity is not sexy or interesting. It is a necessary step for them. That is all.
18:37:39 <topol> ayoung, the selfhating core
18:37:48 <ayoung> topol, I don't hate myself
18:37:48 <stevemar> topol: ++
18:37:49 <ayoung> I love me
18:37:57 <ayoung> I am just frustrated by Keystone
18:38:04 <samueldmq> amakarov: survey
18:38:05 <bknudson> let's make keystone something we can all love
18:38:11 <gyee> ++
18:38:24 <stevemar> ayoung: "how can i make keystone something we can all love?"
18:38:31 <stevemar> anywho
18:38:32 <ayoung> stevemar, no
18:38:46 <stevemar> now that fun topic is over..
18:38:49 <stevemar> #topic Feature proposal freeze is today
18:38:50 <amakarov> stevemar, a title for a new book?
18:38:54 <bknudson> let's just have ayoung write all the code
18:38:54 <dstanek> stevemar: you can't please everyone so you shouldn't even try
18:38:55 <stevemar> amakarov: lol
18:39:10 <stevemar> No patch up for review for a feature (spec or blueprint)? The feature will now target N.
18:39:22 <ayoung> bknudson, just approve my patches without all the nitpicking would be a good start
18:39:25 <stevemar> i don't think we have any folks in danger of that... ?
18:39:30 * ayoung done whining
18:39:41 <breton> stevemar: if it's not merged or not proposed?
18:39:45 <stevemar> #link  http://docs.openstack.org/releases/schedules/mitaka.html#keystone
18:39:54 <stevemar> breton: proposed
18:40:13 <stevemar> breton: if there was a feature, and there is NO code for it (as of today), it's being pushed to N
18:40:40 <henrynash> stevemar: quite right to
18:40:54 <stevemar> we're also approaching mitaka-2 deadline
18:41:05 <stevemar> so anything that isn't GATING today, will be pushed to mitaka-3
18:41:08 <bknudson> can we propose specs to N?
18:41:21 <stevemar> bknudson: sure
18:41:51 <stevemar> the mitaka-2 to mitaka-3 change isn't a big deal. you now have a few more works to get things ironed out
18:41:57 <stevemar> weeks*
18:42:23 <stevemar> i already moved shadow users and domain specific roles (and a few others) to mitaka-3: https://launchpad.net/keystone/+milestone/mitaka-3
18:42:36 <stevemar> for a snapshot of what's going into mitaka-2, here: https://launchpad.net/keystone/+milestone/mitaka-2
18:42:57 <gyee> implied roles made it!
18:43:19 <stevemar> ayoung tjcocozz samueldmq, you guys are on the border, if you get your patches +A'ed today, then y'all have made it
18:43:29 <stevemar> gyee: there are 2 patches for implied roles :)
18:43:48 <gyee> thought they are both A+ed, lemme check
18:43:56 <ayoung> then approve the damn thing and file bugs
18:44:08 <samueldmq> stevemar: + one I will on to eal with circular references :) nits may be fixed later
18:44:21 <samueldmq> ayoung: lol
18:44:22 <stevemar> yep
18:44:33 <ayoung> seriosusly, it is about 50 lines fo code...and 300 of unit tests
18:44:46 <stevemar> i thought there'd be more discussion here
18:44:53 <stevemar> everyone needs coffee
18:44:56 <htruta> stevemar: are we makring bps for mitaka-3 today?
18:44:59 <ayoung> close to 400 of tests
18:45:04 <htruta> marking*
18:45:12 <stevemar> htruta: i already marked most
18:45:17 <samueldmq> ayoung: anything else besides  https://review.openstack.org/#/c/242614
18:45:19 <samueldmq> ?
18:45:34 <stevemar> htruta: if they are not in by today, then they will become mitaka-3 as well
18:45:40 <ayoung> samueldmq, well, there is all of henrynash 's patches that depend on it
18:45:52 <samueldmq> ayoung: but that's domain roles
18:45:54 <henrynash> stevemar: the projects acting as domains part of reseller doesn’t appear in either the m2 or m3 lsits (but is tagged for mitaka)….
18:45:56 <samueldmq> ayoung: which is m3
18:45:56 <gyee> ayoung, that's the last patch right? https://review.openstack.org/#/c/264260/
18:46:02 <stevemar> breton: btw, you owe me a release not for truncated stuff
18:46:14 <stevemar> henrynash: link me?
18:46:15 <ayoung> gyee, that is driver, then the API is https://review.openstack.org/#/c/242614
18:46:15 <htruta> stevemar: nice
18:46:16 <breton> stevemar: will do
18:46:20 <ayoung> useless without API going in
18:46:35 <gyee> ayoung, why  its a different topic?
18:46:35 <stevemar> henrynash: it'll target mitaka-3 likely
18:46:41 <ayoung> gyee, NPI
18:46:44 <samueldmq> gyee: are you confused with new gui ? (I am )
18:46:52 <henrynash> stevemar: https://blueprints.launchpad.net/keystone/+spec/reseller
18:46:57 <gyee> samueldmq, I was going by the "topic"
18:47:06 <henrynash> steevmar: yes m3
18:47:06 <gyee> and I only see 3 patches for implied roles
18:47:11 <stevemar> henrynash: ok
18:47:12 <ayoung> gyee, I blame henrynash as he rebased his changes on mine, and I think he grabbed the topic
18:47:22 <stevemar> ayoung: probably
18:47:24 <henrynash> ayoung: moi?
18:47:38 <stevemar> next topic!
18:47:41 <stevemar> #topic Removing Role LDAP backend
18:47:53 <stevemar> notmorgan: you wanna take this one? i'm tired of typing :P
18:48:03 <bknudson> Role LDAP backend seems useles
18:48:05 <bknudson> useless
18:48:28 <gyee> ya think?
18:48:40 <notmorgan> yes
18:48:43 <notmorgan> it is useless
18:48:46 <stevemar> so, we decided back in K to remove Assignment and Resource LDAP backends, which we have been emiting deprecations for We are removing the Assignment and Resource LDAP backends here: https://review.openstack.org/#/c/231872
18:48:47 <notmorgan> we should kill it
18:49:01 * topol I'm still waiting for gyee to deliver the one and only best schema for it
18:49:05 <notmorgan> basically what stevemar just said.
18:49:11 <ayoung> It can go away
18:49:18 <stevemar> but when we split assignment into role and assignment, we messed up and didn't emit deprecations for role LDAP
18:49:23 <dstanek> ++ to killing it
18:49:33 <stevemar> there's a seperate patch to kill it: https://review.openstack.org/#/c/269385/
18:49:42 <gyee> topol, its posixGroup :-)
18:49:45 <stevemar> i think it's broken if you don't have assignment in there anyway
18:49:47 <ayoung> henrynash, TBH, I would be happier with DSRs under the Implied role topic, to make clear to people that it is one continuous path
18:49:51 <bknudson> maybe we can just say it's implied in the other deprecations
18:49:59 <stevemar> bknudson: i think so
18:50:12 <stevemar> okay, it seems unanimous, we can kill it
18:50:12 <henrynash> stevemar, bknudson: agreed
18:50:28 <stevemar> it's in the release note
18:50:34 <gyee> killing it softly
18:50:42 <stevemar> gyee: ripping it out isn't soft
18:50:47 <bknudson> we'll see if anybody notices
18:50:48 <stevemar> lets give lhcheng and raildo some time
18:50:52 <lbragstad> notmorgan dstanek lets remove it, consolidate the tests and simplify the code
18:50:52 <stevemar> #topic Adding parent_id in the token
18:50:53 <notmorgan> and it was also referenced in the email
18:50:54 <ayoung> bknudson, that is correct.  It is implied; roles were part of assignemtn when we said we were goimng to deprecate assignemnt LDAP backend
18:50:59 <ayoung> stevemar, -2
18:51:01 <notmorgan> that was sent >1yr ago
18:51:05 <ayoung> no parent in token
18:51:26 <stevemar> ayoung: i'll bite, why?
18:51:28 <henrynash> ayoung: I’m not fussed either way….although if we change it I’ll probably mess it up with git again :-)
18:51:29 <raildo> so, we found a bug on cinder, and we have the same issue on nova
18:51:32 <raildo> #link https://bugs.launchpad.net/cinder/+bug/1531502
18:51:33 <openstack> Launchpad bug 1531502 in Cinder "Child project's default quota not enforced" [High,New] - Assigned to Ryan McNair (rdmcnair)
18:51:36 <ayoung> stevemar, it is neither necessary nor sufficient
18:51:47 <ayoung> you need quota, just knowing the parent is not sufficient
18:52:11 <ayoung> if there is a tree, you need to know the whole tree to calc quota
18:52:25 <ayoung> so, let's say in keystone I make the following:
18:52:38 <ayoung> Domain1->p1->p2->p3->4
18:52:39 <gyee> ayoung, why the whole tree if you only set the quota on the domain?
18:52:41 <bknudson> from memory, the projects were going to have a cache of the project hierarchy that they could consult
18:52:53 <lhcheng> cinder/nova needs to make a call to GET project to fetch the parent_id for the quota calculation. however, our policy rule is too restrictive for the GET project.
18:52:56 <ayoung> and I want to check quota on p4, which is inherited from p1
18:53:03 <henrynash> stevemar, ayoung: so to bit more…is it that without parent in the token someone can’t build the tree, or that they want to be “efficient” and not have to call keystone build a tree each time?
18:53:07 <ayoung> they need to know more than just p3->p4
18:53:11 <raildo> ayoung: for now, you can just change quota for the immediate child, so the parent_id will be enough for now
18:53:32 <ayoung> henrynash, right, you can't build enouigh of the tree to matter
18:53:50 <amakarov> bknudson, or they should contain this information in the model: https://review.openstack.org/#/c/251445/
18:53:54 <ayoung> raildo, so...set quota should be using a parent scoped token.
18:53:57 <samueldmq> stevemar: not sure I understood it well, but I had a patch for deprecating role api and I got a -1 hence that wasn't fair to deployers to remove it in +1 ?
18:54:00 <ayoung> not child
18:54:10 <ayoung> use my example above
18:54:24 <ayoung> say I have a role on p1 that lets me change quota
18:54:26 <lhcheng> ayoung: the quota check is only applied to its direct parent, so only need to know p4-> p3
18:54:38 <raildo> ayoung: and they use aparent scoped token for set, but a member user can't get quota for their project...
18:54:42 <ayoung> lhcheng, circular reasoning
18:54:43 <raildo> ayoung: that is the problem
18:54:52 <ayoung> the check is on applied because they wrote this request this way
18:55:00 <ayoung> it is neither necessary nor sufficient
18:55:37 <gyee> raildo, you want to put up a POC patch to show ayoung it is sufficient?
18:55:45 <ayoung> If I get a token scoped to P3 in order to "pull down" quota
18:55:59 <ayoung> gyee, it is a recursive problem
18:56:10 <gyee> otherwise, we are just arguing abstract
18:56:13 <raildo> gyee: sure, I can do that, and we can discuss this next week
18:56:31 <ayoung> if I call set quota on P4, I need a token scoped to P3, and the service needs to query the tree from p3 up to Domain1
18:56:49 <mc_nair> so the particular issue is also with enforcement of default child quotas.  User creates a volume, we know to use the default quota cause none is set.  All we need to know is should defaults be child defaults (all 0s) or not. We don't have any way to grab the project from keystone because volume create isn't an admin operation.
18:57:13 <lbragstad> 3 minutes left
18:57:33 <bknudson> implement a way to get the project from keystone.
18:57:39 <bknudson> we make changes to keystone all the time.
18:57:55 <ayoung> bknudson, I thought we had a query to get the whole tree?
18:58:03 <gyee> we do
18:58:07 <bknudson> yes, we do have a query to get the whole tree
18:58:10 <raildo> bknudson: we already implemented, the problem is that to get the project, you must need to be admin
18:58:10 <ayoung> then they should use that
18:58:13 <mc_nair> bknudson: that's another option, to let get_project be a non-admin command (can get your current project).
18:58:17 <bknudson> so be admin then
18:58:18 <ayoung> raildo, implied roles
18:58:26 <stevemar> or change the policy
18:58:30 <ayoung> don't try to fix things by working around RBAC
18:58:31 <lhcheng> isn't that a privileged query? - GET project
18:58:32 <bknudson> what's stopping someone from being admin?
18:58:34 <mc_nair> but then we need to hit that API on any volume create, nova create, etc
18:58:45 <ayoung> mc_nair, yes you do
18:58:46 <ayoung> and?
18:58:51 <dolphm> lhcheng: why?
18:59:20 <dolphm> it's just a read, and the IDs aren't guessable
18:59:20 <stevemar> we're at time folks
18:59:22 <ayoung> anything that does a quota check, where the quota is not yet set for the project.  You need to know the tree. But the trees are immutable, so cache them
18:59:32 <lhcheng> dolphm: right now it is privileged, maybe it should be less restrictive
18:59:36 <stevemar> lets leave and give the room to infra
18:59:40 <stevemar> continue in -keystone
18:59:46 <stevemar> #endmeeting