| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-19 | |||
| 18:55:47 | openstack | Launchpad bug 1765334 in OpenStack Compute (nova) "Ironic resource class may not be put into inventory in Pike" [Undecided,New] | |
| 18:55:51 | mriedem | johnthetubaguy_: ^ | |
| 19:02:41 | mriedem | looks like https://github.com/openstack/nova/commit/9ed692bf8c84e0a702536101cd6cb084d33e1c26#diff-6243ddf138dd43ec84fc716722531cb8 | |
| 19:06:19 | jroll | mriedem: sounds like 518294 might need a backport to pike? | |
| 19:07:12 | mriedem | eh, idk | |
| 19:07:23 | jroll | mriedem: or it's a race against the resource tracker | |
| 19:07:36 | melwitt | mriedem: novaclient release patch https://review.openstack.org/#/c/562804 | |
| 19:07:45 | mriedem | https://review.openstack.org/#/c/518294/ is specifically about resource inventory that's not in the compute node, only placement | |
| 19:08:00 | jroll | ah | |
| 19:08:04 | mriedem | in the case of this ironic bug on pike, it's a custom resource class that gets proxied into the node later | |
| 19:08:27 | mriedem | so rather than create the ironic node with a custom resource class, they create the node, then add the resource class, and that doesn't get reported, via nova (RT) into placement | |
| 19:08:55 | jroll | mriedem: don't think it's the commit you linked, though, that one is about nodes with instances, the bug is before an instance is places | |
| 19:08:56 | mriedem | because nova doesn't think that custom resource classes are something worth reporting for inventory i guess, unless a *known* inventory class changes, like VCPU, MEMORY_MB and DISK_GB | |
| 19:09:20 | mriedem | ah yeah | |
| 19:09:36 | mriedem | that's what i asked in the bug, is the node deployed or not which might make it different from dtantsur|pto's patch | |
| 19:09:52 | mriedem | "1. Always reporting the custom resource class for deployed nodes, if present." | |
| 19:10:08 | mriedem | so they need to always report custom resource class inventory regardless of node state | |
| 19:10:22 | mriedem | bleh, yay proxy fun | |
| 19:14:39 | mriedem | melwitt: was there something specifically in the novaclient changelog that made you think we should do a major version bump? | |
| 19:15:10 | melwitt | mriedem: the addition of the 2.61 microversion support. is that not necessarily a major version? | |
| 19:15:16 | mriedem | no, that's a feature | |
| 19:15:21 | mriedem | minor version bump | |
| 19:16:00 | melwitt | oh, guh. okay. | |
| 19:19:58 | mriedem | lbragstad: is this right? https://bugs.launchpad.net/nova/+bug/1765144 | |
| 19:19:58 | openstack | Launchpad bug 1765144 in OpenStack Compute (nova) "[keystone_authtoken] auth_url = http://controller:35357 port error, it should be 5000" [Undecided,New] | |
| 19:20:39 | lbragstad | mriedem: yes and no | |
| 19:20:55 | lbragstad | technically we removed the legacy v2.0 app in queens, so we no longer require two ports | |
| 19:21:04 | lbragstad | but it certainly don't have to be port 5000, or 35357 | |
| 19:21:23 | mriedem | yeah looking in http://logs.openstack.org/20/554920/12/check/tempest-full/df42a0d/controller/logs/etc/nova/nova_conf.txt.gz | |
| 19:21:27 | mriedem | we don't specify a port at all | |
| 19:21:50 | lbragstad | oh - sure v | |
| 19:21:52 | lbragstad | https://github.com/openstack/releases/blob/master/deliverables/queens/keystoneauth.yaml#L17 | |
| 19:22:07 | lbragstad | auth_url = https://198.72.124.213/identity | |
| 19:22:16 | mriedem | and auth_uri isn't specified at all | |
| 19:22:44 | mriedem | was auth_uri keystone v1/v2 only? | |
| 19:23:38 | lbragstad | you should use auth_url | |
| 19:23:52 | lbragstad | auth_url and auth_uri was causing a lot of confusion | |
| 19:23:56 | lbragstad | so we renamed it https://github.com/openstack/keystonemiddleware/commit/409b482253dec248ed828e92e52b09d4c02e51dd | |
| 19:24:32 | lbragstad | it was ultimately a side-effect of integrating keystoneauth into keystonemiddleware | |
| 19:27:01 | mriedem | ok so the note at step 5 here https://docs.openstack.org/keystone/latest/install/keystone-install-ubuntu.html#install-and-configure-components | |
| 19:27:09 | mriedem | "Before the Queens release, keystone needed to be run on two separate ports to accommodate the Identity v2 API which ran a separate admin-only service commonly on port 35357. With the removal of the v2 API, keystone can be run on the same port for all interfaces." | |
| 19:28:28 | openstackgerrit | Merged openstack/nova stable/ocata: Clean up volumes on boot failure https://review.openstack.org/545086 | |
| 19:28:42 | mriedem | lbragstad: and i'm assuming that keystone-manage bootstrap creates the identity service endpoint in the catalog? | |
| 19:28:50 | lbragstad | it does | |
| 19:29:01 | mriedem | so if hte docs say "--bootstrap-public-url http://controller:5000/v3/" | |
| 19:29:12 | mriedem | then that's probably what the nova docs should use | |
| 19:29:25 | mriedem | or internal url i guess, but they are the same in the docs | |
| 19:30:16 | mriedem | ok i'll push a change to fix the nova install guide docs to remove auth_uri and change auth_url to use port 5000 | |
| 19:30:20 | mriedem | thanks | |
| 19:32:11 | lbragstad | mriedem: cool - that's a good idea.. | |
| 19:32:16 | lbragstad | i just left a comment on that bug | |
| 19:32:51 | lbragstad | the only things is that people started noticing this when moving from one installation guide to another (and different services were referencing different ports) | |
| 19:38:06 | mriedem | yeah. i've also always been confused by auth_uri and auth_url, glad i wasn't the only one | |
| 19:38:25 | melwitt | mriedem: nova queens 17.0.3 release patch https://review.openstack.org/#/c/562806 | |
| 19:40:40 | mriedem | lgtm | |
| 19:48:10 | jaypipes | lol. turning off @safe_connect blows up unit tests but functional tests work just fine... | |
| 19:48:40 | jaypipes | turns out our unit tests are depending on the behaviour of safe_connect hiding placement connectivity problems. | |
| 19:50:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update docs for [keystone_authtoken] changes since Queens https://review.openstack.org/562812 | |
| 19:54:00 | melwitt | I'm still +1 on https://review.openstack.org/#/c/560690 but bauzas had some concerns | |
| 19:57:57 | efried | jaypipes: I noticed something like that in https://review.openstack.org/#/c/562060/ (except my func tests failed too, obviously) | |
| 20:01:45 | mriedem | melwitt: i can't tell if bauzas is concerned about the encryption thing that was added, or because of the os-brick masssage-a-roo | |
| 20:01:48 | mriedem | *massage | |
| 20:02:40 | melwitt | I assumed both | |
| 20:04:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690 | |
| 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 | |