| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-19 | |||
| 20:08:28 | mriedem | given stable/ocata is blocked otherwise, i think i'm going to just fast approve that revert | |
| 20:10:22 | melwitt | k, makes sense | |
| 20:10:24 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757 | |
| 20:12:15 | mriedem | cfriesen: this might be something you can docify https://bugs.launchpad.net/nova/+bug/1764729 | |
| 20:12:16 | openstack | Launchpad bug 1764729 in OpenStack Compute (nova) "doc: live migration missing part about different cpu models/flags" [Medium,Confirmed] | |
| 20:30:17 | jackie-truong | mriedem: For the trusted certs policy rules, since we're looking for a single admin_or_owner rule for all trusted certs related API calls, there's no need to split things up like this?: https://github.com/openstack/nova/blob/master/nova/policies/server_tags.py | |
| 20:30:52 | jackie-truong | Or are splitting individual calls up like that preferred? | |
| 20:31:46 | melwitt | dansmith: wanna send this in for novaclient stable/pike? fixes a user-facing error message https://review.openstack.org/#/c/562392 | |
| 20:32:56 | mriedem | jackie-truong: it's not really the same thing, tags are their own resource, we aren't implementing trusted_certs as a subresource on the server resource like that, i.e. POST /servers/{id}/trusted_certs | |
| 20:33:26 | openstackgerrit | Giridhar Jayavelu proposed openstack/nova-specs master: VMware: place instances on resource pool https://review.openstack.org/549067 | |
| 20:33:29 | mriedem | jackie-truong: so i think a single policy rule for allowing trusted_certs for POST /servers (server create) and POST /servers/{id}/action (rebuild) is ok | |
| 20:33:48 | dansmith | melwitt: done | |
| 20:33:56 | melwitt | thank ye | |
| 20:34:03 | mriedem | jackie-truong: furthermore, i don't think we need to apply the policy rule to omit 'trusted_certs' from the server response body, it would just always be empty if the user can't create a server with trusted certs | |
| 20:34:06 | efried | melwitt: Sending https://review.openstack.org/#/c/553277/ (sorry for the delay) | |
| 20:34:25 | openstackgerrit | Merged openstack/nova master: Use Queens UCA for nova-multiattach job https://review.openstack.org/554317 | |
| 20:35:13 | jackie-truong | mriedem: I think Nova API extension concept was removed in Pike: https://github.com/openstack/nova/commit/f2d18c2e9989f007a6576be6c9a6fcc5bcd67322 | |
| 20:35:18 | melwitt | efried: coolness, thanks | |
| 20:35:53 | mriedem | jackie-truong: ? i'm not talking about extensions | |
| 20:35:57 | jackie-truong | For example, security_groups policy rules are deprecated for POST /servers https://github.com/openstack/nova/blob/master/nova/policies/security_groups.py | |
| 20:36:01 | jackie-truong | Sorry, I'm confused | |
| 20:36:25 | mriedem | this is similar, imo, to os_compute_api:servers:attach_volume | |
| 20:36:40 | mriedem | which blocks boot from volume on server create, if for example, you don't have cinder in your cloud | |
| 20:36:56 | mriedem | if i don't have barbican, i can't support trusted certs | |
| 20:37:10 | mriedem | s/barbican/any castellan implementation' | |
| 20:38:26 | mriedem | heh looks like we don't have os_compute_api:servers:attach_volume documented | |
| 20:38:42 | mriedem | oh os_compute_api:servers:create:attach_volume | |
| 20:39:17 | mriedem | jackie-truong: yeah so i'd expect to see a policy rule like os_compute_api:servers:trusted_certs | |
| 20:39:21 | jackie-truong | oh okay, i see | |
| 20:39:24 | mriedem | use that for both server create and rebuild | |
| 20:39:36 | mriedem | and no need to check the policy rule on the response (in the view builder) | |
| 20:40:20 | mriedem | if we wanted to get super granular we could have both os_compute_api:servers:create:trusted_certs and os_compute_api:servers:rebuild:trusted_certs | |
| 20:40:28 | mriedem | i do'nt know why we would need to, maybe edmondsw has a preference | |
| 20:40:32 | mriedem | he dreams about this stuff | |
| 20:41:03 | openstackgerrit | Merged openstack/nova stable/ocata: Refactor a test method including 3 test cases https://review.openstack.org/561603 | |
| 20:41:16 | edmondsw | lol | |
| 20:41:33 | mriedem | you know it's true, waking up in a sweat, | |
| 20:41:38 | edmondsw | why are we creating a policy for this? | |
| 20:41:39 | mriedem | "what was it honey? bad dream?" | |
| 20:41:42 | mriedem | "POLICY?!!?!" | |
| 20:41:49 | edmondsw | definitely a bad dream | |
| 20:42:03 | mriedem | edmondsw: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129494.html | |
| 20:42:23 | edmondsw | I saw that, haven't gotten to replying... but seems more like a conf than policy thing | |
| 20:42:32 | dansmith | heh | |
| 20:42:36 | edmondsw | policy is when you want to allow some folks to do it but not others | |
| 20:42:45 | edmondsw | not when you want to enable/disable something entirely | |
| 20:42:59 | edmondsw | did I misunderstand? | |
| 20:43:24 | mriedem | well, | |
| 20:43:25 | dansmith | 🍿 | |
| 20:43:26 | jaypipes | zzzeek_: noticed this littering unit test output nowadays: http://paste.openstack.org/show/719587/. I'm actually not sure how to fix... any ideas? | |
| 20:43:36 | mriedem | consider you have some tenants that want/can do the trusted certs thing, | |
| 20:43:53 | mriedem | and you have those tenants tied to host aggregates via the tenant isolation multitenancy filter | |
| 20:43:59 | melwitt | well, can be both right? if one cloud wants to disable something but another wants to enable it, having it controlled by policy at least gives a consistent behavior where you can get 403 if you're not allowed or if that cloud doesn't allow | |
| 20:44:02 | mriedem | and you know those hosts are configured for cert validation | |
| 20:44:11 | mriedem | melwitt: yes | |
| 20:44:23 | mriedem | i'm looking for consistent api behavior with a 403 | |
| 20:44:45 | edmondsw | ok, so that's what I missed... you DO want to allow it for some folks and not for others in a single cloud | |
| 20:44:59 | melwitt | dansmith: good job putting emoji in here, didn't know we could do that | |
| 20:45:25 | dansmith | melwitt: really? cdent does it incessantly | |
| 20:45:30 | openstackgerrit | Merged openstack/os-traits master: GPU: define traits for maximum display heads https://review.openstack.org/553277 | |
| 20:45:53 | melwitt | oh, that checkmark thing. I have seen that | |
| 20:45:57 | edmondsw | dansmith cdent who wants to teach the rest of us? ;) | |
| 20:46:13 | dansmith | um.. paste? | |
| 20:46:20 | melwitt | but the popcorn has at least three colors in it | |
| 20:46:26 | edmondsw | oh, that simple | |
| 20:46:28 | dansmith | https://emojipedia.org/popcorn/ | |
| 20:46:31 | dansmith | click copy | |
| 20:46:33 | dansmith | then paste | |
| 20:46:35 | dansmith | it's like | |
| 20:46:37 | dansmith | rocket surgery | |
| 20:46:45 | edmondsw | lol | |
| 20:46:50 | melwitt | wah, that's hard | |
| 20:47:49 | zzzeek_ | jaypipes: this is the context for that: https://bitbucket.org/zzzeek/sqlalchemy/commits/63a7b2d2d940#chg-test/orm/test_evaluator.py | |
| 20:48:05 | zzzeek_ | jaypipes: it means you are doing query.update({Object.foo = column('bar')}) | |
| 20:48:34 | zzzeek_ | jaypipes: need to use the real Whereever.bar column. that was an error raise until nova caused a lot of failures :) | |
| 20:48:49 | zzzeek_ | jaypipes: *or*, dont use the "evaluate" strategy | |
| 20:49:06 | melwitt | 🍿<-- dazzling | |
| 20:49:36 | jaypipes | zzzeek_: I have no idea what that means :( | |
| 20:49:57 | zzzeek_ | jaypipes: need to show me where you are caling query.update() | |
| 20:50:00 | melwitt | mriedem: looks like things are happy with this backport now. care to reapply +W? https://review.openstack.org/#/c/539013 | |
| 20:50:24 | jaypipes | zzzeek_: I'm not... it's literally appears thousands of times when I run the unit tests in nova. | |
| 20:50:49 | zzzeek_ | jaypipes: ok by "you" i mean, "you nova people" | |
| 20:50:50 | jaypipes | zzzeek_: fresh master checkout, nothing to do with my local changes. | |
| 20:50:57 | melwitt | *gasp* | |
| 20:51:00 | zzzeek_ | jaypipes: it's not related to your changes it's related to existing code in nova | |
| 20:51:22 | jaypipes | zzzeek_: ok. where we are calling query.update() or query.delete()? | |
| 20:51:30 | edmondsw | mriedem jackie-truong so I don't reallly have a strong opinion between 1) os_compute_api:servers:trusted_certs and 2) both os_compute_api:servers:create:trusted_certs and os_compute_api:servers:rebuild:trusted_certs | |
| 20:51:33 | edmondsw | at least not today :) | |
| 20:51:54 | mriedem | alright | |
| 20:51:57 | zzzeek_ | jaypipes: i dunno. maybe turn those warnigs into error raises and stacktrace will show | |
| 20:52:08 | zzzeek_ | jaypipes: unless nova is calling some other ORM-related application | |
| 20:52:14 | jackie-truong | edmondsw: Np. I went with option 2 | |
| 20:52:14 | edmondsw | I'd probably go granular, but there are pros and cons | |
| 20:52:20 | edmondsw | cool | |
| 20:52:35 | melwitt | gmann has a spec proposed for making policy more granular | |
| 20:52:59 | edmondsw | oh? | |
| 20:53:07 | edmondsw | I'll have to go find that | |
| 20:53:19 | melwitt | or consistently granular https://review.openstack.org/#/c/547850 | |
| 20:53:36 | melwitt | more granular | |
| 20:54:27 | mriedem | melwitt: hmm, how is https://review.openstack.org/#/c/539013/ passing if https://review.openstack.org/#/c/562739/ isn't merged yet? | |