Public bug reported:
When running nova boot without a --nic option, nova will try to
provision an interface for it, even for shared networks where the user
does not have permission to do so.
There is no way to provision an instance without a network in an
installation where a shared network is pr
Public bug reported:
When spawning an SR-IOV enabled instance on a newly deployed host, nova
attempts to spawn it with an type-PF pci device. This fails with the
below stack trace.
After restarting neutron-sriov-agent and nova-compute services on the
compute node and spawning an SR-IOV instance a
Public bug reported:
It appears we can't edit security groups for an instance shared via
rbac. Sharing SGs via RBAC is done via:
`openstack network rbac create --target-project $project --action
access_as_shared --type security_group ...`
We can see the shared SGs in the cli, when doing `openst
Public bug reported:
In a site upgraded to Ussuri we are getting faults starting instances
2020-11-30 13:41:40.586 232871 ERROR oslo_messaging.rpc.server
libvirt.libvirtError: Requested operation is not valid: format of
backing image '/var/lib/nova/instances/_base/xxx' of image
'/var/lib/nova/ins
It appears ubuntu bionic/focal ship with libvirt < 6.1.0, marking nova
as affected in those distribs
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenSt
Public bug reported:
For one of our compute machines I'm seeing two network agents that
appear unhealthy:
```
$ os network agent list | fgrep "register deleted"
| compute1 | OVN Controller agent | ("Chassis"
register deleted) | | XXX | UP| ovn
Public bug reported:
When creating a network with vlan provider "Physical Network" field is
prepopulated with the string "default", although such a physnet doesn't
exist. The user actually needs to specify a real physnet here; trying to
add a net with physnet "default" fails.
UI wise leaving the
Public bug reported:
In case of signing faults the cms_sign_data() function in
keystoneclient/common/cms.py currently includes little detail on the
failing `openssl cms` operation.
To aid operations in troubleshooting, it would be helpful if the
following were logged in case of faults:
- The cer
Public bug reported:
There appears to be some race between nova-compute and
neutron-sriov-agent when rebooting. When trying to bring up an
sriov-enabled instance this intermittently (but often) fails after a
fresh reboot. After restarting the neutron-sriov-agent and
nova-compute seems to fix this,
Public bug reported:
Due to an apparent communication issue between neutron-openvswitch-agent
and openvswitch we were in a situation where we had linux veth devices
set up for a given instance (eg. tapXXX, qvbXXX) but were missing
corresponding ovs ports and iptables rules.
In this situation we
Public bug reported:
Horizon errors with 500 Internal Server Error.
The apache error.log logs an exception "RuntimeError: osrandom engine
already registered", cf. traceback below. We need to restart apache2 to
recover.
This happens in a non-deterministic way, ie. Horizon will function
correctly
11 matches
Mail list logo