18:00:03 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue Jul 25 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 <knikolla> o/
18:00:12 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, notmorgan, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:18 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:22 <lbragstad> agenda ^
18:00:23 <rodrigods> hey
18:00:24 <spilla> o/
18:00:28 <samueldmq> hi o/
18:00:29 <lamt> o/
18:00:41 <gagehugo> o/
18:01:31 <rderose> o/
18:01:45 <lbragstad> #topic announcements: feature status
18:02:21 <lbragstad> #link https://blueprints.launchpad.net/keystone/pike
18:02:34 <lbragstad> this week is the deadline for all feature work
18:02:51 <lbragstad> the biggest changes we have to go through is the project tags implementation
18:03:07 <lbragstad> it looks like most of that is getting broken into smaller patch sets though
18:03:25 <rodrigods> is everything in the same topic?
18:03:31 <rodrigods> on gerrit, i mean
18:03:36 <gagehugo> should be
18:03:39 <rodrigods> cool
18:03:47 <gagehugo> https://review.openstack.org/#/q/topic:bp/project-tags
18:03:51 <rodrigods> thanks gagehugo
18:04:05 <raildo> o/
18:04:10 <samueldmq> lbragstad: gagehugo I added a topic at the end to talk a bit on how we implement that
18:04:26 <samueldmq> I have some suggestions/questions. would be great to discuss here
18:04:40 <gagehugo> sounds good
18:05:20 <lbragstad> I'll propose app creds and extend user API to support federated attributes to backlog
18:05:57 * samueldmq nods
18:06:03 <samueldmq> that makes sense to me
18:06:29 <lbragstad> #info application credentials will be bumped to Queens
18:06:48 <lbragstad> #info extending the user API to support federated attributes will be bumped to Queens
18:06:56 <lbragstad> #topic announcements: bugs
18:07:30 <lbragstad> by EOW we're going to be in full bug mode
18:07:43 <lbragstad> #link https://etherpad.openstack.org/p/keystone-pike-bugs
18:07:55 <lbragstad> i'm going through all bugs opened in PIke and prioritizing accordingly
18:08:12 <lbragstad> by the end of today - i should have a list of things targeted to pike-rc1
18:08:27 <lbragstad> out target week for rc1 is going to be August 11th
18:08:37 <lbragstad> which is about 3 weeks away
18:09:15 <lbragstad> #topic default roles for domains
18:09:20 <lbragstad> dpar o/
18:09:27 <lbragstad> this was on our agenda last week too
18:10:01 <lbragstad> we'll circle back if dpar shows up
18:10:07 <lbragstad> #topic project tags
18:10:12 <lbragstad> samueldmq: gagehugo o/
18:10:32 <samueldmq> so, I was discussing a few points with gagehugo (and others involved)
18:10:38 <samueldmq> regarding the current implementation
18:10:57 <samueldmq> 1) do we really need separate policies for the project-tags operations?
18:11:24 <samueldmq> why not re-use the project's ones ? same rule of project_update for updating tags, for examples
18:11:27 <samueldmq> example*
18:11:33 <knikolla> probably we do.
18:11:36 <samueldmq> since tags IS an attribute of a project
18:12:01 <samueldmq> we don't control any other attribute differently
18:12:10 <samueldmq> why are tags that special?
18:12:58 <gagehugo> are there other attributes that have their own urls?
18:13:04 <lbragstad> i don't think so
18:13:07 <knikolla> i generally like the granularity.
18:13:21 <lbragstad> eventually it would be great to be more granular
18:13:30 <lbragstad> but we have so much work todo before we get to that point
18:13:34 <knikolla> also allows special project management software to be tied in without being given the keys to the cloud.
18:13:42 <gagehugo> the current implementation makes the new rules default to what projects is
18:14:00 <gagehugo> the naming of that rule_project_admin_required isn't very good
18:14:28 <samueldmq> I'd go for re-using what we have (and being consistent with the rest of the attributes)
18:14:51 <gagehugo> we would have to hack the protector then wouldn't we to do something special for project tags?
18:14:56 <samueldmq> when we get to better policies (more granular), I hope we will be able to be more granular and check on the attributes
18:14:57 <lbragstad> maybe a better question is - how hard would it be to break that out later and have project tags be separate?
18:15:24 <knikolla> if we're eventually going to more granular policies, why not start now with this?
18:15:42 <gagehugo> knikolla that's what we thought
18:15:50 <gagehugo> this will probably have to be changed in the future
18:15:58 <gagehugo> it is weird though, tags is an attribute
18:16:19 <samueldmq> knikolla: would be great to figure out how we will do that
18:16:33 <samueldmq> maybe we will have the same policy, but will allow to check on different attributes within the policy rule
18:16:33 <gagehugo> but it stands on it's own behind the scenes
18:16:45 <samueldmq> I wouldnt change that all of a sudden.
18:16:59 <samueldmq> and as pointed out by lbragstad, we can always expand that into several rules later
18:17:09 <samueldmq> if that's what we want, and how we decide to go for more granular access
18:17:23 <lbragstad> if we're restrictive to start out, it's easy to loosen the constraint later
18:17:29 <samueldmq> can you imagine if we start adding new policy rules per resource'attribute
18:17:31 <lbragstad> s/easy/easier/
18:17:58 <knikolla> do you see other use cases for project attributes? and something that we will add often?
18:18:03 <samueldmq> ig you think from the API point of view, tags is just a regular attribute of projects
18:18:07 <knikolla> i thought that was specifically shut down previously
18:18:08 <samueldmq> at least this is how I see them
18:18:14 <knikolla> and tags was the most people agreed to add to projects
18:19:19 <samueldmq> I am not disagreeing on adding tags to projects
18:19:25 <gagehugo> so we can hack in to have tags follow the project policy, then fix it later.  Or just create the rules now and be different from other attributes?
18:19:51 <samueldmq> if we make it special/different, there is no way to get back from that.
18:20:08 <samueldmq> specially because we dont have a deprecation workflow for policy rules yet
18:20:28 <lbragstad> gagehugo: your project admins are going to be the ones using project tags, right?
18:20:32 <samueldmq> starting how we do it nowadays, and making more granular (as we discover how to do that ) would be better imo
18:20:41 <lbragstad> gagehugo: you don't need to have a separate role defined to manage project tags?
18:21:02 <gagehugo> lbragstad ours will be yes, others might not?
18:21:30 <lbragstad> if you reuse the project policies, does that require hacking the protected method?
18:21:45 <gagehugo> That's what it looks like
18:22:07 <gagehugo> will have to make a special case for if tags, enforce project policy
18:22:08 <lbragstad> I'd be inclined to separate the policies specific to get around having a hack for it
18:22:23 <samueldmq> gagehugo: all the new APIs for CRUDing policies are in accordance of what nova did, correct?
18:22:37 <gagehugo> samueldmq for the most part yes
18:23:05 <lbragstad> does nova has a separate policy for tags?
18:23:24 <samueldmq> gagehugo: the part of having separate APIs for handling the tags (adding,removing) within resources...
18:23:52 <lbragstad> i guess it doesn't really make much sense to have operators deal with tag policies in one project and not in another
18:23:53 <samueldmq> lbragstad: that is a good question
18:24:06 <gagehugo> lbragstad yes
18:24:18 <lbragstad> they do have a separate policy for tags?
18:24:22 <gagehugo> https://github.com/openstack/nova/blob/master/nova/policies/server_tags.py
18:24:41 <lbragstad> ah ha
18:25:06 <lbragstad> well - i suppose that's another reason to split it out into it's own policy (for consistency)
18:25:11 <gagehugo> plus separate policies seemed easier than hacking the protector
18:25:24 <gagehugo> which I do agree with samueldmq that it is weird
18:25:39 <gagehugo> since the other attributes don't have them (yet?)
18:26:11 <lbragstad> should we vote?
18:26:20 <lbragstad> or do we have consensus
18:26:47 <samueldmq> I am okay with adding new policies now
18:26:51 <samueldmq> for consistency with nova
18:26:56 <lbragstad> yeah - same here
18:27:07 <samueldmq> would be great to try to use the same names they use
18:27:11 <lbragstad> anyone else have objections to the approach?
18:27:15 <samueldmq> or similar ones for the tags operations
18:27:23 <samueldmq> so that it's not confusing to operators
18:27:30 <gagehugo> samueldmq can def take a look
18:27:35 <samueldmq> and let's add exactly the same operations on tags
18:27:41 <gagehugo> yea
18:27:43 <samueldmq> I guess we dont need to do more than they do
18:28:18 <lbragstad> gagehugo: cool - anything else?
18:28:26 <samueldmq> I think I have somehting else
18:28:31 <samueldmq> just one more detail
18:28:33 <lbragstad> samueldmq: go for it
18:28:52 <samueldmq> why don;t we just re-use the project manager/drivers for handling the tags
18:29:13 <samueldmq> maybe the manager, the driver needs to be separate as we have a different table?
18:29:28 <samueldmq> that's an idea, of course would like to get some views on it
18:29:37 <samueldmq> for the sake of simplifying the implementation
18:30:28 <samueldmq> as of today, they don't share anything than the directory the code is in
18:30:40 <lbragstad> I need to review that change
18:30:46 <samueldmq> nevermind me. I guess it's sane to go for it as it is organized right now
18:30:57 <samueldmq> and if we want to refactor we can do tht
18:31:03 <samueldmq> it isn't a terrible amount of code
18:31:18 <gagehugo> samueldmq it uses the same manager doesn't it?
18:31:29 <lbragstad> yeah - we should be able to refactor it later, we've done that with the project and domain controllers/managers in the past
18:31:41 <samueldmq> lbragstad: ++
18:31:51 <samueldmq> gagehugo: hmm I think so. maybe we could use the same driver?
18:32:10 <samueldmq> I don't think there is a rule that says 1 driver - 1 table. I'd go 1 driver 1 entity.
18:32:21 <samueldmq> and in this case the project is split in more than one table
18:32:32 <samueldmq> but as I said, anyways. this is not the most important thing now
18:32:36 <gagehugo> ok
18:32:43 <samueldmq> the API/policy behavior is the key
18:32:57 <lbragstad> let's shoot to follow the convention nova set
18:33:00 <knikolla> i gave a quick look and it seems sensible the way it's organized.
18:33:00 <lbragstad> with server tags
18:33:16 <samueldmq> lbragstad: ++
18:33:20 <lbragstad> anything else related to project tags?
18:33:29 <samueldmq> gagehugo said he'll look at it and make us consistent
18:33:32 <samueldmq> lbragstad: not from me, thanka
18:33:42 <lbragstad> #topic open discussion
18:33:58 <lbragstad> floor is open
18:33:59 <gagehugo> you can always ping me too about questions, I will be around
18:34:11 <gagehugo> or lamt
18:34:29 <lbragstad> i'll be reviewing that stuff today
18:34:59 <samueldmq> sure, I saw lamt has been updating some of those patches too
18:35:16 <samueldmq> lbragstad: I will be going through the nova api-docs and make sure our implementation is consistent
18:35:19 <samueldmq> that should be enough
18:35:36 <lbragstad> works for me
18:35:47 <lbragstad> looks like we can get some time back before office hours starts
18:36:01 <lbragstad> thanks for coming!
18:36:06 <knikolla> please don't strive for consistency at the expense of other things.
18:36:06 <lbragstad> #endmeeting