[Yahoo-eng-team] [Bug 1650694] Re: nova-manage cell_v2 discover_hosts is broken

2016-12-16 Thread Matt Riedemann
** 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

2016-12-16 Thread Launchpad Bug Tracker
[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

2016-12-16 Thread Launchpad Bug Tracker
[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

2016-12-16 Thread Launchpad Bug Tracker
[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

2016-12-16 Thread Matt Riedemann
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

2016-12-16 Thread Conrad Kimball
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

2016-12-16 Thread Steve Langasek
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

2016-12-16 Thread OpenStack Infra
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 Rosmaita 
Date:   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

2016-12-16 Thread OpenStack Infra
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 Benton 
Date:   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

2016-12-16 Thread Scott Moser
** 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

2016-12-16 Thread Scott Moser
** 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.

2016-12-16 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/388602
Committed: 
https://git.openstack.org/cgit/openstack/magnum/commit/?id=821bacc4a7f0b7a0f99d5b23da23375c3db41f64
Submitter: Jenkins
Branch:master

commit 821bacc4a7f0b7a0f99d5b23da23375c3db41f64
Author: yatin 
Date:   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

2016-12-16 Thread Scott Moser
** 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

2016-12-16 Thread Isaku Yamahata
** 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

2016-12-16 Thread OpenStack Infra
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 Rose 
Date:   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

2016-12-16 Thread Jakub Libosvar
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

2016-12-16 Thread Daniel Alvarez
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

2016-12-16 Thread OpenStack Infra
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 Xiao 
Date:   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

2016-12-16 Thread Barry Warsaw
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

2016-12-16 Thread Matthew Edmonds
*** 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)

2016-12-16 Thread jichenjc
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

2016-12-16 Thread Rob Cresswell
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

2016-12-16 Thread jichenjc
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

2016-12-16 Thread Manik Sidana
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

2016-12-16 Thread Piotr Misiak
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.

2016-12-16 Thread OpenStack Infra
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 Davidge 
Date:   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

2016-12-16 Thread Jesse
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