| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-19 | |||
| 20:05:43 | melwitt | I think the fix itself is important, we had customers hit the problem and then cfriesen's org also hit the problem. and AFAIK what we did to handle the lack of refactoring stuff and os-brick non lower-constraints stuff was the proper thing to do | |
| 20:06:07 | mriedem | i don't disagree | |
| 20:06:14 | melwitt | *encryption refactoring | |
| 20:08:15 | mriedem | so https://review.openstack.org/#/c/562739/ passed except for an rpc messaging timeout in the live migration job | |
| 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 | edmondsw | I'd probably go granular, but there are pros and cons | |
| 20:52:14 | jackie-truong | edmondsw: Np. I went with option 2 | |
| 20:52:20 | edmondsw | cool | |
| 20:52:35 | melwitt | gmann has a spec proposed for making policy more granular | |
| 20:52:59 | edmondsw | oh? | |