Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-19
18:36:34 melwitt and typing
18:37:54 melwitt efried, jaypipes: did y'all want to get these two things in before os-traits release today? https://review.openstack.org/546713 and https://review.openstack.org/553277
18:38:21 melwitt or is it cool to just go ahead
18:38:56 efried It looks like we want gibi to sign off on the former
18:43:48 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: [CLI] Fix token auth type https://review.openstack.org/424256
18:44:01 mriedem melwitt: +2 on ^
18:44:23 melwitt ack
18:47:18 jaypipes melwitt: can't merge https://review.openstack.org/#/c/546713/ until mriedem signs off in. The proposed supports_recreate capability would be changed to supports_evacuate by mdbooth's patch.
18:47:48 mriedem there is no supports_recreate capability in that os-traits patch
18:47:49 jaypipes melwitt: never mind... I forgot I didn't put supports_recreate in there.
18:48:39 jaypipes melwitt: either way, since I proposed the patch, someone else needs to +2.
18:49:17 jaypipes melwitt: as for the CPU max display heads one, I'm already +2 on it.
18:49:21 jaypipes GPU...
18:49:56 melwitt yeah, I mean, were those two things important for the release today or are they fine to wait till a future release
18:50:27 jaypipes melwitt: I wouldn't mind having them merged.
18:50:58 openstackgerrit Matt Riedemann proposed openstack/nova master: Move some tests into nova.tests.unit.notifications.objects.test_instance https://review.openstack.org/562793
18:55:46 mriedem jroll: does https://bugs.launchpad.net/nova/+bug/1765334 sound familiar to you as something we might have fixed already outside of https://review.openstack.org/#/c/518294/ ?
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)

Earlier   Later