Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-06
14:37:20 gmann johnthetubaguy: yeah but it is right or wrong :) ? because we do not allow the same for any other admin only policy
14:37:28 gmann admin only by default
14:38:35 johnthetubaguy we probably should allow that, for things where it is not strictly a system level thing
14:39:04 johnthetubaguy but, we are getting ahead of ourselves I guess
14:39:48 johnthetubaguy this is about digging out of crazy land, so we can add more options in the future
14:40:01 brinzhang gmann, johnthetubaguy: I change that to the target={}, but it has the same issue, http://paste.openstack.org/show/790395/
14:41:07 johnthetubaguy gmann: is brinzhang hitting the same issue you are here: https://review.opendev.org/#/c/706689
14:41:16 johnthetubaguy I am not sure what is causing the problem though :(
14:41:24 gmann johnthetubaguy: ok, let's go case by case and judge the not-strict-system-cases or upon user request . i will leave instance action also in that catagory
14:41:36 johnthetubaguy gmann: +1
14:42:14 gmann johnthetubaguy: brinzhang i think i observed some wired things on aggregate policy also but could not debug those yet. let me debug it
14:42:31 johnthetubaguy gmann: +1 thanks
14:42:53 brinzhang gmann: thanks
14:43:50 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Reproduce bug 1862633 https://review.opendev.org/711626
14:43:50 openstack bug 1862633 in OpenStack Compute (nova) "unshelve leak allocation if update port fails" [Medium,Fix released] https://launchpad.net/bugs/1862633 - Assigned to Balazs Gibizer (balazs-gibizer)
14:44:08 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Clean up allocation if unshelve fails due to neutron https://review.opendev.org/711629
14:46:37 gibi stephenfin: would be nice to get a second opinion on https://review.opendev.org/#/c/666245/ It seems to be working but I'm a bit affraid of what this change means on a busy deployment
14:55:50 stephenfin gibi: ack, will do
14:56:32 mloza I specificied cpu_models=x86_EPYC-IBRS in nova.conf but I keep getting this error ': Invalid: Config requested a custom CPU model, but no model name was provided'
14:56:54 mloza The model exist in /usr/share/libvirt/cpu_map/x86_EPYC-IBRS.xml
14:57:07 mloza This is in stable/stein
14:59:18 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030
14:59:19 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Connect RBD volumes to the compute host as block devices https://review.opendev.org/708029
15:28:36 johnthetubaguy mloza: I think stein only supports the option cpu_model: https://docs.openstack.org/nova/stein/configuration/config.html#libvirt.cpu_model
15:33:12 openstackgerrit Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/706295
15:37:13 mloza johnthetubaguy: yeah. I just noticed now. I was checking the latest docs of nova. I didn't know that they renamed cpu_model to cpu_models in the train release
15:47:28 openstackgerrit Merged openstack/nova master: Introduce scope_types in os-instance-action policy https://review.opendev.org/707751
15:56:36 stephenfin gibi: so what were your specific concerns for https://review.opendev.org/#/c/666245/ ?
16:15:40 stephenfin dansmith: Can this go ahead now? https://review.opendev.org/#/c/708707/ I'm guessing it's blocking the alembic upper-constraint bump (https://review.opendev.org/#/c/708706/)
16:15:58 dansmith I was just looking since I got the review email from you
16:16:11 dansmith I think this had to be tested against the bump,
16:16:17 dansmith and then again against the current version
16:16:21 dansmith so since it's passing now I guess?
16:16:37 dansmith prometheanfire: ^
16:27:22 prometheanfire we talking about the alembic thing?
16:27:33 prometheanfire I'm waiting on nova, so no blocker from me
16:28:00 dansmith prometheanfire: https://review.opendev.org/#/c/708707/4
16:28:43 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP/DNM zuul: Attempt to migrate and break up the nova-live-migration job https://review.opendev.org/711604
16:30:13 gibi stephenfin: that patch introduces a waitall call for the nova-compute stop codepath. So I can imagine it can change the timing of the nova-compute service restart scenarios in real deployments
16:31:27 stephenfin gibi: Yup. There will definitely be knock on effects. That's only for graceful shutdown though, so people could still force things, right?
16:31:27 gibi stephenfin: e.g. nova-compute will wait for the all the ongoing instances to boot up before it stops which could take significant time due to e.g. image download
16:31:44 gibi right, tooling can send kill signalls for sure
16:32:17 dansmith also probably long-running periodics, like resource update for lots of ironic nodes
16:32:41 stephenfin It's not unlimited though. Not by default
16:32:56 stephenfin I checked and graceful_shutdown_timeout defaults to a minute
16:32:58 dansmith no, it's not
16:33:16 dansmith actually, nevermind what I said about the resource update, because that does drop and re-acquire
16:33:19 stephenfin so at worst we're introducing an extra 60 second delay
16:33:36 dansmith stephenfin: where's the 60 second limit?
16:34:02 stephenfin dansmith: https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py#L51
16:34:06 dansmith is that something the service does?
16:34:26 stephenfin yeah, if this comment is to be believed https://review.opendev.org/#/c/666245/16/nova/compute/manager.py@1511
16:34:28 dansmith where's the implementation of that though?
16:34:50 dansmith https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L333
16:35:21 dansmith does it with sigalrm so should break us out of that otherwise infinite wait
16:37:25 gibi OK, so it is really just an extra 60 seconds delay
16:37:37 stephenfin that's my understanding, yes
16:37:50 stephenfin I think that's reasonable. We have a reno too
16:38:15 gibi I feel better that none of you freaked out about that patch.
16:38:23 dansmith I haven't really reviewed
16:38:27 dansmith can I have a few minutes?
16:38:32 gibi dansmith: sure
16:38:47 gibi dansmith: but you already know the basic idea of the patch
16:38:56 dansmith yeah
16:39:05 dansmith we already have a build semaphore and config for it
16:39:14 dansmith this would seem to complicate that a bit
16:40:06 stephenfin Does this need a microversion? https://review.opendev.org/#/c/709431/
16:40:46 stephenfin tl;dr: We've been using '/hypervisors' in our 'links' pagination field, rather than '/os-hypervisors'
16:41:11 gibi stephenfin: I think we don't want API users to opt into a bugfix
16:41:30 stephenfin yes, that's my thinking too
16:41:40 gibi this feels a clear bugfix to me
16:42:28 dansmith gibi: stephenfin: https://review.opendev.org/#/c/666245/16
16:43:36 stephenfin oh, I never even thought of that /o\ good spot
16:43:47 gibi dansmith: good catch
16:44:00 dansmith the change should be small.. just remove the new conf and the old semaphore, wire the group to the old conf
16:44:13 gibi yeah, make sense
16:45:15 gibi stephenfin: I'm +2 on the os-hypervisors bugfix
16:46:49 stephenfin gibi: Just checked and looks like os-keypairs is also wrong
16:47:13 gibi stephenfin: soo you won a bug to fix ;)
16:47:37 gibi dansmith: if you are in a reviewing mood then the last pieces of the qos bp needs a second core https://review.opendev.org/#/q/status:open+bp/support-move-ops-with-qos-ports-ussuri
16:48:14 dansmith gibi: I'm in a -1ing mood.. do you want to take that gamble? :D
16:49:05 gibi dansmith: if it is as valid -1 as on the graceful shutdown patch then please go ahead
17:03:15 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix os-keypairs pagination links https://review.opendev.org/711662
17:03:16 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Rename directory for os-keypairs samples https://review.opendev.org/711663
17:03:17 stephenfin gibi: ^
17:03:28 stephenfin (second one's just a nice-to-have)
17:03:43 gibi stephenfin: thanks, looking
17:04:33 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Fix hypervisors paginted collection_name. https://review.opendev.org/711664
17:05:00 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Fix hypervisors paginted collection_name. https://review.opendev.org/711664
17:05:08 dansmith gibi: https://review.opendev.org/#/c/705475/4/nova/api/openstack/common.py
17:08:02 openstackgerrit Stephen Finucane proposed openstack/nova stable/stein: Fix hypervisors paginted collection_name. https://review.opendev.org/711669
17:08:48 openstackgerrit Stephen Finucane proposed openstack/nova stable/rocky: Fix hypervisors paginted collection_name. https://review.opendev.org/711670
17:11:59 gibi dansmith: so you mean we need a service version bump even without RPC change.
17:12:29 dansmith gibi: you're depending on a behavior change on the compute nodes from the api node.. even though there's not an RPC signature change, you don't know when/if those computes can do what you're asking
17:14:45 gibi dansmith: yeah. you are right. without the compute side change the port binding won't be updated during unshelve.
17:15:18 dansmith this is really *why* we have service version.. the tie to RPC just makes it easier to ensure we can also look up rpc versions for auto pinning
17:16:40 gibi dansmith: in theory it would be the goal of the scheduler to select a host during unshelve that is capable of supporting the server with qos port
17:17:09 dansmith yeah, you could enforce it there too, but that seems messy-er
17:17:13 gibi dansmith: would it be a compute host capability?
17:17:26 dansmith you'd basically need a new filter or a trait

Earlier   Later