[Yahoo-eng-team] [Bug 1835008] [NEW] network_v2 does not set mtu on eni config
Public bug reported: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. (I'm deploying ubuntu xenial via MAAS 2.6.0, setting force_v1_network_yaml=true is my current workaround.) ** Affects: cloud-init Importance: Undecided Status: New ** Affects: maas Importance: Undecided Status: New ** Attachment added: "network v1/v2 configs from maas/curtin and corresponding /etc/network/interfaces.d/50-cloud-init.cfg" https://bugs.launchpad.net/bugs/1835008/+attachment/5274586/+files/cloud-init.tar -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1835008 Title: network_v2 does not set mtu on eni config Status in cloud-init: New Status in MAAS: New Bug description: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. (I'm deploying ubuntu xenial via MAAS 2.6.0, setting force_v1_network_yaml=true is my current workaround.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835008/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1835008] Re: network_v2 does not set mtu on eni config
** Description changed: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. + + (I'm deploying ubuntu xenial via MAAS 2.6.0, setting + force_v1_network_yaml=true is my current workaround.) ** Also affects: maas Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1835008 Title: network_v2 does not set mtu on eni config Status in cloud-init: New Status in MAAS: New Bug description: The MTU is not set on the bond, nor vlans on the bond, nor the bridges attached to the vlans on a network_v2 configuration. It's only set on the underlying interfaces (eth0, eth1) This does not happen if given a network_v1 configuration. (I'm deploying ubuntu xenial via MAAS 2.6.0, setting force_v1_network_yaml=true is my current workaround.) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1835008/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1708389] [NEW] wsgi and rpc-server has issues with dhcp when creating subnet
Public bug reported: I'm not sure how to trace this down further, but with neutron-api running as a wsgi script in a container, and neutron-rpc-server running in a separate container. When creating a subnet in the openstack-cli, e.g. "subnet create --network network1 --subnet-range 10.0.0.0/24 subnet1", the rpc-server logs and dhcp-agent logs fill up with these errors; ValueError: Unrecognized attribute(s) 'binding:host_id' I'm attaching some logs with a stack-trace. ** Affects: neutron Importance: Undecided Status: New ** Tags: neutron-dhcp-agent neutron-rpc-server ** Attachment added: "stack-traces from neutron-dhcp-agent and neutron-rpc-server" https://bugs.launchpad.net/bugs/1708389/+attachment/4926416/+files/dhcp-error.log -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1708389 Title: wsgi and rpc-server has issues with dhcp when creating subnet Status in neutron: New Bug description: I'm not sure how to trace this down further, but with neutron-api running as a wsgi script in a container, and neutron-rpc-server running in a separate container. When creating a subnet in the openstack-cli, e.g. "subnet create --network network1 --subnet-range 10.0.0.0/24 subnet1", the rpc-server logs and dhcp-agent logs fill up with these errors; ValueError: Unrecognized attribute(s) 'binding:host_id' I'm attaching some logs with a stack-trace. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1708389/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1715463] [NEW] binary name gets confused under upgrades of osapi_compute and metadata
Public bug reported: During an upgrade, you'll already have a entry in the nova.services table for 'nova-osapi_compute'. The new wsgi app has NAME='osapi_compute' and first queries for this name, which yields 0 rows. Then since there's no entry it decides to create a new entry with INSERT where it appends 'nova-' to this 'name'. Problem is there's already an entry for 'nova-osapi_compute', so now the insert fails because of duplicate entries. So NAME has to be changed, or append 'nova-' on both queries. Also the queries SELECT if exists UPDATE if not exists INSERT Could really just boil down to UPDATE if fail INSERT This way it's atomic aswell. ** 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/1715463 Title: binary name gets confused under upgrades of osapi_compute and metadata Status in OpenStack Compute (nova): New Bug description: During an upgrade, you'll already have a entry in the nova.services table for 'nova-osapi_compute'. The new wsgi app has NAME='osapi_compute' and first queries for this name, which yields 0 rows. Then since there's no entry it decides to create a new entry with INSERT where it appends 'nova-' to this 'name'. Problem is there's already an entry for 'nova-osapi_compute', so now the insert fails because of duplicate entries. So NAME has to be changed, or append 'nova-' on both queries. Also the queries SELECT if exists UPDATE if not exists INSERT Could really just boil down to UPDATE if fail INSERT This way it's atomic aswell. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1715463/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1687896] [NEW] neutron-rpc-server fails to start on configuration that works under neutron-server
Public bug reported: I'm running neutron-api under uwsgi, but noticed it's not doing any rpc stuff, so I figure that's what "neutron-rpc-server" is for. But it fails to start on configuration that works under the normal "neutron-server". Traceback (most recent call last): File "/usr/local/bin/neutron-rpc-server", line 10, in sys.exit(main_rpc_eventlet()) File "/opt/stack/neutron/neutron/cmd/eventlet/server/__init__.py", line 23, in main_rpc_eventlet server.boot_server(rpc_eventlet.eventlet_rpc_server) File "/opt/stack/neutron/neutron/server/__init__.py", line 42, in boot_server server_func() File "/opt/stack/neutron/neutron/server/rpc_eventlet.py", line 33, in eventlet_rpc_server rpc_workers_launcher = service.start_rpc_workers() File "/opt/stack/neutron/neutron/service.py", line 269, in start_rpc_workers rpc_workers = _get_rpc_workers() File "/opt/stack/neutron/neutron/service.py", line 163, in _get_rpc_workers if not plugin.rpc_workers_supported(): AttributeError: 'NoneType' object has no attribute 'rpc_workers_supported' In neutron/neutron/service.py: from neutron_lib.plugins import directory def _get_rpc_workers(): plugin = directory.get_plugin() service_plugins = directory.get_plugins().values() I'm not sure what directory.get_plugin() does or how it works, but it doesn't return anything of use apparently. You should be able to reproduce quite easily by running neutron-server --config-file neutron.conf neutron-rpc-server --config-file neutron.conf ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1687896 Title: neutron-rpc-server fails to start on configuration that works under neutron-server Status in neutron: New Bug description: I'm running neutron-api under uwsgi, but noticed it's not doing any rpc stuff, so I figure that's what "neutron-rpc-server" is for. But it fails to start on configuration that works under the normal "neutron-server". Traceback (most recent call last): File "/usr/local/bin/neutron-rpc-server", line 10, in sys.exit(main_rpc_eventlet()) File "/opt/stack/neutron/neutron/cmd/eventlet/server/__init__.py", line 23, in main_rpc_eventlet server.boot_server(rpc_eventlet.eventlet_rpc_server) File "/opt/stack/neutron/neutron/server/__init__.py", line 42, in boot_server server_func() File "/opt/stack/neutron/neutron/server/rpc_eventlet.py", line 33, in eventlet_rpc_server rpc_workers_launcher = service.start_rpc_workers() File "/opt/stack/neutron/neutron/service.py", line 269, in start_rpc_workers rpc_workers = _get_rpc_workers() File "/opt/stack/neutron/neutron/service.py", line 163, in _get_rpc_workers if not plugin.rpc_workers_supported(): AttributeError: 'NoneType' object has no attribute 'rpc_workers_supported' In neutron/neutron/service.py: from neutron_lib.plugins import directory def _get_rpc_workers(): plugin = directory.get_plugin() service_plugins = directory.get_plugins().values() I'm not sure what directory.get_plugin() does or how it works, but it doesn't return anything of use apparently. You should be able to reproduce quite easily by running neutron-server --config-file neutron.conf neutron-rpc-server --config-file neutron.conf To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1687896/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
