| *** lamt has quit IRC | 00:06 | |
| *** lamt has joined #openstack-meeting-cp | 00:09 | |
| *** lamt has quit IRC | 00:10 | |
| *** gouthamr has quit IRC | 02:44 | |
| *** lamt has joined #openstack-meeting-cp | 03:14 | |
| *** lamt has quit IRC | 03:43 | |
| *** lamt has joined #openstack-meeting-cp | 03:56 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 03:57 | |
| *** lamt has quit IRC | 04:08 | |
| *** lamt has joined #openstack-meeting-cp | 04:09 | |
| *** lamt has quit IRC | 04:19 | |
| *** lamt has joined #openstack-meeting-cp | 04:44 | |
| *** lamt has quit IRC | 04:52 | |
| *** lamt has joined #openstack-meeting-cp | 04:54 | |
| *** lamt has quit IRC | 05:08 | |
| *** knangia has joined #openstack-meeting-cp | 05:14 | |
| *** diablo_rojo has quit IRC | 05:41 | |
| *** lamt has joined #openstack-meeting-cp | 05:49 | |
| *** lamt has quit IRC | 05:58 | |
| *** dmellado has joined #openstack-meeting-cp | 08:23 | |
| *** MarkBaker_ has quit IRC | 08:29 | |
| *** MarkBaker has joined #openstack-meeting-cp | 08:30 | |
| *** knangia has quit IRC | 08:31 | |
| *** sdague has joined #openstack-meeting-cp | 10:22 | |
| *** gouthamr has joined #openstack-meeting-cp | 12:14 | |
| *** markvoelker has joined #openstack-meeting-cp | 12:37 | |
| *** lamt has joined #openstack-meeting-cp | 12:47 | |
| *** lamt has quit IRC | 12:48 | |
| *** lamt has joined #openstack-meeting-cp | 12:57 | |
| *** lamt has quit IRC | 13:07 | |
| *** lamt has joined #openstack-meeting-cp | 13:16 | |
| *** markvoelker has quit IRC | 13:37 | |
| *** markvoelker has joined #openstack-meeting-cp | 13:40 | |
| *** lamt has quit IRC | 13:49 | |
| *** lamt has joined #openstack-meeting-cp | 13:53 | |
| *** david-lyle has quit IRC | 14:15 | |
| *** lamt has quit IRC | 14:21 | |
| *** lamt has joined #openstack-meeting-cp | 14:42 | |
| *** aselius has joined #openstack-meeting-cp | 14:54 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 15:04 | |
| *** ayoung has joined #openstack-meeting-cp | 15:15 | |
| *** lamt has quit IRC | 15:20 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 15:21 | |
| *** MarkBaker has quit IRC | 15:26 | |
| *** lamt has joined #openstack-meeting-cp | 15:27 | |
| *** knangia has joined #openstack-meeting-cp | 15:36 | |
| *** MarkBaker has joined #openstack-meeting-cp | 15:39 | |
| *** Rockyg has joined #openstack-meeting-cp | 15:42 | |
| *** lamt has quit IRC | 15:53 | |
| *** rarcea has joined #openstack-meeting-cp | 15:54 | |
| *** blancos has joined #openstack-meeting-cp | 15:58 | |
| lbragstad | #startmeeting policy | 16:00 |
|---|---|---|
| openstack | Meeting started Wed Apr 12 16:00:13 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
| openstack | The meeting name has been set to 'policy' | 16:00 |
| lbragstad | ping antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, ravelar, morgan, raj_singh, johnthetubaguy, knikolla | 16:00 |
| knikolla | o/ | 16:00 |
| *** gagehugo has joined #openstack-meeting-cp | 16:00 | |
| * johnthetubaguy lurks | 16:00 | |
| lbragstad | #link https://etherpad.openstack.org/p/keystone-policy-meeting | 16:00 |
| lbragstad | agenda ^ | 16:00 |
| gagehugo | o/ | 16:00 |
| morgan | sorry, missing this one. | 16:01 |
| lbragstad | morgan no worries - thanks for head sup | 16:01 |
| lbragstad | heads up, rather | 16:01 |
| lbragstad | #topic spec reviews | 16:02 |
| *** openstack changes topic to "spec reviews (Meeting topic: policy)" | 16:02 | |
| lbragstad | #link https://review.openstack.org/#/c/427872/ additional default policy roles spec | 16:03 |
| lbragstad | #link https://review.openstack.org/#/c/433037/ policy remove scope checks spec | 16:03 |
| lbragstad | #link https://review.openstack.org/#/c/452198/ RBAC in middleware spec | 16:03 |
| lbragstad | we cancelled last weeks meeting due to several scheduling issues | 16:03 |
| *** blancos has quit IRC | 16:03 | |
| lbragstad | the idea was to review ^ those over the week and talk about them here | 16:04 |
| lbragstad | looks like there is still a bit of discussion going on the rbac in middleware approach | 16:04 |
| lbragstad | johnthetubaguy ayoung is the main issue with https://review.openstack.org/#/c/427872/ the delegation use case? | 16:05 |
| johnthetubaguy | I am not sure its that simple | 16:06 |
| lbragstad | which I assume is "As an end user, i want the ability to discover which role is needed for a particular operation I want to delegate" | 16:06 |
| johnthetubaguy | see line 346 | 16:06 |
| johnthetubaguy | in https://review.openstack.org/#/c/427872 | 16:06 |
| johnthetubaguy | oops | 16:06 |
| johnthetubaguy | https://review.openstack.org/#/c/427872/19/specs/pike/approved/additional-default-policy-roles.rst | 16:06 |
| johnthetubaguy | I am working under the assumption policy is a per service concern | 16:07 |
| *** rarcea has quit IRC | 16:07 | |
| lbragstad | johnthetubaguy aha - sure | 16:07 |
| johnthetubaguy | the current defaults mean thats no true | 16:07 |
| lbragstad | right | 16:07 |
| johnthetubaguy | that where this idea came from: https://review.openstack.org/453739 | 16:08 |
| johnthetubaguy | but none of that gets us closer to delegation | 16:08 |
| lbragstad | yeah | 16:08 |
| lbragstad | the actual act of delegating isn't too bad since that can be done with oauth or trusts | 16:09 |
| lbragstad | the hard part is the inspection piece, finding out which role is needed to do a specific thing | 16:09 |
| lbragstad | which according to the NIST RBAC model is level 4 RBAC | 16:09 |
| *** blancos has joined #openstack-meeting-cp | 16:09 | |
| johnthetubaguy | so, API keys are probably more important than delegation | 16:09 |
| johnthetubaguy | do we have that work progress at all? | 16:09 |
| lbragstad | johnthetubaguy there is a spec in review - but it hasn't been merged yet | 16:10 |
| lbragstad | johnthetubaguy and as far as i know, there is no implementation up for review | 16:10 |
| johnthetubaguy | OK, wasn't sure on the status | 16:10 |
| lbragstad | #link https://review.openstack.org/#/c/450415/ | 16:10 |
| johnthetubaguy | I think for me, this is all a question of priorities | 16:10 |
| lbragstad | sure | 16:10 |
| johnthetubaguy | and how we get people productive quickly | 16:10 |
| johnthetubaguy | (and how we keep things simple) | 16:11 |
| lbragstad | i find that to be paramount | 16:11 |
| lbragstad | because this is going to be a long running effort | 16:11 |
| johnthetubaguy | my current thinking is an API key to a project that might be a sub project, is maybe good enough for Trove "delegation" and "protection" | 16:11 |
| johnthetubaguy | if we get hierarchical quota sorted | 16:12 |
| lbragstad | johnthetubaguy you mean by scoping the api key to a specific role? | 16:12 |
| johnthetubaguy | not really, specific to a project, on behalf of a user and all their roles | 16:13 |
| johnthetubaguy | I am still thinking things through really | 16:13 |
| johnthetubaguy | the main thing is trying to get the problem statement straight | 16:14 |
| johnthetubaguy | not sure I have got there yet either | 16:14 |
| johnthetubaguy | attempted it in here: https://review.openstack.org/#/c/455629 | 16:14 |
| johnthetubaguy | so going back to my spec | 16:14 |
| johnthetubaguy | this one: https://review.openstack.org/#/c/427872 | 16:14 |
| johnthetubaguy | the main issue I find with alternatives is a lack of smooth transition of the operators | 16:14 |
| johnthetubaguy | this seems a nice step wise evolution | 16:15 |
| johnthetubaguy | it doesn't fix all the problems folks have, but it does seem to make quite a few operators lives easier | 16:15 |
| lbragstad | fwiw - i attempted to graph that approach | 16:15 |
| lbragstad | #link https://github.com/lbragstad/orbac | 16:15 |
| johnthetubaguy | hopefully we can find a way to get feedback on the relative approach to these things | 16:15 |
| johnthetubaguy | I mean priority, not approach | 16:15 |
| johnthetubaguy | I remember taking a look at that | 16:16 |
| lbragstad | well - introducing more roles is something we can do today | 16:16 |
| johnthetubaguy | I wasn't really sure about the contstraints | 16:16 |
| johnthetubaguy | lbragstad: I am being told we can't add new roles, even though thats what all the operators are doing today | 16:16 |
| johnthetubaguy | at least, it feels like thats what is being said | 16:17 |
| lbragstad | the ability to figure out which role is needed for a particular action doesn't exist at all - we'd need to build something to do that | 16:17 |
| lbragstad | johnthetubaguy i'm unsure why we can't do that | 16:17 |
| johnthetubaguy | well, we have docs for some of that now | 16:17 |
| johnthetubaguy | lbragstad: i think its the security concern I linked to | 16:17 |
| johnthetubaguy | other than that, I am lost | 16:17 |
| lbragstad | oh - where any role on a project allows a person to do things outside that role ? | 16:18 |
| lbragstad | i.e. i have the observer role on a project but that doesn't stop me from creating instances | 16:18 |
| johnthetubaguy | yeah | 16:18 |
| johnthetubaguy | basically | 16:18 |
| lbragstad | got it | 16:18 |
| lbragstad | so - correct me if I'm wrong | 16:19 |
| johnthetubaguy | hence my suggestion of https://review.openstack.org/453739 | 16:19 |
| lbragstad | but doesn't the service have all theinformation to enforce that today? | 16:19 |
| *** edmondsw has joined #openstack-meeting-cp | 16:19 | |
| johnthetubaguy | Its not really that | 16:19 |
| johnthetubaguy | today if you are in a project, you get access to everything by default | 16:19 |
| johnthetubaguy | if every service did some sort of role check, we would be fine | 16:20 |
| johnthetubaguy | it has access to all that info, we just have a very unhelpful default | 16:20 |
| johnthetubaguy | ... so lets take a step down what I proposed in my spec | 16:20 |
| *** rarcea has joined #openstack-meeting-cp | 16:20 | |
| johnthetubaguy | basically have a transitional release, where you log warnings if people don't have the required role, but still give people access by default | 16:20 |
| johnthetubaguy | operator can override their policy rule to opt into the new behaviour sooner, if they want that | 16:21 |
| johnthetubaguy | not sure if that makes any sense out of context | 16:21 |
| lbragstad | this would assume they have other roles in place besides 'admin' | 16:21 |
| johnthetubaguy | its all about giving the operator help and time to apply the extra roles that are needed | 16:22 |
| johnthetubaguy | if the just use "Member" role for everyone already, it might just be add some implied roles | 16:22 |
| lbragstad | something about this feels like a circular dependency | 16:22 |
| johnthetubaguy | circular? | 16:23 |
| johnthetubaguy | its more there is a transition phase for a cycle where there is pain but little gain | 16:23 |
| lbragstad | like - we can't add new roles without changing each project to be deny-all by default, but we can't be deny-all by default without giving operators more roles to use instead of just 'admin' | 16:23 |
| johnthetubaguy | release N, everyone has access by default | 16:23 |
| dstanek | whoa...not many in here today | 16:23 |
| johnthetubaguy | release N+1, people with new role get access, but everyone also gets access but trigger a log message | 16:24 |
| johnthetubaguy | release N+2, only people with new role get access | 16:24 |
| johnthetubaguy | I think thats my rough proposal | 16:24 |
| lbragstad | johnthetubaguy doesn't the require https://review.openstack.org/#/c/427872/ to land before N+1? | 16:25 |
| lbragstad | that's what it sounds like to me | 16:25 |
| lbragstad | s/the/that/ | 16:25 |
| johnthetubaguy | not really | 16:25 |
| lbragstad | or is it suppose to happen during N+1's cycle? | 16:25 |
| johnthetubaguy | right, that is about N+1 | 16:26 |
| lbragstad | we just have to be able to provide better roles by N+2 is what i'm hearing then | 16:26 |
| johnthetubaguy | ideally you would also do https://review.openstack.org/453739 at the same time | 16:26 |
| johnthetubaguy | right, you have a transition | 16:26 |
| johnthetubaguy | you have a release of nothing is better, to help people transition | 16:26 |
| dstanek | johnthetubaguy: how granular do you think roles will go? | 16:27 |
| lbragstad | so - by the time N+2 rolls around, operators should have a bunch of new roles that they can assign to people that correct part of the issue because each service should now be deny-all by default | 16:27 |
| *** lamt has joined #openstack-meeting-cp | 16:27 | |
| johnthetubaguy | dstanek: initially, I am just talking about getting to no access by default | 16:27 |
| johnthetubaguy | dstanek: read, read/write, admin seems a sensible split to add in any first pass | 16:28 |
| johnthetubaguy | lbragstad: they can assign them during N+1 | 16:28 |
| lbragstad | johnthetubaguy so when they upgrade to N+2 users shouldn't notice any sort of breakage | 16:29 |
| johnthetubaguy | lbragstad: rather, they have to assign the roles to the existing users during N+1, so everything works after upgrading to N+2 | 16:29 |
| johnthetubaguy | lbragstad: thats it, yeah | 16:29 |
| dstanek | johnthetubaguy: do you plan to go as deep as vm_rebooter, catalog_endpoint_changer, etc? | 16:29 |
| lbragstad | ok - that makes sense | 16:29 |
| johnthetubaguy | dstanek: I am trying to ignore all that for now, just get to a happy place where such things are possible | 16:29 |
| johnthetubaguy | dstanek: we give operators the ability to create all of those, but its not in the default, basically | 16:30 |
| lbragstad | johnthetubaguy is that going to pan out with interoperability though? | 16:30 |
| dstanek | johnthetubaguy: i'm trying to figure out the end goal of all of this. | 16:30 |
| johnthetubaguy | lbragstad: which bit? | 16:30 |
| lbragstad | johnthetubaguy one deployment implements reader and another implements observer, for example | 16:31 |
| dstanek | and then i want to poke at it for potentially how it might work | 16:31 |
| johnthetubaguy | dstanek: the end goal I am taking about here, is letting users modify policy without breaking everything | 16:31 |
| johnthetubaguy | lbragstad: ah, thats where the capabilities API comes into play slightly | 16:31 |
| lbragstad | dstanek the big thing i think we're talking about here, right now, is making it so that if you have a role on the project you don't access to all the things | 16:31 |
| johnthetubaguy | lbragstad: at least we have standard error codes for permission denied due to policy | 16:32 |
| lbragstad | dstanek (i.e. I have the 'observer' role on project 'Foo' but that doesn't actually stop me from launching instance) | 16:32 |
| johnthetubaguy | lbragstad: true, thats the big one | 16:32 |
| dstanek | lbragstad: sure, i'm trying to see who it fits in the bigger picture (assuming that we have one) | 16:32 |
| johnthetubaguy | I am thinking really small here, on purpose | 16:32 |
| johnthetubaguy | lets get stuff into a state where folks can innovate and tell us what is best to have as upstream defaults | 16:33 |
| lbragstad | johnthetubaguy is it fair to say that the main thing we're discussing here is closing that security hole? | 16:33 |
| johnthetubaguy | yeah, I think it probably is | 16:33 |
| ayoung | Whoa...I need to read up.... | 16:33 |
| johnthetubaguy | but fixing that allows folks to "understand" policy I guess | 16:33 |
| lbragstad | dstanek do you think that sounds like a fair starting point, or do we need to back up further? | 16:34 |
| ayoung | " I am working under the assumption policy is a per service concern" very no. ...more as I catch up | 16:34 |
| ayoung | the only way that could be true is if a token were issued for a specific service, and invalid for other services | 16:35 |
| johnthetubaguy | ayoung: I think that was me saying "I was" | 16:35 |
| ayoung | johnthetubaguy, ah | 16:35 |
| ayoung | cool | 16:35 |
| ayoung | johnthetubaguy, so you no longer see it like that, I take it? | 16:35 |
| johnthetubaguy | ayoung: yes, but probably not in the way you want to me to | 16:36 |
| ayoung | johnthetubaguy, that is ok, it took me a long time to get to where I am in my opinions. THe fact that you are following me at least thus far is, frankly, more than most people | 16:37 |
| ayoung | johnthetubaguy, lets start with the term delegation. To me, Keystone is a Delegation service, not an identity service | 16:38 |
| dstanek | lbragstad: it sounds like a good middle step....but i'm curious to know what the vision is.... some of ayoung's proposals have high level thoughts on where we should be heading | 16:38 |
| ayoung | a token is a way of saying "I need a delegation agreement so some service can do something on my behalf" | 16:38 |
| johnthetubaguy | ayoung: yeah, thats fair, especially in the LDAP case | 16:38 |
| lbragstad | dstanek ++ | 16:39 |
| ayoung | so, delegation is a way to make operations scale | 16:39 |
| ayoung | if I have to do everything manually myself, I can only handle so much | 16:39 |
| dstanek | i can't formulate an opinion on whether or not we are on the right path if we don't have a concrete destination (like Seatle) or even a general location (like Southern Cal) | 16:39 |
| ayoung | If I can get some other service to do stuff for me with my resources, I can get more done | 16:40 |
| johnthetubaguy | ayoung: +1 that, the hierarchical quota stuff is all about exactly that | 16:40 |
| ayoung | so, a role in Openstack is a label that maps to "permission to perform a set of operations" for a specific scope. I'll use the term project for scope, as only Keystone uses domains | 16:41 |
| ayoung | Someone was thinking this way all-the-way-back to the pre-Keystonelight code base | 16:41 |
| ayoung | cuz termie pulled in "role is on a tenant" even back then | 16:42 |
| ayoung | however, they coded as if roles were global | 16:42 |
| ayoung | thus, admin everywhere | 16:42 |
| ayoung | the only role they actually knew about | 16:42 |
| johnthetubaguy | yeah, role is for a given user on a particular project scope | 16:42 |
| ayoung | So, that is the first thing to fix. Bug 968696 | 16:43 |
| openstack | bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung) | 16:43 |
| johnthetubaguy | thats fair, I think thats the spec I am pushing in Nova to get merged, effectively | 16:43 |
| ayoung | johnthetubaguy, I have a patch for it | 16:43 |
| lbragstad | https://chickenfriedbuffalo.files.wordpress.com/2014/03/keystone-light-keith-stone1.jpg | 16:43 |
| johnthetubaguy | ayoung: yeah, I need to go look at that again now | 16:44 |
| ayoung | https://review.openstack.org/#/c/384148/ | 16:44 |
| ayoung | johnthetubaguy, and getting that patch and fix through is what convinced me that, if we depend on getting a change through all the services, we are sunk | 16:44 |
| johnthetubaguy | the problem there is not one really understands that patch or policy | 16:45 |
| ayoung | johnthetubaguy, the situation in the keystone code base is actually worse | 16:45 |
| *** david-lyle has joined #openstack-meeting-cp | 16:45 | |
| ayoung | I have 2 patches as a pre-req to the Keystone one, and they are both, once again, in need of a rebase | 16:45 |
| ayoung | And, let me be clear, I consider this a CVE level security hole. | 16:45 |
| ayoung | THe only reason it is not a CVE is that everyone knows about it | 16:45 |
| johnthetubaguy | well, for some, its a feature | 16:46 |
| ayoung | but I really would like it if the entire OpenStack community were to treat that as if the house were on fire | 16:46 |
| ayoung | OK, so, next step | 16:46 |
| ayoung | delegation | 16:46 |
| johnthetubaguy | so... I think we are skipping a bit | 16:46 |
| johnthetubaguy | today people modify policy.json to give people subsets of stuff | 16:47 |
| ayoung | I got my first lesson on Delegation when the Heat people asked me about it ... in Dublin, so, it must have been 4 years ago | 16:47 |
| *** rarcea has quit IRC | 16:47 | |
| ayoung | The Trust API was my first attempt at it, and it has stood up, meh, over time | 16:47 |
| ayoung | but a trust is a delegation agreement | 16:47 |
| ayoung | as is a role assignment, when you think about it | 16:48 |
| ayoung | and we did think about it | 16:48 |
| ayoung | and thus, the unified delegation effort... | 16:48 |
| ayoung | which I can link to | 16:48 |
| ayoung | There is a commonality to my rantings here | 16:48 |
| ayoung | they all are driven off the same core principals | 16:48 |
| ayoung | "delegate the minimal amount to perform the operation" | 16:49 |
| ayoung | least principal | 16:49 |
| ayoung | er | 16:49 |
| lbragstad | PofLP | 16:49 |
| ayoung | least privilege principal | 16:49 |
| ayoung | yep | 16:49 |
| ayoung | Pronounce PoffUlp, I believe | 16:49 |
| johnthetubaguy | right, its something that gets most people nodding, the problem we have is usability and transitioning to it | 16:50 |
| ayoung | right | 16:50 |
| ayoung | very right | 16:50 |
| ayoung | and transition is ultra important | 16:50 |
| lbragstad | 10 minutes remaining | 16:50 |
| ayoung | we can't break the existing way of doing things | 16:50 |
| ayoung | ok...this is why I want to do this in a video conf... | 16:50 |
| lbragstad | *without* a transition period | 16:50 |
| ayoung | too much to say, and hard to do on IRC | 16:50 |
| lbragstad | ayoung you're doing well | 16:51 |
| ayoung | so....can we agree to video conf next week? | 16:51 |
| johnthetubaguy | ayoung: +1 | 16:51 |
| lbragstad | yes | 16:51 |
| johnthetubaguy | that +1 actually applies to its hard to do on IRC, and lets do a video conf next week | 16:51 |
| ayoung | johnthetubaguy, would love to have you there. Probably the most important person, right now, as you are the nova person taking point on this | 16:51 |
| lbragstad | johnthetubaguy dstanek gagehugo lamt ayoung knikolla have all confirmed attendance | 16:51 |
| ayoung | excellent | 16:51 |
| ayoung | I'll try to be organized and concise, so I don't take too much time, and we can have a decent discussion | 16:52 |
| lbragstad | which is under 10, which means we can use Google Hangouts | 16:52 |
| johnthetubaguy | actually, what about this slot next week? | 16:52 |
| johnthetubaguy | to keep it simple | 16:52 |
| lbragstad | yep | 16:52 |
| ayoung | johnthetubaguy, btw, some other related efforts you should know about | 16:52 |
| knikolla | works for me | 16:52 |
| lbragstad | that's what ayoung suggested in the thread | 16:52 |
| ayoung | 1. "Request a token with a specific role" | 16:52 |
| johnthetubaguy | ah, I missed that bit | 16:52 |
| edmondsw | I will try to make it if someone will send me the information | 16:53 |
| ayoung | this is the idea that, when I ask Nova to reboot a VM, I get a token that can only do that | 16:53 |
| lbragstad | edmondsw ++ i'll add you to the thread | 16:53 |
| lbragstad | edmondsw want to ping me your preferred email? | 16:53 |
| ayoung | https://review.openstack.org/#/c/186979/ | 16:53 |
| ayoung | johnthetubaguy, the trove example you brought up is a superb starting point | 16:53 |
| johnthetubaguy | do we want to talk API Keys | 16:54 |
| johnthetubaguy | I think thats very relevant here | 16:54 |
| ayoung | if you think of Trove, Sahara, or anything else that makes use of existing OS services as a semi-trusted third-party resource, it makes a lot of sense | 16:54 |
| ayoung | johnthetubaguy, an API key, as I see it, is 2 things | 16:54 |
| ayoung | 1. An identity | 16:54 |
| johnthetubaguy | ayoung: +1 the trove statement | 16:54 |
| ayoung | 2. a delegation agreement | 16:54 |
| *** edtubill has joined #openstack-meeting-cp | 16:55 | |
| lbragstad | quick note before we end the meeting - i'd like to have some idea of the goals we want to accomplish next week | 16:55 |
| ayoung | they really are a way to do lightweight user-like objects | 16:55 |
| ayoung | lbragstad, should we use the etherpad to frame the agenda? | 16:55 |
| lbragstad | i just don't want to get lost in conversation without working towards something | 16:55 |
| lbragstad | ayoung yeah - that's eventually what I was going to do | 16:56 |
| ayoung | link? | 16:56 |
| * lbragstad #link https://etherpad.openstack.org/p/policy-chat-session-one | 16:56 | |
| lbragstad | let's keep the goals short - since we've only got an hour | 16:56 |
| *** edtubill has quit IRC | 16:56 | |
| lbragstad | I want to make sure we come out of the meeting with something accomplished, and having known goals before hand should help us with that | 16:57 |
| johnthetubaguy | so... there is an interesting option about a release goal for queens | 16:58 |
| johnthetubaguy | some quick fixes projects can do in a single cycle, so we are less... broken | 16:58 |
| johnthetubaguy | how could that get packaged into a release goal for queens | 16:59 |
| ayoung | johnthetubaguy, analogs of Bug 968696 | 16:59 |
| openstack | bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung) | 16:59 |
| ayoung | check is_admin_project in policy for every project | 16:59 |
| lbragstad | i like the idea of using release goals to encourage adoption of what we end up moving towards | 16:59 |
| edmondsw | ++ | 16:59 |
| ayoung | Get someone to take that per project and run it through to completion | 16:59 |
| johnthetubaguy | ayoung: yeah, I think closed by default as well | 17:00 |
| lbragstad | johnthetubaguy ++ | 17:00 |
| johnthetubaguy | well, all the projects have to commit or not, basically | 17:00 |
| *** rarcea has joined #openstack-meeting-cp | 17:00 | |
| johnthetubaguy | ideally a few projects have examples, maybe just WIP, to frame the discussion | 17:00 |
| lbragstad | alright - we're out of time | 17:00 |
| lbragstad | we can spill over into -keystone or -dev | 17:00 |
| johnthetubaguy | doh, yep | 17:00 |
| lbragstad | -dev? | 17:00 |
| lbragstad | #endmeeting | 17:01 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:01 | |
| openstack | Meeting ended Wed Apr 12 17:01:09 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-04-12-16.00.html | 17:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-04-12-16.00.txt | 17:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-04-12-16.00.log.html | 17:01 |
| *** blancos has quit IRC | 17:01 | |
| *** gagehugo has left #openstack-meeting-cp | 17:01 | |
| *** lamt has quit IRC | 17:17 | |
| *** rarcea has quit IRC | 17:43 | |
| *** edtubill has joined #openstack-meeting-cp | 18:04 | |
| *** lamt has joined #openstack-meeting-cp | 18:14 | |
| *** ayoung has quit IRC | 18:31 | |
| *** edtubill has quit IRC | 18:46 | |
| *** beekhof has quit IRC | 19:19 | |
| *** lamt has quit IRC | 19:22 | |
| *** lamt has joined #openstack-meeting-cp | 20:03 | |
| *** ayoung has joined #openstack-meeting-cp | 20:26 | |
| *** MarkBaker has quit IRC | 20:38 | |
| *** MarkBaker has joined #openstack-meeting-cp | 20:50 | |
| *** sdague has quit IRC | 21:07 | |
| *** gouthamr has quit IRC | 21:21 | |
| *** edmondsw has quit IRC | 21:33 | |
| *** Qiming has quit IRC | 21:41 | |
| *** Qiming has joined #openstack-meeting-cp | 21:46 | |
| *** lamt has quit IRC | 21:59 | |
| *** lamt has joined #openstack-meeting-cp | 22:04 | |
| *** ayoung has quit IRC | 22:34 | |
| *** lamt has quit IRC | 22:47 | |
| *** aselius has quit IRC | 22:54 | |
| *** lamt has joined #openstack-meeting-cp | 22:59 | |
| *** lamt has quit IRC | 23:08 | |
| *** lamt has joined #openstack-meeting-cp | 23:12 | |
| *** lamt has quit IRC | 23:12 | |
| *** lamt has joined #openstack-meeting-cp | 23:13 | |
| *** lamt has quit IRC | 23:13 | |
| *** lamt has joined #openstack-meeting-cp | 23:14 | |
| *** lamt has quit IRC | 23:15 | |
| *** knangia has quit IRC | 23:21 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
