duplicate of https://bugs.launchpad.net/nova/+bug/1405131
** 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/1417595
Title:
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Confirmed
** Changed in: nova
Importance: Undecided => Low
** Tags added: network
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is s
Duplicate of https://bugs.launchpad.net/nova/+bug/1303360 which has been
merged
** 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
** Changed in: nova
Status: Triaged => Opinion
--
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/1357453
Title:
Resource tracker should create compute node record in
** Changed in: nova
Status: Opinion => Confirmed
--
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/1357453
Title:
Resource tracker should create compute node record
Related change https://review.openstack.org/#/c/189560/
** Changed in: nova
Importance: Undecided => Wishlist
** Changed in: nova
Status: Fix Released => In Progress
** Changed in: nova
Milestone: liberty-1 => None
--
You received this bug notification because you are a member of
Public bug reported:
2015-07-17 12:11:00.987 | ==
2015-07-17 12:11:00.987 | Failed 2 tests - output below:
2015-07-17 12:11:00.987 | ==
2015-07-17 12:11:00.987 |
2015-07-17 12:11:00.988 |
nova.tests.unit.virt.hyperv.test_vhdutils.VHDUtilsTe
#x27;', 'Accept': 'application/json'}
2015-09-04 11:41:29.480 | Body: None
2015-09-04 11:41:29.480 | Response - Headers: {'content-location':
'http://127.0.0.1:8774/v2.1/9ebd4b4550754530b3decbd1eff3f9a3/os-tenant-networks',
'x-openstack-nova-api-version': '2.1',
Okay, so I feel the bug should be marked as Invalid. Why ? Let me
explain :
While any instance can be shown with an AZ, it doesn't mean that the
instance.az field is set with that value but rather showing the value of
CONF.default_availability_zone if that field is left blank.
How to the instanc
Public bug reported:
In
https://github.com/openstack/nova/commit/9db1642e867deb2bea54a3c1a76e52b0480cc30c
we missed to provide a list instead of None, so six.iteritems() can
provide an Exception.
** Affects: nova
Importance: High
Assignee: Sylvain Bauza (sylvain-bauza)
Status
Assignee: Sylvain Bauza (sylvain-bauza)
Status: New
** Tags: cells
--
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/1438601
Title:
Cells Response serialization
Duplicate of https://bugs.launchpad.net/nova/+bug/1438514
** Changed in: nova
Status: In Progress => Invalid
** Changed in: nova
Milestone: kilo-rc1 => None
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Com
I would rather mark it as invalid now that the design changed.
I really would like to keep fix committed to match with Gerrit changes
** Changed in: nova
Status: Fix Committed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is s
Public bug reported:
The API RBAC is done using a policy.json file which allows fine-grained control
over each API endpoint by setting specific rules.
Consequently, some defaulted admin-only endpoints can be opened by modifying
their corresponding policy rules to be for anyone.
Unfortunately, i
ation check should be removed.
** Affects: nova
Importance: Medium
Assignee: Sylvain Bauza (sylvain-bauza)
Status: New
** Tags: conductor
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
Not sure something needs to be fixed on Nova. Please change the status
back to New if you think yes and explain why.
** 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 Compu
Not sure I understand but this is the pattern for any unique key we add
: since we don't remove any row from a table but just updates the
deleted col, we need to make sure that 2 or more same rows are accepted.
** Changed in: nova
Status: New => Invalid
--
You received this bug notificat
Not sure it's Nova related, since the connection is managed by MySQLdb here.
That's all due to the configuration done on SQLA like said in
http://docs.sqlalchemy.org/en/rel_1_0/core/engines.html
Please check your "connection" option for the nova.conf file as this is
how it's called.
** Changed i
Not sure it's a bug (even wishlist), you should create a blueprint
instead.
** 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/bug
As discussed on IRC, the issue you mention comes from the fact that
default_schedule_zone conf flag is set to None by default.
As it's defaulted to None, then the instance has no AZ unless the user
specifically asks for one, so the AZFilter doesn't care about it.
If you want to have a default AZ
It's not a bug as it is explained : there is no current way to rescue a
volume-backend instance, even with the latest code.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStac
** 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/1453675
Title:
Live migration fails
Status in OpenStack Compute (Nova):
I don't think it's a problem, that just means the method took more time
than the periodic one. Can you see it repeatively ?
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStac
Nova is only user of oslo.log, there is nothing in Nova that can be
changed for fixing that.
** 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.
Bill, the logging capabilities are managed by the oslo.log library that
Nova is pulling. All the options you showed in the bug desc are related
to that package, not coming from internal Nova configuration flags (even
if defined in nova.conf)
** Changed in: nova
Status: New => Invalid
--
Not sure it's a Nova problem but rather a MySQLdb problem as per the
log. Could you please try to see the config differences between the 13
good nodes and this one ?
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Status: Opinion => Incomplete
--
You received this
Sorry but this is not a bug, that just means the spec is not fully
complete. In order to do that, please repropose the missing bits in a
separate spec (and blueprint) for Liberty
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Y
nova.scheduler.ibm.ego.ego_manager is not an upstream module
** 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/1456871
Titl
Sorry, hitted tab too fast.
So, was saying that in general, we recommend to run 'nova reset-state
' to set the state to the desired option and then delete it again.
Could you please try it ?
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are
Public bug reported:
For some reason not yet identified, local master branches fail with this
check
==
FAIL:
nova.tests.unit.objects.test_objects.TestObjEqualPrims.test_object_not_equal
--
Just wondering if the solution has to be part of Nova. Are you thinking
of any check in Nova verifying that the instance is running before
calling libvirt ?
** Changed in: nova
Status: New => Opinion
** Tags added: libvirt
--
You received this bug notification because you are a member of
@Kashayp, fair point, we should then prevent Nova to call libvirt if the
instance is not in a correct state.
** Changed in: nova
Status: Opinion => Triaged
** Changed in: nova
Importance: Undecided => Low
** Tags added: low-hanging-fruit
--
You received this bug notification because
But tox.ini has both requirements.txt and test-requirements.txt as
dependencies, so you need to pull all the packages.
** Changed in: nova
Status: New => Invalid
** Changed in: oslo.config
Status: New => Invalid
--
You received this bug notification because you are a member of Yah
The TrustedFilter filter actually doesn't check by itself but rather
calls the Attestation API to know if the destination host is correct or
not. That way, it's just when the instance is scheduled that it goes to
the scheduler, then finds an acceptable destination (so calls the
Attestation API for
Public bug reported:
http://logs.openstack.org/28/145528/22/check/gate-nova-
python27/a818283/console.html
2015-06-23 14:13:01.268 | ==
2015-06-23 14:13:01.268 | Failed 1 tests - output below:
2015-06-23 14:13:01.268 | ==
2015-06-23 14:13:01
Public bug reported:
Base class for tests is not providing helpers for managing mock objects
as it does for mox ones (self.mox)
At the moment, the only way to create a mock object and use it is to
decorate a test method which is not handy and doesn't allow new
contributors to cleary identify that
Public bug reported:
At the moment, Ironic and Blazar gates are failing because of the recent
release of python-keystoneclient-0.9.0 which is raising this kind of trace :
2014-05-30 01:10:13.433 | Traceback (most recent call last):
2014-05-30 01:10:13.434 | File
"/home/jenkins/workspace/gate-b
Fix has to be provided on Blazar side.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1324861
Title:
Pythonclient middleware auth'
I'm tagging the bug as Invalid, as it would require to write a spec file for
explaining the change you want to provide.
That's IMHO not a bug, rather a feature request, see
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
** Changed in: nova
Sta
So, it's pretty hard to explain in one small comment how the model is
behaving, but please consider that we have 'sort of' two-phase commits
when booting an instance.
When a request comes in, you're right, the instances are elected
iteratively by decrementing the resource usage of the elected node
FWIW, I'm changing the tags to match the implementation.
So, that's an expected behaviour, see
https://github.com/openstack/nova/blob/875594ad26da46c773892a901511547b86a9568c/nova/scheduler/host_manager.py#L515-L518
When providing a request using the --az hint, it goes into the Compute API
where
ject is not iterable
http://logs.openstack.org/05/226805/2/check/gate-ironic-inspector-
dsvm/5cd5071/logs/screen-n-cond.txt.gz?level=WARNING
** Affects: nova
Importance: Critical
Assignee: Sylvain Bauza (sylvain-bauza)
Status: In Progress
** Tags: liberty-rc-potential low-han
Public bug reported:
gate-tempest-dsvm-large-ops error rate is spiking since the last 24
hours (http://goo.gl/G9Zazy) with the following stacktrace :
2015-09-28 15:02:50.954 | Traceback (most recent call last):
2015-09-28 15:02:50.954 | File "tempest/test.py", line 127, in wrapper
2015-09-28 15
I feel that request for feature would need a huge effort for changing
the current situation and would be better provided as a blueprint, see
that wikipage for more explanation :
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_get_my_code_merged.3F
** Changed in: nova
Imp
** Changed in: nova
Importance: Undecided => High
** Changed in: nova
Status: New => Confirmed
** Also affects: python-novaclient
Importance: Undecided
Status: New
** Changed in: nova
Status: Confirmed => Invalid
** Changed in: python-novaclient
Status: New =>
I'm really not sure what needs to be done in Nova to fix that problem.
Feel free to reopen the bug to New if you come up with a described
description of any Nova-related issue coming in.
** Changed in: nova
Status: New => Invalid
** Changed in: nova
Status: Invalid => Opinion
--
Y
So, my take on that is that this is not technically a bug, rather a
current limitation (hence Opinion/Wishlist)
That needs at least a blueprint to be created and possibly some
discussion around the implementation design, see
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_do_I_ge
Public bug reported:
There is still one place where the Scheduler does direct DB access
instead of using the oslo.versionedobjects layer
https://github.com/openstack/nova/blob/af2d6c9576b1ac5f3b3768870bb15d9b5cf1610b/nova/scheduler/driver.py#L54
Instead of calling db.service_get_all_by_topic(),
Public bug reported:
It seems that all gate-tempest-dsvm-cells runs against the liberty
branch fail because of
2015-11-16 04:50:15.334 | ==
2015-11-16 04:50:15.334 | Failed 1 tests - output below:
2015-11-16 04:50:15.334 | ==
2015-11-16 04:5
Invalid
** Changed in: nova
Assignee: Sylvain Bauza (sylvain-bauza) => (unassigned)
--
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/1376751
Title:
This change requires a spec as it involves DB migrations
** Changed in: nova
Status: In Progress => 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/1357491
The mirror URL is incorrect, it should be
"http://pypi.openstack.org/openstack/";
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/121398
We assume by design that the AZ information is only a specific key/value
pair of the metadata dict (where the key is 'availability_zone').
Trying to access the AZ info if the metadata field is unset goes against
that design decision because it makes no sense to persist it differently
at the object
I actually opened a blueprint for that feature request. Since it's a
scheduler-related effort, it is part of our Nova Priorities so it's not
impacted by the non-priority Feature Freeze for Mitaka.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification bec
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).
ht
** 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 r
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 Wont
*** 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
--
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
St
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 rece
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 #openstack
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 HTTP5
** 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
Sta
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 Co
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 recei
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 need
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!
E
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.
https://bugs.l
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 is
*** 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. (H
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 servi
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
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
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]
https://docs.openstack.org/nova/latest/reference/api-micro
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: nova
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 n
Tons of connection exceptions in the n-cpu logs. Looks like you
misconfigured it.
2020-04-12 23:29:01.150 10350 CRITICAL nova
[req-51f5a237-fddc-4298-92fb-0b09b134b85c - - - - -] Unhandled error:
ConnectFailure: Unable to establish connection to
http://10.0.0.11:5000/v3/auth/tokens: HTTPConnect
Looks a valid bug for Cinder (or at least some kind of Glance<->Cinder
interlaced issue).
Either way, moving it to the cinder team.
** Project changed: nova => cinder
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Comp
This is intended by design : we don't want the compute manager to
hardstop on an exception, but we rather want to have the instance going
into an ERROR state with the proper exception handling [1]
Since the libvirt driver exposes the fact that it can't resize on the
same host, that's why allow_res
** 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/1863107
Title:
Stein->Train Upgrade : Old nova services not cleaned
Sta
>From what I've seen, nova just tries to use the configured token section
for calling the Cinder API thru cinderclient and this doesn't work.
FWIW, you probably have a misconfigured [cinder] section in nova.conf
and if you use Fernet tokens, please read
https://docs.openstack.org/keystone/pike/adm
I'll close this bug for keeping our bug tracking correct. Feel free to
mark this bug as duplicate if you created another bug.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed t
This sounds a very interesting usecase for discussion. Obviously more
something we should discuss at a PTG instead of within a Launchpad bug
;)
FWIW, I'll close this bug as Invalid/Wishlist but I still think this
usecase deserves a proper brainstorming session, hence a blueprint once
we see some i
Moving this bug to Neutron so they could triage it.
FWIW, Nova has a difference between display_name and hostname BECAUSE we don't
want to change the server's hostname when created since people can just
recreate another instance with another name if they really will, so instead of
modifying an i
Honestly, I don't know what to say from a Nova side if cloud-init isn't
correctly running on the guest.
The only interaction that would impact Nova would be the metadata
service, which could be unavailable, or, or... but if the guest just
doesn't run cloud-init and with other official images it do
** Also affects: nova/stein
Importance: Undecided
Status: New
** Also affects: nova/ocata
Importance: Undecided
Status: New
** Also affects: nova/pike
Importance: Undecided
Status: New
** Also affects: nova/ussuri
Importance: High
Assignee: Mark Goddard (mgo
OK, I have a better understanding on what we manage in Nova.
So, in order to prevent intensive I/O operations to compete, we recently
added in https://review.opendev.org/#/c/609180/ a new compute semaphore
that would hold competitive accesses to disk within Nova thru a
configuration option.
In ou
I honestly don't see any evidence of some broken behaviour in Nova if,
particularly, other instances with other guest image using cloud-init
can boot correctly.
Please provide us some logs or better trace of a potential Nova problem
in order for us to classify the potential root cause and a possib
OK, I'm going to close this bug as Invalid since it appears as a
configuration issue. This being said, feel free to provide such
credentials to nova.conf and test again to see if that resolves your
issue. If that doesn't, please reopen the bug [1] with another
stacktrace that would help us to bette
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.
** Chang
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, the
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 21.
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.
I
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: Sylvain B
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 b
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 error
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 m
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
-x. 2 root root0 Sep 23 06:01 devices
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
/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
1 - 100 of 287 matches
Mail list logo
