Public bug reported:
It seems like this is written exclusively for some dist..
On rocky, it's named strongswan just like in the man page, and it uses
/etc/strongswan
So setting:
[strongswan]
default_config_area = /etc/strongswan/strongswan.d
should be enough according to the configuration, but
** Changed in: nova
Status: Invalid => 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/1774363
Title:
Instance is of no use during "shelve-offloading" operatio
Public bug reported:
VM:s stuck in unshelving has no way forward.
They are stuck in limbo and require database hacks to workaround.
There has to be something a admin can try to restart or reset the
unshelve process.
(running on openstack yoga, installed via kolla-ansible)
** Affects: nova
Public bug reported:
disable a compute node
run migration on a vm not running, it will still have to start on that
compute node to do resize...
next imagine that the compute node has gone down, why can't it just do a
new scheduling and start running on a existing/not-disabled node?
this is with
Public bug reported:
While upgrading to rocky, we ended up with a broken openvswitch
infrastructure and moved back to the old openvswitch.
We ended up with new machines working, old machines didn't and it took a
while to realize that we had qvo* interfaces that not only wasn't
plugged but also wa
Public bug reported:
On a running instance, we have had several occasions of network issues.
During the last issue we noticed that the interfaces lost their vlan tags in
openvswitch:
ovs-vsctl show |grep qg-fb5a3595-48 -A 10
Port "qg-fb5a3595-48"
Interface "qg-fb5a3595-48"
Public bug reported:
We have had problems with openvswitch agent continuously restarting and
never actually completing setup because of this:
# Completed by iptables_manager
; Stdout: ; Stderr: iptables-restore v1.4.21: multiport only works with TCP,
UDP, UDPLITE, SCTP and DCCP
Error occurred at
Public bug reported:
If you run neutron with OVS it doesn't honor MTU values, which is a
issue if you host external environments that needs to communicate with
other entities that f.ex. have PMTU disabled as a security measure...
Another issue is that the MTU difference happens on a L2 bridge and
Public bug reported:
When vxlans are created, f.ex. via ensure_vxlan in
neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py
- no mtu is assigned.
This explains why we get vxlan interfaces with 1500 byte mtu even-though
neutron has been instructed to use 9000 bytes mtu.
The
Public bug reported:
The floating ip:s are ordered according to UUID instead of IP, more
information in the patch.
---
commit 83a10bf02a5079513741039860208e277e1d12e4
Author: Ian Kumlien
Date: Thu Apr 17 13:49:32 2014 +0200
Sorting floating IP:s according to IP.
While using alot
10 matches
Mail list logo