14:59:45 <sigmavirus> #startmeeting craton
14:59:46 <openstack> Meeting started Mon Nov 28 14:59:45 2016 UTC and is due to finish in 60 minutes.  The chair is sigmavirus. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:50 <sigmavirus> #chair jimbaker
14:59:51 <openstack> The meeting name has been set to 'craton'
14:59:52 <openstack> Current chairs: jimbaker sigmavirus
15:00:44 <jimbaker> o/
15:01:20 <jimbaker> sulo, sigmavirus, hope you had a nice weekend
15:01:30 <sigmavirus> I did and I hope you did too jimbaker
15:02:17 * sigmavirus goes off in search of our agenda
15:02:26 <sigmavirus> #link https://etherpad.openstack.org/p/craton-meetings
15:02:36 <sigmavirus> Looks like there's no agenda for today
15:03:02 <jimbaker> sigmavirus, ahh, agendas... we have been working off a standing development agenda
15:03:19 <jimbaker> issues that what are working on this week
15:03:32 <sigmavirus> Let's add that to the meeting etherpad then :)
15:03:34 <sigmavirus> (later)
15:03:44 <sigmavirus> #action jimbaker to fill out meeting etherpad with generic meeting schedule
15:03:46 <jimbaker> #action jimbaker adds standing agenda to craton-meetings etherpad
15:03:56 <jimbaker> yep that will do
15:04:45 <jimbaker> so let's go through the forthcoming week
15:05:02 <jimbaker> sulo, i know you were planning to look at workflows again
15:05:08 <jimbaker> anything else on your plate?
15:05:22 <sulo> yep, just stated that today
15:05:28 <jimbaker> (also do ask my help on that patch i gave you re workflow modeling)
15:05:29 <sulo> na i think ill concentrate on that for now
15:05:45 <jimbaker> (as necessary of course)
15:06:24 <sulo> yep, sure, will do
15:06:37 <jimbaker> sulo, we can get back into the details, but workflow is a big enough chunk to mull upon :)
15:06:54 <jimbaker> sigmavirus, any updates on the forthcoming week?
15:07:03 <sigmavirus> Well I'm out starting Wednesday
15:07:12 <sigmavirus> So I'm going to try to do some more tidying aroudn the client and UX improvements
15:07:22 <sigmavirus> Might take over some of Harry's reviews for him while I"m here
15:07:26 <sigmavirus> (if they need taking over)
15:07:40 <jimbaker> sigmavirus, thanks for the reminder, and sounds like a good plan. you will be back next monday?
15:07:53 <sigmavirus> Yes I will
15:07:58 <sulo> sigmavirus: ah right .. i think i have a few -1s there that need tyding up
15:08:04 <sigmavirus> And will be around most of December except the around Christmas
15:08:12 <sigmavirus> sulo: good, I'll look at those
15:08:14 <sulo> thanks
15:08:18 <jimbaker> cool. speaking of such things: i will be out the last 2 weeks of december
15:08:28 <sulo> same .. i am out from the 12th
15:08:34 <sigmavirus> great
15:08:39 <sulo> but i will be online of and on
15:08:43 <sigmavirus> I'm out starting teh friday before Christmas
15:09:19 <jimbaker> sigmavirus can run what will be the very short meeting here when he's around ;)
15:09:23 <sulo> heh this is going to be a slow month :)
15:09:29 <jimbaker> indeed it is
15:09:43 <jimbaker> we will have to account accordingly on the roadmap
15:09:54 <jimbaker> which i don't think really gets impacted
15:09:58 <jimbaker> my turn
15:10:44 <jimbaker> friday i got most of the rbac modeling done within the database. so i have something that's working in terms of assigning roles to arbitrary resources in our model
15:11:29 <jimbaker> there's more to rbac than that, but this was the piece that's really specific to craton
15:12:01 <jimbaker> in particular, one can use an object's resolution_order to describe the scope of a role
15:12:42 <jimbaker> eg, if the role fleet:may-do-X is assigned to a region, then any device in that region has that role
15:14:40 <jimbaker> i've been working out implications for other aspects. so being able to do stuff like, a workflow can be created by one user ("developer"), then is assigned to a region by another ("authorizer"), and then is run by an operator
15:15:34 <jimbaker> so this gets setuid like qualities
15:16:26 <jimbaker> but such implication will be seen in the corresponding policy.json that we construct
15:17:02 <jimbaker> sigmavirus, i hope you don't mind the mixin approach. but it's really very similar to what was done with variables :)
15:19:02 <jimbaker> sulo, i was revisiting governance considerations
15:19:04 <sigmavirus> jimbaker: I haven't seen it, so it's hard to object
15:19:10 <jimbaker> sigmavirus, excellent! :)
15:20:25 <jimbaker> sigmavirus, really it's just a triple (resource, principal, role) - the only subtleties are doing the search path with resolution_order; and making it a mixin via a polymorphic association
15:20:49 <jimbaker> but both follow the approach we have already done with respect to variables
15:20:55 <sigmavirus> okay
15:21:17 <jimbaker> sulo, https://github.com/NerdWalletOSS/versionalchemy is one aspect of governance
15:21:20 <jimbaker> re auditing
15:21:27 <syed__> o/
15:21:57 <jimbaker> that we might want to look at either using, or least seeing if there's something worth borrowing in terms of approach
15:22:00 <jimbaker> syed__, hi
15:22:05 <jimbaker> we were just talking about rbac
15:22:40 <syed__> Hi jim, i hope everyone is doing fine
15:22:47 <jimbaker> so i have worked out the db modeling we need (or at least i think i did); and have enough insight to finalize the blueprint
15:22:58 <syed__> Thats great
15:24:24 <jimbaker> any rbac will be a combination of stuff we model in the database; additional policy rules (policy.json) that do the desired forward chaining; and use of oslo.policy decorators in our rest api
15:25:38 <sigmavirus> so we're planning to register functions for rules, jimbaker ?
15:25:50 <jimbaker> perhaps the biggest remaining subtlety is how it interacts with keystone. users looks straightforward, and it's possible that keystone's groups + domains just look like users when we see it
15:25:52 <jimbaker> sigmavirus, yeah
15:26:07 <sigmavirus> jimbaker: did you ever write up the needs/use cases for this rbac?
15:26:20 <sigmavirus> Also, is there a WIP/POC anywhere with what you have?
15:26:27 <jimbaker> sigmavirus, part of the investigation
15:26:54 <jimbaker> and here's the relevant gist of my WIP for db modeling - https://gist.github.com/jimbaker/6a4fd7e07a16a318a45d7d1d96819040
15:27:41 <jimbaker> sigmavirus, we don't have detailed requirements here. i'm hoping that our discussion with dusty will help precipitate that
15:27:44 <sigmavirus> cool.
15:27:53 <sigmavirus> jimbaker: should we let syed__ provide updates?
15:27:54 <sulo> so just to be clear .. i am not sure i am follwing the rbac thing btw
15:27:56 <jimbaker> the discussion has been "we need rbac"
15:28:07 <sulo> like what are we trying to rbac ?
15:28:16 <sulo> is it every resource ?
15:29:03 <jimbaker> sulo, we need to rbac every resource. the question is, what does that actually mean :)
15:29:19 <sulo> i guess thats what my question is
15:29:39 <jimbaker> sulo, so i'm working on the assumption that we need to divide below the level of a given project
15:30:16 <jimbaker> and the easiest way to model this is to use the idea of triples
15:30:47 <jimbaker> so for a given resource, principal pairing, we can have a set of roles
15:31:19 <jimbaker> because it would be tedious to assign roles for any resource, we need to have some way of providing scope
15:32:17 <jimbaker> for a little further clarity: a principal - this follows what gus observed back in the spring - would be users or workflows
15:33:31 <jimbaker> we can obviously model this a number of ways, including have a workflow subclass a user. whatever makes the most sense
15:34:10 <jimbaker> sulo, hopefully that adds some clarity
15:34:40 <sulo> yeah, makes a bit more sense
15:34:46 <sigmavirus> jimbaker: so I have questions based off of what you said, but I'd like to let syed__ fill us in on what he's done
15:34:52 <sigmavirus> and doing
15:35:03 <jimbaker> sigmavirus, agreed - wanted to close one question out a bit
15:35:17 <jimbaker> syed__, your turn. what are you working on this week?
15:35:41 <jimbaker> the other question is, do you have any vacation plans in december?
15:36:21 <syed__> I will be working over craton endpoint for network tests
15:36:35 <syed__> And craton client stuff, i have been digging into rbac little bit
15:36:47 <syed__> Will close things up in ny court in this week
15:37:01 <syed__> I have to make sure the schema we are using for craton is same as client
15:37:33 <jimbaker> syed__, how does rbac impact the client?
15:38:29 <syed__> I have not yet fully looked into that. I believe once blueprint is out there will help me get my mind around how we are approaching rbac for craton
15:38:30 <jimbaker> i would assume this is just a question of handling 401
15:38:38 <jimbaker> "not authorized"
15:38:45 <syed__> I really dont know about that ... but i guess so
15:39:17 <jimbaker> syed__, no worries, just want to make sure there's not something i haven't considered
15:39:43 <syed__> Adding tests for routes/schemas is also what i will be doing today
15:39:51 <jimbaker> i know for sure that i don't know enough yet about the subtleties of keystone's domain/group model, and implications for integration with craton
15:40:28 <jimbaker> syed__, sounds good
15:42:37 <jimbaker> sigmavirus, one other topic that came up in #craton earlier today
15:43:10 <jimbaker> just wanted to follow up on openstack client plugin, or not
15:43:36 <jimbaker> sulo, any thoughts on that?
15:44:15 <sulo> i dont know much about openstack client and its plugin structure etc .. tbh
15:44:40 <sulo> never used it, so will have to read up on it etc
15:44:57 <jimbaker> sulo, i had not investigated either. i was just curious why keystoneclient cli for example was deprecated
15:45:34 <jimbaker> i haven't had a chance to properly vet
15:46:20 <jimbaker> but it seems to me that if we could support the plugin, it could be worthwhile. oth, people care more about shade, right?
15:46:32 <jimbaker> for actual usage
15:47:12 <jimbaker> in all such cases, i would assume the underlying python client code is the foundation...
15:47:15 <palendae> openstack-client was part of a push to have a unified user interface for openstack
15:47:16 <sigmavirus> jimbaker: so I think you're frankly confusing a bunch of different projects
15:47:27 <sigmavirus> palendae: is correct, and it's not designed for administrators iirc
15:47:35 <sigmavirus> it's designed for end users of the cloud
15:47:50 <sigmavirus> as I understand it, cratonclient is designed for the administrators of a cloud
15:47:56 <sigmavirus> shade is also designed for end users of MANY clouds
15:48:11 <jimbaker> sigmavirus, correct about our target users
15:48:17 <sulo> sigmavirus: yeah, so thats completely differnt then
15:48:18 <sigmavirus> e.g., Rackspace Public Cloud, Rackspace Private Cloud, and other openstack public cloud
15:48:30 <sigmavirus> Shade hides incompatibilities in all three behind a common interface
15:48:57 <sigmavirus> So when Glance actually lands image creation code that RAX pub cloud could use, then shade will use that for Rackspace Public, and use the regular PUT calls for everything else
15:48:58 <palendae> And only exposes some of the functionality
15:49:07 <sigmavirus> (because literally no one else has problems with PUTing image data to glance)
15:49:10 <jimbaker> but to further confuse things, we are now looking at admin of non openstack clouds :)
15:49:11 <sigmavirus> palendae: correct
15:49:12 <palendae> From their docs: "shade is a simple client library for interacting with OpenStack clouds. The key word here is simple. Clouds can do many many many things - but there are probably only about 10 of them that most people care about with any regularity. If you want to do complicated things, you should probably use the lower level client libraries - or even the REST API directly."
15:49:27 <jimbaker> palendae, yes
15:49:38 <sigmavirus> jimbaker: all the more reason not to try to integrate with OpenStack cilent as the CLI portion of cratonclient
15:49:59 <sigmavirus> People who might use Craton to manage an AWS cloud probably don't want to download the 50 dependencies of OpenStackClient
15:50:04 <jimbaker> sigmavirus, just asking questions here :)
15:50:10 <sigmavirus> They just want the 5-10 cratonclient deps :)
15:50:41 <palendae> jimbaker: While the multi-cloud thing is worth staying cognizant of, I think it's also better to get something working first
15:50:52 <sigmavirus> == palendae
15:50:53 <jimbaker> and that makes perfect sense. you would get a quite a bundle
15:51:38 <jimbaker> palendae, sigmavirus, i understand. trust me, i'm going to try to push that work to ecosystem
15:52:13 <sigmavirus> jimbaker: sure, I just really don't think that OSC is where craton's commands live
15:52:22 <sigmavirus> We can make our commands *better* by mimicking their UX if we want to
15:52:45 <jimbaker> sigmavirus, ack. better UX is a good thing
15:52:57 <jimbaker> what that specifically is, TBD
15:53:15 <jimbaker> so some conclusions then
15:53:36 <jimbaker> 1. let's continue our craton client CLI work as is
15:54:36 <jimbaker> 2. if of interest, it should be a straightforward ecosystem task to add an openstackclient plugin, built on this work - especially the underlying python client code
15:54:57 <jimbaker> palendae, sigmavirus, sulo - sounds reasonable?
15:55:46 <palendae> Sure, if someone wants it in openstackclient they can do that work themselves. But I'm inclined to agree with sigmavirus that they have different audiences
15:55:47 <jimbaker> (ecosystem task is a term of art where we get someone else to do the work...)
15:56:39 <sigmavirus> jimbaker: yeah, the person who wants it there can write that code
15:56:46 <sigmavirus> I don't think it will ever fit in there though
15:56:56 <jimbaker> sure. it's the only reasonable way to build out this project. not just being glib here :)
15:57:52 <jimbaker> just a few minutes left in our scheduled time
15:58:13 <jimbaker> any other questions/concerns before we move back to #craton ?
15:58:53 <sigmavirus> Any reviews people should prioritize this week?
15:59:19 <jimbaker> that is a great question
15:59:33 <jimbaker> let's discuss on #craton, time to end this specific meeting
15:59:35 <sulo> sigmavirus: the one on tests ;)
15:59:46 <jimbaker> #endmeeting