| *** richm has joined #openstack-keystone | 00:04 | |
| *** arunkant__ has joined #openstack-keystone | 00:11 | |
| *** arunkant_ has quit IRC | 00:14 | |
| *** spandhe has quit IRC | 00:20 | |
| *** dims has joined #openstack-keystone | 00:23 | |
| *** spandhe has joined #openstack-keystone | 00:31 | |
| *** bradjones has quit IRC | 00:34 | |
| *** bradjones has joined #openstack-keystone | 00:35 | |
| *** bradjones has quit IRC | 00:35 | |
| *** bradjones has joined #openstack-keystone | 00:35 | |
| *** jasondotstar has quit IRC | 00:43 | |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Prevent attempts to "filter" list() calls by globally unique IDs https://review.openstack.org/182752 | 00:47 |
|---|---|---|
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Stop using .keys() on dicts where not needed https://review.openstack.org/194894 | 00:47 |
| *** dramakri has quit IRC | 00:51 | |
| morganfainberg | bknudson: nice ^^ | 01:04 |
| *** spandhe has quit IRC | 01:10 | |
| *** charlesw has joined #openstack-keystone | 01:12 | |
| *** _cjones_ has quit IRC | 01:15 | |
| *** davechen has joined #openstack-keystone | 01:22 | |
| davechen | ayoung: sorry, I miss our meeting and just read your email. | 01:24 |
| ayoung | davechen, we actually hadn't met yet | 01:25 |
| davechen | ayoung: I am lucky actually. :-) | 01:26 |
| ayoung | davechen, so, I'll ask you the same thing I floated by samueldmq earlier | 01:26 |
| davechen | ayoung: just the time is too bad for me, I am unable to catch up the meeting I am afraid. | 01:26 |
| davechen | ayoung: yes. | 01:27 |
| *** darrenc is now known as darrenc_afk | 01:27 | |
| ayoung | lets take the absolute basic: we enable fetch by URL. Let's work through just that use case | 01:27 |
| ayoung | assumption is we have a stock policy in place | 01:27 |
| davechen | ayoung: I saw the spec is ready. | 01:27 |
| ayoung | now we fetch one from Keystone. My thought is that we ignore the stock and only use the dynamic. | 01:27 |
| ayoung | THoughts on that. | 01:27 |
| ayoung | ? | 01:27 |
| ayoung | morganfainberg, ^^ you should probably read that, too, as it is the core of the discussion | 01:28 |
| davechen | ayoung: stock policy, you mean nova do that? | 01:28 |
| ayoung | davechen, yes, the policy.json out of the nova repo | 01:28 |
| morganfainberg | ayoung: so how does keystone know what the baseline policy should be? | 01:29 |
| davechen | ayoung: if we ignore stock policy, will it broke someting from nova? | 01:29 |
| ayoung | morganfainberg, it is uploaded by the operator. Either manually, or via puppet | 01:29 |
| ayoung | morganfainberg, and, yes, you cut to the chase | 01:29 |
| ayoung | if we were to automate this, based on updating the code, nova itself could be responsble for updating the policy file | 01:30 |
| morganfainberg | ayoung: and then my next question: how do you control when new policy goes out - so as not to end up with situations where you have partial policy | 01:30 |
| morganfainberg | right now with CMS you have control on the windows | 01:30 |
| morganfainberg | centralized, you may not. | 01:30 |
| morganfainberg | and could end up with either a group of endpoints out of sync (different policies) or partial changes | 01:31 |
| ayoung | morganfainberg, I assume by partial policy you mean: we have a new microversion and a new API, and no policy covers that? | 01:31 |
| morganfainberg | no, i made ½ of the change i intended to | 01:31 |
| morganfainberg | and there is an update | 01:31 |
| morganfainberg | and now we have lots of broken things | 01:31 |
| ayoung | morganfainberg, lets simplify this a bit...I'm not talking about database driven, so lets assume policy changes are, to start with, all or nothing | 01:32 |
| ayoung | and byt htat I mean that a user will upload a full policy file... | 01:32 |
| *** timsim has joined #openstack-keystone | 01:32 | |
| ayoung | we can discuss whether that means: for thewhole openstack versuse per service in a bit...lots of weeds to distract here | 01:32 |
| morganfainberg | ok great lets ignore the partial issue then | 01:33 |
| ayoung | lets leave those off for the moment, and just say that it is a full policy file to start, and we are using the endpoint-policy means of assigning it to an endpoint when it requests it | 01:33 |
| morganfainberg | the issue is the different policy for different endpoints now [think ha-proxy], it's a cache coherency probelm | 01:33 |
| morganfainberg | s/different endpoints/different processes in the same "endpoint" | 01:34 |
| ayoung | morganfainberg, ok...so I don't think we support that today, do we? | 01:34 |
| ayoung | I think I misunderstood | 01:34 |
| ayoung | you are just talking about reuse of the thread | 01:35 |
| ayoung | OK...so policy is, today, enforced by reading a full file out of the file system | 01:35 |
| ayoung | I don;'t think oslo has the concept of caching built in. | 01:35 |
| ayoung | let me check... | 01:35 |
| ayoung | ah, I guess it depends on when init is called | 01:36 |
| morganfainberg | and also if you have say multiple nova apis (physically different systems) behind a load balancer | 01:36 |
| morganfainberg | or docker containers | 01:36 |
| morganfainberg | or similar isolation | 01:36 |
| morganfainberg | not a totally uncommon thing to do. | 01:36 |
| morganfainberg | HA reasons. | 01:36 |
| ayoung | ok...so we need a way to signal "refresh your policy" | 01:37 |
| ayoung | totally legitimate concern | 01:37 |
| davechen | ayoung: do you have someting in mind when it's get out of sync? | 01:37 |
| morganfainberg | and oslo.messaging isn't sufficient since it's only guaranteed one worker (even multi eventlet workers) will see it | 01:38 |
| ayoung | morganfainberg, right. So, one option is to always read policy from the cache directory | 01:38 |
| ayoung | and, slightly less bad is to check the directory to see if there is a newr version, and read it there is | 01:38 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Remove "tenants" from user_attribute_ignore default https://review.openstack.org/189029 | 01:38 |
| ayoung | lets see what Nova does... | 01:39 |
| *** vg_ has joined #openstack-keystone | 01:39 | |
| morganfainberg | i'm not sure what happens when you have multiple physical nodes acting as a single API [HA], i think only one would see the notify | 01:39 |
| morganfainberg | if it's not fanout? | 01:40 |
| ayoung | http://git.openstack.org/cgit/openstack/nova/tree/nova/policy.py#n70 | 01:40 |
| ayoung | it looks like they call init every time | 01:40 |
| ayoung | morganfainberg, so, lets assume the fetch is done by either ATM or by a listener daemon, Nova will pick up the new policy file next time it enforces | 01:41 |
| ayoung | morganfainberg, so in ATM, we fetch policy from Keystone and write to a temp dir on the same particion as the policy dir, and then do a rename | 01:44 |
| ayoung | next time nova calls enforce, it will reread the policy file | 01:44 |
| morganfainberg | ayoung: standard fare for posix | 01:44 |
| ayoung | yep | 01:44 |
| *** fangzhou has quit IRC | 01:45 | |
| ayoung | morganfainberg, down the road, if we want something more effecient, I could see using a notification from Keystone to a listener on the nova host, but the first iteration would be fetch on demand | 01:45 |
| morganfainberg | wait every time? | 01:45 |
| ayoung | morganfainberg, the fetch from keystone? Not, that is on a timeout, based on the HTTP headers from Keystone | 01:46 |
| morganfainberg | ayoung: that breaks the multiple physical node mode | 01:46 |
| ayoung | or do you mean read from the directory and parse the rules? | 01:46 |
| morganfainberg | l | 01:46 |
| ayoung | yes, that is currently done every time | 01:46 |
| morganfainberg | node 1 will fetch on a different timeout than node 2 | 01:46 |
| ayoung | morganfainberg, is that a problem? | 01:46 |
| morganfainberg | yes | 01:46 |
| morganfainberg | because now in a HA [master/master] model | 01:47 |
| morganfainberg | whihc isn | 01:47 |
| morganfainberg | t that uncommon | 01:47 |
| morganfainberg | you end up with different enforcement based on where your request goes | 01:47 |
| ayoung | ok...so the only way to keep them in sync would be to do a puppet type thing? | 01:47 |
| morganfainberg | and it could result in some requests failing/working where they shouldnt | 01:47 |
| morganfainberg | i think - or a notify to the group of nodes somehow | 01:47 |
| ayoung | even that, though, is not atomic | 01:47 |
| ayoung | there will always be some lag | 01:47 |
| morganfainberg | but you have a window that is known | 01:47 |
| ayoung | morganfainberg, how about this... | 01:47 |
| ayoung | we put a "no earlier than" time on the policy | 01:48 |
| morganfainberg | i am running puppet now, we might have 5 minutes of bad requests | 01:48 |
| *** arunkant_ has joined #openstack-keystone | 01:48 | |
| ayoung | ATM fetches it, but will not enforce on that file until then. | 01:48 |
| *** Raildo_ has joined #openstack-keystone | 01:48 | |
| morganfainberg | but with timeout/on demand pulls you don't have that level of control. | 01:48 |
| ayoung | morganfainberg, sure we do. We always pull a new file | 01:48 |
| *** Raildo_ has quit IRC | 01:48 | |
| ayoung | and the file has an expiry | 01:49 |
| ayoung | pull like, once a minute | 01:49 |
| morganfainberg | ayoung: unless we do math that says we pull on the same request timeout [that isn't based on _init_ time] | 01:49 |
| *** Raildo_ has joined #openstack-keystone | 01:49 | |
| morganfainberg | which we might be able to do | 01:49 |
| ayoung | clarify? | 01:49 |
| morganfainberg | so something like take the $sha of the endpoint id (URL) | 01:49 |
| morganfainberg | use that to seed the RNG | 01:50 |
| morganfainberg | pull an RNG out, and offset from <top of minute> by that RNG | 01:50 |
| davechen | "no eariler than" is good idea I think. | 01:50 |
| morganfainberg | so you know at <time> these nodes will all fetch policy | 01:50 |
| morganfainberg | and it will be in sync [aka next request after the timeout] | 01:50 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Update developer docs for discretion https://review.openstack.org/194906 | 01:51 |
| ayoung | lets separate the fetch time from the active time, though | 01:51 |
| morganfainberg | ayoung: thats fine | 01:51 |
| morganfainberg | i'm not disagreeing on no-earlier-than | 01:51 |
| morganfainberg | that is a fine model | 01:51 |
| morganfainberg | but i think we also want to ensure all nodes in a HA group fetch at the same indicator | 01:51 |
| *** arunkant__ has quit IRC | 01:51 | |
| morganfainberg | all TTL at the same time(ish) vs. one being even 5 mins offset or whatever | 01:51 |
| ayoung | morganfainberg, OK...so lets take that as accepted...we work hard to make sure that all things that need the smae policy get it in sync | 01:52 |
| morganfainberg | sure. | 01:52 |
| ayoung | what is the relationship between the stock policy on the node at start up and the dynamic? | 01:52 |
| morganfainberg | that is the next step i wanted to jump to | 01:52 |
| ayoung | I think we say the dynamic overwrites it | 01:52 |
| *** arunkant has joined #openstack-keystone | 01:52 | |
| ayoung | however, microversions | 01:52 |
| morganfainberg | i think we need to do an overlay. | 01:52 |
| *** darrenc_afk is now known as darrenc | 01:53 | |
| morganfainberg | dynamic is meant to replace elements | 01:53 |
| morganfainberg | it can replace everythign | 01:53 |
| ayoung | morganfainberg, so...here is where I think splitting the policy file would make sense | 01:53 |
| ayoung | lets say that we can identify two halves of the rule | 01:53 |
| ayoung | one half is RBAC, one half is scope | 01:53 |
| ayoung | the scope is something that tells us "here is the scope on the requested resource" | 01:53 |
| ayoung | and that we overlay | 01:54 |
| ayoung | the RBAC, we accept the defaults from stock if and only if it has not been overwritten in the central server | 01:54 |
| bknudson | https://review.openstack.org/#/c/194906/ suggests some review policy updates. | 01:54 |
| morganfainberg | ayoung: sec, jumping into another convo brb | 01:55 |
| ayoung | morganfainberg, that is fine. | 01:55 |
| *** arunkant_ has quit IRC | 01:55 | |
| ayoung | vg_, did you try the policy check tool I pointed you at? | 01:56 |
| *** arunkant_ has joined #openstack-keystone | 01:56 | |
| vg_ | yes that works.. | 01:56 |
| vg_ | I also switched my API from 2.0 to 3 yesterday | 01:57 |
| davechen | ayoung: do you what's the "policy management api" means? which is marked as todo in the wiki page. | 01:57 |
| ayoung | vg_, ah, very good | 01:57 |
| ayoung | davechen, hold on... | 01:57 |
| davechen | ayoung: ye | 01:57 |
| *** stevemar has joined #openstack-keystone | 01:57 | |
| *** ChanServ sets mode: +v stevemar | 01:57 | |
| ayoung | vg_, make sure you can do the operation from the command line. | 01:58 |
| *** Ctina___ has quit IRC | 01:58 | |
| ayoung | use the openstack common CLI, you still cannoot create users? | 01:58 |
| vg_ | +ayoung I used this link https://docs.hpcloud.com/helion/openstack/1.1/services/identity/configure/ | 01:58 |
| vg_ | for some reason my UI got unresponsive | 01:58 |
| *** Ctina___ has joined #openstack-keystone | 01:58 | |
| vg_ | yes using command line | 01:58 |
| *** Ctina___ has quit IRC | 01:59 | |
| vg_ | any other doc you can point for switching the API for keystone | 01:59 |
| *** Ctina___ has joined #openstack-keystone | 01:59 | |
| *** arunkant has quit IRC | 01:59 | |
| ayoung | vg_, cool, so, to cbe clear, a user with only the project_admin role on a project is capable of adding a role to another user for that same project? | 02:00 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Update developer docs for discretion https://review.openstack.org/194906 | 02:00 |
| ayoung | vg_, and the only problem is that you cannot do that from Horizon? | 02:00 |
| ayoung | davechen, let me see. | 02:00 |
| ayoung | davechen, which wiki do you mean? | 02:00 |
| vg_ | user with project_admin role can also add new users in that tenant | 02:00 |
| morganfainberg | ayoung: so i think i still like the idea of /policy on the endpoints -- *not* for strictly the reason sdague was proposing. | 02:00 |
| vg_ | yes | 02:01 |
| ayoung | morganfainberg, what would /policy have? | 02:01 |
| morganfainberg | ayoung: just as a way of knowing at least what the endpoint thinks it's policy is supposed to be | 02:01 |
| morganfainberg | ayoung: it lest nova ask glance "hey can i do X" without making keystone in the middle | 02:01 |
| davechen | ayoung: https://wiki.openstack.org/wiki/DynamicPolicies#Story_1_-_As_a_cloud_admin.2C_I_want_to_manage_Policies_via_API, this page | 02:01 |
| morganfainberg | glance already knows | 02:01 |
| ayoung | morganfainberg, you really think it is useful? And pracitcal to implement? | 02:01 |
| morganfainberg | ayoung: this is a side thought | 02:01 |
| morganfainberg | ayoung: nova knows it's calling glance for X | 02:01 |
| morganfainberg | take this in isolation of what we just discussed | 02:02 |
| morganfainberg | this really is just a drizzle that occured ot me | 02:02 |
| ayoung | I mean, I could see an automatic post from the endpoint to Keystone with that data, scripted at startup but exposing it via na API is...going to be a lot of work | 02:02 |
| morganfainberg | ayoung: i'm thinking whatever long term way we query for horizon -> keystone or whatever | 02:02 |
| morganfainberg | can be the same on /policy | 02:02 |
| morganfainberg | ayoung: not about ownership just a the base RBAC + what was sourced from keystone | 02:03 |
| morganfainberg | or whatever the central thing is | 02:03 |
| morganfainberg | might be pointless though. | 02:03 |
| ayoung | morganfainberg, so...let me just state that I don;'t think we can prcially do it. If we wait for that to be implemented in every project, we will be waiting for several releases. And, we would need a way to find it in the service catalog...it is a nice thought, but I can;'t really connect the critical pieces of it | 02:03 |
| *** Ctina___ has quit IRC | 02:04 | |
| ayoung | morganfainberg, OTOH, if ATM wants to read the stock policy out of a file and post it to Keystone...that would be practical to do | 02:04 |
| morganfainberg | ayoung: i don't think the stock policy can be a file | 02:05 |
| ayoung | I mean, ugly, sure...but we could make it happen | 02:05 |
| *** arunkant__ has joined #openstack-keystone | 02:05 | |
| morganfainberg | i think it's going to have to be code | 02:05 |
| ayoung | morganfainberg, its a file right now | 02:05 |
| morganfainberg | to support transition from <bad default> to <good default> | 02:05 |
| ayoung | morganfainberg, so...again, with the split | 02:05 |
| ayoung | lets say that we make the code portion the "find the scope" part of policy | 02:05 |
| morganfainberg | so why do we need it to be a file on disk? | 02:05 |
| morganfainberg | it could just be strictly code | 02:05 |
| ayoung | then the RBAC portion is just "this role for this API" | 02:06 |
| morganfainberg | this is just for the base-line policy in a service | 02:06 |
| morganfainberg | the "from disk" can be the overlay from keystone | 02:06 |
| openstackgerrit | Merged openstack/keystone: Python 3: Use range instead of xrange for py3 compatibility. https://review.openstack.org/193820 | 02:06 |
| *** tobe has joined #openstack-keystone | 02:06 | |
| *** bknudson has quit IRC | 02:06 | |
| ayoung | morganfainberg, how about we state that, if we can find a good way to autogenerate the JSON from code in the future, we will entertain it then | 02:06 |
| ayoung | I don;'t want to wait on that | 02:06 |
| morganfainberg | ayoung: i think that is a really easy solve though | 02:07 |
| ayoung | shudder | 02:07 |
| morganfainberg | serializing data to json is *easy* | 02:07 |
| ayoung | morganfainberg, yes, but gathering the data from every single API is not | 02:07 |
| morganfainberg | you've already said you need to upload overrides to keystone manually | 02:07 |
| ayoung | morganfainberg, just enumerating all the APIs is tricky | 02:08 |
| *** arunkant_ has quit IRC | 02:08 | |
| morganfainberg | not seeing the benefit to providing a stock policy on disk | 02:08 |
| morganfainberg | if it's already massively manual | 02:08 |
| ayoung | morganfainberg, so...lets table that for a moment | 02:08 |
| ayoung | I promise to get back to it in a sec | 02:08 |
| ayoung | but..do you understand what I am saying about the split? | 02:08 |
| morganfainberg | ayoung: only partially - i'm not sure what you're looking to gain with it | 02:09 |
| morganfainberg | the scope bit is effectively already solved - it's passed down to the context from middleware | 02:10 |
| morganfainberg | and is already enforced on | 02:10 |
| morganfainberg | sure we do it a bit weird from the URL today in some cases | 02:11 |
| morganfainberg | but scope can be sourced directly already and is enforced on for *most* projects [ignore the new "compute_admin" idea] | 02:11 |
| morganfainberg | it's just part of the auth context | 02:11 |
| morganfainberg | so lets back up | 02:12 |
| morganfainberg | what happens if there is no RBAC override in keystone | 02:12 |
| morganfainberg | we use the default policy | 02:12 |
| morganfainberg | ? | 02:13 |
| morganfainberg | who defines the default policy | 02:13 |
| morganfainberg | the service team? | 02:13 |
| ayoung | morganfainberg, so you are cool with saying "we are really only dealing with the RBAC side here? | 02:13 |
| morganfainberg | we already only really deal with RBAC here. | 02:13 |
| ayoung | heh...not if you look at the current policy files, but I thin we are in agreement | 02:14 |
| ayoung | ok....if that is the case, then we have two choices | 02:14 |
| morganfainberg | the other stuff is outside what we can call our purview, we have no way to reach into nova and say scope allows me to do X on project Y | 02:14 |
| ayoung | 1. overlay. 2. Default from dynamic | 02:14 |
| morganfainberg | sorry on project Y's resource | 02:14 |
| morganfainberg | that is a seprate check | 02:14 |
| morganfainberg | and usually below the Can I call "boot me a vm" check | 02:14 |
| morganfainberg | or "delete my vm, am i allowed to even try?" | 02:15 |
| ayoung | morganfainberg, ok, so the problem with Overlay is they might define a default policuy RBAC that is based on a role that the operator has deleted from Keystone | 02:15 |
| ayoung | We really only have two roles right now, Admin and Memmber, and nothing right now enforces on Member | 02:15 |
| ayoung | so really, we have Admin or not admin | 02:15 |
| morganfainberg | i'd say we have 3 states | 02:15 |
| morganfainberg | "admin, not admin, and GTFO" | 02:15 |
| ayoung | so...lets default to "if nothing is specified, you have to have Admin" | 02:16 |
| morganfainberg | that would be not-member [unscoped] | 02:16 |
| ayoung | heh | 02:16 |
| morganfainberg | or bad-scope | 02:16 |
| morganfainberg | but same argument | 02:16 |
| ayoung | the operator can change the default (and I think we should have per service defaults) | 02:16 |
| ayoung | but I think "admin until set otherwise" is the safest" | 02:17 |
| morganfainberg | ayoung: don't disagree, in fact i think we should push towards that being baseline [hence sdague's desire to make it code, so he can do fallthrough to old-admin as needed for transition] | 02:17 |
| ayoung | so...if we do an overlay...we could say "it will work so long as you use the default set of roles" | 02:17 |
| ayoung | so..if there is a stock policy, and they use Member there, and we have member in the main one, and we limit policy to RBAC...it will work | 02:17 |
| ayoung | keep just the RBAC portion in the policy.json file. The rest can get enforce based on a different policy.json, or based on code. We don't really care | 02:18 |
| *** nkinder has joined #openstack-keystone | 02:18 | |
| ayoung | morganfainberg, OK...so now want the cool part? | 02:18 |
| *** jasondotstar has joined #openstack-keystone | 02:18 | |
| ayoung | lets say we do this...split the policy file. Now...we can enforce the RBAC portion, from Middleware, based on the URL, not on the internal name of the target | 02:19 |
| *** fifieldt_ has quit IRC | 02:23 | |
| morganfainberg | ayoung: i don't think you need the split to do that. | 02:24 |
| morganfainberg | ayoung: since the REQ URL is still passed down. | 02:24 |
| morganfainberg | i am not convinced i'd want middleware doing that enforcement | 02:24 |
| ayoung | morganfainberg, you do, for at least some calls, as they need to fetch the object out of the database. Keystone, at least does that | 02:24 |
| morganfainberg | fwiw, i'm not convinced middleware shouldn't do the enforcement | 02:24 |
| morganfainberg | lets pretend keysotone is special here | 02:25 |
| morganfainberg | because it is | 02:25 |
| morganfainberg | ;) | 02:25 |
| ayoung | well, Nova does it too | 02:25 |
| morganfainberg | yes and we want to get out of the substitution bits in the URL | 02:25 |
| morganfainberg | anyway | 02:25 |
| morganfainberg | so i don't think middleware needs to be doing the enforcement | 02:25 |
| morganfainberg | i think the controller should be [or something hooked into the router] | 02:25 |
| morganfainberg | i'm worried middleware is too detached from this enforcement | 02:27 |
| ayoung | morganfainberg, wouldn;'t it be nice to be able to match the URL to the RBAC policy that will be enforced for it? It would make Horizon happy | 02:28 |
| morganfainberg | ayoung: oh i'm saying we should still move to URL based | 02:28 |
| morganfainberg | i'm just not convinced that enforcement needs to be in middleware | 02:28 |
| morganfainberg | it could be done below the middleware | 02:28 |
| morganfainberg | because what happens is you end up with a new API, middleware is not aware of it [or sub-apis? enforced differently?] and you end up with gaps | 02:29 |
| ayoung | morganfainberg, *could* shmould. | 02:29 |
| morganfainberg | if this is at the controller level it's easier to say "this is enforced" | 02:29 |
| ayoung | We should do it...it is part of the keystone team's job | 02:29 |
| samueldmq | I am still reading up .. interesting conversation though :) | 02:29 |
| ayoung | morganfainberg, if middleware is not aware of it, default policy | 02:30 |
| ayoung | morganfainberg, but...I'll concede. We don;t need it now | 02:30 |
| ayoung | it can be done later | 02:30 |
| morganfainberg | ayoung: i'd rather keep all enforcement at one layer | 02:30 |
| morganfainberg | but thats just for simplicity sake | 02:30 |
| *** lhcheng has joined #openstack-keystone | 02:30 | |
| *** ChanServ sets mode: +v lhcheng | 02:30 | |
| morganfainberg | it means nova can define the default for new apis/slice up apis sanely | 02:30 |
| morganfainberg | it also allows them to tie certain things together more easily. "if you can't do X you definitely can't do Y" | 02:31 |
| morganfainberg | which middleware could never really do easily | 02:31 |
| ayoung | morganfainberg, so...even if we do the split, we could do it by just making two policy files, one that we allow an update for, one we don't. We check policy against both files. If either fails, policy fails | 02:31 |
| morganfainberg | ayoung: lets revisit middleware enforcement | 02:33 |
| morganfainberg | down the line | 02:33 |
| morganfainberg | i want more eyes on that conversation | 02:33 |
| morganfainberg | that just you, me and samueldmq | 02:33 |
| ayoung | morganfainberg, deal. | 02:33 |
| ayoung | morganfainberg, the big thing is figuring out how to do the overlay | 02:34 |
| morganfainberg | ayoung: that is all oslo.policy work | 02:34 |
| morganfainberg | and i think we do it in code (post load) regardless of if it was originally a .json or not | 02:34 |
| ayoung | morganfainberg, except for the actual fetch. That is keystone specific | 02:34 |
| morganfainberg | ayoung: that is outside the overlay bit | 02:34 |
| morganfainberg | ayoung: fetch is orthognal to how we merge / overly the policy | 02:35 |
| ayoung | morganfainberg, I don't follow you on those last statement | 02:35 |
| ayoung | s | 02:35 |
| morganfainberg | fetch happens. | 02:35 |
| morganfainberg | we load policy | 02:35 |
| ayoung | Heh | 02:35 |
| morganfainberg | we merge / overlay | 02:35 |
| morganfainberg | fetch is orthogonal, it has lots of traps around it | 02:35 |
| morganfainberg | but oslo.policy is where the merge/overlay goes | 02:35 |
| ayoung | by "enforec in code" you just mean call policy from inside the controller, or something else? | 02:35 |
| morganfainberg | no, i mean however we load the policy - in memory/code structure | 02:36 |
| morganfainberg | we do the merge, not in the json pre-load | 02:36 |
| ayoung | morganfainberg, let me see if I understand what you are saying... | 02:37 |
| ayoung | we have stock policy...lets say it is in some python form | 02:37 |
| morganfainberg | sure | 02:37 |
| ayoung | that will generate a set of Rules. Then we fetch and parse those, it makes sescond set of rules. Then we merge those based on our own logic? | 02:37 |
| morganfainberg | yes. because we can know what the rules boil down to then | 02:38 |
| ayoung | OK...I think that will work fine | 02:38 |
| morganfainberg | so if an override exists we can pop it in | 02:38 |
| morganfainberg | merging it at the .json layer could get icky | 02:38 |
| morganfainberg | but the rules are a little easier to compare since they've been compiled [especially if you have an is_admin rule, that is combined with an OR, and an AND, for one api - and you then override that api] | 02:39 |
| ayoung | and...we can start today with the stock policuy in JSON. If Nova ever rewrites theirs in python, it will be a level 0 replacemente for the json stock. | 02:39 |
| morganfainberg | yes. | 02:39 |
| ayoung | pretty sure that the merge happens at the rule level already | 02:39 |
| *** nkinder has quit IRC | 02:39 | |
| morganfainberg | we probably will get help putting code structures that make sense in oslo.policy | 02:39 |
| ayoung | morganfainberg, there was the "dirs" thing | 02:39 |
| morganfainberg | ayoung: yeah that thing scares me | 02:39 |
| ayoung | morganfainberg, I think that is a pipe dream | 02:40 |
| morganfainberg | a lot | 02:40 |
| morganfainberg | ayoung: i think we're going to see it happen honestly | 02:40 |
| ayoung | but...so long as we dont push the /policy url I think I can work with what we have here | 02:40 |
| ayoung | morganfainberg, Nova may do it... | 02:40 |
| morganfainberg | the /policy url is useful for different things | 02:40 |
| morganfainberg | ayoung: if nova does it, other projects are likely to do | 02:40 |
| *** nkinder has joined #openstack-keystone | 02:40 | |
| ayoung | again, so long as it doesn't get in the critical path, I do not care | 02:40 |
| morganfainberg | policy.json is awful and almost no one understands it as is | 02:41 |
| ayoung | heh | 02:41 |
| morganfainberg | my guess is people will understand a code represenation better | 02:41 |
| ayoung | go look at XACML. You'll come back loving policy,json | 02:41 |
| morganfainberg | ayoung: i looked at XACML | 02:41 |
| morganfainberg | it makes more sense than policy.json | 02:41 |
| morganfainberg | not a lot more i admit | 02:41 |
| morganfainberg | but it does make more sense. | 02:41 |
| ayoung | It does all the stuff we do with mapping and assignments | 02:42 |
| morganfainberg | yes. | 02:42 |
| morganfainberg | that is why. | 02:42 |
| morganfainberg | but lets not get too buried in that conversation | 02:42 |
| ayoung | Heh | 02:42 |
| morganfainberg | that has enough political overhead i'm not wiling to spearhead it | 02:42 |
| ayoung | Ok...so...I think I can extract a todo list from tonights conversation | 02:42 |
| * ayoung thankful for evesdrop | 02:42 | |
| morganfainberg | good. and lets hit the core targets for L | 02:43 |
| ayoung | and I think we have a path forward | 02:43 |
| morganfainberg | seriously, having clear markers will help get the buy in | 02:43 |
| morganfainberg | especially from nova and sdague | 02:43 |
| morganfainberg | and the other projects will follow | 02:43 |
| ayoung | so...for L, lets work on: enable fetch by URL, and the fetch. Using the merge srtategy you laid out here | 02:43 |
| morganfainberg | good. | 02:43 |
| morganfainberg | maybe enforce by URL *if* it makes sense/possible to do | 02:44 |
| ayoung | we need the sync stuff...that is a new spec | 02:44 |
| ayoung | can we punt on that to start, or is it an essential upfront? | 02:44 |
| morganfainberg | lets put it out on the table | 02:44 |
| morganfainberg | but it's our stretch goal for L | 02:44 |
| morganfainberg | it's the first thing we drop if there is any question | 02:44 |
| morganfainberg | mostly i think it's making oslo.policy and the enforcer smart enough to handle that case | 02:45 |
| morganfainberg | or the old-style | 02:45 |
| morganfainberg | we might get sdague or someone from nova helping on that front | 02:45 |
| ayoung | let's hold off on enforce by URL...it is cool, and we can drop it into the mix at the M summit | 02:45 |
| morganfainberg | ayoung: like i said i'd just put it out as a "if we have someone making those smarts available we wont say no" | 02:46 |
| ayoung | I think that even the split can be tabled for the moment | 02:46 |
| ayoung | its just a better way to organize | 02:46 |
| morganfainberg | focus on fetch, url, and merge | 02:46 |
| morganfainberg | that is our baseline | 02:46 |
| morganfainberg | sorry: | 02:46 |
| ayoung | we do have the potential on conflict based on internal rules like "context_admin" | 02:46 |
| morganfainberg | "Basic Policy local to project", Fetch by url, and merge | 02:47 |
| *** csoukup has joined #openstack-keystone | 02:47 | |
| ayoung | we should try to phase those out | 02:47 |
| morganfainberg | we can stab that stuff once we have a way to phase it out, and i think we're going to see the merge bit help there long ter | 02:47 |
| morganfainberg | just seeing where it leads | 02:48 |
| morganfainberg | annnnyway | 02:48 |
| samueldmq | finally read all the conversation so far :-) | 02:49 |
| samueldmq | morganfainberg: ayoung so looks like we have a plan/scope | 02:49 |
| ayoung | samueldmq, yes, I think we do | 02:49 |
| samueldmq | ayoung: CMS uploads stock policy to keystone? | 02:50 |
| morganfainberg | ayoung: and to be clear we can rewrite the current policy API in keystone to whatever (we may need to call it something else) but if it's bad / bad ux we can | 02:50 |
| samueldmq | morganfainberg: ++ | 02:50 |
| morganfainberg | ayoung, samueldmq: the only impl detail i'd like to add in is CMS upload should be able to upload to the URL-ID | 02:50 |
| morganfainberg | not require upload then associate | 02:50 |
| ayoung | samueldmq, I am going to exercise dilligent laziness here: can you summarize in the Wiki page? I'll correct it if I think anything is out of whack (as will, I am sure, morganfainberg ) but that gives you the onus of geting into all the details | 02:50 |
| morganfainberg | CMS folks hate *hate* the "send something in, get an ID, then do something with ID" | 02:50 |
| samueldmq | morganfainberg: so policy would be associated when uploaded, directly? | 02:51 |
| morganfainberg | samueldmq: it should be possible to do so. | 02:51 |
| ayoung | morganfainberg, I think we could all agree on that | 02:51 |
| morganfainberg | ayoung: great | 02:51 |
| ayoung | and..that solves a big problem, too | 02:51 |
| *** woodster_ has quit IRC | 02:51 | |
| morganfainberg | ayoung: yes. | 02:51 |
| *** dims has quit IRC | 02:51 | |
| ayoung | morganfainberg, if the one URL maps to 3 endpoints...all three endpoints get set the same way | 02:51 |
| ayoung | win win win | 02:51 |
| morganfainberg | yep. | 02:51 |
| morganfainberg | exactly | 02:51 |
| morganfainberg | URL is the important peice here | 02:51 |
| ayoung | morganfainberg, you are, once again, my favorite PTL | 02:52 |
| morganfainberg | ayoung: don't say that too quickly | 02:52 |
| samueldmq | ayoung: those were not your words from earlier :) | 02:52 |
| morganfainberg | you'll regret it in the morning | 02:52 |
| morganfainberg | :P | 02:52 |
| samueldmq | haha | 02:52 |
| samueldmq | just kidding :p | 02:52 |
| ayoung | morganfainberg, let us now both quickly go off line | 02:52 |
| *** nkinder has quit IRC | 02:52 | |
| morganfainberg | i have to do expense reports and such | 02:52 |
| morganfainberg | so.. no rest for the wicked...or something | 02:53 |
| morganfainberg | something | 02:53 |
| morganfainberg | something | 02:53 |
| samueldmq | I have a question regarding the 'no earlier than' in the policy | 02:53 |
| samueldmq | how does that solve the cache coherence issue with HAproxy and multiple nova processes ? | 02:55 |
| samueldmq | ayoung: ^ | 02:55 |
| ayoung | samueldmq, yeah, it is kindof hard to do in the JSON format we have, isn;t it | 02:55 |
| morganfainberg | samueldmq: we use the magic math | 02:56 |
| ayoung | samueldmq, ok, so lets say that there are 30 machines...10 clusters of 3 | 02:56 |
| morganfainberg | if we set a fixed window for refresh, use a known seed for RNG [calculated] we cna guarantee the RNG gives us the same offset | 02:56 |
| ayoung | and they fetch at random internvales...lets say weveryt 5 minutes, so there can be a 4:59 delay between one and another | 02:56 |
| morganfainberg | e.g. if we seed RNG with the sha of the url | 02:56 |
| ayoung | we say "this policy file is active at 10:00. | 02:56 |
| samueldmq | morganfainberg: RNG, | 02:56 |
| samueldmq | ? | 02:56 |
| morganfainberg | then we can do a not-before logic as well to give us a buffer | 02:56 |
| morganfainberg | randome number generator | 02:57 |
| ayoung | so, even though they fetch at random times, they don't actually use that policy file until the first fetch after 10:00 | 02:57 |
| samueldmq | hm, my brain is processing this, wait | 02:57 |
| morganfainberg | ayoung: we might want to add an IMS support for the fetch | 02:57 |
| samueldmq | it's on bash mode for a bit | 02:57 |
| morganfainberg | ayoung: side thought | 02:57 |
| *** nkinder has joined #openstack-keystone | 02:57 | |
| ayoung | IMS? | 02:57 |
| morganfainberg | if modified since | 02:57 |
| ayoung | morganfainberg, absolutely | 02:57 |
| morganfainberg | use HTTP spec to our advantage | 02:58 |
| morganfainberg | ;) | 02:58 |
| ayoung | so.. I think we want to put a header outside the rules? | 02:58 |
| morganfainberg | we could *also* use Cache-control to ensure we cache for the same time everywhere | 02:58 |
| ayoung | or can we do all this in HTTP headers? | 02:58 |
| morganfainberg | if we used cache-control headers we don't need a RNG we can say this is valid until X | 02:58 |
| morganfainberg | and IMS check it | 02:58 |
| morganfainberg | oooooh | 02:58 |
| morganfainberg | we might be able to do this all in HTTP headers | 02:59 |
| morganfainberg | with a little metadata storage along side the policy on disk | 02:59 |
| ayoung | morganfainberg, lets make that a design goal, shall we? | 02:59 |
| morganfainberg | ayoung: yep | 02:59 |
| morganfainberg | ++++++ | 02:59 |
| ayoung | https://en.wikipedia.org/wiki/Web_cache#Cache_control | 02:59 |
| morganfainberg | honestly token validate (HEAD call) should have been an IMS instead | 03:00 |
| ayoung | Freshness is, I think our primary tool here | 03:00 |
| morganfainberg | yes | 03:00 |
| morganfainberg | and we can IMS which *should* [i think] be able to refresh cache-control | 03:00 |
| morganfainberg | and if keystone controls cache-control strictly on a clock, the remote ends know when to try a refresh and stay in sync | 03:00 |
| ayoung | ++ | 03:01 |
| morganfainberg | that is waaaaay less work | 03:01 |
| morganfainberg | than needing to be all sneaky about things | 03:01 |
| samueldmq | is the cache the same for all endpoints in a cloud ? | 03:01 |
| morganfainberg | and the not-valid-until can be controlled from kesytone via the cache-control and IMS checks | 03:02 |
| samueldmq | since we have no control where a token is going to be used | 03:02 |
| morganfainberg | samueldmq: all endpoints of a fixed url | 03:02 |
| morganfainberg | samueldmq: aka any nova that is http://nova-endpoint-1/ | 03:02 |
| morganfainberg | that would have a cache control for it | 03:02 |
| samueldmq | morganfainberg: how do we define the cache timetou, based on a url? | 03:02 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Upgrade Foreign key in Endpoint with ondelete='CASCADE' https://review.openstack.org/179767 | 03:02 |
| samueldmq | morganfainberg: still didnt get thsi though | 03:02 |
| ayoung | samueldmq, its is based on the last file fetched from that URL | 03:03 |
| ayoung | we'll need to record the headers, and check on each validation | 03:03 |
| morganfainberg | samueldmq: so keystone knows when a file is updated, it knows when it tells the services to refresh the cache | 03:03 |
| morganfainberg | samueldmq: when a cache is expired, the endpoint does an "if-modified-since" request | 03:03 |
| morganfainberg | keystone either gives it the new file (and cache-control) or says not-modified and hands back cache-control | 03:04 |
| morganfainberg | cache-control tells the endpoint when to fetch again | 03:04 |
| morganfainberg | it is keytone's responsibility to figure out the window for refresh [internally managed] | 03:04 |
| *** richm has quit IRC | 03:04 | |
| morganfainberg | and communicate that with headers to the endpoints | 03:04 |
| samueldmq | morganfainberg: so cache timeout is +infinite, and when policy changes, it says 0 (update right now)? | 03:05 |
| morganfainberg | no | 03:05 |
| morganfainberg | cache_control will say "try again in X number of seconds" | 03:05 |
| morganfainberg | that X will result in all endpoints for <URL> to try at a fixed time | 03:05 |
| samueldmq | how? | 03:06 |
| *** nkinder has quit IRC | 03:06 | |
| morganfainberg | samueldmq: keystone knows it wants a URL to refresh on a 5 minute window | 03:06 |
| samueldmq | since a token may hit rocess X 10 seconds later than process Y | 03:06 |
| *** nkinder has joined #openstack-keystone | 03:06 | |
| morganfainberg | it also knows the policy was updated at 1200 | 03:06 |
| morganfainberg | so it calculates 5-minute windows from 12:00 | 03:06 |
| morganfainberg | and passes a correct cache_control header so that no matter when the policy is requested fro <url> - the endpoint will ask on the 5minute window | 03:07 |
| morganfainberg | so you'll see a refresh at 12:05, 12:10, 12:15, etc | 03:07 |
| lifeless | isn't that risky | 03:08 |
| morganfainberg | because keystone can calculate time to next window | 03:08 |
| lifeless | thundering herd | 03:08 |
| morganfainberg | lifeless: the idea would be keystone would do an internal offset | 03:08 |
| morganfainberg | this was strictly an example | 03:08 |
| lifeless | phew | 03:08 |
| morganfainberg | lifeless: and the offset would be per-url | 03:08 |
| morganfainberg | lifeless: oh i've done this enough to know not to let the thundering herd happen ;) | 03:08 |
| lifeless | morganfainberg: one never knows | 03:08 |
| morganfainberg | lifeless: but adding that into the description makes the description much harder to communicate | 03:08 |
| morganfainberg | when just conveying the concept | 03:09 |
| morganfainberg | what i like about this is it is abusing HTTP in the right ways | 03:09 |
| morganfainberg | since we're already using HTTP | 03:09 |
| ayoung | samueldmq, you get all that? Take notes, there will be a short quiz at the end. | 03:11 |
| samueldmq | ayoung: hehe I am still re-reading the caching strategy thing | 03:11 |
| samueldmq | I am sorry about still not getting this, I think I am too tired :/ | 03:12 |
| samueldmq | it's been a long day :) | 03:12 |
| morganfainberg | samueldmq: this falls into the category of "my past life was running origin servers for $large_social_media_site and doing all the CDN integration with Akamai" | 03:12 |
| ayoung | samueldmq, No problem. Its all recorded in evesdrop | 03:12 |
| morganfainberg | samueldmq: so i can try and describe it again otmorrow in different ters | 03:12 |
| morganfainberg | terms* | 03:12 |
| Raildo_ | ayoung, if samueldmq don't take A+ in the test he will be kick out from keystone? =P | 03:12 |
| ayoung | Raildo_, he just needs a passing grade | 03:13 |
| Raildo_ | hehe | 03:13 |
| samueldmq | Raildo_: hey you there o/ | 03:13 |
| Raildo_ | samueldmq, we don't sleep :) | 03:13 |
| morganfainberg | ayoung: depends on what you define on passing :P | 03:13 |
| ayoung | As a Junior at WP once told me: if the minimum standard wasn't good enough, it wouldn't be the minimum standard. | 03:13 |
| ayoung | morganfainberg, we need a 2.0 to graduate | 03:14 |
| ayoung | the lowest ranked guy in the class was called the goat | 03:14 |
| morganfainberg | heh | 03:14 |
| morganfainberg | 2.0. wow | 03:14 |
| ayoung | our Goat graduated with a 1.996 | 03:14 |
| morganfainberg | i think i needed a 3.0 | 03:14 |
| morganfainberg | :( | 03:14 |
| samueldmq | morganfainberg: sure, I will re-read it tomorrow, and we talk about it again :) | 03:14 |
| * morganfainberg opted out of number grades | 03:14 | |
| ayoung | morganfainberg, I assure you, as 2.0 at WP was well earned | 03:14 |
| * morganfainberg has a transcript that is about 100pages of evaluations | 03:15 | |
| morganfainberg | and essays | 03:15 |
| morganfainberg | it equates to about a 3.5 | 03:15 |
| morganfainberg | but i had to write contracts for all my classes | 03:15 |
| morganfainberg | and negotiate them with the teachers | 03:15 |
| * morganfainberg never took a final exam either | 03:15 | |
| samueldmq | morganfainberg: ayoung actually ..... what we've been discussing so far is not very distant form what is in the spec already | 03:15 |
| ayoung | I had a 3.1 Academic...slighly lower when military was factored in | 03:15 |
| samueldmq | that only add some (before) hidden details | 03:16 |
| ayoung | 3.0 somethings...graduated 309 out of 1003 | 03:16 |
| morganfainberg | i think i graduated at like 8 of 30 | 03:16 |
| morganfainberg | in equivalency | 03:16 |
| ayoung | and I assure you, we diud not "negotiate" with teachers | 03:16 |
| *** bradjones has quit IRC | 03:16 | |
| * morganfainberg went to a hippy liberal arts college | 03:16 | |
| ayoung | https://www.youtube.com/watch?v=62zRL1mjQeg | 03:18 |
| samueldmq | ayoung: in the case of updaitng a nova endpoint ? CMS uploads the new stock policy to keystone, right ? | 03:18 |
| ayoung | 19 years later...but it looked just the same | 03:18 |
| ayoung | samueldmq, shhh...you'll spoil the moment | 03:18 |
| *** bradjones has joined #openstack-keystone | 03:18 | |
| *** bradjones has quit IRC | 03:18 | |
| *** bradjones has joined #openstack-keystone | 03:18 | |
| ayoung | heh | 03:18 |
| ayoung | no, I don't think we want to automate that | 03:19 |
| *** iamjarvo has joined #openstack-keystone | 03:19 | |
| ayoung | since we are going to an overlay, we can make the update of the policy file a manual task to start | 03:19 |
| samueldmq | and what if nova doesnt find the rule for the new API | 03:20 |
| samueldmq | uses the default rule ? | 03:20 |
| ayoung | uses the rule from stock | 03:20 |
| samueldmq | ayoung: yeah that's what I am talking about | 03:20 |
| morganfainberg | we're going to make the operator upload a new policy to start with | 03:20 |
| samueldmq | and when an update occurs? | 03:20 |
| morganfainberg | it is manual because *oh god lets not solve that problem* | 03:20 |
| ayoung | morganfainberg right | 03:21 |
| * Raildo_ thinking that we need a dynamic police mid-cycle | 03:21 | |
| samueldmq | the operator re-upload the stock policy | 03:21 |
| samueldmq | right? | 03:21 |
| morganfainberg | samueldmq: upload a new file. with new overrides if needed | 03:21 |
| morganfainberg | or delete the file to go back to default stock | 03:21 |
| Raildo_ | policy* | 03:21 |
| morganfainberg | delete stored in keystone file | 03:21 |
| ayoung | samueldmq, that is one choice, but I think it would be more like: fetch the dynacmig policuy, add the new rules, upload new dynamic policy | 03:21 |
| morganfainberg | samueldmq: if it is not defined in the overrides in keystone it falls back on the default policy | 03:21 |
| ayoung | later on, we'll get the database stuff | 03:22 |
| samueldmq | morganfainberg: so update teh custom policy manually to introduce the new added API | 03:22 |
| samueldmq | morganfainberg: or update teh stock policy could be a chocie from the deployer | 03:23 |
| samueldmq | ayoung: ^? | 03:23 |
| *** boris-42 has joined #openstack-keystone | 03:23 | |
| vg_ | <+ayoung><samueldmq> https://ask.openstack.org/en/question/68616/openstack-policy-enforcement-for-custom-role-project_admin/ | 03:23 |
| vg_ | when u get time.. | 03:23 |
| morganfainberg | samueldmq: assume the deployer cannot / should not ever update stock policy | 03:24 |
| ayoung | vg_, did you answer my last quetsion here? | 03:24 |
| *** vg_ has quit IRC | 03:24 | |
| morganfainberg | samueldmq: once everything is truely cut over | 03:24 |
| *** vg_ has joined #openstack-keystone | 03:25 | |
| samueldmq | openstackgerrit: ok so I was assuming stock represents a version of the api | 03:25 |
| samueldmq | openstackgerrit: ahhahaha | 03:25 |
| samueldmq | morganfainberg: ^ | 03:25 |
| * samueldmq might be tired | 03:25 | |
| morganfainberg | samueldmq: the stock policy is owned by say nova | 03:25 |
| morganfainberg | overrides are *not* owned by nova | 03:26 |
| samueldmq | morganfainberg: yes and tht changes in different versions | 03:26 |
| morganfainberg | if you update nova and don't provide an override for a new api | 03:26 |
| morganfainberg | you get the stock policy for it | 03:26 |
| samueldmq | morganfainberg: and why do we need to upload stock policy to keystone at start? | 03:27 |
| morganfainberg | so when you update, if you want an override for a newly introduced API, you need to upload a new file to keystone | 03:27 |
| *** Raildo_ has quit IRC | 03:27 | |
| morganfainberg | samueldmq: because keystone only cares about overrides right now | 03:27 |
| ayoung | morganfainberg, so, I think we are going to need ot make "overlay" wv "replace and default" into a confiug option | 03:27 |
| ayoung | If we do overlay, and the rule from stock goes back to a global admin, it will break the security rules of the deployment | 03:27 |
| morganfainberg | ayoung: maybe. maybe we just also still support just specifying a policy file on disk [location] | 03:27 |
| morganfainberg | and if someone doesn't do a fetch they can still CMS deploy | 03:28 |
| ayoung | morganfainberg, yes, that is base line | 03:28 |
| ayoung | dynamic needs to be enabled | 03:28 |
| morganfainberg | sure. | 03:28 |
| ayoung | but if you do enable dynamic, use only dynamic needs to be an option | 03:28 |
| morganfainberg | "do you really want this?!" | 03:28 |
| morganfainberg | uhm. why do we need that? | 03:28 |
| ayoung | morganfainberg, because right now the stock policies suck | 03:28 |
| morganfainberg | so.... | 03:29 |
| ayoung | and if a microversion means a new API, that has critical info in it, uses the current approach] | 03:29 |
| morganfainberg | i'm not seeing why we need another option | 03:29 |
| ayoung | a deployer will be sad | 03:29 |
| ayoung | lets say that...cinder adds a "fetch private key" API | 03:29 |
| ayoung | about as ugly as it can get | 03:29 |
| ayoung | and the policy for this is defaulted to "context_is_admin" | 03:30 |
| ayoung | which is pretty common | 03:30 |
| ayoung | now..in dynamic, they've gone and done everything scoped | 03:30 |
| ayoung | but the "context_is_admin" rule is defined in stock, and not in dynamic | 03:30 |
| ayoung | so, it just sayd "user must have the admin role" but does not check scope" | 03:30 |
| morganfainberg | you're still going to have a fallthrough issue | 03:31 |
| ayoung | meanwhile in the deployment, they are saying "ok, if you want to be able to assign users to a role in the project, you get admin on that project" | 03:31 |
| morganfainberg | since you have no idea what that rule should be | 03:31 |
| morganfainberg | or.. you override context_is_admin | 03:31 |
| ayoung | context_is_admin is defined differenlyy in each file...but our theoretical org has gotten rid ofi ti...or so they thought | 03:32 |
| ayoung | but, since it is not defined in the dyanimc policy, it sneaks back in in the static | 03:32 |
| morganfainberg | lets circle back on that | 03:32 |
| morganfainberg | i'm not convinced we need *another* option for this atm. | 03:32 |
| ayoung | lets make it a config option, and we can avoid the CVS by saying "set the config option" | 03:33 |
| morganfainberg | lets not worry about that yet | 03:33 |
| ayoung | heh | 03:33 |
| morganfainberg | its easy for us to add an option in | 03:33 |
| samueldmq | morganfainberg: so when the CMS uploadds the initial stock policy, admin is able to read the policy and modify a single existing api | 03:33 |
| morganfainberg | but honestly, i think we're going to run into issues with "use dynamic only" | 03:33 |
| samueldmq | morganfainberg: reading the stock is the way he knows what apis are available, and eventually modify some of them | 03:33 |
| *** jasondotstar has quit IRC | 03:33 | |
| morganfainberg | samueldmq: you don't upload the whole policy file in this iteration | 03:33 |
| morganfainberg | samueldmq: just the overrides | 03:33 |
| morganfainberg | when we get to the more DB managed stuff we're moving to possibly keeping state | 03:34 |
| ayoung | morganfainberg, ++ | 03:34 |
| morganfainberg | i know it doesn't solve horizon's immidiate need | 03:34 |
| ayoung | ok...tuning out for the night | 03:34 |
| morganfainberg | but it's because we need clear targets we can build on | 03:34 |
| samueldmq | morganfainberg: the CMS uploads only the overrides? a policy which already represents the overrides? | 03:34 |
| *** ayoung is now known as ayoung_ZZZZzzz-- | 03:34 | |
| morganfainberg | samueldmq: just a policy that represents the overrides | 03:34 |
| samueldmq | morganfainberg: oh I thought it was the stock one initially | 03:35 |
| morganfainberg | nope | 03:35 |
| morganfainberg | we merge the overrides with the stock one *at the endpoint* | 03:35 |
| samueldmq | morganfainberg: and how do the admin customize the nova policy? where does he lookup to see available apis? | 03:35 |
| morganfainberg | samueldmq: you'll need to have the URLs documented | 03:35 |
| morganfainberg | and what that customize looks like | 03:36 |
| morganfainberg | we can probably autogenerate a doc on it from the enforcement | 03:36 |
| morganfainberg | either it's a policy.json file or it's code that can output something to show options for overrides in a doc | 03:36 |
| morganfainberg | likely it is going to be code (long term) | 03:37 |
| samueldmq | morganfainberg: ok I got the main workflow, which doesn't change too much from what we have on that wiki | 03:37 |
| morganfainberg | samueldmq: but the idea is only the override is uploaded to keystone | 03:37 |
| samueldmq | morganfainberg: what changes is that we have more details now | 03:37 |
| morganfainberg | you can override *everything* | 03:38 |
| samueldmq | morganfainberg: sure I got it, you can even override something that doesn't exist | 03:38 |
| samueldmq | this way .. | 03:38 |
| morganfainberg | yep | 03:38 |
| samueldmq | morganfainberg: you can use it for notes.. | 03:38 |
| morganfainberg | or if you have your own extension | 03:38 |
| morganfainberg | with it's own policy | 03:38 |
| morganfainberg | you could override in the same manner | 03:38 |
| samueldmq | hmmm | 03:39 |
| morganfainberg | uh, no don't use the override for notes :P | 03:39 |
| morganfainberg | really a bad idea | 03:39 |
| morganfainberg | wrong tool for the job | 03:39 |
| samueldmq | just kidding though :) | 03:39 |
| samueldmq | hehe | 03:39 |
| samueldmq | ok so .. let's talk 2 minutes about timing .. | 03:39 |
| samueldmq | morganfainberg: I can write all this up in the wiki until this weeken | 03:40 |
| morganfainberg | sure. | 03:40 |
| morganfainberg | either that or ayoung_ZZZZzzz-- can help write it up tomorrow | 03:40 |
| samueldmq | morganfainberg: and needed specs could be in a good state by the end of next weekend | 03:40 |
| samueldmq | so 1 week to work hard on them | 03:40 |
| morganfainberg | we can do spec exception emails | 03:41 |
| morganfainberg | it's not hard to do | 03:41 |
| morganfainberg | just a "hey we are here and here is our target" | 03:41 |
| morganfainberg | the api-impacting freeze is friday this week | 03:41 |
| morganfainberg | for specs | 03:41 |
| samueldmq | sure, but running with specs is also part of the plan, time is running :) | 03:41 |
| morganfainberg | so we'll do a couple exception emails here | 03:41 |
| morganfainberg | just to clearly outline the targets | 03:41 |
| samueldmq | morganfainberg: will we try to synchronize all this with otehr folks now? sdague and others .. | 03:42 |
| morganfainberg | yes we will chat with them | 03:42 |
| morganfainberg | probably tomorrow | 03:42 |
| samueldmq | morganfainberg: great! I was expecting next week :) | 03:43 |
| samueldmq | morganfainberg: have to go sleep now ... almost 1 am here where I am :( | 03:46 |
| samueldmq | morganfainberg: thanks, talk to you tomorrow (or later today in my case) | 03:46 |
| *** dramakri has joined #openstack-keystone | 03:50 | |
| *** vg_ has quit IRC | 03:58 | |
| *** kiran-r has joined #openstack-keystone | 04:05 | |
| *** ayoung_ZZZZzzz-- has quit IRC | 04:06 | |
| *** kiranr has joined #openstack-keystone | 04:14 | |
| *** kiranr has quit IRC | 04:15 | |
| *** arunkant_ has joined #openstack-keystone | 04:20 | |
| *** iamjarvo has quit IRC | 04:22 | |
| *** charlesw has quit IRC | 04:23 | |
| *** arunkant__ has quit IRC | 04:24 | |
| *** kiran-r has quit IRC | 04:30 | |
| *** csoukup has quit IRC | 04:36 | |
| *** tobe has quit IRC | 05:29 | |
| *** tobe has joined #openstack-keystone | 05:29 | |
| *** mgarza_ has joined #openstack-keystone | 05:41 | |
| *** mabrams has joined #openstack-keystone | 05:55 | |
| *** e0ne has joined #openstack-keystone | 06:07 | |
| *** mabrams has quit IRC | 06:07 | |
| *** mabrams has joined #openstack-keystone | 06:07 | |
| *** Kennan has quit IRC | 06:12 | |
| *** Kennan has joined #openstack-keystone | 06:13 | |
| *** lhcheng has quit IRC | 06:14 | |
| *** kiran-r has joined #openstack-keystone | 06:16 | |
| *** lhcheng has joined #openstack-keystone | 06:17 | |
| *** ChanServ sets mode: +v lhcheng | 06:17 | |
| *** belmoreira has joined #openstack-keystone | 06:18 | |
| *** kiranr has joined #openstack-keystone | 06:18 | |
| *** kiranr has quit IRC | 06:18 | |
| *** _kiran_ has joined #openstack-keystone | 06:18 | |
| *** e0ne has quit IRC | 06:20 | |
| *** bradjones has quit IRC | 06:20 | |
| *** kiran-r has quit IRC | 06:21 | |
| *** bradjones has joined #openstack-keystone | 06:22 | |
| *** bradjones has quit IRC | 06:22 | |
| *** bradjones has joined #openstack-keystone | 06:22 | |
| *** _kiran_ has quit IRC | 06:23 | |
| *** e0ne has joined #openstack-keystone | 06:24 | |
| *** yottatsa has joined #openstack-keystone | 06:30 | |
| *** e0ne is now known as e0ne_ | 06:36 | |
| *** bradjones has quit IRC | 06:36 | |
| *** stevemar has quit IRC | 06:38 | |
| *** bradjones has joined #openstack-keystone | 06:39 | |
| *** bradjones has quit IRC | 06:39 | |
| *** bradjones has joined #openstack-keystone | 06:39 | |
| *** e0ne_ has quit IRC | 06:42 | |
| *** e0ne has joined #openstack-keystone | 06:45 | |
| *** e0ne is now known as e0ne_ | 06:46 | |
| marekd | rodrigods: i'd say yes. | 06:48 |
| *** spandhe has joined #openstack-keystone | 06:52 | |
| *** henrynash has joined #openstack-keystone | 06:53 | |
| *** ChanServ sets mode: +v henrynash | 06:53 | |
| *** e0ne_ has quit IRC | 06:55 | |
| *** browne has quit IRC | 06:55 | |
| *** dramakri has quit IRC | 07:00 | |
| *** _cjones_ has joined #openstack-keystone | 07:03 | |
| *** dguerri` is now known as dguerri | 07:12 | |
| *** kiran-r has joined #openstack-keystone | 07:13 | |
| *** kiran-r has quit IRC | 07:14 | |
| *** rlt_ has joined #openstack-keystone | 07:16 | |
| *** dramakri has joined #openstack-keystone | 07:16 | |
| *** kiran-r has joined #openstack-keystone | 07:17 | |
| *** dramakri has quit IRC | 07:18 | |
| *** yottatsa has quit IRC | 07:24 | |
| *** dguerri is now known as dguerri` | 07:27 | |
| *** lhcheng_ has joined #openstack-keystone | 07:30 | |
| *** lhcheng has quit IRC | 07:33 | |
| *** mgarza_ has quit IRC | 07:33 | |
| *** dguerri` is now known as dguerri | 07:42 | |
| *** _cjones_ has quit IRC | 07:43 | |
| *** dguerri is now known as dguerri` | 07:44 | |
| *** spandhe has quit IRC | 07:53 | |
| *** henrynash has quit IRC | 08:13 | |
| *** yottatsa has joined #openstack-keystone | 08:13 | |
| *** openstack has quit IRC | 08:25 | |
| *** openstack has joined #openstack-keystone | 08:25 | |
| *** e0ne is now known as e0ne_ | 08:34 | |
| *** rushiagr_away is now known as rushiagr | 08:38 | |
| *** e0ne_ has quit IRC | 08:39 | |
| *** e0ne has joined #openstack-keystone | 08:40 | |
| *** kiran-r has quit IRC | 08:41 | |
| *** e0ne has quit IRC | 08:45 | |
| *** bradjones has quit IRC | 08:49 | |
| *** bradjones has joined #openstack-keystone | 08:51 | |
| *** bradjones has quit IRC | 08:51 | |
| *** bradjones has joined #openstack-keystone | 08:51 | |
| *** lhcheng_ has quit IRC | 08:55 | |
| *** lhcheng has joined #openstack-keystone | 08:57 | |
| *** ChanServ sets mode: +v lhcheng | 08:57 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: WIP - closes bug: Ambiguous error https://review.openstack.org/195001 | 09:06 |
| *** yottatsa has quit IRC | 09:08 | |
| *** bradjones has quit IRC | 09:09 | |
| *** bradjones has joined #openstack-keystone | 09:11 | |
| *** bradjones has quit IRC | 09:11 | |
| *** bradjones has joined #openstack-keystone | 09:11 | |
| *** lhcheng has quit IRC | 09:12 | |
| *** dguerri` is now known as dguerri | 09:13 | |
| *** boris-42 has quit IRC | 09:22 | |
| *** afazekas has joined #openstack-keystone | 09:42 | |
| *** e0ne has joined #openstack-keystone | 09:46 | |
| *** vg_ has joined #openstack-keystone | 09:47 | |
| *** jasondotstar has joined #openstack-keystone | 09:49 | |
| *** dims has joined #openstack-keystone | 09:50 | |
| *** davechen has left #openstack-keystone | 09:55 | |
| *** henrynash has joined #openstack-keystone | 10:24 | |
| *** ChanServ sets mode: +v henrynash | 10:24 | |
| *** kiranr has joined #openstack-keystone | 10:36 | |
| *** kiranr has quit IRC | 10:40 | |
| *** vg__ has joined #openstack-keystone | 10:44 | |
| *** arunkant__ has joined #openstack-keystone | 10:44 | |
| *** yottatsa has joined #openstack-keystone | 10:45 | |
| *** vg_ has quit IRC | 10:45 | |
| *** tobe has quit IRC | 10:45 | |
| *** yottatsa has quit IRC | 10:46 | |
| *** arunkant_ has quit IRC | 10:48 | |
| *** vg__ has quit IRC | 10:50 | |
| *** vg_ has joined #openstack-keystone | 10:51 | |
| *** yottatsa has joined #openstack-keystone | 10:52 | |
| *** yottatsa has quit IRC | 10:53 | |
| *** yottatsa has joined #openstack-keystone | 10:53 | |
| *** arunkant_ has joined #openstack-keystone | 10:58 | |
| vg_ | anyone to answer this please https://ask.openstack.org/en/question/68616/openstack-policy-enforcement-for-custom-role-project_admin/ | 11:00 |
| *** arunkant__ has quit IRC | 11:02 | |
| rushiagr | morganfainberg: gyee: Sorry, I was unable to attend the keystone meeting yesterday. It was evening here in India, and I had some prior commitments. | 11:02 |
| rushiagr | This is regarding the stable driver interfaces work. Do we have better clarity now? | 11:03 |
| rushiagr | The stable driver interfaces work is important to us at Reliance, and we can dedicate resources to get this work done if things are going a bit slow right now.. | 11:05 |
| rushiagr | I'll wait for some hours now :) | 11:07 |
| *** jaosorior has joined #openstack-keystone | 11:15 | |
| *** fhubik has joined #openstack-keystone | 11:16 | |
| *** jasondotstar has quit IRC | 11:21 | |
| *** vg_ has quit IRC | 11:22 | |
| *** vg_ has joined #openstack-keystone | 11:22 | |
| *** henrynash has quit IRC | 11:24 | |
| *** bradjones has quit IRC | 11:29 | |
| *** bradjones has joined #openstack-keystone | 11:30 | |
| *** bradjones has quit IRC | 11:30 | |
| *** bradjones has joined #openstack-keystone | 11:30 | |
| openstackgerrit | Sean Dague proposed openstack/keystone: WIP: make keystone-wsgi-public a console entry point https://review.openstack.org/195044 | 11:36 |
| *** aix has quit IRC | 11:37 | |
| *** kiranr has joined #openstack-keystone | 11:48 | |
| *** kiranr has quit IRC | 11:52 | |
| *** amakarov_away is now known as amakarov | 11:58 | |
| *** ajayaa has joined #openstack-keystone | 12:09 | |
| *** jasondotstar has joined #openstack-keystone | 12:09 | |
| *** jasondotstar has quit IRC | 12:11 | |
| *** rushiagr is now known as rushiagr_away | 12:14 | |
| *** bknudson has joined #openstack-keystone | 12:26 | |
| *** ChanServ sets mode: +v bknudson | 12:26 | |
| *** packet has joined #openstack-keystone | 12:34 | |
| *** edmondsw has joined #openstack-keystone | 12:39 | |
| *** yottatsa has quit IRC | 12:39 | |
| *** yottatsa has joined #openstack-keystone | 12:43 | |
| *** yottatsa has quit IRC | 12:43 | |
| *** richm has joined #openstack-keystone | 12:50 | |
| *** EmilienM is now known as EmilienM|off | 12:50 | |
| *** aix has joined #openstack-keystone | 12:56 | |
| *** vg_ has quit IRC | 12:59 | |
| *** ajayaa has quit IRC | 13:02 | |
| *** rushiagr_away has quit IRC | 13:04 | |
| *** jasondotstar has joined #openstack-keystone | 13:06 | |
| *** nkinder has quit IRC | 13:06 | |
| *** Ctina___ has joined #openstack-keystone | 13:19 | |
| *** zzzeek has joined #openstack-keystone | 13:28 | |
| *** e0ne is now known as e0ne_ | 13:33 | |
| *** iamjarvo has joined #openstack-keystone | 13:34 | |
| *** iamjarvo has quit IRC | 13:34 | |
| *** rushiagr_away has joined #openstack-keystone | 13:35 | |
| *** vilobhmm has joined #openstack-keystone | 13:35 | |
| *** ayoung has joined #openstack-keystone | 13:35 | |
| *** ChanServ sets mode: +v ayoung | 13:35 | |
| *** yottatsa has joined #openstack-keystone | 13:35 | |
| *** kiranr has joined #openstack-keystone | 13:36 | |
| *** yottatsa has quit IRC | 13:36 | |
| *** e0ne_ is now known as e0ne | 13:37 | |
| *** janonymous_ has joined #openstack-keystone | 13:38 | |
| *** yottatsa has joined #openstack-keystone | 13:39 | |
| *** kiranr has quit IRC | 13:41 | |
| *** charlesw has joined #openstack-keystone | 13:49 | |
| *** vilobhmm has quit IRC | 13:49 | |
| *** zzzeek has quit IRC | 13:49 | |
| *** vilobhmm has joined #openstack-keystone | 13:49 | |
| *** Raildo_ has joined #openstack-keystone | 13:52 | |
| *** yottatsa has quit IRC | 13:53 | |
| *** yottatsa has joined #openstack-keystone | 13:55 | |
| *** vhoward has left #openstack-keystone | 13:56 | |
| *** yottatsa has quit IRC | 13:56 | |
| *** vhoward has joined #openstack-keystone | 13:56 | |
| *** jasondot_ has joined #openstack-keystone | 14:00 | |
| *** dims has quit IRC | 14:02 | |
| janonymous_ | ``/info`` --> ? | 14:02 |
| *** bknudson has quit IRC | 14:02 | |
| *** marzif has joined #openstack-keystone | 14:02 | |
| *** dims has joined #openstack-keystone | 14:03 | |
| *** timsim has left #openstack-keystone | 14:04 | |
| *** ajayaa has joined #openstack-keystone | 14:10 | |
| *** mabrams has left #openstack-keystone | 14:11 | |
| *** iamjarvo has joined #openstack-keystone | 14:12 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:14 | |
| *** fhubik is now known as fhubik_afk | 14:18 | |
| *** davechen_away has quit IRC | 14:24 | |
| *** davechen_away has joined #openstack-keystone | 14:25 | |
| *** Ctina___ has quit IRC | 14:27 | |
| *** yottatsa has joined #openstack-keystone | 14:33 | |
| *** stevemar has joined #openstack-keystone | 14:34 | |
| *** ChanServ sets mode: +v stevemar | 14:34 | |
| *** fhubik_afk is now known as fhubik | 14:34 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Show friendly message when request body is empty https://review.openstack.org/195001 | 14:35 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 14:39 |
| *** janonymous_ has quit IRC | 14:44 | |
| *** jasondotstar has quit IRC | 14:45 | |
| *** fhubik is now known as fhubik_afk | 14:46 | |
| *** jasondot_ has quit IRC | 14:47 | |
| *** e0ne is now known as e0ne_ | 14:47 | |
| *** e0ne_ is now known as e0ne | 14:48 | |
| *** jasondotstar has joined #openstack-keystone | 14:54 | |
| *** mestery has joined #openstack-keystone | 14:57 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Group role revocation invalidates all user tokens https://review.openstack.org/141854 | 14:57 |
| amakarov | ayoung, hi! ^^ | 14:57 |
| marekd | stevemar: hi, would you care taking a look at this: https://review.openstack.org/#/c/188581/27 and up ? | 14:58 |
| amakarov | ayoung, please look at that revocation change - I hope I understand revocation by scope correctly | 14:58 |
| *** stevemar has quit IRC | 14:59 | |
| *** charlesw_ has joined #openstack-keystone | 15:00 | |
| ayoung | amakarov, looking | 15:01 |
| openstackgerrit | Marek Denis proposed openstack/keystone: Accept both formats of federation mapping rules https://review.openstack.org/195132 | 15:01 |
| *** charlesw has quit IRC | 15:01 | |
| *** charlesw_ is now known as charlesw | 15:02 | |
| ayoung | amakarov, do you really still plan on listing all users in the group? | 15:03 |
| amakarov | ayoung, it's for TRL | 15:03 |
| ayoung | ah...ok, so old code only | 15:03 |
| *** rwsu has joined #openstack-keystone | 15:04 | |
| ayoung | that really should be wrapped by an if block | 15:04 |
| *** thedodd has joined #openstack-keystone | 15:04 | |
| *** r-daneel has joined #openstack-keystone | 15:05 | |
| amakarov | ayoung, if block with witch condition? | 15:06 |
| ayoung | amakarov, one sec, I'll post the review | 15:06 |
| ayoung | amakarov, it seems pretty close | 15:07 |
| *** jasondotstar has quit IRC | 15:08 | |
| *** nkinder has joined #openstack-keystone | 15:10 | |
| amakarov | ayoung, thank you, I'll proceed | 15:11 |
| *** Lactem has joined #openstack-keystone | 15:12 | |
| *** jasondotstar has joined #openstack-keystone | 15:12 | |
| Lactem | test | 15:12 |
| *** fhubik_afk is now known as fhubik | 15:12 | |
| Lactem | My IP was blocked yesterday for some reason. | 15:13 |
| *** rwsu has quit IRC | 15:17 | |
| *** rwsu has joined #openstack-keystone | 15:17 | |
| *** Ctina___ has joined #openstack-keystone | 15:18 | |
| *** browne has joined #openstack-keystone | 15:19 | |
| *** geoffarnold has quit IRC | 15:21 | |
| *** vilobhmm has quit IRC | 15:22 | |
| *** ajayaa has quit IRC | 15:27 | |
| *** nkinder has quit IRC | 15:30 | |
| *** bknudson has joined #openstack-keystone | 15:34 | |
| *** ChanServ sets mode: +v bknudson | 15:34 | |
| *** fhubik is now known as fhubik_afk | 15:38 | |
| *** e0ne is now known as e0ne_ | 15:40 | |
| *** dramakri has joined #openstack-keystone | 15:43 | |
| *** diazjf has joined #openstack-keystone | 15:44 | |
| *** e0ne_ is now known as e0ne | 15:45 | |
| *** pballand has joined #openstack-keystone | 15:47 | |
| *** jasondotstar has quit IRC | 15:50 | |
| *** jasondotstar has joined #openstack-keystone | 15:50 | |
| openstackgerrit | Fernando Diaz proposed openstack/keystone: Adding Documentation for Mapping Combinations https://review.openstack.org/192850 | 15:52 |
| *** charlesw_ has joined #openstack-keystone | 15:53 | |
| *** jasondot_ has joined #openstack-keystone | 15:54 | |
| *** charlesw has quit IRC | 15:54 | |
| *** charlesw_ is now known as charlesw | 15:54 | |
| *** jasondot_ has quit IRC | 15:55 | |
| rodrigods | bknudson, ping... are you ok with the API spec being uploaded in a different review? https://review.openstack.org/#/c/193543/ | 15:55 |
| *** Ephur has joined #openstack-keystone | 15:59 | |
| *** fhubik_afk is now known as fhubik | 16:00 | |
| *** spandhe has joined #openstack-keystone | 16:03 | |
| *** iamjarvo has quit IRC | 16:04 | |
| *** jasondotstar has quit IRC | 16:05 | |
| *** aix has quit IRC | 16:06 | |
| *** jasondotstar has joined #openstack-keystone | 16:07 | |
| *** geoffarnold has joined #openstack-keystone | 16:10 | |
| morganfainberg | Lactem: weird. | 16:11 |
| Lactem | It's cool now. | 16:12 |
| *** edmondsw has quit IRC | 16:12 | |
| Lactem | I'm just waiting to talk to Dolph about the bug. | 16:12 |
| *** belmoreira has quit IRC | 16:12 | |
| *** spandhe has quit IRC | 16:18 | |
| openstackgerrit | Victor Morales proposed openstack/keystone: Integrate OSprofiler in Keystone https://review.openstack.org/103368 | 16:20 |
| *** afazekas has quit IRC | 16:23 | |
| *** _cjones_ has joined #openstack-keystone | 16:24 | |
| *** henrynash has joined #openstack-keystone | 16:27 | |
| *** ChanServ sets mode: +v henrynash | 16:27 | |
| *** tqtran has joined #openstack-keystone | 16:27 | |
| bknudson | rodrigods: sure. | 16:29 |
| rodrigods | bknudson, great! thx | 16:31 |
| bknudson | rodrigods: where the different review? | 16:31 |
| rodrigods | bknudson, https://review.openstack.org/#/c/153007/ we are waiting for this spec to be approved in order to update it | 16:32 |
| *** jasondotstar has quit IRC | 16:36 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Group role revocation invalidates all user tokens https://review.openstack.org/141854 | 16:36 |
| *** jasondotstar has joined #openstack-keystone | 16:37 | |
| *** rushiagr_away is now known as rushiagr | 16:38 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: WIP: API changes for Reseller https://review.openstack.org/153007 | 16:39 |
| *** Jason10258 has joined #openstack-keystone | 16:39 | |
| *** Lactem has quit IRC | 16:39 | |
| rodrigods | bknudson, rebased ^ made the API spec follow up patch from henrynash's change | 16:39 |
| *** Lactem has joined #openstack-keystone | 16:39 | |
| henrynash | rodigods: thx | 16:39 |
| henrynash | rodigods, samueldmq: who was it in Horizon who was working on a patch for domain tokens….if we are going to do this project token idea in L, we probably don’t want them to land a patch to start using domain tokens | 16:40 |
| *** vg_ has joined #openstack-keystone | 16:40 | |
| henrynash | better to get peope to start using project tokens with is_domain=True….that way domain tokens can die an early death | 16:41 |
| morganfainberg | bknudson: we should be looking to back port the simplified wsgi scripts to kilo as well. If at all possible. | 16:42 |
| rodrigods | henrynash, totally agree. Maybe we can ask lhcheng to help with this | 16:42 |
| morganfainberg | henrynash: yay! | 16:42 |
| *** fangzhou has joined #openstack-keystone | 16:44 | |
| Raildo_ | henrynash, ++ | 16:45 |
| samueldmq | henrynash: hi | 16:48 |
| henrynash | samueldmq: hi | 16:49 |
| samueldmq | henrynash: I think there is a patch from david-lyle for this | 16:49 |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Group role revocation invalidates all user tokens https://review.openstack.org/141854 | 16:49 |
| samueldmq | henrynash: let me see if I can find it, I remember to give a link to someone (maybe you) a few days ago | 16:49 |
| henrynash | samueldmq: yes, I think you posted it here….but I can’t find it right now | 16:50 |
| *** iamjarvo has joined #openstack-keystone | 16:50 | |
| samueldmq | henrynash: easy one | 16:51 |
| samueldmq | henrynash: https://review.openstack.org/#/c/141153/ and https://review.openstack.org/#/c/148082/ | 16:51 |
| samueldmq | :-) | 16:51 |
| *** stevemar has joined #openstack-keystone | 16:51 | |
| *** ChanServ sets mode: +v stevemar | 16:51 | |
| bknudson | morganfainberg: I've been trying to figure out how to install the scripts | 16:52 |
| bknudson | pbr / setuptools isn't working as expected | 16:52 |
| morganfainberg | Hmm | 16:52 |
| bknudson | the docs say that with pbr you can tell it to install a file wherever you want but I've tried and no worky | 16:52 |
| *** dontalton has joined #openstack-keystone | 16:52 | |
| morganfainberg | Yeah we shouldn't really be installing *anywhere* | 16:53 |
| morganfainberg | it would break on different distros | 16:53 |
| *** zzzeek has joined #openstack-keystone | 16:53 | |
| bknudson | if that's the case then installing somewhere isn't going to work | 16:53 |
| morganfainberg | If anything the bin dir where other console scripts go.. But don't try and put it someplace else. | 16:53 |
| *** lsmola has quit IRC | 16:53 | |
| bknudson | as far as I can tell pbr / setuptools only supports console scripts | 16:54 |
| morganfainberg | Then either it's a console script or it's not. | 16:54 |
| bknudson | but a wsgi script isn't a console script | 16:54 |
| bknudson | it has to export the application symbol which pbr / setuptools console scripts don't do | 16:54 |
| *** gyee_ has joined #openstack-keystone | 16:55 | |
| morganfainberg | Then let's just do it as we do today and back port the fixes to make it simple / same on kilo and master (and potentially Juno) | 16:55 |
| morganfainberg | I don't think we can do anything else because it becomes too distro specific | 16:55 |
| *** jasondot_ has joined #openstack-keystone | 16:56 | |
| morganfainberg | And the packagers will do something else as well. | 16:56 |
| morganfainberg | This is not something pip really should be handling. | 16:56 |
| bknudson | we'll just not know where the script is going to be and have to document it | 16:56 |
| morganfainberg | And that is what I've been saying from the start. | 16:56 |
| *** fhubik is now known as fhubik_afk | 16:56 | |
| bknudson | sdague won't be happy. | 16:56 |
| morganfainberg | Well he can be unhappy. I'm going to block trying to make this a pip thing for now. | 16:57 |
| morganfainberg | So we can fix the issue at hand. If there is a way in the future to do it we can look at it, but let's not spin our wheels too much. This is a separate concern from what pip usually does. | 16:58 |
| morganfainberg | Block = -1 and say not worth spending too much time on it right now. | 16:58 |
| bknudson | https://review.openstack.org/#/c/194442/ is the change to keystone | 16:58 |
| bknudson | and https://review.openstack.org/#/c/194729/ is the change to devstack | 16:59 |
| bknudson | if you want to comment there | 16:59 |
| *** spandhe has joined #openstack-keystone | 16:59 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Relax the formats of accepted mapping rules for keystone-manage https://review.openstack.org/195132 | 17:01 |
| samueldmq | morganfainberg: ayoung hi, I have a question regarding our conversation on dynamic policies yesterday | 17:04 |
| morganfainberg | bknudson: commented on your patch | 17:05 |
| morganfainberg | bknudson: i'm not a fan of the devstack change... but that is acceptible | 17:06 |
| *** stevemar has quit IRC | 17:06 | |
| samueldmq | morganfainberg: ayoung so keystone doesn't own anything besides the overrides, my only concern is about UX | 17:06 |
| ayoung | samueldmq, go on | 17:06 |
| morganfainberg | samueldmq: for the first step, keystone only owns overrides | 17:06 |
| samueldmq | since admins need to lookup to another place to see what operations are available | 17:06 |
| *** stevemar has joined #openstack-keystone | 17:07 | |
| *** ChanServ sets mode: +v stevemar | 17:07 | |
| samueldmq | morganfainberg: ayoung ah ok, just making sure this is not the final solution in keystone side, as you saidin this first step | 17:07 |
| morganfainberg | samueldmq: i would prefer it to be documentation not an example policy file that they upload to keystone | 17:07 |
| morganfainberg | samueldmq: for now. | 17:07 |
| *** jasondot_ has quit IRC | 17:07 | |
| morganfainberg | if it is policy-in-code, we generate docs from it (likely we should be generating docs based upon the enforcement with sphinx) so it can be clear what things are doing what | 17:08 |
| morganfainberg | in either case, we should have it documented not be "here is a blob, good luck knowhing what these really do" | 17:08 |
| morganfainberg | imo | 17:08 |
| *** fhubik_afk is now known as fhubik | 17:09 | |
| samueldmq | morganfainberg: I mean, I am customizing nova policy is keystone side | 17:10 |
| samueldmq | morganfainberg: I need to be looking to other docs to see what I can put there | 17:10 |
| samueldmq | morganfainberg: actually that's not bad | 17:10 |
| morganfainberg | samueldmq: so, stop thinking of customising policy being a keystone thing | 17:10 |
| samueldmq | morganfainberg: just different from what we have today, where you can see what is available at the same time you customize | 17:10 |
| morganfainberg | samueldmq: the centralization of policy will be 100% optional | 17:11 |
| samueldmq | morganfainberg: when you look at policy.json .. | 17:11 |
| morganfainberg | if the deployer wants to put the overrides on disk on the nova node(s), and never fetch from keystone, that will also work | 17:11 |
| *** iamjarvo has quit IRC | 17:11 | |
| samueldmq | morganfainberg: sure, that's like an extension | 17:11 |
| samueldmq | with a config switch | 17:11 |
| morganfainberg | no not an extension | 17:11 |
| morganfainberg | not a config switch | 17:11 |
| samueldmq | oh, looks like I know nothing then | 17:12 |
| morganfainberg | well maybe a config switch to not fetch | 17:12 |
| *** jasondot_ has joined #openstack-keystone | 17:12 | |
| morganfainberg | you will still source the policy overrides from a known location (path like today) | 17:12 |
| morganfainberg | the fetch policy code will just collect that override from keystone | 17:12 |
| morganfainberg | and place it on disk | 17:12 |
| samueldmq | got it | 17:13 |
| morganfainberg | customizing policy is still customizing policy - we are changing it so only overrides are needed instead of a complete replacement | 17:13 |
| samueldmq | another thing .. | 17:13 |
| samueldmq | yes, we control customization on keystone side, if one decides to use it | 17:13 |
| *** stevemar has quit IRC | 17:14 | |
| samueldmq | morganfainberg: one more thing, endpoint_url should be a property of a policy entity, right? | 17:14 |
| morganfainberg | huh? | 17:14 |
| samueldmq | can we have an override doesn't belong to an endpoint_url? | 17:14 |
| morganfainberg | no | 17:14 |
| samueldmq | so yes, every override (policy) must have an endpoint_url with it | 17:15 |
| morganfainberg | yes. | 17:15 |
| samueldmq | nice | 17:15 |
| morganfainberg | it doesn't need to be a FK on the endpoint in the catalog | 17:15 |
| morganfainberg | it just needs to be specifically tied to an endpoint_url | 17:15 |
| samueldmq | nice | 17:16 |
| samueldmq | going to update wiki | 17:16 |
| morganfainberg | cool | 17:16 |
| samueldmq | morganfainberg: looks like this solution is very simple | 17:16 |
| *** yottatsa has quit IRC | 17:16 | |
| *** e0ne has quit IRC | 17:16 | |
| samueldmq | morganfainberg: and very interesting | 17:16 |
| morganfainberg | samueldmq: we have ~4-5 total things to write here this cycle | 17:16 |
| samueldmq | morganfainberg: and I am sure we'll have all them :) | 17:17 |
| ayoung | GAH!. OK, the Ansible module to create a router (quantum_router.py HA!) needs to convert a tenant name to id, and does a project list...but the user is not allowed to do a project list by policy | 17:17 |
| morganfainberg | oslo.policy overlay / merge [overrides and baseline], updates to local policy files (where appropriate), fetch policy overrides from keystone, store policy overrides in keystone, (stretch goal): enforce on url instead of internal-name | 17:17 |
| ayoung | our naming sucks | 17:17 |
| samueldmq | morganfainberg: let's just keep moving, and working ahrd, we'll get there | 17:17 |
| *** iamjarvo has joined #openstack-keystone | 17:18 | |
| ayoung | morganfainberg, customizing policy is totally going to be keystone thing. | 17:18 |
| samueldmq | morganfainberg: I dont undertand the last one | 17:18 |
| samueldmq | (stretch goal): enforce on url instead of internal-name | 17:19 |
| ayoung | not a stretch goal samueldmq | 17:19 |
| morganfainberg | ayoung: nope. it has to allow CMS to load overrides from disk and never fetch - it does not have to be a keystone thing | 17:19 |
| morganfainberg | ayoung: yes it is. | 17:19 |
| morganfainberg | ayoung: i told you i'm putting it on the table. if someone wants to do it | 17:19 |
| morganfainberg | i wont say no | 17:19 |
| ayoung | morganfainberg, I would say it is a core goal,. mnot stretch | 17:19 |
| morganfainberg | ayoung: core goal overall, stretch for liberty | 17:19 |
| morganfainberg | ayoung: i can agree with that | 17:19 |
| ayoung | ah..sorry | 17:19 |
| morganfainberg | ayoung: yeah :) | 17:19 |
| ayoung | I was thinking of the fetch by URL | 17:20 |
| morganfainberg | no no the enforce by url :) | 17:20 |
| morganfainberg | fetch by url is def. part of liberty goals | 17:20 |
| samueldmq | I enforce by url? | 17:20 |
| ayoung | ok..we are in agreement...with the customize, It is also outside of what we are trying for in liberty | 17:20 |
| morganfainberg | samueldmq: enforce by url - if we have someone who wants to work on it - we want it, but unless someone provides resources we can't commit to it for liberty | 17:20 |
| ayoung | line level modifications of the policy files...needs the DB backend, I think | 17:21 |
| samueldmq | morganfainberg: sure, I just don't remember what this thing is | 17:21 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 17:21 | |
| morganfainberg | samueldmq: enforce by url is instead of saying "nova_create" it's "/path/to/boot/instance" | 17:21 |
| morganfainberg | in the policy file | 17:21 |
| *** Ctina___ has quit IRC | 17:21 | |
| morganfainberg | ayoung: yep, need the DB stuff before we can do line-by-line stuff. | 17:21 |
| samueldmq | morganfainberg: ohmm, got it thanks | 17:21 |
| *** roxanaghe has joined #openstack-keystone | 17:21 | |
| morganfainberg | ayoung: and i don't think we can commit to that in liberty. | 17:21 |
| morganfainberg | since that logically is built behind/on top of the other stuff. | 17:22 |
| *** Ctina___ has joined #openstack-keystone | 17:22 | |
| ayoung | morganfainberg, so...I don;t think we actually need upload by URL | 17:22 |
| *** pnavarro|off has joined #openstack-keystone | 17:22 | |
| ayoung | I think it will more work like this: | 17:23 |
| ayoung | after a base install, upload the policy to Keystone for the service, not the endpoint | 17:23 |
| ayoung | all endpoints for the same service should use the same policy file | 17:23 |
| samueldmq | ayoung: the policy file ? overrides? | 17:23 |
| ayoung | samueldmq, I'll link top the API, but it is in the endpoint-policy extension right now | 17:24 |
| morganfainberg | ayoung: ok we will be delayed on unified catalog work then i think. | 17:24 |
| morganfainberg | ayoung: erm, cleaned up catalog | 17:24 |
| samueldmq | ayoung: oh for the same service? I think we should go in the URL | 17:24 |
| ayoung | morganfainberg, why? | 17:24 |
| morganfainberg | ayoung: and actually some endpoints will have different policy (you might have a beta endpoint that requires different roles) - this is done today | 17:24 |
| morganfainberg | i think we need to stick to endpoint for now. | 17:25 |
| samueldmq | ayoung: when morganfainberg said we should be thinking in a new policy api, I was thinking like a CRUD on policy overrides, where the ID is the URL, or simething like that | 17:25 |
| ayoung | morganfainberg, that will still work, but they are not the norm. Those are the one offs...but, yeah, those could be done by URL | 17:25 |
| david8hu | morganfainberg, store policy override per endpoint? | 17:25 |
| morganfainberg | ayoung: the other issue is right now service is not unique | 17:25 |
| morganfainberg | ayoung: service type | 17:25 |
| morganfainberg | ayoung: so you're back to by id | 17:25 |
| * morganfainberg sighs | 17:25 | |
| morganfainberg | you can have 3 different services today called compute | 17:26 |
| ayoung | morganfainberg, but, in general, won;t they all share the same policy? | 17:26 |
| ayoung | I mean, normale case? | 17:26 |
| morganfainberg | ayoung: not nessicarily | 17:26 |
| morganfainberg | ayoung: you might have distinct things running on those services that are wildly different | 17:26 |
| ayoung | morganfainberg, I'm talking expected deployments, not customizations | 17:26 |
| *** jasondot_ has quit IRC | 17:26 | |
| morganfainberg | ayoung: so, expected deployment is "don't make assumptions about what people do - our catalog is bad and people do bad things in deployments" | 17:27 |
| david8hu | morganfainberg, ayoung, I likt it to be flexible enough, so we can achieve policy per project or domain at some point in the future. | 17:27 |
| ayoung | and...does endpoint link to service by ID or type... | 17:27 |
| morganfainberg | we've already broken people by accident making a similar assumption | 17:27 |
| morganfainberg | endpoint links to service by id | 17:27 |
| morganfainberg | as a FK | 17:27 |
| ayoung | morganfainberg, we haven't broken any ability to do things here, though. Actually, the issue might be higher up... | 17:28 |
| ayoung | 1 sec... | 17:28 |
| morganfainberg | we broke people in a similar way with the domain SQL and ldap change | 17:28 |
| morganfainberg | we assumed no one would ever be using the LDAP driver as the default and override with SQL on one domain | 17:28 |
| morganfainberg | well, we have people doing that | 17:28 |
| morganfainberg | and we need to revert [i need to check on that] the limitation out | 17:28 |
| morganfainberg | i am saying we can't assume a deployment is expected if we have the flexibility in place that lets things be sloppy | 17:30 |
| morganfainberg | david8hu: i can say i expect policy per project is, if ever, a looooooong way out | 17:30 |
| morganfainberg | david8hu: policy per domain i also think is a long way out | 17:30 |
| *** rlt_ has quit IRC | 17:31 | |
| *** jasondot_ has joined #openstack-keystone | 17:31 | |
| david8hu | Let's aim for Z, then :) | 17:31 |
| morganfainberg | david8hu: eh, maybe the next A release :P | 17:31 |
| ayoung | morganfainberg, nah, I am just trying to cover the expected case cleanly. I know people don;'t like the "get back and ID and work with it" approach, but for policy, which was designed with ID as the only idenitifier, ID is the only way to share | 17:32 |
| morganfainberg | can we just dump that old api and stop referencing it | 17:32 |
| ayoung | morganfainberg, It would be better if we used the SHA256 of the policy file as the ID | 17:32 |
| morganfainberg | because no one uses it | 17:32 |
| ayoung | that way, two different uploads of an identical file get the same thing. | 17:32 |
| ayoung | And, it should make it easier to update things in sync when the stock policies change | 17:32 |
| morganfainberg | i'm fine with a behind the scenes using a sha for the id | 17:33 |
| *** Jason10258 has quit IRC | 17:33 | |
| ayoung | morganfainberg, what I don't want to have become the norm is "I installed a new endpoint, I need to explicitly set up the policy for it" | 17:34 |
| morganfainberg | ayoung: we are already heading that way | 17:35 |
| david8hu | morganfainberg, ayoung, Once a new policy is updated for an endpoint, it should persist in keystone and become the new default for that endpoint. | 17:35 |
| morganfainberg | ayoung: because you also can't be too generic, services bridge regions | 17:35 |
| morganfainberg | and policy may be different per region | 17:35 |
| ayoung | david8hu, I'm puishing for a global policy file...do you see the difference in emphasis | 17:35 |
| ayoung | morganfainberg, *may be* is great | 17:36 |
| morganfainberg | i have a meeting i need to go to | 17:36 |
| ayoung | but say I've customized the policy for my region, and I add another endpoint, I should not fall back to stock | 17:36 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: admin and public httpd files https://review.openstack.org/194442 | 17:36 |
| david8hu | ayoung, a global policy, then customizable per endpoint needs? | 17:36 |
| ayoung | david8hu, that is my goal, yes | 17:36 |
| ayoung | so we have sane, and cooperating defaults | 17:36 |
| morganfainberg | ayoung: we may need to map this out at the midcycle instead of on irc | 17:36 |
| ayoung | morganfainberg, ++ but I think we are still making progress | 17:37 |
| *** lhcheng has joined #openstack-keystone | 17:37 | |
| *** ChanServ sets mode: +v lhcheng | 17:37 | |
| ayoung | just the fact that we are having this discussion gives me some small hope | 17:37 |
| *** dguerri is now known as dguerri` | 17:37 | |
| david8hu | ayoung, good idea, so there is always a default policy, not a NULL. | 17:37 |
| morganfainberg | ayoung: lets get the basic support stuff [the biggest peiece we're going to need is the overlay/merge bit] | 17:37 |
| morganfainberg | ayoung: and where we stick the fetcher. | 17:37 |
| samueldmq | morganfainberg: yes as we discussed yesterday | 17:37 |
| *** openstackgerrit has quit IRC | 17:38 | |
| morganfainberg | we can go back and forth on the way policy is stored in keystone a bit more easily | 17:38 |
| *** jasondot_ has quit IRC | 17:38 | |
| morganfainberg | but those two (first) peices we need in either case | 17:38 |
| samueldmq | morganfainberg: ayoung and we will have time to discuss and improve it based on this base things | 17:38 |
| ayoung | morganfainberg, what I would like to see the workflow of a new install in Liberty default to is to upload the policy upon service registration. Later on, I would like there tio be a unified policy file, and the workflow should be only upload once...and then customize deliberately | 17:38 |
| david8hu | ayoung, need to keep the ball rolling...still...:) | 17:38 |
| *** openstackgerrit has joined #openstack-keystone | 17:38 | |
| morganfainberg | david8hu: the thought is the services own the default policy. keystone should not own it | 17:38 |
| morganfainberg | david8hu: ever | 17:39 |
| *** henrynash has quit IRC | 17:39 | |
| *** jasondotstar has quit IRC | 17:39 | |
| morganfainberg | because i don't want services coming to me and saying "hey can we update our policy" | 17:39 |
| morganfainberg | they know the APIs and how things link together, we don't | 17:39 |
| samueldmq | morganfainberg: ++ | 17:39 |
| * morganfainberg goes off to meeting. | 17:39 | |
| morganfainberg | be back a bit later | 17:39 |
| *** yottatsa has joined #openstack-keystone | 17:40 | |
| david8hu | morganfainberg, agreed. nova does not need keystone core to +2 its default policy changes. | 17:40 |
| ayoung | david8hu, I was thinking it should be a cross project repo...maybe Oslo, with a section for each project | 17:41 |
| ayoung | something like this: | 17:41 |
| ayoung | https://github.com/admiyo/openstack-core-policy | 17:41 |
| *** henrynash has joined #openstack-keystone | 17:41 | |
| *** ChanServ sets mode: +v henrynash | 17:41 | |
| ayoung | you update the nova file then regenerate | 17:41 |
| david8hu | ayoung, deployer does the update? | 17:42 |
| *** diazjf has quit IRC | 17:42 | |
| ayoung | david8hu, that is the default, shipped by Openstack | 17:43 |
| ayoung | deployer will fetch that, and can even modify before deploying | 17:44 |
| ayoung | david8hu, the review proces is just to make sure that the policy changes are sane across the projects. | 17:44 |
| david8hu | ayoung, the files in the repo got to have tighter controll in terms of who gets +2 default or stock policy file changes. | 17:44 |
| ayoung | david8hu, one rep per project or something like that | 17:45 |
| david8hu | ayoung, for example, only keystone cores should +2 keystone-policy.json | 17:45 |
| ayoung | just to have a second set of eyeballs on it. Changes should be very infrequest, or require a lot of corss project talk | 17:45 |
| ayoung | david8hu, nah | 17:45 |
| ayoung | let Nova read Keystone policy | 17:45 |
| ayoung | and vice versa | 17:45 |
| *** mgarza_ has joined #openstack-keystone | 17:45 | |
| david8hu | more visibility to each others's policy is not a bad thing | 17:46 |
| *** Raildo_ has quit IRC | 17:47 | |
| *** stevemar has joined #openstack-keystone | 17:48 | |
| *** ChanServ sets mode: +v stevemar | 17:48 | |
| david8hu | ayoung, to solve 6689874657, perhaps have sub dir structure under openstack-core-policy. openstack-core-policy/base openstack-core-policy/service_admin | 17:48 |
| ayoung | 6689874657? | 17:49 |
| david8hu | whatever that number is | 17:50 |
| ayoung | 968696? | 17:50 |
| david8hu | the global admin bug | 17:50 |
| david8hu | yes, 968696 | 17:50 |
| david8hu | ayoung, we can attempt to get it right this time. | 17:51 |
| ayoung | david8hu, it needs a unified policy...all the dyanmic stuff is leading to that | 17:51 |
| ayoung | and I need to try out that unified policy file on a deployemnt | 17:52 |
| david8hu | ayoung, thoughts on what the chances are to have unified policy for liberty? We can implment openstack-core-policy/base openstack-core-policy/service_admin for liberty if unified should come after L. | 17:55 |
| morganfainberg | david8hu: i'd -2 an attempt to split policy into a separate project like that. | 17:57 |
| ayoung | david8hu, I think the effort can go in parallel. My understanding of how this works has changed over time. There really is no reason the unified has to start off as a blessed version; it could be devstack, or even just a community resource until the policy is shaken out | 17:57 |
| ayoung | its not the stock policy, it is *a* unified policy | 17:57 |
| morganfainberg | david8hu: plain and simple. the projects should own the base policy | 17:57 |
| ayoung | morganfainberg, wow...so not | 17:57 |
| ayoung | they should own a section of it | 17:57 |
| ayoung | but not the roles part | 17:57 |
| morganfainberg | ayoung: you and i will continue to disagree on this | 17:57 |
| morganfainberg | i am against centralizing the base policy | 17:58 |
| ayoung | its more complicated than blanket statements like that will support | 17:58 |
| morganfainberg | very much against it | 17:58 |
| ayoung | You run wuith SELinux disabled, too, I bet | 17:58 |
| *** thedodd has quit IRC | 17:59 | |
| ayoung | oh, wait...App Armor...Debian based | 17:59 |
| morganfainberg | ayoung: SELinux is disabled in most places because no one can be bothered with the awful syntax. it's why ubuntu uses apparmor and mostly only RH based distros (or specific distributions) use SELinux | 17:59 |
| morganfainberg | ayoung: and with apparmor, the individual packages own the policy/install the policy. i think even SELinux works like that | 17:59 |
| david8hu | morganfainberg, for keystone, we currently have policy.json and policy.v3cloudsample.json. We need a better way to structure that. | 17:59 |
| ayoung | Security is hard, lets go shopping | 17:59 |
| bknudson | fedora provides SELinux configs for openstack | 18:00 |
| morganfainberg | it's not some other repo that everyone has to commit to updating | 18:00 |
| ayoung | morganfainberg, nope. Default policy is in a single repo | 18:00 |
| morganfainberg | ayoung: yeah i'm still against it for OpenStack. | 18:00 |
| ayoung | there are a few projects that have their own, but that is short lived | 18:00 |
| morganfainberg | i much prefer the apparmor model | 18:00 |
| ayoung | and app armor is on the \Dentry, not the Inode, which is just... | 18:00 |
| *** harlowja has quit IRC | 18:00 | |
| ayoung | misunderstanding the problem.... | 18:01 |
| morganfainberg | because what will happen is no one will keep the central store up to date or it'll be impossible to get anything landed | 18:01 |
| morganfainberg | the services should own their base policy. | 18:01 |
| ayoung | but, regardless, I don't even really care if the unified becomes an official thing, so long as we can support one | 18:01 |
| *** e0ne has joined #openstack-keystone | 18:01 | |
| ayoung | morganfainberg, so each project should then specify the roles they require | 18:02 |
| ayoung | cuz Policy is enforced on roles | 18:03 |
| ayoung | and then we need hierarchical roles | 18:03 |
| ayoung | or soemthing | 18:03 |
| ayoung | because people are not going to assign the individual roles...so you see how the design progresses.... | 18:03 |
| *** spandhe has quit IRC | 18:03 | |
| david8hu | morganfainberg, ayoung, This is what I like to achieve. For customers that wants segregate their service, I can tell them to grab a set of policy files and move on. We don't have that today. | 18:03 |
| *** harlowja has joined #openstack-keystone | 18:04 | |
| ayoung | morganfainberg, so, what would work is something like this: | 18:04 |
| ayoung | we put a base policy file under oslo. It has rules that are shared by the other proejcts | 18:04 |
| *** spandhe has joined #openstack-keystone | 18:04 | |
| ayoung | the other proejcts sync down, uincubator style | 18:04 |
| ayoung | and that becomes the base of the project specific policy files | 18:05 |
| *** jaosorior has quit IRC | 18:05 | |
| *** yottatsa has quit IRC | 18:08 | |
| *** e0ne has quit IRC | 18:08 | |
| *** stevemar has quit IRC | 18:08 | |
| *** stevemar has joined #openstack-keystone | 18:09 | |
| *** ChanServ sets mode: +v stevemar | 18:09 | |
| *** stevemar has quit IRC | 18:10 | |
| samueldmq | ayoung: I think oslo.policy should know the role hierarchy, through middleware | 18:11 |
| samueldmq | ayoung: and then it exapneds the policy, whne it is overriding it as well | 18:11 |
| *** stevemar has joined #openstack-keystone | 18:11 | |
| *** ChanServ sets mode: +v stevemar | 18:11 | |
| samueldmq | ayoung: that old idea where role:member is replaced by (role:member or role:admin), in the case admin inherits member | 18:11 |
| david8hu | ayoung, I don't think https://github.com/admiyo/openstack-core-policy/blob/master/policy.json is going to work, since "is_admin:True" is all over the place, and there is no context_is_admin defined. | 18:13 |
| ayoung | david8hu, that one is broken | 18:13 |
| ayoung | david8hu, I just was testing the ability to merge them based on the rule names, not even if the policy itself made sense | 18:13 |
| david8hu | LOL... ok | 18:13 |
| *** diazjf has joined #openstack-keystone | 18:14 | |
| ayoung | I had started by merging in the changes on at a time...but the turn around was way too slow. It really needs something like a temptest run to see if it will work | 18:14 |
| rushiagr | morganfainberg: did you hear back from folks who are working on stable driver interfaces stuff? | 18:14 |
| samueldmq | ayoung: I forgot what is tht tool we've been using to define those diagrams in the wiki | 18:15 |
| *** shaleh has joined #openstack-keystone | 18:15 | |
| ayoung | david8hu, if you go back a few revisions, I did have a working one for nova, cinder, and neutron (I think) maybe glance? | 18:15 |
| samueldmq | ayoung: I can look in the logs, but asking you would be quicker :) | 18:15 |
| ayoung | samueldmq, seqdiag...I have it installed locally | 18:15 |
| *** jaosorior has joined #openstack-keystone | 18:16 | |
| samueldmq | ayoung: thanks | 18:16 |
| ayoung | python-seqdiag-0.9.0-4.fc21.noarch samueldmq | 18:16 |
| rushiagr | morganfainberg: sorry for being a pest of sorts :) | 18:16 |
| *** jasondotstar has joined #openstack-keystone | 18:17 | |
| *** csoukup has joined #openstack-keystone | 18:17 | |
| *** boris-42 has joined #openstack-keystone | 18:18 | |
| *** yottatsa has joined #openstack-keystone | 18:18 | |
| *** stevemar has quit IRC | 18:20 | |
| *** fhubik is now known as fhubik_afk | 18:21 | |
| *** jasondot_ has joined #openstack-keystone | 18:21 | |
| ayoung | rushiagr, so, the current driver contract sucks | 18:22 |
| ayoung | its all dictionaries and I don't really know if it is a contract we should try to support | 18:22 |
| ayoung | so...I'm not that excited about it | 18:22 |
| rushiagr | ayoung: I assume by 'it' you mean dictionaries? | 18:24 |
| *** Rockyg has joined #openstack-keystone | 18:24 | |
| ayoung | rushiagr, yeah | 18:24 |
| gyee_ | ayoung, I don't think we should do params and return type enforcement, something Python is not natural to do | 18:24 |
| rushiagr | ayoung: and not the stable driver interface work :) | 18:24 |
| ayoung | rushiagr, so, If I thought we could actually do things in a timely manner, thuis is what I would suggest | 18:24 |
| ayoung | gyee_, python is totally capable of doing it | 18:25 |
| gyee_ | enforcing return type? | 18:25 |
| ayoung | rushiagr, here is my starting point: https://review.openstack.org/#/c/184651/ | 18:25 |
| *** stevemar has joined #openstack-keystone | 18:25 | |
| *** ChanServ sets mode: +v stevemar | 18:25 | |
| rushiagr | gyee_: I didn't like that idea either. BUT what we can totally do is write tests which try to see if the return value matches expected values | 18:26 |
| ayoung | rushiagr, I would have Keystone token construction work as a pipeline, calling each of the Managers in turn to return an object added to the token-WIP | 18:26 |
| gyee_ | we should think about openssl fips-140 certification approach | 18:26 |
| gyee_ | come up with a set of test vectors | 18:26 |
| gyee_ | if the lib pass the tests, digitally signed the code | 18:27 |
| ayoung | gyee_, we should start by defining a reasonable contract | 18:27 |
| gyee_ | enhance stevedor to validate signatures on lib loading | 18:27 |
| ayoung | gyee_, stop. I know you are only half joking | 18:27 |
| gyee_ | no I am serious | 18:27 |
| ayoung | and it is the other half that scares me | 18:27 |
| ayoung | then I am even more scared | 18:27 |
| gyee_ | loading digitally signed lib? | 18:27 |
| ayoung | that is toally not what we need here | 18:27 |
| gyee_ | what's scary about that | 18:28 |
| rushiagr | ayoung: so are you implying we move _every_ database backend driver to use objects first, and then solve stable driver interfaces? I think stable driver interface work was to avoid people headaches who already maintain out-of-tree drivers :) | 18:28 |
| *** amakarov is now known as amakarov_away | 18:28 | |
| ayoung | gyee_, people are loking for stable interfaces adn you are going full blown crypto enforcement. | 18:28 |
| ayoung | Shill dude | 18:28 |
| ayoung | CHill | 18:28 |
| gyee_ | we for to enforce compliance | 18:28 |
| *** fhubik_afk is now known as fhubik | 18:28 | |
| gyee_ | we want | 18:28 |
| *** fhubik is now known as fhubik_afk | 18:28 | |
| ayoung | rushiagr, meh...I am loosing more and more motivation for doing things in a sustainable way | 18:28 |
| *** diazjf has quit IRC | 18:28 | |
| ayoung | I'm not going to get in the way of other people doing what they think best...just not going to actively contribute to things I think are suboptimal | 18:29 |
| rushiagr | ayoung: that is what technical debt is for :) | 18:29 |
| *** diazjf has joined #openstack-keystone | 18:29 | |
| david8hu | gyee_, Requiring driver developer to pay a fee, go through certication process, then get their driver signed? I thought only Microsoft does that. | 18:29 |
| ayoung | david8hu, fips-140 is a government process | 18:30 |
| gyee_ | david8hu, that's how they certify openssl I think | 18:30 |
| *** dguerri` is now known as dguerri | 18:30 | |
| rushiagr | ayoung: I agree with your spirit of doing work in a way which is beneficial for the long term benefit of the project | 18:30 |
| gyee_ | I don't know any python magic out there that can enforce return type on lib loading | 18:31 |
| *** dguerri is now known as dguerri` | 18:32 | |
| rushiagr | ayoung: but how about this: we implement stable driver interfaces first. Yes, with dictionaries, which is kind-of suboptimal, so as to get other people who are already struggling to keep up with the pace at which we move. And then take on the problem of passing objects instead of dictionaries? | 18:32 |
| *** fhubik_afk is now known as fhubik | 18:33 | |
| *** thedodd has joined #openstack-keystone | 18:33 | |
| *** fhubik is now known as fhubik_afk | 18:33 | |
| rushiagr | ayoung: it will help the motivation of people who maintain out-of-tree drivers a little bit | 18:33 |
| gyee_ | rushiagr, what are we *enforcing* then? | 18:34 |
| *** Rockyg has quit IRC | 18:34 | |
| rushiagr | ayoung: and just to reiterate, I completely agree with you that object passing _should_ be the long term way forward | 18:34 |
| rushiagr | gyee_: what can we enforce with objects that we can't with dictionaries? | 18:36 |
| gyee_ | ayoung, btw, I got sssd working on my devstack somewhat, but there are issues | 18:36 |
| gyee_ | rushiagr, how do we enforce return type at load time? | 18:37 |
| morganfainberg | gyee_: you don't get to do that in python :P | 18:37 |
| gyee_ | morganfainberg, exactly, so test vector is one way to do it | 18:38 |
| gyee_ | and make sure the code stay the same as tested | 18:38 |
| morganfainberg | gyee_: i'm not advocating driver signing - lets not go down that path yet | 18:38 |
| morganfainberg | lets just get stable defined contracted interfaces first ;) | 18:38 |
| gyee_ | morganfainberg, yes, they are two different issues | 18:38 |
| morganfainberg | we can build on top of that | 18:38 |
| gyee_ | but yes, stable interface first is a must | 18:38 |
| morganfainberg | gyee_: ++ | 18:39 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 18:39 | |
| morganfainberg | rushiagr: ^ | 18:39 |
| gyee_ | ayoung, sssd and mapping choke on multiple groups | 18:39 |
| ayoung | gyee_, nah...it is a different separator character | 18:39 |
| gyee_ | and it does not work with UserGroupsIter | 18:40 |
| ayoung | gyee_, I had it at one point...lets see | 18:40 |
| gyee_ | ayoung, don't think our mapping is capable of handling separators in one string | 18:40 |
| rushiagr | gyee_: yes, test vector is what I was thinking when I was talking about SDI | 18:40 |
| gyee_ | we'll need a patch to fix that | 18:40 |
| *** fhubik_afk is now known as fhubik | 18:40 | |
| ayoung | gyee_, you don't have to, it is a mod_lookup_id config | 18:40 |
| gyee_ | ayoung, I have both LookupUserGroups and LookupUserGroupsIter set | 18:41 |
| ayoung | LookupUserGroups REMOTE_USER_GROUPS ";" | 18:41 |
| gyee_ | yes | 18:41 |
| morganfainberg | bknudson: fixed https://review.openstack.org/#/c/173972/ with test-requirements.txt missing oslosphinx change | 18:42 |
| gyee_ | env['REMOTE_USER_GROUPS'] = group1;group2;group3 | 18:42 |
| ayoung | that worked for me... | 18:42 |
| gyee_ | you stuff the entire string in group name? | 18:42 |
| gyee_ | group name is a string, not a set | 18:42 |
| ayoung | gyee_, what do you have for your mapping? | 18:43 |
| ayoung | http://fpaste.org/236276/35171418/ was what I got working | 18:43 |
| ayoung | gyee_, I think it was the difference between "group" and "groups" in the mapping | 18:44 |
| gyee_ | local [group {name: {0}}], remote [REMOTE_USER_GROUPS] | 18:44 |
| ayoung | make that | 18:44 |
| gyee_ | oh | 18:44 |
| ayoung | local [groups {name: {0}}], remote [REMOTE_USER_GROUPS] | 18:44 |
| gyee_ | change group to groups | 18:44 |
| ayoung | yeah...subtle. messed me up too. sorry I didn't not that in the blog. | 18:45 |
| gyee_ | ayoung, thanks, let me give it a try | 18:45 |
| ayoung | gyee_, if it works, please post a comment to the blog...lets record it this time | 18:45 |
| gyee_ | ayoung, sure, will do | 18:46 |
| gyee_ | also, for sssd group lookup to work, I had to add memberUid to the posixGroup | 18:46 |
| *** jasondotstar has quit IRC | 18:48 | |
| rushiagr | gyee_: morganfainberg: so does that mean we're agreeing on doing the stable driver interface work first, without moving to python-objects in place of dictionary passing? Sorry, this part wasn't clear.. | 18:49 |
| rushiagr | or did I miss something? | 18:49 |
| morganfainberg | rushiagr: pretty much. a contract that the drivers can rely on for multiple releases is the important part | 18:50 |
| morganfainberg | if we move to passing objects, it has to be another version of the interface [easy to handle really] | 18:50 |
| morganfainberg | either we convert dict -> object -> dict where needed [use the new version of the interface] - or vice versa | 18:51 |
| bknudson | marshmallow does object marshalling | 18:51 |
| gyee_ | rushiagr, morganfainberg, yeah I agree | 18:51 |
| *** jasondotstar has joined #openstack-keystone | 18:51 | |
| gyee_ | bknudson, mmm, smores | 18:52 |
| rushiagr | morganfainberg: oh. This thought never occurred to me before. Yes, moving from dict -> object can be a version bump... | 18:52 |
| gyee_ | bknudson, you have something that lookup keystone with scim? | 18:53 |
| *** jasondotstar has quit IRC | 18:53 | |
| gyee_ | s/lookup/hookup/ | 18:53 |
| gyee_ | just curious | 18:53 |
| *** stevemar has quit IRC | 18:54 | |
| *** stevemar has joined #openstack-keystone | 18:55 | |
| *** ChanServ sets mode: +v stevemar | 18:55 | |
| *** stevemar has quit IRC | 18:56 | |
| *** stevemar has joined #openstack-keystone | 18:57 | |
| *** ChanServ sets mode: +v stevemar | 18:57 | |
| rushiagr | morganfainberg: gyee_: Okay. I'm also assuming we're going to have a test matrix kind of a thing to check drivers are sticking to the contract. Coz there really is no other way I guess. At least with the method return types part.. | 18:57 |
| ayoung | I want to move to Rust | 18:57 |
| morganfainberg | ayoung: sure do it. | 18:57 |
| morganfainberg | ayoung: it's a cool language. | 18:57 |
| ayoung | morganfainberg, I need some more time to learn it. | 18:58 |
| morganfainberg | rushiagr: gate/check jobs - it's what they're for | 18:58 |
| ayoung | I like what I've seen so far, though | 18:58 |
| morganfainberg | ayoung: it really is hitting the mark for me as i'm learning it | 18:58 |
| morganfainberg | it's fun. | 18:58 |
| gyee_ | rushiagr, yes, phase 2 | 18:58 |
| ayoung | I want to write a PXE server in Rust | 18:58 |
| morganfainberg | rushiagr: return values would fail gate/check type jobs | 18:58 |
| morganfainberg | ayoung: i know someone is writing a gearman server in rust | 18:58 |
| ayoung | maybe iuntegrated with DHCP..although I'd rather move to something IPv6 ish instead | 18:59 |
| morganfainberg | ayoung: PXE, etc that is great stuff for rust | 18:59 |
| ayoung | morganfainberg, yeah, and TFTP is not a bad way for cutting teeth on a new network stack | 18:59 |
| ayoung | one of the easier protocols to hack | 19:00 |
| rushiagr | morganfainberg: 'return values would fail gate/check type jobs' means? | 19:00 |
| *** nkinder has joined #openstack-keystone | 19:01 | |
| *** jasondotstar has joined #openstack-keystone | 19:01 | |
| *** jasondotstar has quit IRC | 19:02 | |
| samueldmq | morganfainberg: ayoung middleware fetches the override policy and uses oslo.policy to do the overlay | 19:04 |
| ayoung | samueldmq, yes | 19:04 |
| samueldmq | ayoung: k | 19:04 |
| morganfainberg | rushiagr: if you don't pass correct values back our testing would show the driver fails | 19:04 |
| morganfainberg | rushiagr: or your testing [if using tempest] would | 19:05 |
| *** jasondot_ has quit IRC | 19:05 | |
| morganfainberg | rushiagr: so not worried about return types/values atm | 19:05 |
| rushiagr | morganfainberg: ah. I thought you were saying gate/check type jobs are unable to catch return values mismatch type of problems :) | 19:06 |
| rushiagr | morganfainberg: got it now. Clearer | 19:06 |
| morganfainberg | rushiagr: yep | 19:06 |
| morganfainberg | rushiagr: :) | 19:06 |
| rushiagr | morganfainberg: I think I'm pretty much in sync with the agreed approach. Now about implementation.. | 19:07 |
| rushiagr | has anyone started it? If yes, I'd like to have a look, and contribute.. | 19:07 |
| morganfainberg | rushiagr: i think we're needing to merge the spec update, cc gyee_ ? | 19:08 |
| gyee_ | rushiagr, morganfainberg, I haven't started on it yet | 19:08 |
| morganfainberg | rushiagr: gyee_ is the goto on this one. | 19:08 |
| gyee_ | rushiagr, if you have some cycles, please feel free | 19:08 |
| morganfainberg | rushiagr: so we need to merge the spec... gyee_ ^^ please review the move the spec to liberty | 19:08 |
| morganfainberg | review | 19:08 |
| gyee_ | morganfainberg, I think the spec's already there | 19:08 |
| gyee_ | moved to liberty | 19:09 |
| morganfainberg | gyee_: i think it isn't targeted to liberty | 19:09 |
| *** stevemar has quit IRC | 19:09 | |
| gyee_ | oh | 19:09 |
| morganfainberg | https://review.openstack.org/#/c/184896/ | 19:09 |
| rushiagr | gyee_: sure | 19:09 |
| *** dramakri has quit IRC | 19:10 | |
| *** stevemar has joined #openstack-keystone | 19:10 | |
| *** ChanServ sets mode: +v stevemar | 19:10 | |
| gyee_ | rushiagr, you want to add your name to it? | 19:10 |
| gyee_ | or I can add your name to the assignee list | 19:11 |
| *** fhubik is now known as fhubik_afk | 19:11 | |
| rushiagr | gyee_: I'd love to contribute | 19:11 |
| rushiagr | gyee_: please add my name, if you're pushing up a newer version of spec. Else I'll do the same, but tomorrow | 19:12 |
| rushiagr | it's past midnight here right now :) | 19:12 |
| gyee_ | rushiagr, thank, I'll push a new patch with your name added | 19:12 |
| *** fhubik_afk is now known as fhubik | 19:13 | |
| *** fhubik is now known as fhubik_afk | 19:13 | |
| openstackgerrit | guang-yee proposed openstack/keystone-specs: Moved driver interface from backlog to liberty https://review.openstack.org/184896 | 19:14 |
| *** harlowja has quit IRC | 19:15 | |
| *** harlowja has joined #openstack-keystone | 19:15 | |
| morganfainberg | rushiagr: strictABC needs to be pulled out | 19:16 |
| morganfainberg | rushiagr: and made into a library or some such | 19:16 |
| *** yottatsa has quit IRC | 19:16 | |
| morganfainberg | rushiagr: i'll take a look at it today | 19:16 |
| morganfainberg | it's been on my todo for a while now | 19:16 |
| rushiagr | morganfainberg: okay, thanks for clarifying.. | 19:17 |
| morganfainberg | rushiagr: but it wont be part of keystone, it shouldn't be. | 19:17 |
| *** mgarza_ has quit IRC | 19:17 | |
| morganfainberg | it should be it's own lib | 19:17 |
| rushiagr | morganfainberg: agreed | 19:18 |
| *** vg_ has quit IRC | 19:20 | |
| *** stevemar has quit IRC | 19:22 | |
| *** stevemar has joined #openstack-keystone | 19:22 | |
| *** ChanServ sets mode: +v stevemar | 19:22 | |
| *** mgarza_ has joined #openstack-keystone | 19:24 | |
| *** nkinder has quit IRC | 19:24 | |
| *** stevemar has quit IRC | 19:32 | |
| *** stevemar has joined #openstack-keystone | 19:33 | |
| *** ChanServ sets mode: +v stevemar | 19:33 | |
| *** e0ne has joined #openstack-keystone | 19:33 | |
| *** _cjones_ has quit IRC | 19:35 | |
| *** jasondotstar has joined #openstack-keystone | 19:36 | |
| *** diazjf has quit IRC | 19:36 | |
| *** _cjones_ has joined #openstack-keystone | 19:39 | |
| *** dramakri has joined #openstack-keystone | 19:40 | |
| *** dguerri` is now known as dguerri | 19:41 | |
| *** stevemar has quit IRC | 19:42 | |
| *** stevemar has joined #openstack-keystone | 19:43 | |
| *** ChanServ sets mode: +v stevemar | 19:43 | |
| *** dguerri is now known as dguerri` | 19:44 | |
| *** diazjf has joined #openstack-keystone | 19:50 | |
| *** dguerri` is now known as dguerri | 19:52 | |
| *** packet has quit IRC | 19:53 | |
| *** gordc_ has joined #openstack-keystone | 19:56 | |
| *** dguerri is now known as dguerri` | 19:59 | |
| *** stevemar has quit IRC | 19:59 | |
| *** stevemar has joined #openstack-keystone | 20:01 | |
| *** ChanServ sets mode: +v stevemar | 20:01 | |
| samueldmq | morganfainberg: ayoung I just updated the sequence diagrams based on our discussions | 20:01 |
| samueldmq | morganfainberg: ayoung please check https://wiki.openstack.org/wiki/DynamicPolicies#Workflows_-_Liberty_Scope and let me know what you think about it | 20:02 |
| samueldmq | morganfainberg: ayoung at a glance, it looks much simpler than what we had before, looks a very consistent and realistic scope for L | 20:02 |
| ayoung | samueldmq, let me add some verbage, first | 20:03 |
| ayoung | I think explaining the scope of the changes we are going to do in Liberty, and then we can link to the actual specs, might bea better introduction to other people | 20:03 |
| samueldmq | ayoung: how those diagrams are defined in terms of specs ? | 20:05 |
| *** e0ne has quit IRC | 20:06 | |
| samueldmq | ayoung: most of those specs could go in a kind of backlog, so we keep only the needed specs for that scope in hands | 20:06 |
| *** stevemar_ has joined #openstack-keystone | 20:06 | |
| ayoung | samueldmq, all specs are submitted to backlog | 20:06 |
| samueldmq | ayoung: I mean in that wiki, we could have a separation between what is in the backlog and what is scoped to L | 20:08 |
| *** afazekas has joined #openstack-keystone | 20:08 | |
| samueldmq | ayoung: matching what is defined in those diagrams | 20:08 |
| stevemar_ | dolphm: help me!!! | 20:08 |
| stevemar_ | i have no idea what i'm doing on a mac | 20:09 |
| marekd | gyee_: you should like this patch: https://review.openstack.org/#/c/188581/ | 20:09 |
| stevemar_ | lbragstad: help mojo | 20:09 |
| ayoung | samueldmq, https://wiki.openstack.org/wiki/DynamicPolicies#Tasks_targetted_for_Liberty | 20:09 |
| ayoung | stevemar_, what you should be doing on a Mac is installing Fedora | 20:09 |
| * marekd http://i.imgur.com/xVyoSl.jpg cc/ stevemar_ | 20:09 | |
| stevemar_ | marekd: pretty accurate representation | 20:10 |
| marekd | :D | 20:10 |
| stevemar_ | expect my reviewing to take a nose dive for a week or so | 20:10 |
| samueldmq | ayoung: looks good, thanks | 20:10 |
| ayoung | samueldmq, those should probably be updated to be the links, or contain the links, to the specs, but leave them for now | 20:11 |
| bknudson | stevemar_: just set up kvm on it so you can run ubuntu in a vm | 20:11 |
| bknudson | or install ubuntu on it | 20:11 |
| samueldmq | ayoung: will do | 20:11 |
| marekd | Torvalds uses MacBook Air as a hardware | 20:11 |
| *** afazekas has quit IRC | 20:12 | |
| marekd | i wonly wish OSX had some tiling WMs | 20:13 |
| marekd | morganfainberg: re: https://review.openstack.org/#/c/195132/ i was not seeint this in terms of bug, because it's like an enhancement but i can file a bug. | 20:15 |
| *** harlowja has quit IRC | 20:18 | |
| *** harlowja has joined #openstack-keystone | 20:18 | |
| dolphm | marekd: stevemar_: i use http://magnet.crowdcafe.com/ | 20:20 |
| dolphm | stevemar: welcome to the dark side? | 20:20 |
| stevemar_ | dolphm: can i install it via not-the-app-store? | 20:20 |
| *** Lactem has quit IRC | 20:21 | |
| dolphm | stevemar: no, it's a paid app to upgrade OS X to be useable | 20:21 |
| *** Lactem has joined #openstack-keystone | 20:21 | |
| stevemar_ | screw that noise! | 20:21 |
| *** iamjarvo has quit IRC | 20:22 | |
| marekd | dolphm: ++ looks like i am ready for Mac now. | 20:23 |
| dolphm | stevemar: my OS X config https://github.com/dolph/dotfiles/blob/master/osx.sh | 20:23 |
| Lactem | dolphm: Hi. I think my internet should actually work today. | 20:24 |
| dolphm | the most important change: https://github.com/dolph/dotfiles/blob/master/osx.sh#L78-L79 | 20:24 |
| dolphm | Lactem: lol welcome back to the internet then | 20:24 |
| Lactem | Thanks. | 20:25 |
| Lactem | Umm okay so about that bug... | 20:25 |
| Lactem | You added the test-improvement tag. What were you saying I need to do to finish it? | 20:25 |
| dolphm | Lactem: add a test to, i think, keystone/tests/unit/test_v3_catalog.py which does exactly what you did to show the bug could not be reproduced | 20:27 |
| Lactem | Okay so a .sh script with the commands I did? | 20:27 |
| Lactem | Cool so then where would I put that script? Just in a private GitHub repo and put the link in the bug page or...? | 20:28 |
| *** jasondotstar has quit IRC | 20:29 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Relax the formats of accepted mapping rules for keystone-manage https://review.openstack.org/195132 | 20:30 |
| marekd | morganfainberg: stevemar_ rodrigods dstanek dolphm lbragstad ^^ | 20:30 |
| *** rushiagr is now known as rushiagr_away | 20:31 | |
| marekd | stevemar_: thanks for cleaning the commit msg. | 20:32 |
| stevemar_ | marekd: np sir | 20:32 |
| dolphm | Lactem: p.s. if you prefix your message with my nick then i'll get a notification when you're talking to me! | 20:32 |
| dolphm | Lactem: no, not a .sh -- python tests! | 20:32 |
| gyee_ | marekd, k2k, yay! | 20:32 |
| Lactem | Yeah I probably should've done that prefix thing. | 20:33 |
| dolphm | Lactem: we have a bunch of tests can you read through to find where yours would best fit in https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_catalog.py#L410-L724 | 20:34 |
| dolphm | bunch of related* tests | 20:34 |
| *** mestery has quit IRC | 20:35 | |
| *** stevemar_ has quit IRC | 20:35 | |
| *** Lactem has quit IRC | 20:35 | |
| *** jasondotstar has joined #openstack-keystone | 20:36 | |
| marekd | gyee_: if you have time/resources - go ahead and test it (I did). I feel it's been there for too long. | 20:37 |
| marekd | gyee_: and we need people who are familiar with that kind of stuff :-) | 20:37 |
| *** Lactem has joined #openstack-keystone | 20:37 | |
| gyee_ | marekd, yeah, I'll need to test it locally | 20:38 |
| marekd | gyee_: please do! | 20:38 |
| *** gordc_ has quit IRC | 20:38 | |
| gyee_ | I have an environment setup for sssd right now, might as well test them both | 20:38 |
| Lactem | dolphm: So I have to change all of those cmd-line commands into python code? | 20:39 |
| *** stevemar has quit IRC | 20:39 | |
| *** stevemar has joined #openstack-keystone | 20:39 | |
| dolphm | Lactem: yep! | 20:39 |
| *** stevemar2 has joined #openstack-keystone | 20:39 | |
| *** ChanServ sets mode: +v stevemar2 | 20:39 | |
| dolphm | Lactem: all of our tests are written in python | 20:39 |
| Lactem | Okay. | 20:40 |
| *** diazjf has quit IRC | 20:40 | |
| *** stevemar2 has quit IRC | 20:43 | |
| *** stevemar2 has joined #openstack-keystone | 20:44 | |
| *** ChanServ sets mode: +v stevemar2 | 20:44 | |
| *** stevemar has quit IRC | 20:46 | |
| *** mestery has joined #openstack-keystone | 20:49 | |
| *** stevemar has joined #openstack-keystone | 20:50 | |
| *** jasondotstar has quit IRC | 20:54 | |
| ayoung | seen in the keystone client code: # TODO(heckj): supporting backwards compatibility with environment | 20:54 |
| ayoung | # variables. To be removed after DEVSTACK is updated, ideally in | 20:54 |
| ayoung | # the Grizzly release cycle. | 20:54 |
| ayoung | I miss heckj | 20:54 |
| david8hu | samueldmq, for https://wiki.openstack.org/w/images/f/f4/Dynamic-policies-enforce.png, there is really no need for step 10, because when you call a rule, that rule is already a osla policy rule(forgot the exact name) object.. | 20:56 |
| lbragstad | stevemar: who is mojo? | 20:57 |
| stevemar | lbragstad: you fail at the simspons quiz | 20:57 |
| *** belmoreira has joined #openstack-keystone | 20:58 | |
| samueldmq | david8hu: step 10 loads the policy.json file | 20:58 |
| samueldmq | david8hu: from the cache, isn't that needed? | 20:58 |
| lbragstad | stevemar: I don't think I ever completed an episode of the simpsons... | 20:59 |
| samueldmq | david8hu: oslo policy reads from the policy.json file and then intantiate the rules objects | 20:59 |
| david8hu | samueldmq, In that case, which component calls something like policy.Rules.load_json(policy_data, "default") ? | 21:00 |
| *** stevemar has quit IRC | 21:01 | |
| Lactem | dolphm: For testing all of those methods in test_v3_catalog.py, what do I use as the self parameter? For example: stack@Ubuntu64:~/keystone/keystone/tests/unit$ python -c 'from test_v3_catalog import *; print test_create_endpoint_enabled_false()' | 21:02 |
| Lactem | stack@Ubuntu64:~/keystone/keystone/tests/unit$ python -c 'from test_v3_catalog import *; print test_create_endpoint_enabled_false()' | 21:02 |
| Lactem | stack@Ubuntu64:~/keystone/keystone/tests/unit$ python -c 'from test_v3_catalog import *; print test_create_endpoint_enabled_false()' | 21:02 |
| Lactem | stack@Ubuntu64:~/keystone/keystone/tests/unit$ python -c 'from test_v3_catalog import *; print test_create_endpoint_enabled_false()' | 21:02 |
| Lactem | Oops. | 21:02 |
| *** stevemar has joined #openstack-keystone | 21:02 | |
| Lactem | dolphm: Those weren't showing up. Okay so for that method/function/whatever it's called in Python, what would the self parameter be? | 21:02 |
| *** stevemar has quit IRC | 21:03 | |
| samueldmq | david8hu: I think it is the oslo.policy itself, since policy_file and policy_dirs is a config defined there | 21:04 |
| samueldmq | david8hu: it gets teh policy.json, instantiates the rules, and check the APIa agianst the instantiated rules | 21:04 |
| samueldmq | david8hu: if that makes sense | 21:04 |
| Lactem | stack@Ubuntu64:~/keystone/keystone/tests/unit$ python -c 'from test_v3_catalog.py import *; test_create_endpoint_enabled_false()' | 21:04 |
| Lactem | Maybe it's supposed to be like that, but either way there's an error. | 21:04 |
| david8hu | samueldmq, It felt like backard, because the enforcer has to be instantiated before doing rule enforcement in step 9. | 21:09 |
| *** csoukup has quit IRC | 21:10 | |
| *** diazjf has joined #openstack-keystone | 21:10 | |
| david8hu | samueldmq, when it gets to step 11, all keys and rules are loaded, so it doesn't need to go to the cache again. | 21:11 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Tests for correct key removed https://review.openstack.org/194388 | 21:11 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Simplify fernet rotation code https://review.openstack.org/194335 | 21:11 |
| *** stevemar2 has quit IRC | 21:12 | |
| ayoung | Hey bknudson , If I do a keystone tenant-list (CLI, v2.0) as a non-prived user, I get a list of tenants that I am a member of. If the Ansible module trys to do the same thing, it errors out, because it is trying to use the admin endopoint. Why does the CLI work? It should not have an unsocoped token. | 21:13 |
| ayoung | I know it is a jamielennox|away question | 21:13 |
| bknudson | ayoung: ansible doesn't use the CLI? | 21:13 |
| ayoung | bknudson, in this case, ansible makes a keystoneclient v2 call | 21:14 |
| ayoung | http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v2_0/tenants.py#n123 | 21:14 |
| ayoung | bknudson, I hacked my version to always do the fall back, and now ansible works...but I don't understand what the CLI is doing | 21:14 |
| *** dramakri has quit IRC | 21:14 | |
| ayoung | if there is a SQL backend, and OS_TENANT_* ios set, we should get a scoped token. So why does the CLI know to use something that has no admin endpoint? | 21:15 |
| bknudson | the code says it does admin query first and if that doesn't work use auth_url | 21:17 |
| bknudson | which is weird. | 21:17 |
| bknudson | the APIs are totally different so you really should have to pick one or the other | 21:17 |
| ayoung | bknudson, right, and that is, I think, to help enumerate projects for an unscoped token | 21:17 |
| bknudson | is the auth_url being set differently in the cli case? | 21:18 |
| bknudson | --os-auth-url | 21:18 |
| ayoung | bknudson, if a user logs in to Horizon, and there is no default project set, the user gets an un scoped token. That call is used to then list the tenants to select the first one for the webui | 21:18 |
| ayoung | no, auth url is passed in like this | 21:19 |
| ayoung | ansible localhost -m quantum_router -a "name=ayoung-test-router login_username=$OS_USERNAME auth_url=$OS_AUTH_URL login_password=$OS_PASSWORD login_tenant_name=$OS_PROJECT_NAME" | 21:19 |
| *** dramakri has joined #openstack-keystone | 21:19 | |
| ayoung | maybe it is the fact that login_tenant_name=$OS_PROJECT_NAME is set, where as maybe the CLI ignores it? | 21:19 |
| bknudson | it's weird that a non-priv user works at all since this comment says that it uses the admin endpoint | 21:20 |
| ayoung | heh, I bet the CLI is looking for TENANT and I jhave PROJECT set | 21:20 |
| ayoung | lets see...if I set tenant does it break.... | 21:20 |
| ayoung | nope, still works | 21:21 |
| ayoung | agh, but I have my hack in still | 21:22 |
| ayoung | yeah, now it fails | 21:22 |
| ayoung | keystone --debug --os-tenant-name $OS_PROJECT_NAME tenant-list | 21:22 |
| ayoung | You are not authorized to perform the requested action: admin_required (HTTP 403) | 21:23 |
| *** ankita_wagh has joined #openstack-keystone | 21:23 | |
| bknudson | what's the action, is it trying to get the tenant-id ? | 21:23 |
| ayoung | bknudson, yeah, from the tenant-name | 21:23 |
| ayoung | I don't thin the module will accept tenant-id as a param...lets see | 21:23 |
| morganfainberg | ayq | 21:24 |
| morganfainberg | ayoung: i think we need to support a get-project-by-name (and domain) at the REST API level | 21:24 |
| bknudson | that's kind of strange you can't look up the tenant id for name without admin auth | 21:24 |
| ayoung | morganfainberg, if you ayq take ayspryn | 21:24 |
| *** morganfainberg is now known as ayspryn | 21:24 | |
| ayspryn | ayoung: >.> | 21:24 |
| *** ayspryn is now known as morganfainberg | 21:24 | |
| ayoung | morganfainberg, yeah. But I think from an ansible standpoint, we need to make the whole thing work with V3 | 21:25 |
| morganfainberg | ayoung: it's silly we need to do crazy things to filter/look that info up | 21:25 |
| morganfainberg | ayoung: yes that much for sure | 21:25 |
| *** pballand has quit IRC | 21:25 | |
| ayoung | morganfainberg, I just did a git blame on the file that does the core auth, it is all mordred | 21:25 |
| bknudson | I'd say switch ansible to v3. | 21:25 |
| *** jaosorior has quit IRC | 21:25 | |
| morganfainberg | ayoung: yes he owns upstream ansible stuff | 21:26 |
| morganfainberg | ayoung: shade does a lot of the v2/v3 maic | 21:26 |
| morganfainberg | magic* | 21:26 |
| morganfainberg | ayoung: depending on what you're trying to accomplish, shade might do what you need (it's ansible + smart hacks for openstack smoothing out) | 21:26 |
| mordred | must support both | 21:26 |
| *** pballand has joined #openstack-keystone | 21:26 | |
| ayoung | morganfainberg, I was able to do everything I needed with V3 | 21:26 |
| ayoung | mordred, yeah, I understand that | 21:26 |
| ayoung | mordred, what would be really nice is supporting the whole range of auth plugins, to include SAML for authorization | 21:27 |
| mordred | yes! | 21:27 |
| morganfainberg | ayoung: is nkinder around? wanted to ask if we were getting some resources to do get-domain-by-name and get-project-by-name REST APIs? | 21:27 |
| mordred | I agree - in theory we shoudl support them | 21:27 |
| morganfainberg | ayoung: he was interested in that. | 21:27 |
| mordred | but in practice it has seen no testing | 21:27 |
| ayoung | morganfainberg, he's at the RH summit, and there is basically me and jamielennox|away | 21:28 |
| mordred | oh! | 21:28 |
| mordred | oh | 21:28 |
| mordred | nonon | 21:28 |
| mordred | just saw the scrollback | 21:28 |
| mordred | if you see ANYTHING that says login_$blah | 21:28 |
| mordred | it is old and deprecated | 21:28 |
| morganfainberg | mordred: i need to get KeystonAuth going again | 21:28 |
| * morganfainberg goes and stares at the outstanding reviews | 21:28 | |
| morganfainberg | mordred: I *think* we are relatively close once the reviews land | 21:28 |
| mordred | ayoung: quantum_router is broken and old and will be destroyed for all of the reasons you stated | 21:28 |
| mordred | morganfainberg: ++ | 21:28 |
| ayoung | mordred, yeah, and I'm using the version of ansible that ships with F22. I've seen that there are some minor changes moving forward | 21:28 |
| *** jasondotstar has joined #openstack-keystone | 21:29 | |
| mordred | ayoung: there are MAJOR COMPLETE REWRITE NOT COMPATIBLE changes | 21:29 |
| mordred | in the openstack modules | 21:29 |
| ayoung | mordred, where does this rewrite live? | 21:29 |
| mordred | becaue the existing ones are completely unworkable | 21:29 |
| morganfainberg | bknudson: last of the stevedore BPs just got +A | 21:29 |
| ayoung | is it in upstream openstack devel branch yet? | 21:29 |
| morganfainberg | bknudson: for auth plugins in keystone server | 21:29 |
| morganfainberg | bknudson: except sample config (for obvious reasons) | 21:29 |
| mordred | ayoung: about half has landed in ansible devel branch | 21:29 |
| mordred | ayoung: the other half are in these PRs: https://github.com/ansible/ansible-modules-core/pulls/emonty | 21:30 |
| ayoung | mordred, so...timing on that? Can we still affect change? | 21:30 |
| bknudson | morganfainberg: neat! | 21:30 |
| mordred | ayoung: yes and no - depending on what you want to change | 21:30 |
| ayoung | mordred, Auth.... | 21:30 |
| ayoung | as I just said | 21:30 |
| mordred | yah. the interface we have for that SHOULD handle everything | 21:30 |
| mordred | we designed it from scratch with auth plugins in mind | 21:31 |
| ayoung | mordred, I saw that the core modules code was pulling code in from anible repo. Is that split going away? | 21:31 |
| mordred | for now the core modules repo will still be a submodule in the ansible/ansible repo | 21:31 |
| mordred | we might rejoin them in the future | 21:31 |
| morganfainberg | marekd: are you happy with the k2k plugins in keystoneauth? | 21:31 |
| morganfainberg | marekd: i'm about to press go on them. | 21:31 |
| ayoung | morganfainberg, I'm not talking about that | 21:32 |
| ayoung | I mean that is uses the copenst helper out of anisble.. | 21:32 |
| mordred | yes. the helper should be in released ansible at the moment | 21:32 |
| *** Ctina___ is now known as Ctina | 21:32 | |
| mordred | you're talking about https://github.com/ansible/ansible-modules-core/pull/1048 | 21:32 |
| mordred | gah | 21:32 |
| mordred | https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/openstack.py | 21:32 |
| morganfainberg | Ctina: /wave cause /wave is possible | 21:32 |
| morganfainberg | ^_^ | 21:33 |
| ayoung | from ansible.module_utils.openstack import * | 21:33 |
| mordred | ayoung: and openstack_full_argument_spec is the one that matters - yah | 21:33 |
| mordred | ayoung: openstack_full_argument_spec from 1.9 should work with the openstack modules in devel | 21:33 |
| Ctina | @morganfainberg hi! | 21:33 |
| morganfainberg | Ctina: just saw you un-idle and had to wave. thats all. :) | 21:33 |
| Ctina | :) | 21:34 |
| mordred | ayoung: the README here: https://github.com/openstack/os-client-config has the best succint discussion of what the auth dict stuff looks like - that's carried over now into shade and ansible modules and friends - so if there is a deficiency in it, we should definitely sort that out | 21:34 |
| *** csoukup has joined #openstack-keystone | 21:34 | |
| ayoung | mordred, very cool. I'm just learning ansible. | 21:35 |
| mordred | ayoung: yay! welcome to the party | 21:35 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Update MANIFEST.in https://review.openstack.org/195327 | 21:36 |
| mordred | ayoung: I actually have a pile of shade changes up adding keystone api support and several ansible PRs - so if you get bored, reviews/patches are more than welcome | 21:36 |
| ayoung | mordred, so, one thing I need to do, that is shade-like is this: | 21:36 |
| mordred | ayoung: https://review.openstack.org/#/q/status:open+project:openstack-infra/shade+branch:master+topic:keystone-modules,n,z | 21:36 |
| ayoung | create a router, a network, a subnet, attach the router to the network...blah | 21:37 |
| mordred | yup | 21:37 |
| ayoung | mordred, so I had coded it up using the python APIs directly | 21:37 |
| mordred | ayoung: so - first step of that is here: https://review.openstack.org/#/c/192475/ | 21:37 |
| mordred | ayoung: but I want to have a "just give me a working end to end thing please" | 21:37 |
| mordred | ayoung: similar to what we do with create_server | 21:38 |
| mordred | whcih will do all the things you need it to | 21:38 |
| ayoung | mordred, so...I have some ideas along those lines. | 21:38 |
| mordred | sweet! | 21:38 |
| ayoung | mordred, what I wrote was designed to do 3 things | 21:38 |
| ayoung | create , destroy, display state | 21:38 |
| ayoung | and it had to do it for chains of tasks... | 21:38 |
| ayoung | like the one you have there... | 21:38 |
| ayoung | POC code is : https://github.com/admiyo/ossipee/blob/master/ossipee.py | 21:39 |
| ayoung | mordred, one thing it allows is sharing of a session across all the calls, which should speed up processing. Better than each thing needing to go to Keystone to get another token | 21:39 |
| ayoung | to build a network setup https://github.com/admiyo/ossipee/blob/master/ossipee.py#L523 | 21:40 |
| ayoung | it runs through the create function on each of those classes | 21:40 |
| mordred | yah - totally agree on shared session - we do that in shade too - the collection of tasks is interesting | 21:40 |
| ayoung | mordred, yeah, that was the idea I wanted to share, because this way, they are also reversable | 21:41 |
| mordred | and is totally potentially either a thing we could layer on top - or just expose as api calls | 21:41 |
| ayoung | tear down a netwokr is painful | 21:41 |
| ayoung | so...reverse the Array and call teardown on each WorkItem | 21:41 |
| mordred | yah - that's not terrible at all | 21:41 |
| ayoung | mordred, its a technique from Network marshalling code | 21:42 |
| mordred | ayoung: you know what would be great? if it wasn't so painful in teh first place ... | 21:42 |
| ayoung | heh | 21:42 |
| ayoung | mordred, well, I think they are probably being careful. If you allowed a delete while something was still connected, you'd orphan the VM. Since that is kindof a deal breaker...make it deliberate. I don;'t fault the decision | 21:43 |
| ayoung | but having a script to tear down makes a lot of sense | 21:44 |
| mordred | oh sure - I mean, having the functions broken out is great | 21:44 |
| mordred | but also having a "please give me a vm with a workign IP" or "please give me a network that can talk to the internet" | 21:44 |
| *** dguerri` is now known as dguerri | 21:44 | |
| mordred | are some basic rollups of that sort of thing that are super useful | 21:44 |
| mordred | because at first, I do not want a network a subnet and a router - I want a place form which I can get an IP | 21:44 |
| ayoung | mordred, what I need is a recipe I can hand over to QA saying: here is a Federated setup | 21:46 |
| mordred | yup | 21:47 |
| ayoung | mordred, so nkinder has been working on a bunch of shell scripts for that, but it all assumes that you are working on local VMs, using libvirt. We want to start by splitting out what he uses into a "secutp the VMS" versus "configure the oopenstack stuff" | 21:48 |
| ayoung | and...the second half can probably use the OSAD approach, | 21:48 |
| ayoung | mordred, what is the relationship between shade and ansible? None? | 21:49 |
| morganfainberg | ayoung: shade makes working between clouds where things are ... "different", not terriblew | 21:51 |
| mordred | ayoung: all of the new ansible openstack modules use shade | 21:51 |
| ayoung | ah... | 21:51 |
| mordred | ayoung: so, infra owns the library, but we basically put any logic into shade rather than the ansible modules | 21:51 |
| mordred | so that it can be reused for not-ansible | 21:51 |
| ayoung | mordred, right, but that should actually make ansible better | 21:51 |
| mordred | and we keep the ansible modules about data marshalling and parameter stuff | 21:52 |
| mordred | yup | 21:52 |
| ayoung | because not one process per | 21:52 |
| mordred | we're also moving nodepool to using shade | 21:52 |
| mordred | so - it'll be very battle tested :) | 21:52 |
| ayoung | mordred, OK, let me give shade a test run | 21:53 |
| mordred | sweet! bugs more than welcome | 21:54 |
| *** pballand has quit IRC | 21:54 | |
| ayoung | mordred, I think you mean bug reports. If you are accpeting my code, you will get plenty new bugs... | 21:54 |
| * ayoung has a realistic view of his own potential for damage | 21:54 | |
| *** diazjf has left #openstack-keystone | 21:56 | |
| mordred | heh. we welcome both | 21:57 |
| *** pballand has joined #openstack-keystone | 21:57 | |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Document use of wip up to developer https://review.openstack.org/195335 | 21:57 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Document update sample config up to developer https://review.openstack.org/194906 | 21:57 |
| *** dguerri is now known as dguerri` | 21:58 | |
| morganfainberg | bknudson: https://review.openstack.org/#/c/195338/ | 21:59 |
| morganfainberg | bknudson: will be doing the strip out CLI next on that branch | 22:00 |
| bknudson | morganfainberg: cool! | 22:00 |
| bknudson | morganfainberg: I'm a little concerned about the branch now... I tried a dry-run of the merge with master and there was a conflict | 22:00 |
| bknudson | so at this point I'd prefer it if nothing more was merged there until we're synced | 22:00 |
| morganfainberg | bknudson: i expect there to be a conflict | 22:00 |
| morganfainberg | bknudson: because some ksa specific things have been landed | 22:01 |
| morganfainberg | bknudson: i'll propose the strip out cli patch and then resolve the conflict(s) | 22:01 |
| bknudson | the conflict was pretty minor | 22:01 |
| morganfainberg | bknudson: we can rebase things from there | 22:01 |
| morganfainberg | bknudson: yeah there should be a conflict at this point | 22:01 |
| bknudson | it was in exceptions | 22:01 |
| morganfainberg | since iirc jamie had some ksa porting stuff merged over | 22:01 |
| *** Ctina has quit IRC | 22:03 | |
| bknudson | need 1 more +2 and we'll have the power to push merges. | 22:03 |
| bknudson | he he he | 22:03 |
| bknudson | I don't know if that makes a review or if it's ninja. | 22:03 |
| morganfainberg | lol | 22:04 |
| morganfainberg | bknudson: it makes a merge commit | 22:04 |
| morganfainberg | bknudson: and we need to approve it | 22:04 |
| bknudson | since I'm not going to run tempest on it I hope there's a review | 22:05 |
| *** bknudson has quit IRC | 22:09 | |
| *** jasondotstar has quit IRC | 22:09 | |
| ayoung | $ ./.tox/py34/bin/shade-inventory --list | wc -l | 22:13 |
| ayoung | 1470 | 22:13 |
| ayoung | ok..it works | 22:13 |
| *** Lactem has quit IRC | 22:13 | |
| *** fhubik_afk is now known as fhubik | 22:16 | |
| *** fhubik has quit IRC | 22:16 | |
| *** henrynash has quit IRC | 22:18 | |
| *** pballand has quit IRC | 22:18 | |
| *** belmoreira has quit IRC | 22:19 | |
| *** thedodd has quit IRC | 22:21 | |
| openstackgerrit | Merged openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 22:22 |
| openstackgerrit | Merged openstack/keystone: Short names for auth plugins https://review.openstack.org/182107 | 22:24 |
| *** pballand has joined #openstack-keystone | 22:27 | |
| openstackgerrit | Merged openstack/keystoneauth: Keystone2KeystoneAuthPlugin scoping capabilities https://review.openstack.org/188881 | 22:28 |
| openstackgerrit | Merged openstack/keystoneauth: Support discovery on the AUTH_INTERFACE https://review.openstack.org/191641 | 22:28 |
| openstackgerrit | Merged openstack/keystone: Document entrypoint namespaces https://review.openstack.org/194435 | 22:28 |
| *** belmoreira has joined #openstack-keystone | 22:29 | |
| openstackgerrit | Merged openstack/keystoneauth: Add get_communication_params interface to plugins https://review.openstack.org/191646 | 22:29 |
| *** belmoreira has quit IRC | 22:35 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/192386 | 22:38 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 22:42 |
| *** pballand has quit IRC | 22:47 | |
| *** arunkant_ has quit IRC | 22:48 | |
| *** charlesw has quit IRC | 22:48 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Moved driver interface from backlog to liberty https://review.openstack.org/184896 | 22:49 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Cleanup and removal of StrictABC requirement https://review.openstack.org/195347 | 22:49 |
| *** pballand has joined #openstack-keystone | 22:50 | |
| *** belmoreira has joined #openstack-keystone | 22:53 | |
| *** ankita_w_ has joined #openstack-keystone | 22:55 | |
| *** arunkant has joined #openstack-keystone | 22:56 | |
| morganfainberg | dolphm, jamielennox|away: https://review.openstack.org/#/c/195348/ | 22:56 |
| *** mgarza_ has quit IRC | 22:57 | |
| ayoung | morganfainberg, I can very happy +2 that | 22:57 |
| morganfainberg | ayoung: :) | 22:57 |
| ayoung | morganfainberg, will it pass gate? | 22:57 |
| morganfainberg | ayoung: no idea | 22:57 |
| ayoung | Heh | 22:58 |
| morganfainberg | ayoung: it passes unit tests | 22:58 |
| ayoung | +2 anyway | 22:58 |
| morganfainberg | ayoung: we'll see if anything is using the keystone CLI now wont we ;) | 22:58 |
| ayoung | morganfainberg, yes we will | 22:58 |
| *** ankita_wagh has quit IRC | 22:58 | |
| morganfainberg | also https://review.openstack.org/#/c/195338/ | 22:58 |
| morganfainberg | no more middleware in keystoneclient | 22:58 |
| ayoung | +3, -4408 | 23:00 |
| ayoung | morganfainberg, you snuck bandit in there? | 23:00 |
| ayoung | https://review.openstack.org/#/c/195338/1/test-requirements.txt,cm morganfainberg ? that a mistake? | 23:01 |
| morganfainberg | ayoung: oh must have snuck in elsewhere | 23:01 |
| *** zzzeek has quit IRC | 23:01 | |
| morganfainberg | well it should be in there but it probably was a merge oddity | 23:01 |
| morganfainberg | i'll get resolved when we merge back from master | 23:01 |
| ayoung | 2015 oddity 2 | 23:02 |
| morganfainberg | removing ~6k lines of code from keystonelcient = nice | 23:02 |
| ayoung | morganfainberg, you don;t want to resubmit it? | 23:02 |
| morganfainberg | ayoung: i need to do a rebase once we merge back from master | 23:02 |
| morganfainberg | so i'll wait till then | 23:02 |
| morganfainberg | waiting on https://review.openstack.org/194801 to land | 23:03 |
| ayoung | morganfainberg, so that is due to the fact that this branched prior to bandit going in, but bandit is now in master | 23:03 |
| morganfainberg | yeah | 23:03 |
| morganfainberg | and it snuck in when i did the cherry-pick from master | 23:03 |
| morganfainberg | so once i rebase from master we that should go away | 23:03 |
| morganfainberg | but ^^ that infra change needs to land so we can merge to the feature branch | 23:04 |
| ayoung | morganfainberg, so I'm going to abandon the initialize/sample code for client | 23:04 |
| morganfainberg | ok | 23:04 |
| ayoung | I'm guessing that should go somewhere, but not sure where | 23:04 |
| ayoung | maybe shade | 23:04 |
| ayoung | although, it is more of an install thing. | 23:05 |
| morganfainberg | devstack maybe? | 23:05 |
| morganfainberg | is it really a dev-only tool | 23:05 |
| morganfainberg | or is it something genrrally useful | 23:05 |
| ayoung | nay, this is using the python API. devstack uses the CLI | 23:05 |
| * morganfainberg isn't sure where it should land | 23:05 | |
| ayoung | morganfainberg, there was a repo I found that was hugely helpful with examples. I would loveto have something like that...I'll find it | 23:06 |
| *** Ephur has quit IRC | 23:06 | |
| ayoung | https://github.com/rajdeepd/openstack-samples morganfainberg something like that | 23:07 |
| morganfainberg | hm | 23:07 |
| morganfainberg | yeh not sure where that really belongs | 23:07 |
| ayoung | it showed python-*client code for all the things I wanted to do | 23:07 |
| morganfainberg | this almost feels like something that belongs under docs somewhere | 23:07 |
| ayoung | https://github.com/rajdeepd/openstack-samples/tree/master/lab-master/keystonesamples is a little dated, but the neutron ones were good | 23:08 |
| ayoung | yes | 23:08 |
| ayoung | he hasn't touched it in a year. | 23:10 |
| morganfainberg | ok back in a bit | 23:13 |
| morganfainberg | neeed to finish running errands | 23:13 |
| *** pballand has quit IRC | 23:13 | |
| *** belmoreira has quit IRC | 23:15 | |
| *** darrenc is now known as darrenc_afk | 23:16 | |
| openstackgerrit | Merged openstack/python-keystoneclient-saml2: Updated from global requirements https://review.openstack.org/192320 | 23:16 |
| openstackgerrit | Victor Morales proposed openstack/keystone: Integrate OSprofiler in Keystone https://review.openstack.org/103368 | 23:21 |
| *** darrenc_afk is now known as darrenc | 23:23 | |
| *** bradjones has quit IRC | 23:26 | |
| *** bradjones has joined #openstack-keystone | 23:26 | |
| *** bradjones has quit IRC | 23:26 | |
| *** bradjones has joined #openstack-keystone | 23:26 | |
| *** geoffarnold has quit IRC | 23:29 | |
| *** roxanaghe has quit IRC | 23:35 | |
| *** mestery has quit IRC | 23:36 | |
| openstackgerrit | Merged openstack/pycadf: Updated from global requirements https://review.openstack.org/194017 | 23:56 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
