As said by the exception, your certificates are invalid. Please double-check
your configs.
This isn't a Nova bug, rather a configuration problem, closing the report.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
This is a known issue that we recently fixed by ensuring that you can't
change the hostname silently :
https://specs.openstack.org/openstack/nova-
specs/specs/2023.1/implemented/stable-compute-uuid.html
That series won't be backported to Zed so I'd recommend you to upgrade
to Antelope. In the
Seems to me a neutron issue, moving the bug report to the proper
project.
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
The exception comes from OSC, moving the bug report to that project.
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
As discussed on the nova meeting, nova-grenade-multinode is no longer
failing, so I'll close this bug report only for Nova.
** Changed in: nova
Status: Confirmed => Invalid
** Changed in: nova
Status: Invalid => Won't Fix
** Changed in: nova
Importance: Critical => Low
--
You
Doesn't look to me a Nova bug, maybe a Kolla one. Moving this report
then.
** Also affects: kolla
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Are you sure you also upgraded Neutron ? Apparently, the Neutron
metadata agent tries to call the neutron server by RPC but the server
doesn't support the RPC version from the agent.
Doesn't look to me a problem from Nova, so I'll close this bug report
but please reopen it if you find some
This isn't a Nova bug, maybe some oslo.messaging problem, but anyway, as
the nova-compute service will be off, then the servicegroup API wouldn't
accept it for the scheduler, so this shouldn't be a problem.
** Also affects: oslo.messaging
Importance: Undecided
Status: New
** Changed
As you can see on the exception, this is not a Nova bug. Keystone just
tells you 'sorry, it's forbidden' so maybe you have some wrong
configuration for it. Eventually, as I said, as this is not a Nova bug,
closing this report.
** Changed in: nova
Status: New => Invalid
--
You received
Fabian, do you want some kind of root cause analysis ? If so, I'd prefer if you
could ping us in the nova channel rather than creating a bug report.
Once you know why you get this exception, you could reopen this bug report if
you want to explain why it's having a problem, but for the moment,
Looks to me it's more a feature question, not a bug.
Which problem do you have ?
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Ironic nodes are seen exactly as nova-compute libvirt nodes. If you want
to avoid them, you need to use aggregates.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
This appears to me a configuration issue as said in the exception :
Error Cannot apply both stateful and stateless security groups on the same
port at the same time while attempting the operation.,
Neutron server returns request_ids:
['req-1007ffaa-3501-4566-9ad9-c540931138f0']
I don't think
Fixed by https://review.opendev.org/c/openstack/nova/+/899406/2
** Changed in: nova
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Please reopen the bug report by changing the status back to new if you
think it's related to Nova.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
As you said, this is due to a connection error :
https://controller/identity looks to not be able for your environment.
Are you sure this URL is right?
Anyway, not a nova bug.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of
As you can see here, this is a messaging timeout :
f8c11b038ef198fc0 d865adb13a8d4c15b7a4c07f040efdc5 - - default default]
Unexpected exception in API method: oslo_messaging.exceptions.MessagingTimeout:
Timed out waiting for a reply to message ID c44ae10b2f774b428763a1d11368cb16
2023-11-27
Public bug reported:
This is hard to summarize the problem in a bug report title, my bad.
Long story short, the case arrives if you start using nVidia SR-IOV next-gen
GPUs like A100 which create Virtual Functions on the host, each of them
supporting the same GPU types but with a specific
This is indeed not a bug report, please don't create bug reports for
this kind of internal points.
** Changed in: nova
Status: New => Invalid
** Changed in: nova
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Yahoo!
Engineering
** Changed in: nova
Status: In Progress => Invalid
** Changed in: nova
Status: Invalid => Fix Committed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Probably due to the recent merge of
https://review.opendev.org/c/openstack/nova/+/882284
Now, when rebooting, we call the Cinder API for checking the BDMs so it
could be needing more time.
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification
Seems to be a regression coming from the automatic rebase of
https://github.com/openstack/tempest/commit/eea2c1cfac1e5d240cad4f8be68cff7d72f220a8
** Also affects: tempest
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug
Changing the bug importance to High as the fix is merged in master
https://review.opendev.org/c/openstack/nova/+/887674
Keeping the stable branches status to Critical since the backports
aren't merged yet.
** Changed in: nova
Importance: Critical => High
** Changed in: nova
Status: In
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Confirmed
** Changed in: nova
Importance: Undecided => High
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of
File
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor could not be found.
Jun 05 14:47:45 sbauza-dev2 nova-compute[75181]: ERROR oslo_service.service
Let's just to support the CPU state if so.
** Affects: nova
Importance: Low
Assignee: Sylvain Bauza (sylvain-bauza)
path) from exc
Jun 05 16:18:49 sbauza-dev2 nova-compute[76374]: ERROR oslo_service.service
nova.exception.FileNotFound: File /sys/devices/system/cpu/cpu1/online could not
be found.
Jun 05 16:18:49 sbauza-dev2 nova-compute[76374]: ERROR oslo_service.service
** Affects: nova
Importance: Undecided
A
I left a very large comment on Gerrit but I'll add it here for better
visibility.
FWIW, I think the problem is legit and needs to be addressed. I'm gonna
change the title and the subject to make it clearer but I also think
that the solution isn't simple at first and requires some design
While I understand your concern, I think you missed the intent of
default_availability_zone
This config option is not intended for scheduling instances, but rather
for showing off by default one AZ if none exists.
With your environment, you could just decide to define any existing AZ
as
deec903c340a19e - default default] Starting to schedule for
instances: ['412ca82a-06a4-40d9-b12d-08c56a78c5a9'] select_destinations
/usr/lib/python3.9/site-packages/nova/scheduler/manager.py:124
** Affects: nova
Importance: Low
Assignee: Sylvain Bauza (sylvain-bauza)
Status: Confirmed
** T
This is an expected behaviour, as you can read in
https://docs.openstack.org/nova/latest/admin/availability-
zones.html#resource-affinity
If an instance is not pinned for a AZ [1] and if cross_az_attach is equal to
True, then the instance can float between *all* Availability Zones.
We only pin
Closing this bug report as we said in the PTG that we don't have any
cycle themes for Bobcat.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Can you add more details about your problem ?
At least, I see a MessagingTimeout from the logs, so I'm pretty sure
this isn't a Nova bug, rather a configuration issue.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
This is a wikipage, you can just update it directly.
Closing this bug report as it's not needing to have a Gerrit change.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
This looks to me that the servicegroup API wasn't able to query the DB
to find the compute state value. For some reason, the conductor can't
connect to the DB.
Anyway, closing this one as this is not related to a project development
bug.
** Changed in: nova
Status: New => Invalid
--
You
It looks your environment is not able to call the Neutron API, hence the
exception.
Sorry, but this is not a nova bug report, hence me closing it.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
Sorry Amit, you maybe missed the point. Those URLs are actually fake,
those are just examples for explaining what you need to do when you
create a Launchpad feature.
For https://review.opendev.org/q/status:open+project:openstack/nova-
specs+message:apiimpact that just means that we don't have any
Well, I don't really know about the root cause and why the
map_instances() wasn't adding the cell UUID directly when it created the
record here first. Now we have a transaction like Mohamed said so it
shouldn't be a problem.
Closing this bug report now.
** Changed in: nova
Status:
Honestly, I don't know what to say here. When the query parameter was
added, it was just for a convenient purpose for operators to prevent
them to query Neutron first to get the list of ports but this was
actually some kind of orchestration we try to avoid.
Keeping in mind that an instance can be
Okay, I did a bit of digging today for some other CI failure I saw on
another change and eventually, I found this was related.
So, lemme explain the issue here. First, I was looking at
Moving the Nova status of the bug to Fix Released as
https://review.opendev.org/c/openstack/tempest/+/871000 fixed the root
cause for the failing nova jobs.
** Changed in: nova
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
** Also affects: glance
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/2004641
Title:
ImageLocationsTest.test_replace_location fails
Public bug reported:
Saw a new gate failure happening a couple of times :
https://review.opendev.org/c/openstack/nova/+/871612 is now merged,
putting the bug report to Fix Released.
** Changed in: nova
Importance: Undecided => Critical
** Changed in: nova
Status: New => Confirmed
** Changed in: nova
Status: Confirmed => Fix Released
--
You received
FWIW, I created another change that was running this test *earlier*, and
it worked :
https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_362/870924/2/check/nova-
ceph-multistore/3626391/testr_results.html
That being said, this test tooked more than
Looks like nova-compute service is unable to talk to the libvirt API.
Definitely a config issue, closing this bug.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Public bug reported:
We agreed during the Nova 2023.1 Antelope PTG to modify the behaviour of
evacuate which would *not* start the instance. This requires an API
microversion.
** Affects: nova
Importance: Wishlist
Status: Triaged
** Tags: low-hanging-fruit rfe
--
You received
Public bug reported:
Nova compute services use the privsep library [1] for specific 'root'
privilege usage for a command or a direct call to the system.
Unfortunately, our current usage we do from this library is not really a
good recommendation : instead of using a sysadmin context that uses
Public bug reported:
This is a tracking rfe bug to enable the use of the OpenStack SDK when
calling cinder.
This is in aid of allowing cinder to deprecate and eventually remove
cinder client in a future release by removing nova dependency on it.
** Affects: nova
Importance: Wishlist
Looks to me not a Nova issue, maybe just a devstack issue or a
configuration problem. Moving it then to devstack.
** Also affects: devstack
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a
Master patch : https://review.opendev.org/c/openstack/nova/+/858236
** Also affects: nova/zed
Importance: Critical
Status: In Progress
** Changed in: nova/zed
Importance: Critical => High
** Changed in: nova/zed
Assignee: (unassigned) => Thomas Goirand (thomas-goirand)
--
Putting the bug to Opinion/Wishlist as this sounds half a Nova problem
(since we set the chmod) and half a distro-specific configuration.
I'm not against any modification but we need to correctly address this
gap as a blueprint ideally.
** Changed in: nova
Status: Triaged => Opinion
**
Setting to High as we need to bump our requirements on master to prevent
older releases of oslo.concurrency.
Also, need to backport the patch into stable releases of
oslo.concurrency for Yoga.
** Also affects: nova/yoga
Importance: Undecided
Status: New
** Changed in: nova/yoga
OK, I maybe mistriaged this bug report, as this is specific to the
Ampere architecture with SR-IOV support, so nevermind comment #2.
FWIW, this hardware support is very special as you indeed need to enable VFs,
as described in nvidia docs :
As we have proof of the issue being due to os-vif 3.0.0 release,
changing the Nova status to Invalid.
** Also affects: os-vif
Importance: Undecided
Status: New
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of
Unfortunately, this doesn't look a Nova issue : this is either an
oslo.messaging bug or rather a configuration issue.
Closing this bug for Nova.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
If you see some compute flapping due to some network issue, you can force it to
be down :
https://docs.openstack.org/api-ref/compute/?expanded=update-forced-down-detail#update-forced-down
Once the compute is down (because either it's forced down or by the
service group API), indeed you can
Marking the bug as WONTFIX as we fixed the root cause in the Yoga
release.
** Changed in: nova
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
You're asking to shrew the disk from 160GB to 100GB and that's something
we don't support.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
We discussed this during the previous Nova meeting and we agreed on the
fact this is a correct issue, but we need to deprecate the generation
API (and continue to accept to import the public keys).
As this means a new API microversion, we need a spec for it so we'll
discuss this during the next
Looks to me a config issue, not a project bug.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1962381
Title:
Nova
This doesn't sound a Nova project-specific bug, rather a config issue
for a specific OS/arch.
AFAIK, you need to use CentOS AArch64 images for the RPi.
Anyway, closing the bug.
** Changed in: nova
Status: New => Incomplete
** Changed in: nova
Status: Incomplete => Invalid
--
You
No, it's just calling the API DB.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1964097
Title:
Questions about the
You need to give us more logs in order to understand what the issue is.
Looks to me it's not a bug, rather a configuration issue.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1959682
Title:
String concatenation TypeError in resize
This is expected behaviour. As we assume that we can only evacuate when
a nova-compute service is down, there are no ways for the nova-compute
service to ask Placement to remove those allocations.
That's only when nova-compute is back up that we can delete those
allocations. We also provide some
I'm not sure I'd classify it as a bug. Probably a good thought so, so
marking it Invalid/Wishlist but I'm open to thoughts.
To answer your question, now that we have an hardstop blocking nova
services to restart if there are old enough, this sound a legit
blueprint to address.
** Changed in:
As we document in our API docs, this /os-security-groups API resource is
now deprecated [1] since API microversion 2.36 [2] which is shipped with
the Newton release
[1] https://docs.openstack.org/api-ref/compute/#create-security-group
[2]
If I understand correctly which module has this issue, this is about
hacking.py.
@dw1s, you tell this is before SHA1
8f250f50446ca2d7aa84609d5144088aa4cded78 but I can't find it in the nova
repo.
Either way, this hacking.py module isn't run by our services and is just
used by our PEP8 jobs, so I
Yeah, I'll put it to the Neutron team to ask them to look at this bug.
In case they say it's a Nova bug, please modify the nova status to "New" again.
Thanks.
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Opinion
--
You received
OK, let me get it right.
You say that if you want to evacuate an instance, you don't really know whether
the original service runs correctly, right?
That's basically why Nova verifies whether the host is not operational and
somehow 'failed'.
Sometimes, you're right, Nova thinks the compute
*** This bug is a duplicate of bug 1947825 ***
https://bugs.launchpad.net/bugs/1947825
** This bug has been marked a duplicate of bug 1947825
503 Service Unavailable: The server is currently unavailable. Please try
again at a later time.: The Keystone service is temporarily unavailable.
Looks a configuration issue from Keystone. Not really a Nova bug : the
nova-api service tells you that the Keystone API service is not
available.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
This looks a glanceclient issue, nope ?
** Also affects: glance
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
This is not a bug, rather a feature request.
If the instance is in ERROR, why should you want to modify the tag ?
** Changed in: nova
Importance: Undecided => Wishlist
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
We discussed this bug report during the latest Asian-friendly Nova
meeting [1] and we agreed on the fact this report is about asking Nova
to support iPXE, as for the moment Nova doesn't really expose it for the
moment, even if libvirtd does this.
Please provide a blueprint for explaining your
You need to use aggregates if you want to use different storage backends
per compute.
For what's it worth, if you really want to have the scheduler having a
way to verify storage backends, that would be a new feature and not a
bug.
** Changed in: nova
Status: New => Invalid
--
You
This looks to me an unrelated issue for the Nova repository. This rather
looks to me an issue with the Ubuntu packages.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
** Changed in: nova/yoga
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1944111
Title:
Missing __init__.py in nova/db/api
Public bug reported:
The nova-lvm job seems to fail for every change [1] which prevents us to
merge any change touching nova/virt/libvirt [2]
All failures seem to relate to the same Tempest tests (6 of them)
failing with the same problem : a Glance image upload issue as Glance
API returns a
Fixing unit tests or tech debt concern don't really need to have bug reports.
That's also why we have Gerrit, for discussing whether the debt fix is good or
not.
So, instead of discussing here about what to do, please upload a new change
fixing what you want and ask us to review it by
Victoria backport candidate :
https://review.opendev.org/c/openstack/nova/+/784907
** Also affects: nova/victoria
Importance: Undecided
Status: New
** Changed in: nova/victoria
Status: New => Confirmed
** Changed in: nova/victoria
Importance: Undecided => Medium
--
You
You shouldn't disable the host by calling the host API, but rather
either waiting for the periodic verification (indeed, around 60 secs) or
calling the force-down API.
https://docs.openstack.org/api-ref/compute/?expanded=update-forced-down-
detail#update-forced-down
** Changed in: nova
*** This bug is a duplicate of bug 196 ***
https://bugs.launchpad.net/bugs/196
Marking this bug report as duplicate, so we can directly backport the
change down to stable/victoria.
** This bug has been marked a duplicate of bug 196
Asking for different vGPU types is racey
--
While I understand your concern, the nova community has a consensus
about telling that nova services shouldn't verify the status of Rabbit
MQs and those should expect that MQs are working.
Given there are workarounds for removing the attachment in case you had
a failure, I'll move this bug to
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Confirmed
** Changed in: nova
Importance: Undecided => Critical
** Changed in: nova
Assignee: (unassigned) => Lee Yarwood (lyarwood)
** Tags added: wallaby-rc-potential
--
You
putting it as invalid as we can't really help here, but in case I'm
wrong, please punt it again as New.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
with the compute='auto'
default value as this value will elect to automatically pin a version
that both the source and destination can support.
** Affects: nova
Importance: Critical
Assignee: Sylvain Bauza (sylvain-bauza)
Status: Confirmed
** Affects: nova/victoria
_get_supported_vgpu_types()
** Affects: nova
Importance: Medium
Assignee: Sylvain Bauza (sylvain-bauza)
Status: Confirmed
** Tags: libvirt vgpu
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https
** Changed in: nova/ussuri
Status: New => Confirmed
** Also affects: nova/victoria
Importance: Low
Assignee: Sylvain Bauza (sylvain-bauza)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscri
/train
Importance: Undecided => Low
** Changed in: nova/train
Assignee: (unassigned) => Sylvain Bauza (sylvain-bauza)
** Changed in: nova/ussuri
Assignee: (unassigned) => Sylvain Bauza (sylvain-bauza)
--
You received this bug notification because you are a member of Yahoo!
E
evices
When looking at the kernel driver API documentation
https://www.kernel.org/doc/html/latest/driver-api/vfio-mediated-
device.html it says that the "name" attribute is optional:
"name
This attribute should show human readable name. This is optional
attribute."
The
While I totally understand the use case, I think this is a new feature
for performance reasons and not a bug. CLosing it as Wishlist but of
course you can work on it if you wish ;)
** Changed in: nova
Importance: Undecided => Wishlist
** Changed in: nova
Status: New => Invalid
--
You
This was a known issue that should have been fixed by
https://review.opendev.org/#/c/715489/ which was merged during the
Ussuri timeframe.
For being clear, since mdevs disappear when you reboot, Nova now tries
to find the already provided GPU by looking at the guest XML.
Closing this bug as the
This sounds a configuration issue :
2020-09-10 14:27:50.134 3545 ERROR nova.api.openstack.wsgi
[req-2c75be17-d5c4-4acd-a302-326388068067 170fdf1f861847fa995f2f0646ec4143
85dd9df42f4e47b3b0fc5848ab947b62 - default default] Unexpected exception in API
method: MigrationError_Remote: Migration
Now that the minimum versions for Ussuri are libvirt 4.0.0 are QEMU 2.1,
I think we can close this one unless libvirt 4.0.0 with QEMU 2.5 have
the same issues.
Please open this one again if you see this.
** Changed in: nova
Status: New => Won't Fix
--
You received this bug notification
sh query :
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22testtools.matchers._impl.MismatchError%3A%202%20!%3D%201%5C%22%20AND%20build_name%3A%5C%22nova-tox-functional-py36%5C%22
8 occurrences over 7 days.
** Affects: nova
Importance: High
Assignee: Sylva
In Stein, we merged the ability to have multiple Resource Providers, each of
them being a pGPU.
In Ussuri, we accepted to have a specific vGPU type per pGPU.
Now, I tested the above behaviour with https://review.opendev.org/723858
and it works now, unless you ask for a specific total capacity.
Given we are after RC1 (which means that we only accept regression
bugfixes for RC2 and later versions), I think we should just document
the current caveat in https://docs.openstack.org/api-guide/compute
/accelerator-support.html and trying to backport the bugfix for a later
Ussuri release (say
This is indeed fixed upstream, as you can see in the source code there
https://github.com/openstack/nova/blob/2cddf595a8cdedbdb844e800d853ea143817b545/nova/compute/manager.py#L721-L738
We only delete instances if the evacuation was either done, or just precreated.
If the migration wasn't good,
I'm happy the main root cause is fixed (deleting the source disks).
To be clear, you can configure to resume guest states on compute service
restarts with the flag
https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.resume_guests_state_on_host_boot
Closing the bug.
**
1 - 100 of 285 matches
Mail list logo
