15:00:00 <jimbaker> #startmeeting craton
15:00:00 <openstack> Meeting started Mon Nov 21 15:00:00 2016 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:04 <openstack> The meeting name has been set to 'craton'
15:01:22 <jimbaker> #topic roll call
15:04:03 <palendae> Here-ish
15:04:10 <jimbaker> palendae, o/
15:04:14 <sigmavirus> o/
15:04:56 <jimbaker> hope everyone is having a great monday after the weekend. also just a quick reminder: no vidyo meeting this thanksgiving ;)
15:05:22 <jimbaker> (thurs for those not in the US)
15:06:03 <jimbaker> just waiting on sulo at this point, but he's online, so he will have the log
15:06:29 <jimbaker> #topic plans for the week
15:06:46 <jimbaker> it's a short week. but hopefully good progress
15:07:06 <jimbaker> i will start
15:07:20 <jimbaker> sulo, sigmavirus - i need a review of https://review.openstack.org/#/c/399305/
15:07:49 <jimbaker> this is the predecessor change for adding support for virtualized variables
15:08:30 <jimbaker> (which will simply work by registering new objects in the resolution_order)
15:09:01 <jimbaker> so more of a plugin scheme than anything else
15:09:19 <jimbaker> also on friday i made good progress on rbac modeling, so should have that written up real soon now
15:09:49 <jimbaker> lastly i will send out the roadmap this week, after working on it with dusty
15:10:53 <jimbaker> we can dive into the details of all three after this part of the meeting
15:11:00 <jimbaker> sigmavirus, what about your forthcoming week?
15:12:41 <sigmavirus> This week is looking busy for me,
15:12:50 <sigmavirus> But I have some work queued up around the roadmap and client
15:14:01 <jimbaker> sigmavirus, maybe a good week to be busy, depending on if any travel plans (i have none, so easy for me)
15:15:19 <jimbaker> ok, this could be a super short meeting today. which is fine
15:15:36 <jimbaker> #topic rbac
15:16:08 <jimbaker> sigmavirus, so i spent some time reviewing my notes on rbac from the summer; and going through oslo.policy details
15:17:05 <sigmavirus> okay
15:17:08 <jimbaker> right now, i'm planning to implement a mixin for our sqlalchemy objects such that a polymorphic association is created between a given object and a role
15:18:08 <jimbaker> if some ancestor object has that role, this implies the object has the role. self of course is implicit
15:18:53 <jimbaker> i believe it should just all work. but let's see in a forthcoming blueprint + change(s) to be reviewed
15:19:01 <sigmavirus> hm, so, for policy work I'd think we'd want to have some constraints that can't be enforced with polymorphic associations
15:19:24 <sigmavirus> having foreign key constraints would mean it'd be harder for a malicious admin to manipulate role data
15:19:25 <jimbaker> sigmavirus, i would assume said constraints go in a policy.json file
15:19:42 <jimbaker> ahh, different constraints
15:19:55 <sigmavirus> yeah, what goes into a policy.json file is a rule
15:20:00 <sigmavirus> (or a collection of rules)
15:20:04 <jimbaker> so polymorphic association actually does the fk stuff
15:20:10 <sigmavirus> (at least that's how we talk about them usually)
15:20:46 <sigmavirus> so I was under the impression you couldn't enforce foreign key constraints with polymorphic associations
15:20:49 <jimbaker> sigmavirus, right, for deriving roles from other roles. hence my confusion re "constraints" (which is somewhat loaded)
15:21:03 <jimbaker> sigmavirus, no that's the beauty of doing polymorphic associations correctly
15:21:28 * sigmavirus isn't a db expert, hence why I'm asking :)
15:21:29 <jimbaker> in particular, this is how we implement variables
15:22:39 <jimbaker> one question is: are we just redoing the variable machinery? i don't believe so. also there's something to be said in the relational model of making relationships be explicit, vs implied through code
15:22:54 <jimbaker> variables are fantastic. not everything should be a variable
15:23:53 <sigmavirus> So, I just worry that if an operator needs to start debugging craton at the db layer, this is going to be as clear as mud to them what's happening
15:24:00 <jimbaker> sigmavirus, old post by mike bayer on this subject - http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/
15:24:24 <sigmavirus> And I'm worried we're reaching for polymorphic associations a lot, almost as though everything's a nail we can fix with that hammer
15:24:53 <jimbaker> sigmavirus, that's a good point. but that sounds like a doc issue to me
15:25:26 <jimbaker> i see it is an inherent when we want to apply a common sort of approach to our code
15:26:13 <jimbaker> we have certainly embraced the polymorphic approach in our modeling. i think it has worked well in terms of its modeling elegance
15:26:42 * jimbaker is planning to propose a sqlalchemy topic for pycon, fwiw
15:26:52 <jimbaker> s/topic/talk/
15:28:14 <jimbaker> sigmavirus, the flip side is that not having duplicated code probably means greater robustness. the only place where a bug has arisen in variables to my knowledge is where we duplicated code
15:28:42 <jimbaker> hence the refactoring patch i proposed for resolution_order :)
15:28:44 <sigmavirus> okay, just making sure we're taking a step back and introspecting :)
15:28:56 <jimbaker> sigmavirus, hey, that's the point of the review process
15:29:21 <jimbaker> nothing is going to get just dumped in to the project
15:31:36 <jimbaker> sulo, around?
15:32:56 <jimbaker> sigmavirus, i think we can just end the meeting early
15:33:07 <sigmavirus> jimbaker: works for me :)
15:33:30 <jimbaker> cool. i will sync up with syed, jovon, sulo later
15:33:39 <jimbaker> #endmeeting