[Yahoo-eng-team] [Bug 1650694] Re: nova-manage cell_v2 discover_hosts is broken
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Status: New => Confirmed ** Changed in: nova/newton Importance: Undecided => Medium -- 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/1650694 Title: nova-manage cell_v2 discover_hosts is broken Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) newton series: Confirmed Bug description: This is from an ocata devstack created 2 days ago: (venv) stack@filters:/opt/stack/nova$ nova-manage cell_v2 discover_hosts 2016-12-17 00:57:07.652 DEBUG oslo_policy.policy [req-ed0bd6be-c6d8-4e25-895e-33e8fa50692f None None] The policy file policy.json could not be found. from (pid=29365) load_rules /opt/stack/nova/.tox/venv/local/lib/python2.7/site-packages/oslo_policy/policy.py:520 error: 'module' object has no attribute 'session' (venv) stack@filters:/opt/stack/nova$ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1650694/+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 1504725] Re: rabbitmq-server restart twice, log is crazy increasing until service restart
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1504725 Title: rabbitmq-server restart twice, log is crazy increasing until service restart Status in neutron: Expired Status in oslo.messaging: Won't Fix Bug description: After I restart the rabbitmq-server for the second time, the service log(such as nova,neutron and so on) is increasing crazy, log is such as " TypeError: 'NoneType' object has no attribute '__getitem__'". It seems that the channel is setted to None. trace log: 2015-10-10 15:20:59.413 29515 TRACE root Traceback (most recent call last): 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 95, in inner_func 2015-10-10 15:20:59.413 29515 TRACE root return infunc(*args, **kwargs) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_messaging/_executors/impl_eventlet.py", line 96, in _executor_thread 2015-10-10 15:20:59.413 29515 TRACE root incoming = self.listener.poll() 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 122, in poll 2015-10-10 15:20:59.413 29515 TRACE root self.conn.consume(limit=1, timeout=timeout) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1202, in consume 2015-10-10 15:20:59.413 29515 TRACE root six.next(it) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1100, in iterconsume 2015-10-10 15:20:59.413 29515 TRACE root error_callback=_error_callback) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 868, in ensure 2015-10-10 15:20:59.413 29515 TRACE root ret, channel = autoretry_method() 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 458, in _ensured 2015-10-10 15:20:59.413 29515 TRACE root return fun(*args, **kwargs) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 545, in __call__ 2015-10-10 15:20:59.413 29515 TRACE root self.revive(create_channel()) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 251, in channel 2015-10-10 15:20:59.413 29515 TRACE root chan = self.transport.create_channel(self.connection) 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 91, in create_channel 2015-10-10 15:20:59.413 29515 TRACE root return connection.channel() 2015-10-10 15:20:59.413 29515 TRACE root File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 289, in channel 2015-10-10 15:20:59.413 29515 TRACE root return self.channels[channel_id] 2015-10-10 15:20:59.413 29515 TRACE root TypeError: 'NoneType' object has no attribute '__getitem__' 2015-10-10 15:20:59.413 29515 TRACE root To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1504725/+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 1629227] Re: Floating-ip-creation
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629227 Title: Floating-ip-creation Status in neutron: Expired Bug description: On network node a floating ip is being created by assigning a range of floating ip address to external network pool on routers, where gateway addresses and dhcp is disabled, but here neutronclient/v2_0/client.py returns an empty list to ceilometer which is wrong it should return a floating ip status or something meaningful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1629227/+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 1633998] Re: serveral neutron server process CPU punching height
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633998 Title: serveral neutron server process CPU punching height Status in neutron: Expired Bug description: The bug will happen when 2000 routers are created by rally script. rally script: "NeutronNetworks.create_N_routers_M_network_M_subnet": [ { "args": { "num_of_routers":1, "num_of_networks":1, "network_create_args": {}, "subnet_create_args": {}, "subnet_cidr_start": "2.1.3.0/24", "subnets_per_network": 1, "router_create_args": { "external_gateway_info": { "network_id":"65a81c28-6ea3-47be-9e4d-ca34fc0b0844" } } }, "runner": { "type": "constant", "times": 1, "concurrency": 1 }, "context": { "users": { "tenants": 1, "users_per_tenant": 1 }, "quotas": { "neutron": { "network": -1, "subnet": -1, "router": -1 } } } } ] environment:openstack K api-workers = 24 phenomenon: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 28582 neutron 20 0 1972384 1.513g 2112 R 100.0 2.4 690:03.53 neutron-server 28587 neutron 20 0 2042504 1.582g 2108 R 100.0 2.5 753:38.91 neutron-server 28579 neutron 20 0 2405900 1.919g 2108 R 100.0 3.1 714:32.32 neutron-server 28581 neutron 20 0 2833136 2.326g 2108 R 100.0 3.7 723:43.28 neutron-server 28586 neutron 20 0 1969648 1.509g 2108 R 100.0 2.4 679:06.97 neutron-server 28588 neutron 20 0 2097372 1.626g 2108 R 100.0 2.6 735:03.23 neutron-server 28589 neutron 20 0 2054628 1.593g 2108 R 100.0 2.5 711:27.87 neutron-server 31289 neutron 20 0 346980 51872 5300 S 9.9 0.1 295:11.30 neutron-zenic-a 1842 root 20 0 911552 10188 1700 S 8.9 0.0 3249:10 tecs-tc-main To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633998/+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 1650694] [NEW] nova-manage cell_v2 discover_hosts is broken
Public bug reported: This is from an ocata devstack created 2 days ago: (venv) stack@filters:/opt/stack/nova$ nova-manage cell_v2 discover_hosts 2016-12-17 00:57:07.652 DEBUG oslo_policy.policy [req-ed0bd6be-c6d8-4e25-895e-33e8fa50692f None None] The policy file policy.json could not be found. from (pid=29365) load_rules /opt/stack/nova/.tox/venv/local/lib/python2.7/site-packages/oslo_policy/policy.py:520 error: 'module' object has no attribute 'session' (venv) stack@filters:/opt/stack/nova$ ** Affects: nova Importance: High Status: Confirmed ** Tags: cells nova-manage -- 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/1650694 Title: nova-manage cell_v2 discover_hosts is broken Status in OpenStack Compute (nova): Confirmed Bug description: This is from an ocata devstack created 2 days ago: (venv) stack@filters:/opt/stack/nova$ nova-manage cell_v2 discover_hosts 2016-12-17 00:57:07.652 DEBUG oslo_policy.policy [req-ed0bd6be-c6d8-4e25-895e-33e8fa50692f None None] The policy file policy.json could not be found. from (pid=29365) load_rules /opt/stack/nova/.tox/venv/local/lib/python2.7/site-packages/oslo_policy/policy.py:520 error: 'module' object has no attribute 'session' (venv) stack@filters:/opt/stack/nova$ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1650694/+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 1650678] [NEW] Allow specifying dns_domain when creating a port
Public bug reported: When creating a port, allow specifying a dns_domain instead of inheriting dns_domain from the network. In our enterprise we do not tie DNS domains to networks - we use the DNS domain of a VM port to indicate the business unit or the infrastructure function of a VM. Thus our data center networks routinely have VM ports with a variety of DNS domains, with the choice of DNS domain left to the person deploying the VM instance. To carry this practice into OpenStack, we will extend our data center network into OpenStack using a provider network, and we need the ability to create ports on that network with various dns_names furnished by the VM creator. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1650678 Title: Allow specifying dns_domain when creating a port Status in neutron: New Bug description: When creating a port, allow specifying a dns_domain instead of inheriting dns_domain from the network. In our enterprise we do not tie DNS domains to networks - we use the DNS domain of a VM port to indicate the business unit or the infrastructure function of a VM. Thus our data center networks routinely have VM ports with a variety of DNS domains, with the choice of DNS domain left to the person deploying the VM instance. To carry this practice into OpenStack, we will extend our data center network into OpenStack using a provider network, and we need the ability to create ports on that network with various dns_names furnished by the VM creator. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650678/+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 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit
We don't use the -u option to sfdisk. ** Changed in: ubuntu-image Status: New => Invalid -- 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/1460715 Title: MBR disk setup fails because sfdisk no longer accepts M as a valid unit Status in cloud-init: Fix Committed Status in Ubuntu Image: Invalid Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Committed Status in cloud-init source package in Yakkety: In Progress Bug description: === Begin SRU Template === [Impact] Cloud-init has function to partition disks on devices. Creating partitions on a disk no longer works with sfdisk as recent versions of sfdisk no accept the unit 'M' as input, this function is broken. [Test Case] 1. Launch an instance with provided user-data On Azure, this will work: #cloud-config disk_setup: ephemeral0: table_type: mbr layout: [66, [33, 82]] overwrite: True fs_setup: - device: ephemeral0.1 filesystem: ext4 - device: ephemeral0.2 filesystem: swap mounts: - ["ephemeral0.1", "/mnt2"] - ["ephemeral0.2", "none", "swap", "sw", "0", "0"] On a typical kvm openstack use: #cloud-config disk_setup: /dev/vdb: table_type: mbr layout: [66, [33, 82]] overwrite: True fs_setup: - device: /dev/vdb1 filesystem: ext4 - device: /dev/vdb2 filesystem: swap mounts: - ["/dev/vdb1", "/mnt2"] - ["/dev/vdb2", "none", "swap", "sw", "0", "0"] 2. Add proposed, update, and reboot as fresh instance. # enable proposed echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main | sudo tee /etc/apt/sources.list.d/proposed.list sudo apt-get -qy update && sudo apt-get -qy install cloud-init https://bugs.launchpad.net/cloud-init/+bug/1460715/+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 1650108] Re: remove v3 controller stub
Reviewed: https://review.openstack.org/411092 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=a6740ac5e5277abb8ee3fe56fc18af8c0969c888 Submitter: Jenkins Branch:master commit a6740ac5e5277abb8ee3fe56fc18af8c0969c888 Author: Brian RosmaitaDate: Wed Dec 14 23:00:11 2016 -0500 Remove v3 stub controller This patch removes the stub controller for v3 that was introduced in Mitaka when Glare became a standalone service. As the v3 API was always EXPERIMENTAL, this removal does not require a deprecation period. (Also, anyone interested in artifacts is using Glare, not the v3 API.) Change-Id: Ie16ba13c5970596eebf7b757c0712358c80f376e Closes-bug: #1650108 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1650108 Title: remove v3 controller stub Status in Glance: Fix Released Bug description: The Mitaka release contained a stub controller to redirect calls from the experimental v3 API to the standalone Glare service. This is no longer required. Since the v3 API was clearly marked EXPERIMENTAL, it does not require a deprecation period. Further, this change would only affect deployments running the v3 API, which is very unlikely, as the standalone artifacts API is a bit different from v3, and hence anyone interested in artifacts is using Glare. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1650108/+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 1650615] Re: objects: unittest may fail due to objects using same integer primary key
Reviewed: https://review.openstack.org/411897 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=02fa4a1fbfbbb843a02c9d1aeb45c250373d937c Submitter: Jenkins Branch:master commit 02fa4a1fbfbbb843a02c9d1aeb45c250373d937c Author: Kevin BentonDate: Fri Dec 16 08:24:51 2016 -0800 Ensure random object unique constraints aren't violated The unit test framework for objects generates random values for the objects it creates. We need to pay attention to previously generated values to avoid using the same value for data models that have unique constrains. Closes-Bug: #1650615 Change-Id: I0c54b0d82b8c15f2740cce5a850c8fa50acba536 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1650615 Title: objects: unittest may fail due to objects using same integer primary key Status in neutron: Fix Released Bug description: Data are randomly generated in DB unittests for objects. Some objects use integer type as primary key, that is uniquely constrained in database. Integer data are randomly generated from 1000 items so it may non-deterministically happen, that two objects obtain same integer number. example of failure: http://logs.openstack.org/17/385617/29/gate/gate- neutron-python35/720352f/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650615/+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 1354694] Re: useradd crashes if group list contains whitespace on Fedora
** Changed in: cloud-init (Ubuntu) Status: Fix Released => Confirmed ** Changed in: cloud-init Status: Fix Committed => Confirmed -- 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/1354694 Title: useradd crashes if group list contains whitespace on Fedora Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Confirmed Bug description: See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1354694/+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 1354694] Re: useradd crashes if group list contains whitespace on Fedora
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Fix Released ** Changed in: cloud-init (Ubuntu) Importance: Undecided => Low ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Yakkety) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Yakkety) Status: New => Confirmed ** Changed in: cloud-init (Ubuntu Yakkety) Importance: Undecided => Low ** Changed in: cloud-init (Ubuntu Xenial) Status: New => Confirmed ** Changed in: cloud-init (Ubuntu Xenial) Importance: Undecided => Low -- 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/1354694 Title: useradd crashes if group list contains whitespace on Fedora Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Confirmed Bug description: See downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1126365 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1354694/+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 1629133] Re: New neutron subnet pool support breaks multinode testing.
Reviewed: https://review.openstack.org/388602 Committed: https://git.openstack.org/cgit/openstack/magnum/commit/?id=821bacc4a7f0b7a0f99d5b23da23375c3db41f64 Submitter: Jenkins Branch:master commit 821bacc4a7f0b7a0f99d5b23da23375c3db41f64 Author: yatinDate: Wed Oct 19 10:36:52 2016 + Revert "devstack: Fix neutron configuration to run in OSIC" This reverts commit 45f071e36eab4f3d20cacbc9cd610e536e1dd2b9. The Temporary fix can be reverted as devstack has released the fix in following patch:- https://review.openstack.org/398012 Change-Id: I837f4925cf4c797bd1b02a7bf244ca5742159971 Closes-Bug: #1628267 Closes-Bug: #1629133 ** Changed in: magnum Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629133 Title: New neutron subnet pool support breaks multinode testing. Status in networking-bgpvpn: New Status in devstack: Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in Magnum: Fix Released Status in Manila: New Status in neutron: Incomplete Status in OpenStack DBaaS (Trove): In Progress Bug description: The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts. For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools. I think the correct way to fix this is to use a much smaller subnet pool range to avoid conflicting with every possible 10.0.0.0/8 network in the wild, possibly by defaulting to the existing FIXED_RANGE information. Using the existing information will help ensure that anyone with networks in 10.0.0.0/8 will continue to work if they have specified a range that doesn't conflict using this variable. In addition to this we need to clearly document what this new stuff in devstack does and how people can work around it should they conflict with the new defaults we end up choosing. I have proposed https://review.openstack.org/379543 which mostly works except it fails one tempest test that apparently depends on this new subnet pool stuff. Specifically the V6 range isn't large enough aiui. To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1629133/+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 1625766] Re: Fallback networking doesn't handle IOError when reading sys/net//carrier
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Fix Released ** Changed in: cloud-init (Ubuntu) Importance: Undecided => Medium ** Changed in: cloud-init Status: Triaged => Fix Committed ** Also affects: cloud-init (Ubuntu Yakkety) 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/1625766 Title: Fallback networking doesn't handle IOError when reading sys/net//carrier Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Yakkety: New Bug description: Sometimes reading from /sys/class/net//carrier returns an error and is unhangled causing fallback networking to not bring anything up. [Original Description] I am running Arch on a KVM vps provider. I installed using this template: Arch Linux 2016.03 64-bit (template). Everything was working fine until I decided to upgrade. I did pacman -Syu and everything upgraded without error until it restarted. I had to manually install certain python packages. But, I kept getting more errors so I joined IRC. Here's the log: https://irclogs.ubuntu.com/2016/09/20/%23cloud- init.html Was told to post it Here to sum up everything To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1625766/+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 1650351] Re: test_service_providers.test_service_providers_list runs unconditionally
** Also 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/1650351 Title: test_service_providers.test_service_providers_list runs unconditionally Status in neutron: In Progress Status in tempest: In Progress Bug description: test_service_providers.test_service_providers_list requires neutron service-type extension. It's enabled by default from Newton. So by default it fails with mitaka(or older). The test case needs to be skipped when service-type extension isn't enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650351/+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 1649412] Re: user to nonlocal_user should be a 1 to 1 table relationship
Reviewed: https://review.openstack.org/409946 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e3f55e7b54250f46f8ade623fe9d62586cf780be Submitter: Jenkins Branch:master commit e3f55e7b54250f46f8ade623fe9d62586cf780be Author: Ronald De RoseDate: Mon Dec 12 21:46:27 2016 + Make user to nonlocal_user a 1:1 relationship The table relationship between 'user' and 'nonlocal_user' should be 1 to 1, which is consistent with 'user' to 'local_user'. However, it's mistakenly 1 to many. In fact, the backend code treats 'user' to 'nonlocal_user' as 1:1 and wouldn't allow duplicates, so this will have zero impact on existing deployments. This patch fixes this by making the user_id column unique. Closes-Bug: #1649412 Partially-Implements: bp support-federated-attr Change-Id: Ib371df18f3fb2c67e5421cf0bf4551183902cf00 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1649412 Title: user to nonlocal_user should be a 1 to 1 table relationship Status in OpenStack Identity (keystone): Fix Released Bug description: The 'nonlocal_user' table shadows LDAP or custom identity driver users. Currently, the 'user' to 'nonlocal_user' table relationship is 1 to many. However, this is inaccurate. For example, there shouldn't be a user with multiple usernames from a single domain; keystone doesn't support that. A user belongs to a domain and has a single username. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1649412/+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 1650615] [NEW] objects: unittest may fail due to objects using same integer primary key
Public bug reported: Data are randomly generated in DB unittests for objects. Some objects use integer type as primary key, that is uniquely constrained in database. Integer data are randomly generated from 1000 items so it may non-deterministically happen, that two objects obtain same integer number. example of failure: http://logs.openstack.org/17/385617/29/gate/gate- neutron-python35/720352f/console.html ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ** Tags added: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1650615 Title: objects: unittest may fail due to objects using same integer primary key Status in neutron: New Bug description: Data are randomly generated in DB unittests for objects. Some objects use integer type as primary key, that is uniquely constrained in database. Integer data are randomly generated from 1000 items so it may non-deterministically happen, that two objects obtain same integer number. example of failure: http://logs.openstack.org/17/385617/29/gate/gate- neutron-python35/720352f/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650615/+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 1650611] [NEW] dhcp agent reporting state as down during the initial sync
Public bug reported: When dhcp agent is started, neutron agent-list reports its state as dead until the initial sync is complete. This can lead to unwanted alarms in monitoring systems, especially in large environments where the initial sync may take hours. During this time, systemctl shows that the agent is actually alive while neutron agent-list reports it as down. Technical details: If I'm right, this line [0] is the exact point where the initial sync takes place right after the first state report (with start_flag=True) is sent to the server. As it's being done in the same thread, it won't send a second state report until it's done with the sync. Doing it in a separate thread would let the heartbeat task to continue sending state reports to the server but I don't know whether this have any unwanted side effects. [0] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L751 ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-bgp -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1650611 Title: dhcp agent reporting state as down during the initial sync Status in neutron: New Bug description: When dhcp agent is started, neutron agent-list reports its state as dead until the initial sync is complete. This can lead to unwanted alarms in monitoring systems, especially in large environments where the initial sync may take hours. During this time, systemctl shows that the agent is actually alive while neutron agent-list reports it as down. Technical details: If I'm right, this line [0] is the exact point where the initial sync takes place right after the first state report (with start_flag=True) is sent to the server. As it's being done in the same thread, it won't send a second state report until it's done with the sync. Doing it in a separate thread would let the heartbeat task to continue sending state reports to the server but I don't know whether this have any unwanted side effects. [0] https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L751 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650611/+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 1649488] Re: Duplicated revises_on_change in qos models
Reviewed: https://review.openstack.org/410065 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=503fc8c9187912062d7ade1d9c7933973f6ad0bc Submitter: Jenkins Branch:master commit 503fc8c9187912062d7ade1d9c7933973f6ad0bc Author: Hong Hui XiaoDate: Tue Dec 13 15:14:52 2016 +0800 Remove duplicated revises_on_change in qos db model Both [1] and [2] add revises_on_change to qos db model. This patch removes the duplication. [1] 3b610a1debdfb99def758406b1604aa3273edeea [2] 0e51574b2fb299eb42d6f5333e68f70244b08d50 Change-Id: I93c80e4f7d2b1c0989d1889e11f586cc5dc09bc5 Closes-Bug: #1649488 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1649488 Title: Duplicated revises_on_change in qos models Status in neutron: Fix Released Bug description: Both 0e51574b2fb299eb42d6f5333e68f70244b08d50 and 3b610a1debdfb99def758406b1604aa3273edeea add revises_on_change to qos db models, which cause duplication in https://github.com/openstack/neutron/blob/09bc8a724e42fed0f527b56d38c5720167031764/neutron/db/qos/models.py#L49-L75 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1649488/+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 1460715] Re: MBR disk setup fails because sfdisk no longer accepts M as a valid unit
This probably affects u-i too. ** Also affects: ubuntu-image 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/1460715 Title: MBR disk setup fails because sfdisk no longer accepts M as a valid unit Status in cloud-init: Fix Committed Status in Ubuntu Image: New Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Committed Status in cloud-init source package in Yakkety: In Progress Bug description: === Begin SRU Template === [Impact] Cloud-init has function to partition disks on devices. Creating partitions on a disk no longer works with sfdisk as recent versions of sfdisk no accept the unit 'M' as input, this function is broken. [Test Case] 1. Launch an instance with provided user-data On Azure, this will work: #cloud-config disk_setup: ephemeral0: table_type: mbr layout: [66, [33, 82]] overwrite: True fs_setup: - device: ephemeral0.1 filesystem: ext4 - device: ephemeral0.2 filesystem: swap mounts: - ["ephemeral0.1", "/mnt2"] - ["ephemeral0.2", "none", "swap", "sw", "0", "0"] On a typical kvm openstack use: #cloud-config disk_setup: /dev/vdb: table_type: mbr layout: [66, [33, 82]] overwrite: True fs_setup: - device: /dev/vdb1 filesystem: ext4 - device: /dev/vdb2 filesystem: swap mounts: - ["/dev/vdb1", "/mnt2"] - ["/dev/vdb2", "none", "swap", "sw", "0", "0"] 2. Add proposed, update, and reboot as fresh instance. # enable proposed echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main | sudo tee /etc/apt/sources.list.d/proposed.list sudo apt-get -qy update && sudo apt-get -qy install cloud-init https://bugs.launchpad.net/cloud-init/+bug/1460715/+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 1632820] Re: os-server-groups policy doesn't separate CRUD actions
*** This bug is a duplicate of bug 1636157 *** https://bugs.launchpad.net/bugs/1636157 ** This bug has been marked a duplicate of bug 1636157 os-server-groups uses same policy.json rule for all CRUD operations -- 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/1632820 Title: os-server-groups policy doesn't separate CRUD actions Status in OpenStack Compute (nova): Opinion Bug description: nova.api.openstack.compute.server_groups.ServerGroupController uses the same policy check (os_compute_api:os-server-groups) for show, delete, index, and create, instead of separating these into separate checks (e.g. os_compute_api:os-server-groups:delete). This makes it impossible to customize policy such that some roles are allowed to do some but not all of these operations, E.g. show/index server groups but not create/delete them. Found with Newton. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632820/+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 1650051] Re: nova console-log returns error for Centos 6.x : 'ascii' codec can't encode character u'\ufffd' in position 13206: ordinal not in range(128)
per above comments ** 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/1650051 Title: nova console-log returns error for Centos 6.x : 'ascii' codec can't encode character u'\ufffd' in position 13206: ordinal not in range(128) Status in OpenStack Compute (nova): Invalid Bug description: Description === nova console-log returns error for Contos 6.x : 'ascii' codec can't encode character u'\ufffd' in position 13206: ordinal not in range(128). nova console-log returns the log properly for Centos 7.x 14.x images. Steps to reproduce: Step 1 : Upload Centos 6.x image. Ex: http://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud.qcow2 | ID | Name | Status | +--+---++ | f963d9c7-cff3-4ac1-88a8-6c78648462ad | CentOS-6-x86_64-GenericCloud RC8 | active | Step 2 : Create a VM and look for console log Ex: openstack server create test --image f963d9c7-cff3-4ac1-88a8-6c78648462ad --flavor m1.small --key-name test_key nova console-log selva_test Expected result === Console log should be printed Actual result = ERROR (UnicodeEncodeError): 'ascii' codec can't encode character u'\ufffd' in position 0: ordinal not in range(128) Environment === Newton 14.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1650051/+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 1648014] Re: Syntax Error 'Settings and Configuration' Horizon Doc
Patch here: https://review.openstack.org/#/c/411788/ ** Also affects: horizon Importance: Undecided Status: New ** Changed in: openstack-manuals Status: New => Invalid ** Changed in: horizon Milestone: None => ocata-2 ** Changed in: horizon Importance: Undecided => Low ** Changed in: horizon Status: New => Fix Released ** Changed in: horizon Milestone: ocata-2 => ocata-3 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1648014 Title: Syntax Error 'Settings and Configuration' Horizon Doc Status in OpenStack Dashboard (Horizon): Fix Released Status in openstack-manuals: Invalid Bug description: http://docs.openstack.org/developer/horizon/topics/settings.html at LAUNCH_INSTANCE_DEFAULTS there is a missing ',' in the code block. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1648014/+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 1650103] Re: HTTP exception thrown: Unexpected API Error
ConnectFailure: Unable to establish connection to http://10.0.0.11:9696/v2.0/networks.json this indicated you have some trouble in let nova communcate with neutron, please refer to openstack install and configure doc http://docs.openstack.org for additional info, especially make sure compute service (nova) is well configured ** 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/1650103 Title: HTTP exception thrown: Unexpected API Error Status in OpenStack Compute (nova): Invalid Bug description: When I executed openstack-status, I got an error like below: It's not easy to explain exactly the situation because I am a novice in openstack. 2016-12-14 21:42:26.834 3684 INFO nova.osapi_compute.wsgi.server [req-a7c43921-d9d6-465d-823f-56e0d106dae0 ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] 10.0.0.11 "GET /v2/534ba2401a104bc79b13f66f01ddf14c HTTP/1.1" status: 404 len: 264 time: 0.1577229 2016-12-14 21:42:26.845 3684 INFO nova.osapi_compute.wsgi.server [req-88af2f2e-29f7-492c-a3fb-272fb0a9ee8f ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] 10.0.0.11 "GET /v2/ HTTP/1.1" status: 200 len: 571 time: 0.0055239 2016-12-14 21:42:27.019 3684 INFO nova.osapi_compute.wsgi.server [req-665ec85a-ce4b-4843-a8dd-3117ad1cb1bd ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] 10.0.0.11 "GET /v2/534ba2401a104bc79b13f66f01ddf14c/os-services HTTP/1.1" status: 200 len: 1187 time: 0.0232651 2016-12-14 21:42:28.795 3684 INFO nova.osapi_compute.wsgi.server [req-d13e2d50-9bed-4e74-985f-e49227d25d91 ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] 10.0.0.11 "GET /v2/534ba2401a104bc79b13f66f01ddf14c HTTP/1.1" status: 404 len: 264 time: 0.1563978 2016-12-14 21:42:28.803 3684 INFO nova.osapi_compute.wsgi.server [req-a269f49f-69f0-4ee7-abd4-5092c9694111 ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] 10.0.0.11 "GET /v2/ HTTP/1.1" status: 200 len: 571 time: 0.0046468 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions [req-63893eeb-f5bb-4f1b-88c5-7610e71f4a31 ae52f67ac3474529b556ed6de7119543 534ba2401a104bc79b13f66f01ddf14c - - -] Unexpected exception in API method 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, in wrapped 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/networks.py", line 89, in index 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions networks = self.network_api.get_all(context) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1290, in get_all 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions networks = client.list_networks().get('networks') 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 97, in with_params 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions ret = self.function(instance, *args, **kwargs) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 671, in list_networks 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions **_params) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 373, in list 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions for r in self._pagination(collection, path, **params): 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 388, in _pagination 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions res = self.get(path, params=params) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 358, in get 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions headers=headers, params=params) 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 335, in retry_request 2016-12-14 21:42:28.957 3684 ERROR nova.api.openstack.extensions headers=headers, params=params)
[Yahoo-eng-team] [Bug 1650529] [NEW] Unwanted text below Cancel button after Launch Instance Fails
Public bug reported: I followed Mitaka installation using the guide - http://docs.openstack.org/mitaka/install-guide-ubuntu/. When I got a failure in launching instance, I observed that unwanted text gets displayed below the cancel button [Screenshot attached]. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Unwanted text "object Object" below cancel button" https://bugs.launchpad.net/bugs/1650529/+attachment/4792342/+files/B1.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1650529 Title: Unwanted text below Cancel button after Launch Instance Fails Status in OpenStack Dashboard (Horizon): New Bug description: I followed Mitaka installation using the guide - http://docs.openstack.org/mitaka/install-guide-ubuntu/. When I got a failure in launching instance, I observed that unwanted text gets displayed below the cancel button [Screenshot attached]. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1650529/+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 1650512] [NEW] Slow net-list command, over 15K returned records by SQL
Public bug reported: OpenStack Release: Mitaka We have: 230 networks 102 entries in network RBAC When I'm listing instances from Horizon (takes ages), neutron runs this SQL query: http://paste.openstack.org/show/592603/ and it gets over 15k records from it. For almost all networks there are two records but for four networks there are more: 4 200d2ee9-fcac-4224-9005-5bcff43944c9 - 1 entry in network RBAC 4 a36912c4-7202-4074-b10a-3f6af7514498 - no entry in network RBAC 144 ba9d80b7-8593-4214-be1a-731ea7c92e56 - 12 entries in network RBAC 14792 7493c1b5-6954-4f71-8145-6c95694a9ba6 - 86 entries in network RBAC So it is clear that number of rows is correlated with network RBAC: (network RBAC entries)^2 When neutron-server process receives those 15k records it consumes 100% of one CPU core (2.6GHz) for 1-2 seconds. The result is that network- list command takes over 2sec. I found two LEFT JOINs in the SQL query: LEFT OUTER JOIN networkrbacs AS networkrbacs_1 ON subnets_1.network_id = networkrbacs_1.object_id LEFT OUTER JOIN networkrbacs AS networkrbacs_2 ON networks.id = networkrbacs_2.object_id I think this is the reason of ^2 correlation. The meaning of the conditions in both LEFT JOIN are the same. I'm not sure if I read the code correctly but I see rbac_entries in both Subnet and Network models here: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/models_v2.py Please find a way how to remove (network RBAC entries)^2 correlation because it is dangerous and have influence on many Horizon operations, for sure on those: - networks list - instances list - "Launch instance" form creation ** Affects: neutron Importance: Undecided Status: New ** Description changed: OpenStack Release: Mitaka - I have: + We have: 230 networks 102 entries in network RBAC When I'm listing instances from Horizon (takes ages), neutron runs this SQL query: http://paste.openstack.org/show/592603/ and it gets over 15k records from it. For almost all networks there are two records but for four networks there are more: - 4 200d2ee9-fcac-4224-9005-5bcff43944c9 - 1 entry in network RBAC - 4 a36912c4-7202-4074-b10a-3f6af7514498 - no entry in network RBAC -144 ba9d80b7-8593-4214-be1a-731ea7c92e56 - 12 entries in network RBAC - 14792 7493c1b5-6954-4f71-8145-6c95694a9ba6 - 86 entries in network RBAC + 4 200d2ee9-fcac-4224-9005-5bcff43944c9 - 1 entry in network RBAC + 4 a36912c4-7202-4074-b10a-3f6af7514498 - no entry in network RBAC + 144 ba9d80b7-8593-4214-be1a-731ea7c92e56 - 12 entries in network RBAC + 14792 7493c1b5-6954-4f71-8145-6c95694a9ba6 - 86 entries in network RBAC So it is clear that number of rows is correlated with network RBAC: (network RBAC entries)^2 When neutron-server process receives those 15k records it consumes 100% of one CPU core (2.6GHz) for 1-2 seconds. The result is that network- list command takes over 2sec. I found two LEFT JOINs in the SQL query: LEFT OUTER JOIN networkrbacs AS networkrbacs_1 ON subnets_1.network_id = networkrbacs_1.object_id LEFT OUTER JOIN networkrbacs AS networkrbacs_2 ON networks.id = networkrbacs_2.object_id I think this is the reason of ^2 correlation. Meaning of conditions in both LEFT JOIN are the same. I'm not sure if I read the code correctly but I see rbac_entries in both Subnet and Network models here: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/models_v2.py Please find a way how to remove (network RBAC entries)^2 correlation because it is dangerous and have influence on many Horizon operations, for sure on those: - networks list - instances list - "Launch instance" form creation ** Description changed: OpenStack Release: Mitaka We have: 230 networks 102 entries in network RBAC When I'm listing instances from Horizon (takes ages), neutron runs this SQL query: http://paste.openstack.org/show/592603/ and it gets over 15k records from it. For almost all networks there are two records but for four networks there are more: 4 200d2ee9-fcac-4224-9005-5bcff43944c9 - 1 entry in network RBAC 4 a36912c4-7202-4074-b10a-3f6af7514498 - no entry in network RBAC 144 ba9d80b7-8593-4214-be1a-731ea7c92e56 - 12 entries in network RBAC 14792 7493c1b5-6954-4f71-8145-6c95694a9ba6 - 86 entries in network RBAC So it is clear that number of rows is correlated with network RBAC: (network RBAC entries)^2 When neutron-server process receives those 15k records it consumes 100% of one CPU core (2.6GHz) for 1-2 seconds. The result is that network- list command takes over 2sec. I found two LEFT JOINs in the SQL query: LEFT OUTER JOIN networkrbacs AS networkrbacs_1 ON subnets_1.network_id = networkrbacs_1.object_id LEFT OUTER JOIN networkrbacs AS networkrbacs_2 ON networks.id = networkrbacs_2.object_id - I think
[Yahoo-eng-team] [Bug 1649531] Re: No supported trunking drivers currently display the "default" behavior.
Reviewed: https://review.openstack.org/410919 Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=849baa89815e44a0727bce1d99d9a1c1bb1e0320 Submitter: Jenkins Branch:master commit 849baa89815e44a0727bce1d99d9a1c1bb1e0320 Author: John DavidgeDate: Wed Dec 14 18:49:47 2016 + [network] Clarify current trunk driver limitations All currently supported trunk drivers require both the ``segmentation-type`` and ``segmentation-id`` to be provided when creating a trunk. This is contrary to these parameters being optional in the neutron API. This patch adds a note to clarify the situation until a future driver removes this requirement. Change-Id: I18c5577ab04058dc46eaa4ef8b5742e75d3baab7 Closes-Bug: #1649531 ** Changed in: openstack-manuals Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1649531 Title: No supported trunking drivers currently display the "default" behavior. Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: According to Neutron trunk specification [0] segmentation_id and segmentation_type are optional fields. But when we adding subport to trunk requests without segmentation_id/segmentation_type are failing. Example: $ openstack network trunk set --subport port=port2 trunk10 Failed to add subports to trunk 'trunk10': Invalid input for operation: Invalid subport details '{u'port_id': u'f9922f99-f0e4-4420-be73-dbb9ea7904c6'}': missing segmentation information. Must specify both segmentation_id and segmentation_type. Neutron server returns request_ids: ['req-7601d1a4-afdf-40e6-9273-1fdab1fc8040'] [0] https://specs.openstack.org/openstack/neutron-specs/specs/mitaka /vlan-aware-vms.html#proposed-change UPDATE: Though these parameters are not required at the API level, all currently supported drivers make them a requirement. This should be documented to avoid confusion until a driver that behaves in the "default" way is added. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1649531/+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 1650486] [NEW] cloud-init issue when vm's vnic has no security group
Public bug reported: VM will fail to get metadata with cloud-init timeout error if the VM's vnic does not have security group. We can allow VM access 169.254.169.254 whether VM has security group or not. ** Affects: neutron Importance: Undecided Assignee: Jesse (jesse-5) Status: New ** Changed in: neutron Assignee: (unassigned) => Jesse (jesse-5) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1650486 Title: cloud-init issue when vm's vnic has no security group Status in neutron: New Bug description: VM will fail to get metadata with cloud-init timeout error if the VM's vnic does not have security group. We can allow VM access 169.254.169.254 whether VM has security group or not. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1650486/+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