18:00:03 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue May 23 18:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:06 <openstack> The meeting name has been set to 'keystone'
18:00:11 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius
18:00:16 <edmondsw> o/
18:00:18 <rodrigods> hey
18:00:20 <spilla> o/
18:00:27 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:28 <hrybacki> o/
18:00:41 <lbragstad> o/
18:01:01 <gagehugo> o/
18:01:10 <lamt> o/
18:01:44 <lbragstad> #topic Updating keystone's documentation theme
18:02:03 <lbragstad> ping Samriddhi ?
18:02:15 <lbragstad> asettle: ^
18:02:21 <gagehugo> I put it on there just in case there is no reason to do this
18:02:43 <gagehugo> Samriddhi is making the changes
18:02:46 <lbragstad> gagehugo: ah
18:03:17 <lbragstad> gagehugo: i haven't seen these changes yet - is this the new theme for all projects to move to?
18:03:33 <gagehugo> I think so
18:03:35 <rodrigods> can I add a doc convo after the theme discussion?
18:03:58 <lbragstad> rodrigods: sure
18:04:04 <rodrigods> cool
18:04:06 <lbragstad> rodrigods: we should be able to get through all the topics today
18:04:27 <lbragstad> gagehugo: has the general direction of moving to this new theme be documented somewhere?
18:04:38 <gagehugo> lbragstad no idea :(
18:04:46 <knikolla> o/ i'm late
18:04:49 <lbragstad> gagehugo: ah - no worries
18:04:50 <gagehugo> idea was more to just bring this to our attention
18:05:03 <lbragstad> gagehugo: if it is - it would be nice to track that down so that we can include it in the commit
18:05:17 <lbragstad> gagehugo: i can leave a comment
18:05:23 <gagehugo> lbragstad sounds good
18:05:48 <gagehugo> there is a comment saying that the plan is to get all project using this theme on that change
18:05:59 <samueldmq> hi, sorry I am late
18:06:03 <gagehugo> but idk where there is documentation for it
18:06:07 <rodrigods> the new theme is much nicer, btw
18:06:13 <gagehugo> rodrigods ++
18:06:15 <rodrigods> material design? :) heh
18:06:18 <lbragstad> sweet - i let a comment
18:06:33 <lbragstad> we can iterate on it in review - thanks gagehugo for bringing it up
18:06:42 <gagehugo> sounds good!
18:06:46 <samueldmq> #thanks https://review.openstack.org/#/c/466066/
18:06:48 <samueldmq> oops
18:06:50 <samueldmq> #link https://review.openstack.org/#/c/466066/
18:07:07 <lbragstad> rodrigods: do you want to do your topic now?
18:07:08 <samueldmq> lbragstad ^ I think I added you to the review, but I should have pinged you on IRC
18:07:14 <rodrigods> lbragstad, sure!
18:07:19 <rodrigods> speaking of docs...
18:07:27 <lbragstad> rodrigods: sure - go for it
18:07:43 <rodrigods> please take a look at https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:tests_development_docs
18:07:59 <rodrigods> no reviews for a while
18:08:14 <lbragstad> #topic review requests for functional testing documentation
18:08:23 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:tests_development_docs
18:08:26 <lbragstad> rodrigods: ++
18:08:31 <rodrigods> thanks lbragstad
18:08:40 <lbragstad> rodrigods: thank you for the reminder
18:08:52 <lbragstad> rodrigods: is there anything else you need on that front besides reviews?
18:09:19 <rodrigods> lbragstad, i think reviews are enough
18:09:30 <rodrigods> specially for those who haven't touched the functional tests
18:09:42 <lbragstad> rodrigods: cool - thanks
18:09:48 <lbragstad> #topic Microversion header bug
18:09:54 <lbragstad> #link https://bugs.launchpad.net/keystone/+bug/1689644
18:09:56 <openstack> Launchpad bug 1689644 in OpenStack Identity (keystone) "Keystone does not report microversion headers" [Undecided,New] - Assigned to Jaewoo Park (aselius)
18:09:57 <lbragstad> nhelgeson: o/
18:10:09 <aselius> o/
18:10:19 <nhelgeson> o/
18:10:37 <nhelgeson> uh
18:11:04 <nhelgeson> So I have been working on finding a way to implement versioning in the header
18:11:05 <ayoung> I reported that based on the convo at the summit
18:11:23 <ayoung> I really don't care about it, but wanted to make sure we didn't lose the concept
18:11:24 <nhelgeson> and I was wondering about where the code should be added
18:11:43 <nhelgeson> I found a way to add some version info in the header
18:11:45 <lbragstad> nhelgeson: ayoung ah - this must have been in the microversion session?
18:11:49 <nhelgeson> so I can leave it at that for now
18:11:52 <ayoung> nhelgeson, yep
18:11:59 <lbragstad> nhelgeson: do you have a patch up for review?
18:12:03 <nhelgeson> not yet
18:12:10 <edmondsw> I don't know that I really care, but at the PTG all the keystone cores seemed pretty anti-microversions
18:12:21 <ayoung> we should probably put it in common/WSGI.py  somewhere, right?
18:12:34 <nhelgeson> thats where I am looking at the moment
18:12:41 <gagehugo> edmondsw I think it was more we don't really "need" them atm
18:12:44 <lbragstad> ayoung: most likely, or the common controller layer at the very least
18:12:53 <ayoung> edmondsw, I think the reason they wanted it was so that a common client code could be written for the others and for Keystone
18:13:09 <knikolla> i sent a link on irc the last time this was asked, let me look it up
18:13:11 <ayoung> probably the right thing to do, not a burning issue
18:13:31 <edmondsw> there are pretty good arguments that microversions are a mistake and make things more difficult for users rather than less...
18:13:49 <lbragstad> robcresswell: has a bunch of opinions on them
18:14:03 <nhelgeson> right now im looking at adding a few lines to the render_response on line 746
18:14:05 <lbragstad> which he represented at both the PTG and forum
18:14:34 <knikolla> #link https://github.com/openstack/keystone/blob/1c44a3a1af5a9e3e48f6799b3006f02dada3341f/keystone/common/wsgi.py#L710
18:14:59 <nhelgeson> just figuring out how to include the request version in the header
18:15:24 <ayoung> edmondsw, I'm kindof of the mindset that at least we should be consistent, that there is very little completely right about our APIs anyway
18:15:34 <lbragstad> nhelgeson: feel free to propose something for review
18:15:53 <nhelgeson> ill post a fix by the end of the week
18:15:57 <lbragstad> but this doesn't require us to *implement* microversions does it?
18:16:10 <robcresswell> I *think* dtroyer was working on making some of the code more common.
18:16:14 <ayoung> lbragstad, just "report" I think
18:16:19 <robcresswell> Which alleviates one of my issues with the implementation, at least.
18:16:21 <lbragstad> ayoung: ok - good
18:16:22 <nhelgeson> at this point is is just going to report the current version and let you know if its current or now
18:16:32 <knikolla> no, this is just for returning the version of our api
18:16:34 <nhelgeson> not*
18:16:39 <ayoung> we can probably manually set a number, and just keep bumping it for now, kindof like what we do elsewhere
18:16:59 <lbragstad> yeah
18:17:03 <knikolla> ayoung: thats the feel i got too
18:17:12 <lbragstad> at least until we figure out what our strategy is long term
18:17:47 <nhelgeson> I was planning on going a step further and getting the version request from the url and checking to see if its v1 v2 or v3
18:18:06 <nhelgeson> and then reporting which one is being used and specifying it as current vs depricated
18:18:07 <ayoung> nhelgeson, take it as far as you can.  We'll review.
18:18:11 <nhelgeson> ok
18:18:31 <lbragstad> nhelgeson: we can address those bit in gerrit, too
18:19:15 <ayoung> all good?
18:19:19 <lbragstad> nhelgeson: is there anything else outside of that?
18:19:19 <knikolla> nhelgeson: that might be unnecessary given that controllers for v3 subclass v3controller
18:19:30 <knikolla> so they have a common base class
18:19:37 <samueldmq> Yeah, just returning the version and making cp happy wouldn't hurt
18:19:41 <nhelgeson> nope
18:19:45 <lbragstad> cool
18:19:47 <nhelgeson> ill post something in gerrit
18:19:53 <samueldmq> nhelgeson: ++
18:19:56 <lbragstad> #topic Project Tag Spec
18:19:58 <nhelgeson> and we can go from there
18:20:03 <lbragstad> #link https://review.openstack.org/#/c/431785/
18:20:06 <lbragstad> gagehugo: o/
18:20:12 <ayoung> So, tags are very like labels in Kubernetes
18:20:37 <lbragstad> last i checked cmurphy had a couple comments on that spec
18:20:55 <lbragstad> so did samueldmq
18:21:02 <samueldmq> who's looking for that?
18:21:21 <samueldmq> I guess it's been a while, but if it's something people want and it's the best way I wouldn't be against it
18:21:29 <lbragstad> samueldmq: who wants tags?
18:21:29 <ayoung> I think I am for it
18:21:50 <gagehugo> lbragstad yeah we made some updates, hadn't touched it since before the summit
18:21:51 <ayoung> it provides users a non-hierarchical way to organize projects, and people have asked for that for a while.
18:22:25 <ayoung> I did have a suggestion that we call them labels to be consistant with Kubernetes, but since we really are not anywhere else, its a small thing
18:22:40 <lbragstad> gagehugo: i'll review it again
18:22:53 <edmondsw> I think other places in OpenStack, e.g. nova, use the "tags" term
18:22:55 <samueldmq> lbragstad: yes, who wants it
18:23:10 <lbragstad> samueldmq: gagehugo has proposed it for a couple releases now
18:23:21 <gagehugo> edmondsw yeah, this spec closely follows the API-WG one for having resource tags
18:23:28 <lbragstad> edmondsw: yeah - so does neutron i think
18:23:33 <samueldmq> for easing management when you k's of projects correct?
18:23:56 <ayoung> yep
18:24:04 <gagehugo> samueldmq yes
18:24:12 <samueldmq> nice, so perhaps nobody is against it, pretty much a "hey, review it"
18:24:12 <ayoung> any lessons learned we sould apply here?
18:24:13 <lbragstad> samueldmq: yeah - like i could take projects hosting my production app with a 'prod' tag for example
18:24:32 <samueldmq> lbragstad: that way you could easily create groups of projects
18:24:34 <ayoung> Ah...I remember the trick
18:24:35 <lbragstad> i found the API-WG guidelines to be really helpful when reviewing gagehugo proposal
18:24:41 <ayoung> "who owns the label"
18:25:00 <samueldmq> ayoung: the project
18:25:01 <samueldmq> ?
18:25:05 <knikolla> project owns the label, applied by admins
18:25:07 <knikolla> i think
18:25:17 <samueldmq> knikolla: that's how I see it too
18:25:18 <lbragstad> ayoung: last i remember, we wanted that to be owned by the person who has the ability to create and modify projects
18:25:19 <ayoung> let me try that again.
18:25:33 <ayoung> lets say I have a label called "production"
18:25:37 <lbragstad> knikolla: only by default
18:25:40 <ayoung> can anyone add that label to their project?
18:25:45 <lbragstad> knikolla: if someone wants to change it they can
18:26:05 <lbragstad> but by default, regular users shouldn't have the ability to list tags on a project
18:26:09 <lbragstad> ayoung: no
18:26:27 <samueldmq> and it only make sense to add tags
18:26:32 <samueldmq> if you have the rights to list projects
18:26:34 <ayoung> ok, then who?
18:26:35 <knikolla> lbragstad: yes, updating policy they can restrict or open it up as much as they want
18:26:48 <samueldmq> because that's where filtering projects by tags will be useful
18:27:02 <gagehugo> samueldmq ++
18:27:04 <samueldmq> ayoung: I'd say domain and cloud admins
18:27:17 <lbragstad> sure - i agree that would be useful
18:27:28 <lbragstad> but we don't have that worked into our default policy yet
18:27:44 <knikolla> we recently found a project from a class project of a year ago just sitting there. tags would have been useful
18:28:20 <lbragstad> i was thinking that the required role to add and remove tags would be equivalent to the default we use for projects
18:28:35 <ayoung> I suspect ability to create tags, to add a tag to a project, and to remove tags will all come up in RBAC discussions in the future
18:28:39 <edmondsw> lbragstad i.e. admin, not looking at scope?
18:28:46 <gagehugo> ayoung probably
18:28:59 <edmondsw> ayoung ++
18:29:09 <lbragstad> edmondsw: what do you mean?
18:29:28 <ayoung> lbragstad, global admin
18:29:35 <edmondsw> lbragstad today's policy allows any admin to create/edit/delete projects
18:29:37 <ayoung> admin + is_admin_project in newspeak
18:29:51 <knikolla> ++
18:30:08 <ayoung> should tags be considered domain-specific?
18:30:12 <lbragstad> sure - https://github.com/openstack/keystone/blob/master/keystone/common/policies/project.py#L20
18:30:33 <edmondsw> I don't recall whether there is a scope check in the code yet
18:30:37 <ayoung> i.e  there may be a prod tag on projects in two different domains, but they don't mean anything?
18:30:41 <edmondsw> there should be... but probably isn't
18:30:42 <ayoung> er
18:30:47 <ayoung> they are not related to each other?
18:31:01 <edmondsw> then there's the question of whether an admin of a project should be able to change the tag for their project... or only admins of the parent of that project
18:31:12 <samueldmq> well just as assignments we may allow project tags to cross domains boundaries?
18:31:17 <edmondsw> I'd probably lean toward the latter
18:31:33 <knikolla> edmondsw: only admins of the parent i would say
18:31:39 <lbragstad> initially
18:31:49 <edmondsw> just like I'd say that when we get into adding scope checks, you should only be able to create projects under a project/domain that you admin
18:31:51 <lbragstad> eventually it would be nice if that changed as policy evolves
18:31:58 <samueldmq> are we talking about rbac for the future? or for now
18:32:01 <edmondsw> none of that's there today, though
18:32:04 <gagehugo> edmondsw yes
18:32:21 <ayoung> are tags inherited when you make a child project?
18:32:45 <edmondsw> ayoung good question... probably not?
18:32:46 <lbragstad> i would rather restrict the feature (by default) to global admin usage than open up security issues by allowing it to be used by project level assignment
18:32:47 <knikolla> ayoung: i would lean towards no.
18:32:55 <ayoung> Will tags be used for quotas?
18:32:55 <lbragstad> ayoung: i wouldn't think so
18:32:57 <samueldmq> lbragstad: I'd start it simple now and say it's like a project update call/same protection?
18:32:59 <lbragstad> ayoung: no
18:33:09 <samueldmq> and then we evolve it later as policy keeps improving
18:33:11 <ayoung> all those responses are lies.
18:33:17 <ayoung> of course they will be used for quotas
18:33:28 <ayoung> we are going to be burnt by this.
18:33:33 <ayoung> Lets do it!
18:33:38 <edmondsw> ayoung how would they be used for quotas?
18:33:54 <lbragstad> edmondsw: tagging the project with the quota as the tag
18:34:05 <ayoung> edmondsw, why wouldn't they be used for quotas?  Because we tell people not to?  They will ignore us.
18:34:06 <samueldmq> per-tag-quota-driver
18:34:37 <edmondsw> I'm not following... what would enforce a tag value as a quota?
18:34:38 <knikolla> oh god please no. let's just do unified limits already
18:34:50 <lbragstad> knikolla: right
18:35:13 <lbragstad> edmondsw: as an admin i could manage tags on a project for `vcpu_limit:50`
18:35:17 <samueldmq> let me step a bit back, why is project tags better than organizing projects in a tree?
18:35:20 <ayoung> Heh.
18:35:28 <ayoung> samueldmq, it is in addition to a tree
18:35:34 <lbragstad> the dangerous part is if projects build on it to enforce quota in other services
18:35:54 <ayoung> samueldmq, sometimes you have two different org schemes to follow, and a tree can only follow one of them
18:36:09 <samueldmq> ayoung: that's the answer I think
18:36:10 <edmondsw> samueldmq e.g.  you could have multiple "production" projects under wildly different places in the tree
18:36:11 <ayoung> organize by company structure versus organize dev-staging-prod
18:36:19 <samueldmq> we don't enforce same quota to 2 different orgs
18:36:24 <samueldmq> that wouldn't make sense to me
18:36:38 <samueldmq> so quotas on project tags doesn't make sense
18:36:43 <ayoung> samueldmq, its not us
18:36:45 <edmondsw> I'm still missing how this has anything to do with quotas
18:36:50 <knikolla> hence we really need to push for unified limits, so the only way they can do limits is the one we validate
18:36:54 <ayoung> samueldmq, we can never predict how the things we make will be used
18:37:03 <ayoung> unified limits are a pipe dream
18:37:12 <lbragstad> edmondsw: the thing is that it *could be used* to implement quotas based on limits
18:37:13 <samueldmq> ayoung: they'd need to write their per-tag-quota-driver then
18:37:17 <ayoung> pretty sure they are impossible with the way they've been speced
18:37:34 <samueldmq> ayoung: and we can tell them its not what they're up to, if they do not agree they can do whatever they think is better
18:37:53 <ayoung> so long as tagging and untagging a project is a separate api call from creating a project, we can RBAC manage them separately
18:37:55 <edmondsw> lbragstad oh, you mean nova/etc. could use it for something we don't intend... not that an operator could?
18:38:07 <knikolla> edmondsw: yes
18:38:11 <lbragstad> edmondsw: correct
18:38:17 <ayoung> start off with the call very restricted, and then think about if we need an call to create a tag separate from tagging a project
18:38:20 <edmondsw> finally makes sense
18:38:30 <samueldmq> I don't think they will implement anything without really understanding what the thing is for
18:38:41 <ayoung> samueldmq, they never have before
18:38:51 <ayoung> which leads to the next topic on the agenda...
18:39:00 <lbragstad> but... the thing is that we're not going to be validating tags with the tree hierarchy that project limits require (as detailed in the unified limits spec)
18:39:08 <edmondsw> but I don't think that's likely, unless the quota work that's already in process falls apart... they won't want to switch to something totally different and start over their design work
18:39:27 <edmondsw> and what lbragstad just said
18:39:34 <samueldmq> edmondsw: ++
18:39:40 <samueldmq> lets make it happen
18:39:44 <samueldmq> and document it really well
18:39:48 <lbragstad> while it's entirely possible - i'm not sure it would be a good design decision
18:40:11 <lbragstad> but that's totally up to the people consuming this and if that's what they want to do - we can't really stop them
18:40:50 <lbragstad> we *can* move forward with unified limits and promote that as the supported way of solving the problem
18:40:54 <samueldmq> lbragstad: exactly
18:41:23 <samueldmq> and not hesitate on implementing something we need because people may use it on things we haven't planned it for
18:41:34 <samueldmq> it's useful for managing projects, lets go for it
18:41:37 <samueldmq> :-)
18:42:14 <knikolla> i think we need this more than it can hurt us.
18:42:14 <lbragstad> anyone else have anything on project tags?
18:42:27 <ayoung> +2 from me
18:42:50 <lbragstad> #topic super-infamous-bug-that-must-not-be-named-or-cited-by-number
18:43:02 <lbragstad> #link http://adam.younglogic.com/2017/05/fixing-bug-96869/
18:43:10 <lbragstad> ayoung: i assume you added this one?
18:43:10 <samueldmq> would that be 968696?
18:43:17 <ayoung> yep
18:43:42 <ayoung> so...I wrote that up to try and explain to the other projects (namely nova) why they should review our fixes
18:43:58 <ayoung> I had sdague say that he did not understand the approach
18:43:58 <lbragstad> ayoung: looks like it's hot off the press
18:44:02 <gagehugo> ayoung interesting
18:44:09 <ayoung> read it, critique, it might be incoherent
18:44:16 <ayoung> tried to make it as clear and simple as possible
18:44:22 <lbragstad> ayoung: cool
18:44:33 <lbragstad> ayoung: are you planning on presenting this to anyone/
18:44:35 <edmondsw> I'll try to read before our policy mtg tomorrow
18:44:42 <ayoung> lbragstad, nope
18:44:42 <edmondsw> did you ping johnthetubaguy to point it out?
18:44:47 <lbragstad> edmondsw: ++
18:44:51 <ayoung> lbragstad, just pointing people at it when I ask them to review
18:44:54 <lbragstad> ayoung: or sdague?
18:45:04 <ayoung> just finished it last night.  Did send a link to sdague yes
18:45:09 <lbragstad> ayoung: ok
18:45:17 <lbragstad> I will parse it today
18:45:49 <ayoung> thanks.  And critique.  It looked right to me, but It was late, and I've been looking at this way too long
18:46:05 <lbragstad> ayoung: i'm not sure it's possible to leave comments
18:46:14 <gagehugo> ayoung I'll read it over today as well
18:46:17 <lbragstad> ayoung: how do you want us to critique it?
18:46:32 <ayoung> email or pings in IRC will all work, comments on the blog.  Carrier Pidgeon
18:46:39 <lbragstad> ok
18:47:05 <lbragstad> Alaskan sled dog is becoming my new favorite way to deliver super important messages
18:47:22 <ayoung> I'd like to put this to rest. The bug is tagged high or critical everywhere, except nova, that has tagged it as a wishlist item
18:47:34 <ayoung> I would like to point out that this is their bug.  THis bug is older than Keystone
18:47:44 <ayoung> it goes back to when identity was in Nova
18:48:16 <ayoung> lbragstad, Malamutes or Huskies are both acceptable. Dog friendly household here.
18:48:40 <lbragstad> fwiw - i started working on OpenStack two months before that bug was opened... not sure how that makes me feel ;)
18:49:09 <lbragstad> #topic open discussion
18:49:21 <ayoung> lbragstad, I'm pretty sure I know. Its been assigned to me that whole time, except where people grab it for short spurts
18:49:33 <lbragstad> the floor is open if anyone has something
18:49:52 <knikolla> anybody knows if they're making the ptg yet?
18:49:59 <knikolla> making it to*
18:50:09 <gagehugo> knikolla no idea
18:50:14 <lbragstad> knikolla: not sure yet - planning on it but I hope to know more this week
18:50:16 <samueldmq> knikolla: I don't, too early yet
18:50:25 <edmondsw> knikolla I expect to be there but not sure yet
18:50:26 <samueldmq> but I am working on getting approval already
18:51:24 <knikolla> hopefully a lot of us make it
18:51:27 <knikolla> i got approval for it
18:51:35 <lbragstad> knikolla: sweet
18:51:50 <lbragstad> fwiw - it's sept 11 - 15
18:52:34 <lbragstad> anyone have anything else?
18:53:08 <lbragstad> cool - well thanks for coming!
18:53:11 <lbragstad> #endmeeting