| *** threestrands has quit IRC | 01:00 | |
| *** yamamoto has joined #openstack-oslo | 01:18 | |
| *** yamamoto has quit IRC | 01:25 | |
| *** namnh has joined #openstack-oslo | 01:35 | |
| *** dave-mccowan has joined #openstack-oslo | 01:41 | |
| *** yamamoto has joined #openstack-oslo | 01:41 | |
| *** yamamoto has quit IRC | 01:46 | |
| *** yamamoto has joined #openstack-oslo | 02:02 | |
| *** yamamoto has quit IRC | 02:06 | |
| *** yamamoto has joined #openstack-oslo | 02:23 | |
| *** yamamoto has quit IRC | 02:29 | |
| *** yamamoto has joined #openstack-oslo | 02:45 | |
| *** rcernin has quit IRC | 02:46 | |
| *** yamamoto has quit IRC | 02:50 | |
| *** rcernin has joined #openstack-oslo | 02:50 | |
| *** yamamoto has joined #openstack-oslo | 03:06 | |
| *** yamamoto has quit IRC | 03:10 | |
| *** nicolasbock has quit IRC | 03:11 | |
| *** yamamoto has joined #openstack-oslo | 03:27 | |
| *** yamamoto has quit IRC | 03:33 | |
| *** links has joined #openstack-oslo | 03:37 | |
| *** dave-mccowan has quit IRC | 03:38 | |
| openstackgerrit | Vu Cong Tuan proposed openstack/taskflow master: Update Kazoo to correct URL https://review.openstack.org/567181 | 03:48 |
|---|---|---|
| *** yamamoto has joined #openstack-oslo | 03:50 | |
| *** yamamoto has quit IRC | 03:54 | |
| *** gyankum has joined #openstack-oslo | 03:59 | |
| *** yamamoto has joined #openstack-oslo | 04:12 | |
| *** yamamoto has quit IRC | 04:17 | |
| *** namnh has quit IRC | 04:18 | |
| *** namnh has joined #openstack-oslo | 04:18 | |
| *** lpetrut has joined #openstack-oslo | 04:25 | |
| *** pcaruana has joined #openstack-oslo | 04:31 | |
| *** yamamoto has joined #openstack-oslo | 04:33 | |
| *** yamamoto has quit IRC | 04:33 | |
| *** yamamoto has joined #openstack-oslo | 04:35 | |
| *** linhnm has joined #openstack-oslo | 04:38 | |
| *** chhagarw has joined #openstack-oslo | 04:54 | |
| *** linhnm has quit IRC | 05:04 | |
| *** mikal has joined #openstack-oslo | 05:12 | |
| *** mikal_ has quit IRC | 05:15 | |
| *** linhnm has joined #openstack-oslo | 05:26 | |
| *** lpetrut has quit IRC | 05:50 | |
| *** linhnm has quit IRC | 05:56 | |
| *** snapiri has joined #openstack-oslo | 05:58 | |
| *** jbadiapa has quit IRC | 06:00 | |
| *** lpetrut has joined #openstack-oslo | 06:12 | |
| *** linhnm has joined #openstack-oslo | 06:22 | |
| *** lpetrut has quit IRC | 06:38 | |
| *** namnh has quit IRC | 07:01 | |
| *** namnh has joined #openstack-oslo | 07:01 | |
| *** rcernin has quit IRC | 07:13 | |
| *** tesseract has joined #openstack-oslo | 07:13 | |
| *** yamamoto_ has joined #openstack-oslo | 07:15 | |
| *** pcaruana has quit IRC | 07:17 | |
| *** pcaruana has joined #openstack-oslo | 07:17 | |
| *** pcaruana has quit IRC | 07:18 | |
| *** yamamoto has quit IRC | 07:18 | |
| *** lpetrut has joined #openstack-oslo | 07:22 | |
| *** pcaruana has joined #openstack-oslo | 07:23 | |
| *** lpetrut has quit IRC | 07:33 | |
| *** linhnm has quit IRC | 07:36 | |
| *** AlexeyAbashkin has joined #openstack-oslo | 07:36 | |
| *** kashyap has joined #openstack-oslo | 07:39 | |
| kashyap | Hi folks, wonder if anyone here know when was the oslo.config 'types' ("from oslo_config import types") was introduced? | 07:40 |
| *** lucas-afk is now known as lucasagomes | 08:04 | |
| *** shardy has joined #openstack-oslo | 08:09 | |
| *** finucannot is now known as stephenfin | 08:21 | |
| *** e0ne has joined #openstack-oslo | 08:50 | |
| *** edmondsw has joined #openstack-oslo | 08:52 | |
| *** edmondsw has quit IRC | 08:56 | |
| *** linhnm has joined #openstack-oslo | 09:11 | |
| *** jbadiapa has joined #openstack-oslo | 09:15 | |
| *** e0ne has quit IRC | 09:29 | |
| *** e0ne has joined #openstack-oslo | 09:33 | |
| *** lpetrut has joined #openstack-oslo | 09:35 | |
| *** bhagyashri_s has joined #openstack-oslo | 09:37 | |
| *** e0ne has quit IRC | 09:38 | |
| *** pooja-jadhav has joined #openstack-oslo | 09:38 | |
| *** sambetts|afk is now known as sambetts | 09:40 | |
| *** bhagyashris has quit IRC | 09:40 | |
| *** pooja_jadhav has quit IRC | 09:41 | |
| *** linhnm has quit IRC | 09:42 | |
| *** e0ne has joined #openstack-oslo | 09:59 | |
| *** jaosorior has quit IRC | 10:00 | |
| *** jaosorior has joined #openstack-oslo | 10:01 | |
| *** namnh has quit IRC | 10:15 | |
| *** edmondsw has joined #openstack-oslo | 10:40 | |
| *** nicolasbock has joined #openstack-oslo | 10:40 | |
| *** tesseract is now known as info | 10:41 | |
| *** info is now known as tesseract | 10:41 | |
| *** edmondsw has quit IRC | 10:44 | |
| *** pbourke has quit IRC | 11:14 | |
| *** pbourke has joined #openstack-oslo | 11:14 | |
| *** edmondsw has joined #openstack-oslo | 11:21 | |
| openstackgerrit | Moisés Guimarães de Medeiros proposed openstack/oslo.config master: Create INI file ConfigurationSourceDriver. https://review.openstack.org/562746 | 11:26 |
| *** ansmith has quit IRC | 11:26 | |
| *** raildo has joined #openstack-oslo | 12:01 | |
| *** pooja-jadhav is now known as pooja_jadhav | 12:17 | |
| *** gyankum has quit IRC | 12:25 | |
| *** ansmith has joined #openstack-oslo | 12:50 | |
| *** nicolasbock has quit IRC | 12:55 | |
| *** nicolasbock has joined #openstack-oslo | 13:01 | |
| *** kgiusti has joined #openstack-oslo | 13:02 | |
| *** dave-mccowan has joined #openstack-oslo | 13:02 | |
| *** rpittau has quit IRC | 13:02 | |
| *** eck` is now known as eck`gone | 13:08 | |
| openstackgerrit | Raildo Mascena proposed openstack/oslo-specs master: config: Protecting Plaintext Secrets https://review.openstack.org/474304 | 13:10 |
| *** eck`gone is now known as eck` | 13:11 | |
| *** kashyap has left #openstack-oslo | 13:25 | |
| *** gyankum has joined #openstack-oslo | 13:28 | |
| *** janzian has joined #openstack-oslo | 13:32 | |
| *** pblaho has joined #openstack-oslo | 13:56 | |
| *** bobh has joined #openstack-oslo | 14:13 | |
| *** takedakn has joined #openstack-oslo | 14:19 | |
| openstackgerrit | Merged openstack/oslo-specs master: Trivial: update url to new url https://review.openstack.org/568108 | 14:37 |
| *** spilla has joined #openstack-oslo | 14:47 | |
| lbragstad | o/ curious if anyone happens to have feedback on https://review.openstack.org/#/c/530509/ | 14:52 |
| *** takedakn has quit IRC | 14:58 | |
| *** takedakn has joined #openstack-oslo | 14:59 | |
| *** takedakn has quit IRC | 15:01 | |
| openstackgerrit | Doug Hellmann proposed openstack/oslo-specs master: fix pip install command https://review.openstack.org/568618 | 15:18 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo-specs master: add rocky specs to toctree https://review.openstack.org/568619 | 15:18 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo-specs master: remove redundant index pages https://review.openstack.org/568620 | 15:18 |
| *** eck` is now known as eck`gone | 15:20 | |
| *** eck`gone is now known as eck` | 15:20 | |
| *** links has quit IRC | 15:21 | |
| dhellmann | lbragstad : I promised you a review of that a few days ago :-( | 15:21 |
| dhellmann | I'll do it after this meeting | 15:21 |
| dhellmann | moguimar : do those tests pass for you locally? | 15:27 |
| moguimar | dhellmann, spilla, raildo: I'm planning to submit a talk to EuroPython about our work on this drivers, do you guys have any sugestion for a 30 min talk scope? | 15:28 |
| moguimar | when I run tox it runs the py35, py27 and flake8 only | 15:28 |
| dhellmann | moguimar : do you want to talk about oslo.config in general? or just the drivers? | 15:28 |
| moguimar | how can I test those locally? | 15:28 |
| dhellmann | I see 2 failures, lower-constraints and requirements-check | 15:28 |
| dhellmann | the lower-constraints job you can test with "tox -e lower-constraints" | 15:29 |
| dhellmann | I'll propose an update to your patch to fix the requirements-check job | 15:29 |
| moguimar | thanks dhellmann | 15:30 |
| moguimar | I was thinking on a talk focused on the security aspect of not having sensitive data in plaintext | 15:30 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.config master: Base class for a configuration driver https://review.openstack.org/560027 | 15:34 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.config master: ConfigurationSource base class https://review.openstack.org/559389 | 15:34 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.config master: Create INI file ConfigurationSourceDriver. https://review.openstack.org/562746 | 15:34 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.config master: fix lower-constraints https://review.openstack.org/568622 | 15:34 |
| dhellmann | ok, ^^ should fix the lower-constraints and I put it at the bottom of the stack so we can approve it before the other changes | 15:34 |
| moguimar | nice dhellmann, thanks | 15:37 |
| lbragstad | dhellmann: no worries :) | 15:39 |
| *** snapiri has quit IRC | 15:43 | |
| dhellmann | lbragstad : is there something (spec? bug?) that explains the different levels of scope? | 15:51 |
| lbragstad | dhellmann: there are - let me grab you a link | 15:52 |
| dhellmann | lbragstad : thanks, and if you have a few minutes now I have a few more background questions about this stuff | 15:53 |
| dhellmann | I can leave them as review comments, too, if you don't have time | 15:53 |
| lbragstad | dhellmann: this might help give you a high level view of the problem http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html#problem-description | 15:53 |
| lbragstad | you don't have to read the whole specification | 15:54 |
| lbragstad | (i attempted to condense it down into just that first paragraph) | 15:54 |
| lbragstad | we do have the keystone meeting in about 5 minutes, but i'm available afterwords | 15:55 |
| dhellmann | can you give me an example of a valid value for the system argument to that constructor? | 15:55 |
| dhellmann | lbragstad : ok | 15:55 |
| lbragstad | dhellmann: a valid value would be a string | 15:55 |
| lbragstad | and today we support a special string, which is 'all' | 15:56 |
| dhellmann | ok, I think I need to read that spec because system='all' conveys no meaning at all to me right now | 15:56 |
| dhellmann | which means I don't know enough, but also "system" is not a sufficiently descriptive name for that argument | 15:57 |
| lbragstad | yeah - that was a downside of the implementation | 15:57 |
| dhellmann | also we need an enum or const with that 'all' string | 15:57 |
| lbragstad | good call | 15:57 |
| dhellmann | does some automatic part of the implementation dictate the naming convention? | 15:58 |
| lbragstad | sorry, which naming convention? | 15:59 |
| lbragstad | the header? | 15:59 |
| dhellmann | why did you choose the name "system" for that argument to the constructor? | 15:59 |
| dhellmann | yeah, does something translate the header into "system" automatically? | 16:00 |
| dhellmann | oh, it looks like there's a mapping in here | 16:00 |
| dhellmann | so we could make that name better | 16:00 |
| lbragstad | yeah - it's supposed to map to a "system" scoped token | 16:00 |
| lbragstad | similar to how context handles project-scoped tokens | 16:01 |
| dhellmann | I'm talking about line 52 | 16:01 |
| dhellmann | do your meeting, I'm going to get lunch, we can talk more after both :-) | 16:01 |
| lbragstad | sounds like a plan | 16:01 |
| *** lucasagomes is now known as lucas-afk | 16:09 | |
| *** tesseract has quit IRC | 16:21 | |
| *** jaosorior has quit IRC | 16:31 | |
| *** pcaruana has quit IRC | 16:33 | |
| *** e0ne has quit IRC | 16:35 | |
| openstackgerrit | Nam Nguyen Hoai proposed openstack/oslo.config master: Handle config mapping changes https://review.openstack.org/526314 | 16:56 |
| lbragstad | dhellmann: done with our meeting | 17:04 |
| dhellmann | good timing, I just finished lunch :-) | 17:04 |
| lbragstad | awesome | 17:05 |
| dhellmann | so I read the spec | 17:05 |
| dhellmann | let me see if I can summarize it accurately | 17:05 |
| dhellmann | our existing role scopes all relate somehow to resources owned by projects | 17:05 |
| dhellmann | this new scope relates to things that are outside of projects | 17:05 |
| dhellmann | so "system" in this sense means the underlying cloud system? (the example given is hypervisors) | 17:06 |
| * lbragstad nods | 17:06 | |
| dhellmann | and so I might have permission to look at hypervisors but not routers or other network gear, for example | 17:06 |
| dhellmann | does that cover it? | 17:06 |
| lbragstad | yep - pretty much | 17:06 |
| dhellmann | ok | 17:06 |
| lbragstad | the main crux of the issue is that openstack evolved APIs without evolving something to separate them | 17:07 |
| dhellmann | I think the variable should have a better name, but I now don't know what that is :-) | 17:07 |
| lbragstad | s/APIs/system-level APIs/ | 17:07 |
| lbragstad | yeah - it could have a better name, but i went with the existing convention (e.g. project_id) | 17:07 |
| dhellmann | yeah | 17:07 |
| lbragstad | ideally - it might make sense to have something like project_scope, or system_scope | 17:08 |
| dhellmann | system_name isn't that much better | 17:08 |
| dhellmann | system_scope feels not quite right | 17:08 |
| dhellmann | is that value "scoping" the system? or is it a system name? | 17:09 |
| dhellmann | I'm still unclear on what the valid values might be | 17:09 |
| dhellmann | are they arbitrary? or defined somewhere? | 17:09 |
| lbragstad | so - it can be both | 17:09 |
| dhellmann | maybe I have permissions to do things to hypervisors in one data center but not another? | 17:09 |
| lbragstad | right now - keystone supports getting a system-scoped token, which means you have authorization to operate on the entire deployment system | 17:09 |
| dhellmann | so the system value might be the data center name? | 17:09 |
| lbragstad | more so a region + service pairing | 17:09 |
| lbragstad | but we don't support that today | 17:10 |
| lbragstad | when we originally designed this, we thought that might be a powerful addition in the future | 17:10 |
| dhellmann | I see, so there's a plan for more levels but for now it's "all" or nothing | 17:10 |
| lbragstad | e.g. i could give Alice the admin role on the compute service and Bob the auditor role on the storage service, and you could have the admin role on everything | 17:11 |
| lbragstad | yeah - right now it's all or nothing | 17:11 |
| dhellmann | ok | 17:11 |
| dhellmann | for the other things like project and domain we have both a name and an id, will we need that here? | 17:12 |
| lbragstad | no | 17:12 |
| lbragstad | that should be specific to project or domain scoped tokens | 17:12 |
| *** shardy has quit IRC | 17:12 | |
| dhellmann | ok, the http header name is HTTP_OPENSTACK_SYSTEM_SCOPE so maybe we can at least call the argument system_scope so it's obvious those are tied together | 17:12 |
| lbragstad | ++ | 17:13 |
| dhellmann | oh, I meant would we need both a name and an id for this scope | 17:13 |
| lbragstad | i think that is reasonable | 17:13 |
| dhellmann | does it need to be 2 variables, iow | 17:13 |
| lbragstad | oh... | 17:13 |
| lbragstad | no i don't think so? | 17:13 |
| dhellmann | like, are these things someone is going to define in a database somewhere? | 17:13 |
| dhellmann | or are we going to have them hard-coded somehow? | 17:13 |
| lbragstad | the only hardcoded value that carries special meaning would be 'all' | 17:13 |
| lbragstad | future work to scope to a specific service would likely incorporate a service_id | 17:14 |
| dhellmann | will the others be site-specific conventions? | 17:14 |
| dhellmann | ah | 17:14 |
| dhellmann | so a different 2nd variable | 17:14 |
| lbragstad | yeah | 17:14 |
| lbragstad | i guess so | 17:15 |
| dhellmann | well, maybe not | 17:15 |
| dhellmann | maybe it would system_scope='compute' ? | 17:15 |
| lbragstad | that's kinda where we are in the discussion of it | 17:15 |
| dhellmann | or would it be system_scope='compute-in-iad-data-center'? | 17:15 |
| lbragstad | because regions play a part in that, too | 17:15 |
| dhellmann | yeah | 17:15 |
| lbragstad | exactly | 17:15 |
| dhellmann | ok | 17:15 |
| * lbragstad has a crazy idea | 17:15 | |
| *** chhagarw has quit IRC | 17:15 | |
| dhellmann | it really feels like what we need is a second type for some of these things | 17:15 |
| dhellmann | like instead of having 2 args, project_name and project_id, we should have had a ProjectID class that had those parameters | 17:16 |
| dhellmann | and maybe one or the other is optional or whatever | 17:16 |
| dhellmann | and then we'd have a SystemScopeDefinition or something and *that* could eventually grow other parameters to deal with the other cases | 17:16 |
| lbragstad | so - what if the "system" was composed of service entities (that keystone already has to know about) and the value of system_scope is always a node in that tree? | 17:17 |
| dhellmann | but that's all off the top of my head and I'm sure it makes instantiating the context way harder | 17:17 |
| dhellmann | that makes a lot of sense to me | 17:17 |
| dhellmann | how does "all" fit into that? | 17:17 |
| lbragstad | i hate to bring up hierachical projects, but it would kinda be like that | 17:17 |
| lbragstad | 'all' would be the root of the tree | 17:17 |
| lbragstad | every service, every region, etc... | 17:18 |
| lbragstad | then you could have services without regions that sit at the top of the tree | 17:18 |
| lbragstad | (e.g. keystone and swift make good example of services that serve multiple regions) | 17:19 |
| lbragstad | then you can organize your regions, and services within those regions | 17:19 |
| lbragstad | so if you have compute services in ord, iad, and dfw | 17:19 |
| lbragstad | i could give someone the admin role on compute in iad, and they could get tokens scoped to that "target" | 17:20 |
| dhellmann | that sounds logical | 17:20 |
| lbragstad | allowing them to do things there, but isolating their permissions to that region | 17:20 |
| lbragstad | s/region/region+service/ | 17:20 |
| dhellmann | could you give them the same access in 2 disconnected regions? | 17:20 |
| lbragstad | you could, but it would likely be two separate role assignments? | 17:21 |
| lbragstad | e.g. i can give Alice admin on compute+iad and admin on compute+dfw | 17:21 |
| dhellmann | sure, that makes sense | 17:21 |
| lbragstad | but she would be required to get different tokens | 17:21 |
| lbragstad | (much like getting different tokens for different projects you have authorization on) | 17:21 |
| lbragstad | even though you may have the same role assignment on each | 17:22 |
| dhellmann | so does that turn "system_scope" into "service_id" instead? | 17:22 |
| lbragstad | yeah - it totally could be | 17:22 |
| dhellmann | or some variation of that, I guess -- I don't know what it's called in the keystone API | 17:22 |
| dhellmann | ok, I'd rather get some consensus about that then and pick the name properly to start out | 17:22 |
| dhellmann | that's going to be a little confusing with all of the service_* parameters, though | 17:23 |
| dhellmann | so maybe system_scope is still a good name, and we just say the value needs to be a service_id | 17:23 |
| lbragstad | so - system_scope could be `system_scope='all'` or `system_scope=$COMPUTE_IAD_SERVICE_ID` | 17:23 |
| dhellmann | right | 17:24 |
| lbragstad | none of the service id stuff exists yet, but we're just trying to make sure we can build for that or add that later | 17:24 |
| dhellmann | system_scope is fine as a name in that case, and we just need to document what is expected as a value | 17:24 |
| lbragstad | ok - that's reasonable | 17:24 |
| dhellmann | sure, that's fine. I'd just hate for us to realize in 3 months that this should all have been 4 different variables describing something other than what we're describing today | 17:25 |
| dhellmann | I mean, that can still happen, but I'd like to at least pretend we think we know what we're doing ;-) | 17:25 |
| lbragstad | right - i completely agree | 17:25 |
| *** spilla has quit IRC | 17:25 | |
| *** AlexeyAbashkin has quit IRC | 17:25 | |
| dhellmann | ok, so I think my comments about naming still apply, and I had asked for some light docs about the parameter | 17:26 |
| lbragstad | that was a big reason why we just decided to target 'all' initially and leave things open to build on in the future (once we figure out the semantics of how all that should work) | 17:26 |
| dhellmann | otherwise the patch looks OK | 17:26 |
| lbragstad | cool | 17:26 |
| lbragstad | i can get those addressed today | 17:26 |
| dhellmann | I completely support that approach. My goal in talking about it was to see what you were thinking *today* because I haven't really been focused on this at all | 17:26 |
| dhellmann | thanks for spending the time to bring me up to speed | 17:26 |
| lbragstad | anytime, thanks for the review and fresh perspective | 17:27 |
| *** e0ne has joined #openstack-oslo | 17:39 | |
| dhellmann | lbragstad: another question just popped into my mind: | 17:42 |
| lbragstad | sure | 17:42 |
| dhellmann | if the system scope is tied to the id of the service, do we need to pass it explicitly? | 17:42 |
| dhellmann | isn't the check just "what roles do they have for my service id? or 'all'?" | 17:43 |
| dhellmann | where "my" is from the perspective of the running service, which presumably knows its id? | 17:43 |
| dhellmann | it's not like project, where a user might log in to different projects, right? | 17:44 |
| lbragstad | right | 17:44 |
| dhellmann | so why does it need to be part of the context? | 17:44 |
| dhellmann | and why do we need an http header? | 17:44 |
| dhellmann | sorry, I'm probably just missing some fundamental assumption | 17:44 |
| lbragstad | the http header gets populated by keystonemiddleware when it receives a token | 17:44 |
| dhellmann | hmm, ok | 17:45 |
| lbragstad | so - taking a step back | 17:45 |
| dhellmann | so I might get a token in one scope, and need a token in a different scope? | 17:45 |
| lbragstad | yeah - so the work in oslo.context tries to expose all scope information to oslo.policy (in a way) | 17:46 |
| lbragstad | it's very closely related to http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html | 17:46 |
| dhellmann | if I get a token scoped to compute-iad but then talk to compute-ord or something? | 17:46 |
| dhellmann | I guess I'm not sure why we make the user specify that when they login, vs. deriving what they can get at the point we need to do the check | 17:47 |
| dhellmann | maybe it makes the policy check implementation easier | 17:47 |
| lbragstad | when we support that case, each service would need to understand it's own service id to be able to say "no, you may have the right role, but that doesn't match my service id" | 17:47 |
| dhellmann | that part makes sense | 17:47 |
| dhellmann | the bit that doesn't is why the user has to specify that scope up front in order to login to keystone | 17:47 |
| lbragstad | kinda of like trying to delete instances in a project you don't have the admin role on | 17:48 |
| dhellmann | or to get the token, I should say | 17:48 |
| lbragstad | sure | 17:48 |
| dhellmann | because if the token identifies me, and I can have many roles, shouldn't we be caring about those roles? not the scope? | 17:48 |
| lbragstad | traditionally, we've always required users to only have one "scope" per token | 17:48 |
| dhellmann | I suppose that makes using the token on the receiving end simpler | 17:49 |
| dhellmann | at least inside the middlware and service | 17:49 |
| lbragstad | do you have all your roles on the same project? | 17:49 |
| dhellmann | although as a user I might end up needing several tokens to do different things | 17:49 |
| lbragstad | very true | 17:49 |
| dhellmann | I guess if we look at the service_id as a parallel to the project, then saying "get the token for the service_id you're trying to talk to" makes sense | 17:50 |
| dhellmann | but if I need to talk to compute-iad and networking-iad then I need 2 tokens? | 17:50 |
| dhellmann | unless I have an all-iad token, I suppose | 17:50 |
| lbragstad | yes | 17:50 |
| lbragstad | or if you have a role assignment on 'all' | 17:50 |
| lbragstad | then you can do everything anywhere | 17:50 |
| dhellmann | would I ever combine project and service ids? like projectA and compute-iad in one call then projectB and compute-iad in another? | 17:51 |
| lbragstad | ideally, you wouldn't... but i also wouldn't be surprised if there are APIs somewhere in openstack where that would make sense | 17:51 |
| dhellmann | ok | 17:52 |
| lbragstad | one of the interesting ones if force create in nova | 17:52 |
| lbragstad | where you have an API that allows users to force instances creation on a specific hypervisor | 17:52 |
| lbragstad | is that a system-level api or a project level api? | 17:52 |
| dhellmann | it feels a bit like we're creating another set of hierarchy and could collapse a bunch of the arguments to the context to avoid duplication of code, but maybe we need to keep them all separated | 17:52 |
| dhellmann | it sounds like a bad idea, however we classify it :-) | 17:53 |
| lbragstad | right - it's an odd thing | 17:53 |
| dhellmann | but, ok, I see that as a case that calls for keeping project and service separate | 17:53 |
| *** lpetrut has quit IRC | 17:54 | |
| *** sambetts is now known as sambetts|afk | 17:54 | |
| lbragstad | it's kind of treads the line between usability and limiting damage control | 17:54 |
| dhellmann | heh, yeah | 17:54 |
| lbragstad | which has traditionally been the argument against allowing tokens scoped to multiple projects or targets | 17:55 |
| dhellmann | I think I get enough of this to see that the current proposal is a good step forward | 17:55 |
| *** gyankum has quit IRC | 17:55 | |
| *** dave-mccowan has quit IRC | 17:55 | |
| dhellmann | yeah, that's a good point | 17:55 |
| openstackgerrit | Lance Bragstad proposed openstack/oslo.context master: Implement system-scope https://review.openstack.org/530509 | 17:56 |
| *** dave-mcc_ has joined #openstack-oslo | 17:56 | |
| *** links has joined #openstack-oslo | 18:00 | |
| *** spilla has joined #openstack-oslo | 18:02 | |
| eandersson | Are there any guidelines for adding schema changes to projects? | 18:05 |
| *** e0ne has quit IRC | 18:20 | |
| dhellmann | eandersson : database schema? or jsonschema? | 18:21 |
| eandersson | Sorry, database schema. | 18:21 |
| dhellmann | I thought that was probably what you meant, but wanted to make sure | 18:21 |
| dhellmann | I don't see anything in the oslo.db docs | 18:21 |
| dhellmann | https://docs.openstack.org/oslo.db/latest/ | 18:21 |
| dhellmann | is your project using sqlalchemy-migrate or alembic? | 18:21 |
| dhellmann | eandersson : I think the best I'm going to be able to do is refer you to an implementation in an existing project | 18:23 |
| dhellmann | which is disappointing, because I thought we had docs on this | 18:24 |
| dhellmann | maybe I just can't find them | 18:24 |
| dhellmann | zzzeek : maybe you know? ^^ | 18:24 |
| * zzzeek knows all | 18:24 | |
| dhellmann | I'm not finding them in the nova contributor guide, either | 18:24 |
| zzzeek | eandersson: not official docs no, you need to look through the migrations given for indiviual projects and see how they are doing them | 18:25 |
| zzzeek | eandersson: best way to find out is to propose one and put it up for gerrit review | 18:25 |
| eandersson | Yea - that is kinda what I figured. I couldn't find any documentation, but was hoping that I just couldn't find it. :p | 18:25 |
| * zzzeek concludes this moment's episode of zzzeek knows all | 18:25 | |
| * zzzeek does not know why his fedora 28 DL just crapped out | 18:26 | |
| zzzeek | nor what is causing this eventlet issue | 18:26 |
| eandersson | Wish I had more time to write documentation :D | 18:29 |
| *** lpetrut has joined #openstack-oslo | 18:34 | |
| *** bobh has quit IRC | 18:34 | |
| *** e0ne has joined #openstack-oslo | 18:35 | |
| *** mriedem has joined #openstack-oslo | 18:37 | |
| mriedem | the oslo.policy sphinx extension seems to either have a bug in it or i'm doing something wrong, based on building docs for this policy https://review.openstack.org/#/c/524425/11/nova/api/openstack/placement/policies/base.py - just two rules, but the rendered doc has one line uncommented: http://logs.openstack.org/25/524425/11/check/build-openstack-sphinx-docs/39855e8/html/configuration/sample-placement-policy.html | 18:39 |
| mriedem | it seems to be duplicating "placement": "role:admin" | 18:39 |
| mriedem | i guess it would be sphinxpolicygen in this case | 18:42 |
| *** yamamoto_ has quit IRC | 18:46 | |
| bnemec | lbragstad: ^might be relevant to your interests | 18:49 |
| lbragstad | mriedem: checking your placement patch quick | 18:50 |
| bnemec | I think this is the bug: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/generator.py#L140 | 18:50 |
| bnemec | Missing # on that line of the format string. | 18:50 |
| bnemec | Hmm, the deprecated_rule one is missing comment characters too. | 18:51 |
| lbragstad | i think that is supposed to be uncommented? | 18:51 |
| bnemec | Yeah, I'm a little confused why that DEPRECATED has a comment and the other doesn't. | 18:53 |
| mriedem | yeah looks like the spot i was just looking at, not sure why it would be uncommented though (intentionally( | 18:54 |
| lbragstad | i remember working with mgagne on some aliasing stuff, i can't remember it if was directly related to this | 18:54 |
| lbragstad | it certainly was related to deprecation things though | 18:54 |
| lbragstad | we ultimately had to modify how the sample was rendered | 18:55 |
| mriedem | i seems like L140 shouldn't even exist | 18:55 |
| mriedem | because the name:check_str are already in text | 18:55 |
| lbragstad | oh | 18:55 |
| mriedem | well, see the TODO i have in my code https://review.openstack.org/#/c/524425/11/nova/api/openstack/placement/policies/base.py@28 - i probably should be using deprecated_rule here | 18:55 |
| mriedem | but i was having some issues getting that to work | 18:55 |
| lbragstad | i was just looking at that | 18:55 |
| lbragstad | we have examples of it here - https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#oslo_policy.policy.DeprecatedRule | 18:56 |
| mriedem | i know and i tried following that once, | 18:58 |
| mriedem | but it made the undeprecated alias look like it was actually deprecated, | 18:58 |
| mriedem | i'll see if i can reproduce what i was seeing | 18:58 |
| mgagne | this isn't the case that we worked on. The case we worked on was about deprecating/replacing a rule name, not a check_str. And make the deprecated rule name an alias of the new rule name so you only have to update the check_str at one place. | 18:58 |
| mgagne | so app still parsing the old rule name (like Horizon) can still work until they are updated to read the new rule name. | 18:59 |
| *** ansmith has quit IRC | 18:59 | |
| lbragstad | mriedem: try this? http://paste.openstack.org/raw/721040/ | 19:00 |
| lbragstad | mgagne: ah - yes.. you're right | 19:00 |
| mriedem | i think i might see the problem | 19:00 |
| mriedem | my problem was i had both deprecated_for_removal and deprecated_rule set for my alias, but the sample gen handles those as mutually exclusive | 19:01 |
| lbragstad | yeah... | 19:02 |
| lbragstad | there is some logic in the RuleDefault constructor for handling that, but i might have missed something | 19:02 |
| mriedem | yeah now i get this | 19:03 |
| mriedem | # DEPRECATED | 19:03 |
| mriedem | # "placement":"role:admin" has been deprecated since 18.0.0 in favor | 19:03 |
| mriedem | # of "admin_api":"role:admin". | 19:03 |
| mriedem | "placement": "rule:admin_api" | 19:03 |
| mriedem | i'm not sure why it's uncommented though | 19:03 |
| lbragstad | are you generating a sample? | 19:03 |
| mgagne | so it's an alias of admin_api | 19:04 |
| *** lpetrut has quit IRC | 19:04 | |
| mgagne | so one still using the "placement" rule can still rely on it until it's removed | 19:04 |
| mriedem | mgagne: right that's the point of the alias, | 19:04 |
| mriedem | i'm just wondering why the sample has the deprecated rule uncommented | 19:04 |
| *** e0ne has quit IRC | 19:04 | |
| mriedem | here https://github.com/openstack/oslo.policy/blob/master/oslo_policy/generator.py#L160 | 19:04 |
| mgagne | as an op, I want it to be uncommented so it actually works as an alias | 19:05 |
| mriedem | ok but then admin_api (the rule) doesn't show up on its own in the sample - but i guess it is documented in the context of the deprecated rule, so maybe that's good enough? | 19:06 |
| mgagne | but... I suppose that | 19:06 |
| mgagne | you are now aliasing to something that doesn't exist | 19:06 |
| mriedem | right... | 19:06 |
| mgagne | I see your point | 19:06 |
| mriedem | because admin_api isn't listed in the sample | 19:06 |
| *** yamamoto has joined #openstack-oslo | 19:06 | |
| *** e0ne has joined #openstack-oslo | 19:07 | |
| mgagne | I'm not sure how to fix it, maybe commenting it is the right thing to do | 19:07 |
| mriedem | that's why i was using deprecated_for_removal before, | 19:07 |
| mriedem | but then i get this weird output http://logs.openstack.org/25/524425/11/check/build-openstack-sphinx-docs/39855e8/html/configuration/sample-placement-policy.html | 19:07 |
| mriedem | were "placement": "role:admin" is uncommented, and #"admin_api": "role:admin" is commented | 19:07 |
| mriedem | but at least it's listed | 19:07 |
| mriedem | *where | 19:07 |
| bnemec | Maybe we need to include the original text in the one at line 159? | 19:08 |
| mriedem | deprecated_reason isn't used in here either https://github.com/openstack/oslo.policy/blob/master/oslo_policy/generator.py#L146 | 19:08 |
| bnemec | I think the deprecation text is overwriting the new policy text as it is. | 19:09 |
| *** yamamoto has quit IRC | 19:12 | |
| mriedem | bnemec: so like this? http://paste.openstack.org/show/721041/ | 19:12 |
| mriedem | that would comment out the deprecated rule but also document the alias rule | 19:13 |
| bnemec | mriedem: Yeah, something like that. Although I might put the original text first so the new rule comes before the deprecated rule. | 19:14 |
| bnemec | I'm not sure I'm familiar enough with how policy works to comment on how best to handle commenting/uncommenting the alias though. | 19:16 |
| *** yamamoto has joined #openstack-oslo | 19:17 | |
| openstackgerrit | Ben Nemec proposed openstack/oslo.policy master: Include both new and deprecated rules in generated sample https://review.openstack.org/568676 | 19:19 |
| *** links has quit IRC | 19:20 | |
| bnemec | ^leaves it uncommented. If we want to comment it we just need to add the appropriate #. | 19:20 |
| mriedem | i'll test that out locally quick | 19:20 |
| bnemec | You can see the change in output in the unit test though. | 19:20 |
| *** jaosorior has joined #openstack-oslo | 19:21 | |
| *** yamamoto has quit IRC | 19:22 | |
| *** janzian has quit IRC | 19:24 | |
| mriedem | yeah this is what i get now | 19:25 |
| mriedem | # Default rule for most placement APIs. | 19:25 |
| mriedem | #"admin_api": "role:admin" | 19:25 |
| mriedem | # DEPRECATED | 19:25 |
| mriedem | # "placement":"role:admin" has been deprecated since 18.0.0 in favor | 19:25 |
| mriedem | # of "admin_api":"role:admin". | 19:25 |
| mriedem | "placement": "rule:admin_api" | 19:25 |
| mriedem | which is better imo | 19:25 |
| bnemec | Cool. | 19:28 |
| bnemec | The alias should work fine, right? Even if the new rule isn't explicitly set, it still exists and has a default. | 19:28 |
| bnemec | Except it's a little concerning that users would need to add the alias manually when upgrading. :-/ | 19:29 |
| bnemec | That's kind of the opposite of oslo.config deprecation where the deprecated alias is handled in code so existing configs continue to work during the deprecation period. | 19:30 |
| mriedem | "would need to add the alias manually when upgrading" - if the alias rule is policy in code, then it's not added manually, right? | 19:30 |
| mriedem | the default would be in code | 19:31 |
| mriedem | so if your check string for the deprecated rule didn't match the default on the alias, then yeah you'd have to add it manually | 19:31 |
| mriedem | but isn't that true with config options also? | 19:31 |
| bnemec | If it's already being handled in code, then yeah. | 19:33 |
| bnemec | I guess I got the impression it was uncommented in the sample file because it needed to be. | 19:33 |
| bnemec | But if the code will handle the alias by default then we should comment out the alias in the sample file. | 19:34 |
| *** yamamoto has joined #openstack-oslo | 19:39 | |
| *** yamamoto has quit IRC | 19:44 | |
| mriedem | that's what i was thinking - it seems weird to have the old rule uncommented in the file, but idk | 19:46 |
| *** lpetrut has joined #openstack-oslo | 19:47 | |
| mriedem | anyway, i think i got what i needed and have changed my code to use deprecated_rule, thanks bnemec lbragstad mgagne | 19:48 |
| lbragstad | mriedem: cool - let me know if you hit any other weird cases | 19:50 |
| *** yamamoto has joined #openstack-oslo | 19:59 | |
| *** e0ne has quit IRC | 20:02 | |
| *** yamamoto has quit IRC | 20:04 | |
| openstackgerrit | Ben Nemec proposed openstack/oslo.policy master: Include deprecated_reason when deprecated_rule is set https://review.openstack.org/568687 | 20:20 |
| *** yamamoto has joined #openstack-oslo | 20:22 | |
| *** yamamoto has quit IRC | 20:26 | |
| *** e0ne has joined #openstack-oslo | 20:35 | |
| *** mriedem has left #openstack-oslo | 20:39 | |
| *** e0ne has quit IRC | 20:40 | |
| *** yamamoto has joined #openstack-oslo | 20:43 | |
| *** janzian has joined #openstack-oslo | 20:45 | |
| *** yamamoto has quit IRC | 20:47 | |
| *** raildo has quit IRC | 20:59 | |
| *** kgiusti has quit IRC | 21:00 | |
| *** yamamoto has joined #openstack-oslo | 21:04 | |
| *** yamamoto has quit IRC | 21:08 | |
| *** mriedem has joined #openstack-oslo | 21:21 | |
| mriedem | hmm, so when i changed to use deprecated_rule, i'm getting errors now when using the deprecated "placement" policy because it's not registered, but its alias is | 21:21 |
| mriedem | http://logs.openstack.org/25/524425/12/check/openstack-tox-py27/82bf7ed/testr_results.html.gz | 21:22 |
| mriedem | i thought the point of the alias was so we could continue using the old thing and it wouldn't blow up? | 21:22 |
| *** yamamoto has joined #openstack-oslo | 21:24 | |
| *** yamamoto has quit IRC | 21:29 | |
| mgagne | mriedem: an alias to external consumer app which reads the file manually like Horizon. I don't think the app (placement) will actually register an alias. | 21:32 |
| *** ansmith has joined #openstack-oslo | 21:37 | |
| mriedem | ok, i've changed back and just marked the "placement" rule as deprecated_for_removal | 21:40 |
| mriedem | with the reason being, use rule:admin_api | 21:40 |
| *** yamamoto has joined #openstack-oslo | 21:45 | |
| *** yamamoto has quit IRC | 21:50 | |
| *** edmondsw has quit IRC | 21:52 | |
| *** edmondsw has joined #openstack-oslo | 21:53 | |
| *** lpetrut has quit IRC | 21:54 | |
| *** mriedem is now known as mriedem_afk | 21:55 | |
| *** edmondsw has quit IRC | 21:57 | |
| *** rcernin has joined #openstack-oslo | 22:00 | |
| *** yamamoto has joined #openstack-oslo | 22:06 | |
| *** yamamoto has quit IRC | 22:10 | |
| *** yamamoto has joined #openstack-oslo | 22:27 | |
| *** yamamoto has quit IRC | 22:31 | |
| *** yamamoto has joined #openstack-oslo | 22:47 | |
| *** yamamoto has quit IRC | 22:52 | |
| *** yamamoto has joined #openstack-oslo | 23:08 | |
| *** yamamoto has quit IRC | 23:12 | |
| *** edmondsw has joined #openstack-oslo | 23:29 | |
| *** yamamoto has joined #openstack-oslo | 23:30 | |
| *** edmondsw has quit IRC | 23:34 | |
| *** yamamoto has quit IRC | 23:35 | |
| *** yamamoto has joined #openstack-oslo | 23:52 | |
| *** yamamoto has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!