| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-18 | |||
| 08:38:47 | eandersson | Thanks yea just found it | |
| 08:40:15 | eandersson | I'll try it out in the lab | |
| 08:56:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Restore retrying the RPC connection to conductor https://review.opendev.org/763138 | |
| 09:09:47 | eandersson | Worked great in the lab | |
| 09:11:58 | gibi | eandersson: good to hear that | |
| 09:42:03 | lyarwood | Morning | |
| 10:29:09 | openstack | bug 1896463 in OpenStack Compute (nova) rocky "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,In progress] https://launchpad.net/bugs/1896463 | |
| 10:29:09 | openstackgerrit | Merged openstack/nova master: Reproduce bug 1896463 in func env https://review.opendev.org/754100 | |
| 10:32:57 | openstackgerrit | Merged openstack/nova master: Set instance host and drop migration under lock https://review.opendev.org/754815 | |
| 10:33:06 | openstackgerrit | Merged openstack/nova master: [Trivial]Add missing white space in the log message https://review.opendev.org/762804 | |
| 10:33:16 | openstackgerrit | Merged openstack/nova master: [docs] Fix a placement client's command https://review.opendev.org/762663 | |
| 10:35:53 | openstack | bug 1896463 in OpenStack Compute (nova) rocky "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,In progress] https://launchpad.net/bugs/1896463 | |
| 10:35:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Reproduce bug 1896463 in func env https://review.opendev.org/763152 | |
| 10:38:30 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Set instance host and drop migration under lock https://review.opendev.org/763154 | |
| 11:36:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Revert "Temporarily disable parts of heal port allocation test" https://review.opendev.org/755995 | |
| 11:41:14 | stephenfin | Does unshelving a server always result in that server going to ACTIVE or ERROR state? | |
| 11:42:20 | stephenfin | I'm adding a '--wait' option to 'openstack server unshelve' and was checking for 'SHUTOFF' status, but a quick check suggests we don't restore to the original state after unshelving https://review.opendev.org/#/c/763166/1/openstackclient/compute/v2/server.py@3713 | |
| 11:43:15 | stephenfin | So I guess I just need to check for 'ACTIVE'? | |
| 11:49:17 | sean-k-mooney | i shoudl go to active but if there is an error i dont knwo if it will go back to shelved or error | |
| 11:49:52 | sean-k-mooney | we wont restore the orgininal state as far as i know | |
| 11:56:57 | stephenfin | okay, I'll just check for ACTIVE so | |
| 12:24:30 | openstackgerrit | Shi Yan proposed openstack/nova master: Fix the instance_uuid for test https://review.opendev.org/763171 | |
| 13:58:49 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199 | |
| 14:02:13 | aarents | Hi nova, | |
| 14:03:24 | aarents | lyarwood: can you confirm, when you can, that those both change are ok ? https://review.opendev.org/#/c/743708/ https://review.opendev.org/#/c/752463/2 thanks ! | |
| 15:10:49 | gmann | stephenfin: sean-k-mooney I agree on full list of hypervisors to project admin if no limit - https://review.opendev.org/#/c/763043/1/specs/wallaby/approved/modernize-os-hypervisors-api.rst@162 | |
| 15:11:29 | gmann | stephenfin: if you can update the other comments I am good on this. | |
| 15:18:37 | owalsh | artom, rm_work: FYI there is a better option for DB creds etc... for cell uris: https://docs.openstack.org/nova/latest/user/cells.html#template-urls-in-cell-mappings | |
| 15:21:32 | stephenfin | gmann: Cool, I will respin that shortly | |
| 15:21:49 | stephenfin | dansmith: Is 'nova refresh-network' worth porting to OSC? | |
| 15:22:03 | dansmith | stephenfin: isn't that a xen-specific thing? | |
| 15:22:16 | stephenfin | It uses the os-server-external-events extension | |
| 15:22:21 | stephenfin | "extension" | |
| 15:22:31 | stephenfin | is that XenAPI specific? | |
| 15:22:50 | stephenfin | surely not; that's what neutron uses iirc | |
| 15:23:19 | stephenfin | asking you specifically because you authored the novaclient change waaaay back https://review.opendev.org/#/c/74763/ | |
| 15:23:30 | dansmith | oh, then I'm thinking of something else | |
| 15:24:37 | owalsh | dansmith: re cell nova-conductor still requiring api db for affinity checks, should I assume that will eventually change? | |
| 15:24:39 | dansmith | oh, right, this probably really shouldn't even be a CLI thing, we probably added it there so we could poke it for testing | |
| 15:24:40 | rm_work | owalsh: oooo will take a look, thanks | |
| 15:24:59 | stephenfin | okay, that was my gut feel too; I'll skip it so | |
| 15:25:04 | stephenfin | dansmith++ thanks | |
| 15:26:19 | dansmith | stephenfin: I was thinking of this: https://docs.openstack.org/api-ref/compute/#reset-networking-on-a-server-resetnetwork-action | |
| 15:26:40 | dansmith | note the "no longer supported by any virt driver" because xen | |
| 15:26:56 | stephenfin | aha, yes, I've done work on that recently | |
| 15:28:47 | dansmith | owalsh: probably not any time soon.. it was hinging on affinity in placement, and I gather that people aren't interested in furthering those goals these days, | |
| 15:28:55 | dansmith | owalsh: so probably no change on the horizon | |
| 15:39:40 | owalsh | dansmith: ack, thanks, so it wouldn't be crazy to use these creds to create the cell mapping when deploying a new cell conductor? | |
| 15:40:09 | dansmith | owalsh: nope, that's reasonable at the moment I'd say | |
| 15:46:12 | owalsh | dansmith: ack, great. Also does metadata api need the api db config even when local_metadata_per_cell=True? | |
| 15:47:06 | dansmith | owalsh: shouldn't, no | |
| 15:48:08 | dansmith | owalsh: yeah, if that's set, we never run the mapping lookup, which is the api hit | |
| 15:48:25 | dansmith | owalsh: so unless there's a bug or something buried deep, that's the intent.. no api db hit if =True | |
| 15:49:21 | owalsh | dansmith: ack, yea, didn't initially make sense that local_metadata_per_cell existed when everything else just checks if the api db is configured, but need to support cell conductor & metadata api sharing nova.conf | |
| 15:53:27 | dansmith | owalsh: well, I think metadata was the first thing to need that determination, so we added a conf knob for it specifically.. it's also potentially security-related because the workloads can talk to it, so explicit-ness is good | |
| 15:53:47 | dansmith | owalsh: but we could deprecate that conf knob and actually just honor the presence of the api creds if you think it'd be better for consistency | |
| 15:58:11 | owalsh | dansmith: but that wouldn't work in cases where the cell conductor shares nova conf with cell metadata-api | |
| 15:58:32 | dansmith | cell conductor, yeah | |
| 16:01:25 | owalsh | dansmith: which goes back to the recommendation on the ML to follow the devstack approach to conf - it doesn't seem to work when using cell local metadata api... | |
| 16:02:01 | owalsh | since metadata-api always uses nova.conf, never nova-cellN.conf | |
| 16:02:36 | dansmith | owalsh: but devstack runs a global metadata api right? | |
| 16:03:02 | owalsh | dansmith: yup, doesn't seem to support cell local metadata api | |
| 16:03:31 | dansmith | devstack's goal, of course, is not to support every possible deployment arrangement... | |
| 16:03:59 | owalsh | dansmith: indeed, and for CI/dev running multiple cells makes sense but in production it does not... | |
| 16:04:09 | owalsh | multiple cells on the same host that is | |
| 16:04:45 | dansmith | I've lost track of what we're arguing about | |
| 16:06:14 | owalsh | dansmith: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018732.html | |
| 16:06:59 | owalsh | I'm saying we can't use a similar strategy to separate files | |
| 16:10:04 | dansmith | owalsh: okay I'm sorry, I've really lost track of who "we" and what the problem is. You're saying "we=tripleo" deploy a metadata per cell and can't, for some reason, point it at the cellN conductor's config file? | |
| 16:11:44 | owalsh | dansmith: rpms/debs in particular are the issue, but yes, can't point metadata-api at the conductor's config file | |
| 16:14:19 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: WIP libvirt: Allow the default machine type to be changed https://review.opendev.org/762199 | |
| 16:15:02 | dansmith | owalsh: okay, I'm not sure why not currently, because we have that other knob | |
| 16:15:30 | owalsh | dansmith: nova.conf is hardcoded in wsgi_api.py | |
| 16:21:07 | owalsh | dansmith: TBH it would make a lot more sense to just say: use nova.conf for everything except nova-compute.... | |
| 16:22:25 | dansmith | owalsh: I'm really lost, I'm sorry | |
| 16:22:38 | dansmith | you can, of course, just use nova.conf for everything, | |
| 16:23:00 | dansmith | but if they're all on the same host and you have cell and super conductors, they can't all use the same config file | |
| 16:29:57 | bauzas | grmblbl, I get exceptions about RPC API 6.0 that I don't understand... | |
| 16:31:10 | bauzas | "ERROR nova.api.openstack.wsgi oslo_messaging.rpc.client.RPCVersionCapError: Requested message version, 5.0 is incompatible. It needs to be equal in major version and less than or equal in minor version as the specified version cap 6.0" | |
| 16:31:19 | bauzas | WTF | |
| 16:36:43 | bauzas | dansmith: do you have any idea why the RPC API only supports 6.0 as the minor RPC version while I wrote a 5.12 proxy in https://review.opendev.org/#/c/761452/2 ? | |
| 16:37:03 | bauzas | I got tons of tempest and func tests failing because of this | |
| 16:37:59 | bauzas | in theory, I should expose 5.x as a valid RPC target thanks to the added service RPC endpoint | |
| 16:50:06 | gmann | stephenfin: bauzas dansmith can you review this, sample config file fix - https://review.opendev.org/#/c/762721/ | |
| 17:01:59 | noonedeadpunk | hey! | |
| 17:02:14 | noonedeadpunk | having a question regarding http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018663.html | |
| 17:03:18 | noonedeadpunk | to be specific - was trying to provide --config-file for uwsgi via pyargv but nova seems to ignore it... | |
| 17:04:12 | noonedeadpunk | and it indeed works for neutron... so not sure if it's just me having issues or what, as things are set via oslo anyway.... | |
| 17:39:54 | dansmith | noonedeadpunk: funny you should ask | |
| 17:40:32 | dansmith | noonedeadpunk: I think it should, I dunno why it doesn't, and I'm about to caffeinate myself and write a tome to the ML thread about it and other things | |
| 18:32:40 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.opendev.org/602432 | |
| 18:32:57 | sean-k-mooney | melwitt: i hope that adresses your comments ^ | |
| 18:33:25 | sean-k-mooney | stephenfin: if you have time to have a look again at ^ it basicaly the same + some typo fixes and a rebase | |
| 18:33:33 | melwitt | thanks | |
| 18:34:40 | sean-k-mooney | based on your question i set the min verion to 1.15.2 instaed of 1.15.1 since it has imporant bugfixes for linuxbridge and added that to the commit | |
| 18:35:46 | sean-k-mooney | 1.15.0 was broken for ovs 1.15.1 fixed that but still was broken in some cases for linux bridge 1.15.2 is what we released with and support on stable stine in upper constratints | |
| 18:37:19 | melwitt | thanks for explaining that, makes sense now. I had been confused by the gap in the release notes and couldn't find the significance of 1.15.1 | |
| 18:39:07 | melwitt | sean-k-mooney: oh, one more question that I had on the review that I think was missed, is this new delegation to os-vif for the plug, does it run during tempest tests in the gate? or is it for a config that is not running in the gate | |
| 18:41:04 | sean-k-mooney | oh right i will run in any job using iptables | |
| 18:41:12 | sean-k-mooney | i think we have on that does that but ill check now | |