Reviewed: https://review.opendev.org/753302
Committed:
https://git.openstack.org/cgit/openstack/ovn-octavia-provider/commit/?id=76b20882aa9fef3c693e45c2b504224a44e84ce8
Submitter: Zuul
Branch:master
commit 76b20882aa9fef3c693e45c2b504224a44e84ce8
Author: Brian Haley
Date: Tue Sep 22 08:34
As background, adding libvirt-qemu user to the nova group was an attempt
to make /var/lib/nova/* directories more restricted, but that proved to
be difficult with ownership changes between changes nova and
libvirt/qemu.
** Summary changed:
- Creation of image (or live snapshot) from the existing
This is caused because the libvirt-qemu user is added to the nova group
as part of the nova-compute-libvirt package post-install script.
Following up on comment #17 above, the user/group of the delta file
changes from nova:nova to libvirt-qemu:kvm, whereas in comment #21
above, the user/group of t
** Changed in: masakari
Status: In Progress => Fix Released
** Changed in: masakari
Milestone: None => 10.0.0.0rc1
** Changed in: masakari
Assignee: ZHOU LINHUI (zhoulinhui) => Radosław Piliszek (yoctozepto)
** Also affects: masakari/victoria
Importance: Undecided
Assigne
adding devstack also as devstack needs to move to opensuse 15.2[1] which
has qemu 4.2.0 available
also move jobs to run on opensuse 15.2 will fix this.
[1]https://github.com/openstack/devstack/blob/5aa38f51b3dd0660a0622aecd65937d3c56eedc2/stack.sh#L224
** Also affects: devstack
Importance: U
Public bug reported:
Nova bumped minimum qemu version to 4.0.0 [1]. It seem that the
devstack-platform-opensuse-15 non-voting job has older qemu version than
that. Therefore nova-compute service does not start[2].
[1] https://review.opendev.org/#/c/746981
[2]
https://a5f2733c1907b1f26b90-5593d50
** 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 subscribed to O
I'm still really confused by this but some thoughts on the nova
os.chmod() call mentioned in an earlier commit that would fix this.
If I chmod the tmp dir that gets created by nova (e.g.
/var/lib/nova/instances/snapshots/tmpkajuir8o) to 755 just before the
snapshot (after the nova chmod), the snap
just adding the previous filed downstream redhat bug
https://bugzilla.redhat.com/show_bug.cgi?id=1852110
this can happen in queens for context so when we root cause the issue
and fix it it should like be backported to queens. tjere are other older
bugs form newton that look similar related to unsh
Public bug reported:
As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1772106,
between Queens and Train there was a performance degradation in the port
listing operation.
This could be caused because of the port DB object new relationships
(portuplinkstatuspropagation) or new extensions
Public bug reported:
Name: cloud-init
Version : 20.2-1
Code in questioning: cloudinit/config/cc_mounts.py
try:
create_swap(fname, size, "fallocate")
except util.ProcessExecutionError as e:
LOG.warning(errmsg, fname, size, "dd", e)
Public bug reported:
With current router configuration set by neutron, a number of logical
flows in lr_in_arp_resolve seems to have O(n^2) scaling where n is a
number of routers connected to the external network, for example this is
our test where we created 800 routers (I believe it was 800, and
Reviewed: https://review.opendev.org/721992
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=d403b31d70e06d784bc644c525e89a7e1b0b549d
Submitter: Zuul
Branch:master
commit d403b31d70e06d784bc644c525e89a7e1b0b549d
Author: Ivan Kolodyazhny
Date: Wed Apr 22 17:41:13 2020
Public bug reported:
* High level description:
I've been attempting to enable Fedora 32 support in devstack and
encountered the following issue where dnsmasq as configured by q-dhcp
isn't responding to DHCP requests from clients:
https://review.opendev.org/#/c/750292/
Looking at tcpdump and str
Reviewed: https://review.opendev.org/734814
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=a4a549a1814a9ea9f142fd8ec5928fe9cfebc269
Submitter: Zuul
Branch:master
commit a4a549a1814a9ea9f142fd8ec5928fe9cfebc269
Author: pedh
Date: Wed Jun 10 18:18:00 2020 +0800
Public bug reported:
This was found as a UT regression failure in the x/group-based-policy
project, but I think the same issue applies to the auto-allocated-
topology workflow (or any feature that creates a network at the plugin
or DB layer instead of at the REST layer). The exception seen is this
Public bug reported:
In method "ensure_device_is_ready" [1], if the device does not exist or
the MAC is still not assigned, the method returns False and also logs an
error. This error log is distracting; instead of this, an info message
could be logged.
The code using this method, that returns Tr
17 matches
Mail list logo
