[Yahoo-eng-team] [Bug 1525163] [NEW] add-router-interface can not recover when failing create_port_post_commit

[Yushiro FURUKAWA]

Public bug reported:

When the following situation, a port created that no one can delete it:

  1. Configure ML2 plugin.
  2. Execute router-interface-add with subnet_id and failed in 
create_port_post_commit

  After that, undeletable port is created.
  Even if the admin tries to delete the port, he cannot delete it.

case1: delete-port with port_id
  => Port {port_id} cannot be deleted directly via the port API: has device 
owner network:router_interface.

case2: router-interface-delete with subnet_id or port_id
  => Router {router_id} has no interface on subnet {subnet_id}
  => Router {router_id} does not have an interface with id {port_id}

[How to fix]
  create_port_post_commit has a recovery process.  When failed, then calls
  delete_port.  However, in this case, 'device_owner' and 'device_id' have 
already
  registered at port's DB.  Therefore, delete_port fails due to device_owner 
check.
  
  Hence, I'll add 'l3_port_check=False' into delete_port's argument.

[Environment]
  trunk(devstack all-in-one with ML2 plugin(openvswitch))

[How to reproduce]
* You have to arrange create_port_post_commit shuld be failed.

source devstack/openrc admin admin
export TOKEN=`openstack token issue | grep ' id ' | get_field 2`

curl -s -X GET -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/ports | jq "."
{
  "ports": []
}

curl -i -X PUT -d '{"subnet_id":"214ebeb5-2d08-4ae5-9d60-3c7a76d56746"}'
-H "x-auth-token:$TOKEN"
192.168.122.253:9696/v2.0/routers/7d1561d1-71f9-4355-9248-5ac313de8ee3/add_router_interface

HTTP/1.1 409 Conflict
Content-Type: application/json; charset=UTF-8
Content-Length: 204
X-Openstack-Request-Id: req-ec3bad1f-84a2-4865-9cac-e63723c0a3bb
Date: Fri, 11 Dec 2015 10:11:11 GMT

{"NeutronError": {"message": "Port 570a4166-d463-4ee6-894b-f8aab6cc63b2
cannot be deleted directly via the port API: has device owner
network:router_interface.", "type": "ServicePortInUse", "detail": ""}}

$ curl -s -X GET -H "x-auth-token:$TOKEN" 
192.168.122.253:9696/v2.0/ports/570a4166-d463-4ee6-894b-f8aab6cc63b2 | jq "."
{
  "port": {
"mac_address": "fa:16:3e:c3:1c:8d",
"tenant_id": "4c0b8881d3e24a1cb1afe9ea6b07d946",
"binding:vif_type": "unbound",
"binding:vnic_type": "normal",
"binding:vif_details": {},
"binding:profile": {},
"port_security_enabled": false,
"device_owner": "network:router_interface",
"dns_assignment": [
  {
"fqdn": "host-172-16-1-1.openstacklocal.",
"ip_address": "172.16.1.1",
"hostname": "host-172-16-1-1"
  }
],
"extra_dhcp_opts": [],
"allowed_address_pairs": [],
"binding:host_id": "",
"status": "DOWN",
"fixed_ips": [
  {
"ip_address": "172.16.1.1",
"subnet_id": "214ebeb5-2d08-4ae5-9d60-3c7a76d56746"
  }
],
"id": "570a4166-d463-4ee6-894b-f8aab6cc63b2",
"security_groups": [],
"device_id": "7d1561d1-71f9-4355-9248-5ac313de8ee3",
"name": "",
"admin_state_up": true,
"network_id": "11515598-c20e-4e8a-94d0-1fef56f4607d",
"dns_name": ""
  }
}

** Affects: neutron
 Importance: Undecided
 Assignee: Yushiro FURUKAWA (y-furukawa-2)
 Status: New


** Tags: neutron

** Changed in: neutron
 Assignee: (unassigned) => Yushiro FURUKAWA (y-furukawa-2)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525163

Title:
  add-router-interface can not recover when failing
  create_port_post_commit

Status in neutron:
  New

Bug description:
  When the following situation, a port created that no one can delete
  it:

1. Configure ML2 plugin.
2. Execute router-interface-add with subnet_id and failed in 
create_port_post_commit

After that, undeletable port is created.
Even if the admin tries to delete the port, he cannot delete it.

  case1: delete-port with port_id
=> Port {port_id} cannot be deleted directly via the port API: has 
device owner network:router_interface.

  case2: router-interface-delete with subnet_id or port_id
=> Router {router_id} has no interface on subnet {subnet_id}
=> Router {router_id} does not have an interface with id {port_id}

  [How to fix]
create_port_post_commit has a recovery process.  When failed, then calls
delete_port.  However, in this case, 'device_owner' and 'device_id' have 
already
registered at port's DB.  Therefore, delete_port fails due to device_owner 
check.

Hence, I'll add 'l3_port_check=False' into delete_port's argument.

  [Environment]
trunk(devstack all-in-one with ML2 plugin(openvswitch))

  [How to reproduce]
  * You have to arrange create_port_post_commit shuld be failed.

  source devstack/openrc admin admin
  export TOKEN=`openstack token issue | grep ' id ' | get_field 2`

  curl -s -X GET -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/ports | jq 
"."
  {
"ports": []
  }

  curl -i -X PUT -d

[Yahoo-eng-team] [Bug 1525137] Re: doc wrong about BAK extensions of injection

[jichenjc]

commit 4474dce9e6b847a7691fc3f01d0c594061570d73 of nova
master is same

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: nova
 Assignee: (unassigned) => jichenjc (jichenjc)

-- 
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/1525137

Title:
  doc wrong about BAK extensions of injection

Status in OpenStack Compute (nova):
  New
Status in openstack-api-site:
  New

Bug description:
  I cat following contents into a.pwd , note the '1' at /bin/sh1 of ssh line 
it's on purpose
  after following opreations, I didn't see fllowing mechanism talked in doc
  For example, if the /etc/passwd file exists, it is backed up as 
/etc/passwd.bak.1246036261.5785.

  
  
https://github.com/openstack/nova/blob/master/api-guide/source/server_concepts.rst
  http://developer.openstack.org/api-ref-compute-v2.1.html

  
  $ sudo cat passwd
  root:x:0:0:root:/root:/bin/sh
  daemon:x:1:1:daemon:/usr/sbin:/bin/sh
  bin:x:2:2:bin:/bin:/bin/sh
  sys:x:3:3:sys:/dev:/bin/sh
  sync:x:4:100:sync:/bin:/bin/sync
  mail:x:8:8:mail:/var/spool/mail:/bin/sh
  proxy:x:13:13:proxy:/bin:/bin/sh
  www-data:x:33:33:www-data:/var/www:/bin/sh
  backup:x:34:34:backup:/var/backups:/bin/sh
  operator:x:37:37:Operator:/var:/bin/sh
  haldaemon:x:68:68:hald:/:/bin/sh
  dbus:x:81:81:dbus:/var/run/dbus:/bin/sh
  ftp:x:83:83:ftp:/home/ftp:/bin/sh
  nobody:x:99:99:nobody:/home:/bin/sh
  sshd:x:103:99:Operator:/var:/bin/sh1
  cirros:x:1000:1000:non-root user:/home/cirros:/bin/sh

  
  do the following 

  jichen@devstack1:/opt/stack/nova$ nova boot --file 
/etc/passwd=/home/jichen/a.pwd --image 9eee793a-25e5-4f42-bd9e-b869e60d3dbd 
--flavor m1.micro t6
  
+--++
  | Property | Value
  |
  
+--++
  | OS-DCF:diskConfig| MANUAL   
  |
  | OS-EXT-AZ:availability_zone  |  
  |
  | OS-EXT-STS:power_state   | 0
  |
  | OS-EXT-STS:task_state| scheduling   
  |
  | OS-EXT-STS:vm_state  | building 
  |
  | OS-SRV-USG:launched_at   | -
  |
  | OS-SRV-USG:terminated_at | -
  |
  | accessIPv4   |  
  |
  | accessIPv6   |  
  |
  | adminPass| 9VUVZY53nbFb 
  |
  | config_drive |  
  |
  | created  | 2015-12-11T09:19:28Z 
  |
  | flavor   | m1.micro (84)
  |
  | hostId   |  
  |
  | id   | 80f24559-2bd9-4709-b1a2-36709cfb3b50 
  |
  | image| cirros-0.3.4-x86_64-uec 
(9eee793a-25e5-4f42-bd9e-b869e60d3dbd) |

  
  jichen@devstack1:/opt/stack/nova$ ssh cirros@10.0.0.17
  The authenticity of host '10.0.0.17 (10.0.0.17)' can't be established.
  RSA key fingerprint is c2:44:7a:4f:61:cb:1b:95:b4:3a:49:fe:ce:dc:1e:20.
  Are you sure you want to continue connecting (yes/no)? yes
  Warning: Permanently added '10.0.0.17' (RSA) to the list of known hosts.
  cirros@10.0.0.17's password:

  
  $ cd /etc
  $ ls
  TZ cirros fstab  init.d ld.so.conf 
mtab   profileresolv.confshadow
  acpi   cirros-initgroup  inittabld.so.conf.d   
networkprotocols  screenrc   ssl
  blkid.tab  defaulthostname   inputrcmke2fs.conf
os-release random-seedsecuretty  sudoers
  blkid.tab.old  dropbear   hosts  issue  modules
passwd rc3.d  services   sudoers.d
  $ suco cat passwd
  -sh: suco: not found
  $ sudo cat passwd
  root:x:0:0:root:/root:/bin/sh
  daemon:x:1:1:daemon:/usr/sbin:/bin/sh
  bin:x:2:2:bin:/bin:/bin/sh
  sys:x:3:3:sys:/dev:/bin/sh
  

[Yahoo-eng-team] [Bug 1525196] [NEW] change default policy for password and resetstate

[jichenjc]

Public bug reported:

all cases from devstack, git head commit
4474dce9e6b847a7691fc3f01d0c594061570d73

I created an instance with admin tenant then use set-password with demo user, 
it make the instance ERROR
this kind of operations should not disabled by default

jichen@devstack1:~$ export OS_USERNAME=demo
jichen@devstack1:~$ nova set-password t5
New password:
Again:
ERROR (Conflict): Failed to set admin password on 
d3485187-779c-441f-8394-4e3d31234a9f because error setting admin password (HTTP 
409) (Request-ID: req-96b69164-e353-44f8-82a1-ecd20200173b)
jichen@devstack1:~$ nova list
+--+--+++-+---+
| ID   | Name | Status | Task State | Power 
State | Networks  |
+--+--+++-+---+
| d3485187-779c-441f-8394-4e3d31234a9f | t5   | ERROR  | -  | Running   
  | private=10.0.0.10 |
+--+--+++-+---+


Also, after the instance become ERROR state, I can't change it to ACTIVE state 
even if I am the owner of the instance

jichen@devstack1:~$ nova list
+--++-++-+--+
| ID   | Name   | Status  | Task State | Power 
State | Networks |
+--++-++-+--+
| 380e55e3-9726-4928-a44c-a206bc656f48 | t2 | ERROR   | -  | 
Running | private=10.0.0.8 |
| c426c3d0-a981-4839-969a-50d828e05459 | t4  é | SHUTOFF | -  | 
Shutdown| private=10.0.0.2 ||
+--++-++-+--+
jichen@devstack1:~$ nova reset-state --active t2
Reset state for server t2 failed: Policy doesn't allow 
os_compute_api:os-admin-actions:reset_state to be performed. (HTTP 403) 
(Request-ID: req-e7669a3c-3075-4a63-a7a6-f646013a5428)
ERROR (CommandError): Unable to reset the state for the specified server(s)

** Affects: nova
 Importance: Undecided
 Assignee: jichenjc (jichenjc)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => jichenjc (jichenjc)

-- 
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/1525196

Title:
  change default policy for password and resetstate

Status in OpenStack Compute (nova):
  New

Bug description:
  all cases from devstack, git head commit
  4474dce9e6b847a7691fc3f01d0c594061570d73

  I created an instance with admin tenant then use set-password with demo user, 
it make the instance ERROR
  this kind of operations should not disabled by default

  jichen@devstack1:~$ export OS_USERNAME=demo
  jichen@devstack1:~$ nova set-password t5
  New password:
  Again:
  ERROR (Conflict): Failed to set admin password on 
d3485187-779c-441f-8394-4e3d31234a9f because error setting admin password (HTTP 
409) (Request-ID: req-96b69164-e353-44f8-82a1-ecd20200173b)
  jichen@devstack1:~$ nova list
  
+--+--+++-+---+
  | ID   | Name | Status | Task State | Power 
State | Networks  |
  
+--+--+++-+---+
  | d3485187-779c-441f-8394-4e3d31234a9f | t5   | ERROR  | -  | Running 
| private=10.0.0.10 |
  
+--+--+++-+---+

  
  Also, after the instance become ERROR state, I can't change it to ACTIVE 
state even if I am the owner of the instance

  jichen@devstack1:~$ nova list
  
+--++-++-+--+
  | ID   | Name   | Status  | Task State | 
Power State | Networks |
  
+--++-++-+--+
  | 380e55e3-9726-4928-a44c-a206bc656f48 | t2 | ERROR   | -  | 
Running | private=10.0.0.8 |
  | c426c3d0-a981-4839-969a-50d828e05459 | t4  é | SHUTOFF | -  | 
Shutdown| private=10.0.0.2 ||
  
+--++-++-+--+
  jichen@devstack1:~$ nova reset-state --active t2
  Reset state for server t2 failed: Policy doesn't allow 
os_compute_api:os-admin-actions:reset_state to be performed. (HTTP 403) 
(Request-ID: req-e7669a3c-3075-4a63-a7a6-f646013a5428)
  ERROR (CommandError): Unable to reset the state for the specified server(s)

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 1461406] Re: libvirt: missing iotune parse for LibvirtConfigGuestDisk

[OpenStack Infra]

** Changed in: nova
   Status: Expired => In Progress

** Changed in: nova
 Assignee: (unassigned) => ChangBo Guo(gcb) (glongwave)

-- 
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/1461406

Title:
  libvirt: missing  iotune parse for  LibvirtConfigGuestDisk

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  We support  instance disk IO control with  iotune like :


  102400


  we set iotune in class LibvirtConfigGuestDisk  in libvirt/config.py . The 
method parse_dom doesn't parse iotue options now.
  Need fix that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1461406/+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 1525002] Re: The ironic driver needs to scale back how many errors it traces out

[Dmitry Tantsur]

Actually it's even more interesting: traceback comes from ironic as part
of message instead of details. Investigating on...

** Also affects: ironic
   Importance: Undecided
   Status: New

** Changed in: ironic
   Status: New => Confirmed

** Changed in: ironic
   Importance: Undecided => Low

** Changed in: ironic
 Assignee: (unassigned) => Dmitry Tantsur (divius)

-- 
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/1525002

Title:
  The ironic driver needs to scale back how many errors it traces out

Status in Ironic:
  Confirmed
Status in OpenStack Compute (nova):
  Confirmed
Status in python-ironicclient:
  Triaged

Bug description:
  The amount of tracing in this n-cpu log is a bit much:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE

  Like these warnings:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  
agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-12-10_16_11_48_799

  2015-12-10 16:11:48.798 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Request returned failure status.
  2015-12-10 16:11:48.799 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Error contacting Ironic server: Node 1 is 
locked by host localhost, please retry after the current operation is completed.
  Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", 
line 150, in inner
  return func(*args, **kwargs)

File "/opt/stack/new/ironic/ironic/conductor/manager.py", line 1519, in 
update_port
  purpose='port update') as task:

File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 152, in 
acquire
  driver_name=driver_name, purpose=purpose)

File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 222, in 
__init__
  self.release_resources()

File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
204, in __exit__
  six.reraise(self.type_, self.value, self.tb)

File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 203, in 
__init__
  self._lock()

File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 243, in 
_lock
  reserve_node()

File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in 
wrapped_f
  return Retrying(*dargs, **dkw).call(f, *args, **kw)

File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 212, in call
  raise attempt.get()

File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 247, in get
  six.reraise(self.value[0], self.value[1], self.value[2])

File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 200, in call
  attempt = Attempt(fn(*args, **kwargs), attempt_number, False)

File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 236, in 
reserve_node
  self.node_id)

File "/opt/stack/new/ironic/ironic/objects/node.py", line 260, in reserve
  db_node = cls.dbapi.reserve_node(tag, node_id)

File "/opt/stack/new/ironic/ironic/db/sqlalchemy/api.py", line 226, in 
reserve_node
  host=node['reservation'])

  NodeLocked: Node 1 is locked by host localhost, please retry after the 
current operation is completed.
   (HTTP 409). Attempt 1 of 61

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1525002/+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 1368661] Re: Unit tests sometimes fail because of stale pyc files

[Julien Danjou]

** Changed in: oslo.cache
   Status: In Progress => Invalid

** Changed in: oslo.concurrency
   Status: In Progress => Invalid

** Changed in: oslo.log
   Status: In Progress => 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/1368661

Title:
  Unit tests sometimes fail because of stale pyc files

Status in congress:
  Fix Released
Status in Gnocchi:
  Invalid
Status in Ironic:
  Fix Released
Status in Magnum:
  Fix Released
Status in Mistral:
  Fix Released
Status in Monasca:
  Fix Committed
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Released
Status in oslo.cache:
  Invalid
Status in oslo.concurrency:
  Invalid
Status in oslo.log:
  Invalid
Status in oslo.service:
  Fix Committed
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Committed
Status in python-keystoneclient:
  Fix Committed
Status in python-magnumclient:
  Fix Released
Status in python-mistralclient:
  Fix Committed
Status in python-neutronclient:
  In Progress
Status in Python client library for Sahara:
  Fix Committed
Status in python-solumclient:
  In Progress
Status in python-swiftclient:
  In Progress
Status in python-troveclient:
  Fix Committed
Status in Python client library for Zaqar:
  Fix Committed
Status in Solum:
  In Progress
Status in OpenStack Object Storage (swift):
  New
Status in Trove:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Because python creates pyc files during tox runs, certain changes in
  the tree, like deletes of files, or switching branches, can create
  spurious errors. This can be suppressed by PYTHONDONTWRITEBYTECODE=1
  in the tox.ini.

To manage notifications about this bug go to:
https://bugs.launchpad.net/congress/+bug/1368661/+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 1525259] [NEW] Add request_ids attribute to v2 schemas

[Abhishek Kekane]

Public bug reported:

We are adding support for returning ‘x-openstack-request-id’  to the caller as 
per the design proposed in cross-project specs:
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

Problem Description:
Cannot add a new property of list type to the warlock.model object.

The requirement we are trying to meet is to make the request id
available to the user of the client library [3].  The user typically
doesn't have access to the headers, so the request id needs to be part
of the payload returned from each method. In other clients that work
with simple data types, we've subclassed dict, list, etc. to add the
extra property. This adds the request id to the return value without
making a breaking change to the API of the client library.

How is a model object created:
Let’s take an example of glanceclient.api.v2.images.get() call [1]:

Here after getting the response we call model() method. This model()
does the job of creating a warlock.model object(essentially a dict)
based on the schema given as argument (image schema retrieved from
glance in this case). Inside model() the raw() method simply return the
image schema as JSON object. The advantage of this warlock.model object
over a simple dict is that it validates any changes to object based on
the rules specified in the reference schema.  The keys of this  model
object are available as object properties to the caller.

Underlying reason:
The schema for different sub APIs is returned a bit differently. For images, 
metadef APIs glance.schema.Schema.raw() is used which returns a schema 
containing “additionalProperties”: {“type”: “string”}. Whereas for members and 
tasks APIs glance.schema.Schema.minimal() is used to return schema object which 
does not contain “additionalProperties”.

So we can add extra properties of any type to the model object returned
from members or tasks API but for images and metadef APIs we can only
add properties which can be of type string. Also for the latter case we
depend on the glance configuration to allow additional properties.

As per our analysis we have come up with two approaches for resolving
this issue:

Approach #1:  Inject request_ids property in the warlock model object in glance 
client
Here we do the following:
1. Inject the ‘request_ids’ as additional property into the model 
object(returned from model())
2. Return the model object which now contains request_ids property

Limitations:
1. Because the glance schemas for images and metadef only allows additional 
properties of type string, so even though natural type of request_ids should be 
list we have to make it as a comma separated ‘string’ of request ids as a 
compromise.
2. Lot of extra code is needed to wrap objects returned from the client API so 
that the caller can get request ids. For example we need to write wrapper 
classes for dict, list, str, tuple, generator.
3. Not a good design as we are adding a property which should actually be a 
base property but added as additional property as a compromise.
4. There is a dependency on glance whether to allow custom/additional 
properties or not. [2]

Approach #2:  Add ‘request_ids’ property to all schema definitions in
glance

Here we add  ‘request_ids’ property as follows to the various APIs
(schema):

“request_ids”: {
  "type": "array",
  "items": {
"type": "string"
  }
}

Doing this will make changes in glance client very simple as compared to 
approach#1.
This also looks a better design as it will be consistent.
We simply need to modify the request_ids property in  various API calls for 
example glanceclient.v2.images.get().

[1] 
https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L179
[2] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L944
[3] 
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

** Affects: glance
 Importance: Wishlist
 Assignee: Abhishek Kekane (abhishek-kekane)
 Status: New


** Tags: lite-spec

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1525259

Title:
  Add request_ids attribute to v2 schemas

Status in Glance:
  New

Bug description:
  We are adding support for returning ‘x-openstack-request-id’  to the caller 
as per the design proposed in cross-project specs:
  
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

  Problem Description:
  Cannot add a new property of list type to the warlock.model object.

  The requirement we are trying to meet is to make the request id
  available to the user of the client library [3].  The user typically
  doesn't have access to the headers, so the request id needs to be part
  of the payload returned from each method. In other clients that work
  with simple data types, we've subclassed dict, list, etc. to add the
  extra property. This adds the 

[Yahoo-eng-team] [Bug 1456439] Re: Disable Disassociate Floating IP to an instance in error state

[Timur Sufiev]

*** This bug is a duplicate of bug 1441088 ***
https://bugs.launchpad.net/bugs/1441088

** This bug has been marked a duplicate of bug 1441088
   hide disassociate floating ip when no floating ip attached

-- 
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/1456439

Title:
  Disable Disassociate Floating IP to an instance in error state

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  
  "Disassociate Floating IP" button should be disabled for instances in error 
state.

  As per the following bug, it has disabled only Associate Floating IP. 
  https://bugs.launchpad.net/horizon/+bug/1374576

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1456439/+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 1525250] [NEW] Failure when federated user name contains non ascii characters

[Jon Kåre Hellan]

Public bug reported:

When logging in with openid-connect, I get

 '{"error": {"message": "An unexpected error prevented the server from
fulfilling your request: 'ascii' codec can't decode byte 0xc3 in
position 5: ordinal not in range(128) (Disable debug mode to suppress
these details.)", "code": 500, "title": "Internal Server Error"}}'

My name has an 'å'. I suspect there is a connection.

Coincidentally(?), if I do the following in  python shell:

>>> unicode('Jon Kåre Hellan')

I get 'UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
position 5: ordinal not in range(128)'

This is on liberty, using federation in contrib. On master, federation
has been moved up from contrib, but I couldn't see any code changes that
would help.

Stack trace:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 248, in 
__call__
result = method(context, **params)
  File 
"/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", 
line 315, in federated_sso_auth
protocol_id)
  File 
"/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", 
line 297, in federated_authentication
return self.authenticate_for_token(context, auth=auth)
  File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 
385, in authenticate_for_token
self.authenticate(context, auth_info, auth_context)
  File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 
510, in authenticate
auth_context)
  File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 
69, in authenticate
self.identity_api)
  File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 
144, in handle_unscoped_token
federation_api, identity_api)
  File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 
188, in apply_mapping_filter
identity_provider, protocol, assertion)
  File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/core.py", 
line 90, in evaluate
mapped_properties = rule_processor.process(assertion_data)
  File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", 
line 470, in process
new_local = self._update_local_mapping(local, direct_maps)
  File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", 
line 611, in _update_local_mapping
new_value = self._update_local_mapping(v, direct_maps)
  File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", 
line 613, in _update_local_mapping
new_value = v.format(*direct_maps)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal 
not in range(128)

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
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/1525250

Title:
  Failure when federated user name contains non ascii characters

Status in OpenStack Identity (keystone):
  New

Bug description:
  When logging in with openid-connect, I get

   '{"error": {"message": "An unexpected error prevented the server from
  fulfilling your request: 'ascii' codec can't decode byte 0xc3 in
  position 5: ordinal not in range(128) (Disable debug mode to suppress
  these details.)", "code": 500, "title": "Internal Server Error"}}'

  My name has an 'å'. I suspect there is a connection.

  Coincidentally(?), if I do the following in  python shell:

  >>> unicode('Jon Kåre Hellan')

  I get 'UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in
  position 5: ordinal not in range(128)'

  This is on liberty, using federation in contrib. On master, federation
  has been moved up from contrib, but I couldn't see any code changes
  that would help.

  Stack trace:

  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 248, 
in __call__
  result = method(context, **params)
File 
"/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", 
line 315, in federated_sso_auth
  protocol_id)
File 
"/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", 
line 297, in federated_authentication
  return self.authenticate_for_token(context, auth=auth)
File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 
385, in authenticate_for_token
  self.authenticate(context, auth_info, auth_context)
File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 
510, in authenticate
  auth_context)
File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", 
line 69, in authenticate
  self.identity_api)
File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", 
line 144, in handle_unscoped_token
  federation_api, identity_api)
File 

[Yahoo-eng-team] [Bug 1525219] [NEW] Trust-scoped user requests failed while using fernet tokens

[Oleksii Chuprykov]

Public bug reported:

1. Enable reauthentication in heat: add reauthentication_auth_method = trusts 
in heat.conf
2. Enable fernet tokens in keystone.
3. Create stack with the following template:

heat_template_version: 2013-05-23
parameters:
  key_name:
type: string
default: default
  flavor:
type: string
default: m1.tiny
  image:
type: string
default: fedora-heat-test-image

resources:
  server:
type: OS::Nova::Server
properties:
  image: {get_param: image}
  flavor: {get_param: flavor}

heat stack-create abc -f 

Creation stack failed.

Found this in heat logs:
2015-12-11 14:56:52.992 INFO heat.engine.resource [-] CREATE: Server "server" 
Stack "abc" [b1957493-41b6-437d-87af-64ebe166e6dd]
2015-12-11 14:56:52.992 TRACE heat.engine.resource Traceback (most recent call 
last):
2015-12-11 14:56:52.992 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resource.py", line 636, in _action_recorder
2015-12-11 14:56:52.992 TRACE heat.engine.resource yield
2015-12-11 14:56:52.992 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resource.py", line 703, in _do_action
2015-12-11 14:56:52.992 TRACE heat.engine.resource pre_func()
2015-12-11 14:56:52.992 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/properties.py", line 410, in validate
2015-12-11 14:56:52.992 TRACE heat.engine.resource message=ex.error_message
2015-12-11 14:56:52.992 TRACE heat.engine.resource StackValidationFailed: 
Property error: server.Properties.image: Error retrieving image list from 
glance: 503 Service Unavailable: The server is currently unavailable. Please 
try again at a later time. (HTTP 503)

Found in glance log:
380cf351a6a29fbe971e3a1b32" -H "User-Agent: python-keystoneclient" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}15a31c1b48e559620d731e3756fb882eb3796ef3" from (pid=3209) 
_http_log_request 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:198
2015-12-11 14:56:52.987 DEBUG keystoneclient.session [-] RESP: [403] 
Content-Length: 131 Vary: X-Auth-Token Keep-Alive: timeout=5, max=99 Server: 
Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date: Fri, 11 Dec 2015 12:56:52 
GMT Content-Type: application/json x-openstack-request-id: 
req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 
RESP BODY: {"error": {"message": "User is not a trustee. (Disable debug mode to 
suppress these details.)", "code": 403, "title": "Forbidden"}}
 from (pid=3209) _http_log_response 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:216
2015-12-11 14:56:52.987 DEBUG keystoneclient.session [-] Request returned 
failure status: 403 from (pid=3209) request 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:401
2015-12-11 14:56:52.989 ERROR keystonemiddleware.auth_token [-] Bad response 
code while validating token: 403
2015-12-11 14:56:52.989 WARNING keystonemiddleware.auth_token [-] Identity 
response: {"error": {"message": "User is not a trustee. (Disable debug mode to 
suppress these details.)", "code": 403, "title": "Forbidden"}}
2015-12-11 14:56:52.989 CRITICAL keystonemiddleware.auth_token [-] Unable to 
validate token: Failed to fetch token data from identity server

Keystone logs:
2015-12-11 14:56:52.975204 10268 DEBUG keystone.middleware.auth 
[req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 
4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: auth_context: 
{'is_delegated_auth': False, 'access_token_id': None, 'user_id': 
u'be1cc1b5290a4e8c9e54abea7d247d77', 'roles': [u'service'], 'user_domain_id': 
u'default', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 
'token': , 'project_id': 
u'4eb9350e276f49ddbea4c7d2e6f0a013', 'trust_id': None, 'project_domain_id': 
u'default'} process_request /opt/stack/keystone/keystone/middleware/auth.py:187
2015-12-11 14:56:52.975976 10268 INFO keystone.common.wsgi 
[req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 
4eb9350e276f49ddbea4c7d2e6f0a013 - default default] GET 
http://192.168.122.82:35357/v3/auth/tokens
2015-12-11 14:56:52.976121 10268 DEBUG keystone.common.controller 
[req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 
4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: Authorizing 
identity:validate_token() _build_policy_check_credentials 
/opt/stack/keystone/keystone/common/controller.py:62
2015-12-11 14:56:52.976227 10268 DEBUG keystone.common.controller 
[req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 
4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: using auth context 
from the request environment _build_policy_check_credentials 
/opt/stack/keystone/keystone/common/controller.py:67
2015-12-11 14:56:52.976640 10268 WARNING keystone.token.providers.fernet.utils 
[req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 
4eb9350e276f49ddbea4c7d2e6f0a013 - default default] [fernet_tokens] 
key_repository is world 

[Yahoo-eng-team] [Bug 1509121] Re: [UI] job_binaries Exception Value: too many values to unpack

[Vitaly Gridnev]

** Also affects: horizon
   Importance: Undecided
   Status: New

-- 
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/1509121

Title:
  [UI] job_binaries Exception Value: too many values to unpack

Status in OpenStack Dashboard (Horizon):
  New
Status in Sahara:
  Fix Released

Bug description:
  I accidentally created a Sahara EDP Job Binary, in RDO Kilo, with the
  following properties:

  Name
  Binary
  ID
  c1fa1a5b-2458-43cc-9fbc-52a54fe74009
  URL
  swift://swift://container.sahara/Test-Private-Container/
  Description
  None

  When I try to "Delete the Job Binary" the Dashboard displays a full-
  page exception. Here is the Traceback:

  Environment:

  Request Method: POST
  Request URL: https://my.org/dashboard/project/data_processing/job_binaries/

  Django Version: 1.8.3
  Python Version: 2.7.5
  Installed Applications:
  ['openstack_dashboard.dashboards.project',
   'openstack_dashboard.dashboards.admin',
   'openstack_dashboard.dashboards.identity',
   'openstack_dashboard.dashboards.settings',
   'openstack_dashboard',
   'django.contrib.contenttypes',
   'django.contrib.auth',
   'django.contrib.sessions',
   'django.contrib.messages',
   'django.contrib.staticfiles',
   'django.contrib.humanize',
   'django_pyscss',
   'openstack_dashboard.django_pyscss_fix',
   'compressor',
   'horizon',
   'openstack_auth']
  Installed Middleware:
  ('django.middleware.common.CommonMiddleware',
   'django.middleware.csrf.CsrfViewMiddleware',
   'django.contrib.sessions.middleware.SessionMiddleware',
   'django.contrib.auth.middleware.AuthenticationMiddleware',
   'django.contrib.messages.middleware.MessageMiddleware',
   'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
   'horizon.middleware.HorizonMiddleware',
   'django.middleware.locale.LocaleMiddleware',
   'django.middleware.clickjacking.XFrameOptionsMiddleware')

  Traceback:
  File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in 
get_response
    132. response = wrapped_callback(request, 
*callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
    36. return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
    52. return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
    36. return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
    84. return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in view
    71. return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in 
dispatch
    89. return handler(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in post
    223. return self.get(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in get
    159. handled = self.construct_tables()
  File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in 
construct_tables
    150. handled = self.handle_table(table)
  File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in 
handle_table
    125. handled = self._tables[name].maybe_handle()
  File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in maybe_handle
    1640. return self.take_action(action_name, obj_id)
  File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in take_action
    1482. response = action.multiple(self, self.request, 
obj_ids)
  File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in multiple
    302. return self.handle(data_table, request, object_ids)
  File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle
    827. exceptions.handle(request, ignore=ignore)
  File "/usr/lib/python2.7/site-packages/horizon/exceptions.py" in handle
    364. six.reraise(exc_type, exc_value, exc_traceback)
  File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle
    811. self.action(request, datum_id)
  File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in action
    926. return self.delete(request, obj_id)
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/data_processing/job_binaries/tables.py"
 in delete
    56. (jb_type, jb_internal_id) = jb.url.split("://")

  Exception Type: ValueError at /project/data_processing/job_binaries/
  Exception Value: too many values to unpack

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 1525226] [NEW] Write an integration test for joint behavior of inline cell edit & confirmation of entity deletion

[Timur Sufiev]

Public bug reported:

While fix bug 1481850 keeps entity names shown in Confirm
Delete/whatever modal dialog up to date, we should provide a test for
this regression. Since it's very hard to write a simple python/js unit
test on a border of python and js functionality (see the fix at
https://review.openstack.org/256362), the simplest approach is to test
this by means of Selenium integration tests.

The natural candidate here is Identity->Projects table, since it was the
table the original bug was filed for.

** Affects: horizon
 Importance: Wishlist
 Status: New


** Tags: integration-tests

** Description changed:

  While fix bug 1481850 keeps entity names shown in Confirm
  Delete/whatever modal dialog up to date, we should provide a test for
  this regression. Since it's very hard to write a simple python/js unit
  test on a border of python and js functionality (see the fix at
  https://review.openstack.org/256362), the simplest approach is to test
  this by means of Selenium integration tests.
+ 
+ The natural candidate here is Identity->Projects table, since it was the
+ table the original bug was filed for.

-- 
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/1525226

Title:
  Write an integration test for joint behavior of inline cell edit &
  confirmation of entity deletion

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  While fix bug 1481850 keeps entity names shown in Confirm
  Delete/whatever modal dialog up to date, we should provide a test for
  this regression. Since it's very hard to write a simple python/js unit
  test on a border of python and js functionality (see the fix at
  https://review.openstack.org/256362), the simplest approach is to test
  this by means of Selenium integration tests.

  The natural candidate here is Identity->Projects table, since it was
  the table the original bug was filed for.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525226/+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 1525309] [NEW] action_present and action_past attributes have to be deprecated in favor of action_present and action_past methods

[Yves-Gwenael Bourhis]

Public bug reported:

actions.BatchAction subclasses need to use action_present and action_past 
methodes and triger a deprecation warning when using attributes
If we don't do so, attributes will ever come back and are not translatable.

** Affects: horizon
 Importance: Undecided
 Assignee: Yves-Gwenael Bourhis (yves-gwenael-bourhis)
 Status: In Progress

-- 
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/1525309

Title:
  action_present and action_past attributes have to be deprecated in
  favor of action_present and action_past methods

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  actions.BatchAction subclasses need to use action_present and action_past 
methodes and triger a deprecation warning when using attributes
  If we don't do so, attributes will ever come back and are not translatable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525309/+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 1525074] Re: test for submit

[Alexis Lee]

** 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/1525074

Title:
  test for submit

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  just test for submit a bug report

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1525074/+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 1525319] [NEW] Cisco apic router_id field length incorrectly changed for Mitaka

[Henry Gessau]

Public bug reported:

Bug #1465678 was intended to be included in Liberty but it did not make
it into the Liberty release.

The neutron patch must be reverted and instead the field size change
must be done in the vendor repo for the Mitaka release.

** Affects: networking-cisco
 Importance: Undecided
 Assignee: Henry Gessau (gessau)
 Status: New

** Affects: neutron
 Importance: Undecided
 Assignee: Henry Gessau (gessau)
 Status: In Progress


** Tags: cisco db

** Tags added: cisco

** Tags added: db

** Also affects: networking-cisco
   Importance: Undecided
   Status: New

** Changed in: neutron
 Assignee: (unassigned) => Henry Gessau (gessau)

** Changed in: networking-cisco
 Assignee: (unassigned) => Henry Gessau (gessau)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525319

Title:
  Cisco apic router_id field length incorrectly changed for Mitaka

Status in networking-cisco:
  New
Status in neutron:
  In Progress

Bug description:
  Bug #1465678 was intended to be included in Liberty but it did not
  make it into the Liberty release.

  The neutron patch must be reverted and instead the field size change
  must be done in the vendor repo for the Mitaka release.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-cisco/+bug/1525319/+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 1524476] Re: Compute API in Compute API Guide

[OpenStack Infra]

Reviewed:  https://review.openstack.org/255729
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=a54834df23e26f2255578dffb16fdac023fd495e
Submitter: Jenkins
Branch:master

commit a54834df23e26f2255578dffb16fdac023fd495e
Author: Andreas Jaeger 
Date:   Thu Dec 10 09:34:04 2015 +0100

Report compute-api bugs against nova

For compute-api set the launchpad project users report bugs
against to "nova". Users can report bugs using the "bug icon" that will
directly link to the launchpad project, it currently goes to
"openstack-manuals" which is wrong for this content.

This variable is used by openstackdocstheme 1.2.6.

Closes-Bug: #1524476
Change-Id: I08ba11bb1c5388bc4611cea581274ac5d724c8d9


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1524476

Title:
  Compute API in Compute API Guide

Status in OpenStack Compute (nova):
  Fix Released
Status in openstack-manuals:
  In Progress

Bug description:
  The conf.py for the project has what I thought is the right
  configuration, but even so the Log a Bug link on the Compute API guide
  and the OpenStack SDK docs on developer.openstack.org are going to log
  bugs in OpenStack-manuals.

  Source link is correct, bug tag is correct, but the launchpad link is
  incorrect.

  ---
  Release: 2.1.0 on 2015-12-09 11:33
  SHA: b5890b3c36613919338f83c4f59225f424c99cb1
  Source: 
http://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/index.rst
  URL: http://developer.openstack.org/api-guide/compute/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524476/+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 1525282] [NEW] wrap_exception decorator does not grab arguments properly for decorated methods

[Andrew Laski]

Public bug reported:

The wrap_exception decorator, which pulls the wrapped method arguments
and sends a notification if there is an exception raised from the
method, is not pulling the full list of arguments.  This is because of a
combination of relying on safe_utils.getcallargs which doesn't pull
arguments when the called method uses *args or **kwargs and not using
get_wrapped_function to get the call args for the decorated method.
What is currently happening is getcallargs is passed a decorated method
and pulls the argument list for the decorator, and most decorators are
defined with *args and **kwargs.  Instead get_wrapped_function should be
called first and the result should be passed to getcallargs.

** Affects: nova
 Importance: Low
 Assignee: Andrew Laski (alaski)
 Status: In Progress

-- 
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/1525282

Title:
  wrap_exception decorator does not grab arguments properly for
  decorated methods

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  The wrap_exception decorator, which pulls the wrapped method arguments
  and sends a notification if there is an exception raised from the
  method, is not pulling the full list of arguments.  This is because of
  a combination of relying on safe_utils.getcallargs which doesn't pull
  arguments when the called method uses *args or **kwargs and not using
  get_wrapped_function to get the call args for the decorated method.
  What is currently happening is getcallargs is passed a decorated
  method and pulls the argument list for the decorator, and most
  decorators are defined with *args and **kwargs.  Instead
  get_wrapped_function should be called first and the result should be
  passed to getcallargs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1525282/+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 1525279] [NEW] Request Liberty release for networking-bgpvpn

[Mathieu Rohon]

Public bug reported:

The networking-bgpvpn project is now ready to have its first release.

We'd like to create a dedicated branch to backport needed patches in the
future.

Release Info :

Current branch : master
Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc
New Tag: 3.0.0

** Affects: bgpvpn
 Importance: Undecided
 Status: New

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: release-subproject

** 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/1525279

Title:
  Request Liberty release for networking-bgpvpn

Status in bgpvpn:
  New
Status in neutron:
  New

Bug description:
  The networking-bgpvpn project is now ready to have its first release.

  We'd like to create a dedicated branch to backport needed patches in
  the future.

  Release Info :

  Current branch : master
  Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc
  New Tag: 3.0.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1525279/+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 1525295] [NEW] subnet listing is too slow with rbac

[Eugene Nikanorov]

Public bug reported:

subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware.
60% of the time is consumed by the calculation of 'shared' attribute of the 
subnet which involves rbac rules.

This makes horizon barely usable as number of networks grow.

** Affects: neutron
 Importance: Undecided
 Status: New

** Description changed:

  subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware.
- 60% of the time is consumed by the calculation of 'shared' attribute of the 
subnet.
+ 60% of the time is consumed by the calculation of 'shared' attribute of the 
subnet which involves rbac rules.
  
  This makes horizon barely usable as number of networks grow.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525295

Title:
  subnet listing is too slow with rbac

Status in neutron:
  New

Bug description:
  subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware.
  60% of the time is consumed by the calculation of 'shared' attribute of the 
subnet which involves rbac rules.

  This makes horizon barely usable as number of networks grow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525295/+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 1525275] Re: Loading configuration items from keystoneauth is causing warnings

[Brant Knudson]

** Also affects: keystoneauth
   Importance: Undecided
   Status: New

** No longer affects: keystone

-- 
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/1525275

Title:
  Loading configuration items from keystoneauth is causing warnings

Status in keystoneauth:
  New

Bug description:
  Neutron uses the oslo-config-generator to automatically generate
  configuration files.

  Some configuration items are authentication items retrieved from
  keystone like 'domain-id', 'password' etc. These items are retrieved
  in
  https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275.

  The following warnings are now been output when you run the tox target
  to generate config items (tox -e genconfig) or pep8 as it also
  generates the config files:

  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_type should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_section should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth-url should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option password should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option trust-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-id should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-name should have a type derived from 
types.ConfigType instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-id should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)
  
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-name should have a type derived from types.ConfigType 
instead of 
    warnings.warn(msg)

  These warnings may 

[Yahoo-eng-team] [Bug 1524476] Re: Compute API in Compute API Guide

[Andreas Jaeger]

** 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 OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1524476

Title:
  Compute API in Compute API Guide

Status in OpenStack Compute (nova):
  Fix Released
Status in openstack-manuals:
  Fix Released

Bug description:
  The conf.py for the project has what I thought is the right
  configuration, but even so the Log a Bug link on the Compute API guide
  and the OpenStack SDK docs on developer.openstack.org are going to log
  bugs in OpenStack-manuals.

  Source link is correct, bug tag is correct, but the launchpad link is
  incorrect.

  ---
  Release: 2.1.0 on 2015-12-09 11:33
  SHA: b5890b3c36613919338f83c4f59225f424c99cb1
  Source: 
http://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/index.rst
  URL: http://developer.openstack.org/api-guide/compute/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524476/+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 1525275] [NEW] Loading configuration items from keystoneauth is causing warnings

[Martin Hickey]

Public bug reported:

Neutron uses the oslo-config-generator to automatically generate
configuration files.

Some configuration items are authentication items retrieved from
keystone like 'domain-id', 'password' etc. These items are retrieved in
https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275.

The following warnings are now been output when you run the tox target
to generate config items (tox -e genconfig) or pep8 as it also generates
the config files:

/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_type should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth_section should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option auth-url should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-id should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option default-domain-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-id should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option domain-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option password should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-id should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-domain-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-id should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option project-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-id should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option tenant-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option trust-id should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-id should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-domain-name should have a type derived from 
types.ConfigType instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-id should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)
/opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204:
 UserWarning: Option user-name should have a type derived from types.ConfigType 
instead of 
  warnings.warn(msg)

These warnings may have been introduced with the following change:
https://github.com/openstack/neutron/commit/a37e11f637b21785307e14e9725de3db14a1d37b

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  Neutron uses the oslo-config-generator to automatically generate
  configuration files.
  
  Some configuration items are authentication items retrieved from
  keystone like 'domain-id', 'password' etc. These items are retrieved in
  

[Yahoo-eng-team] [Bug 1303856] Re: please mark a volume as read-only

[Sean McGinnis]

** Changed in: python-cinderclient
   Status: In Progress => Won't Fix

-- 
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/1303856

Title:
  please mark a volume as read-only

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in python-cinderclient:
  Won't Fix

Bug description:
  currently, once I update a volume to read-only its only shown in the 
metadata. 
  however, I think a read-only change (could be worse when we change from 
read-only to read/write) is really important and should be very visible to the 
user. 

  as you can see, we can only see that the volume is read-only in the
  metadata:

  [root@host ~(keystone_admin)]# cinder create --display-name dafna 10
  +-+--+
  |   Property  |Value |
  +-+--+
  | attachments |  []  |
  |  availability_zone  | nova |
  |   bootable  |false |
  |  created_at |  2014-04-03T13:16:03.137237  |
  | display_description | None |
  | display_name|dafna |
  |  encrypted  |False |
  |  id | 51c841ec-24a5-49fe-8441-01593b39b2f7 |
  |   metadata  |  {}  |
  | size|  10  |
  | snapshot_id | None |
  | source_volid| None |
  |status   |   creating   |
  | volume_type | None |
  +-+--+
  [root@host ~(keystone_admin)]# cinder list 
  
+--+---+--+--+-+--+-+
  |  ID  |   Status  | Display Name | Size | 
Volume Type | Bootable | Attached to |
  
+--+---+--+--+-+--+-+
  | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available |dafna |  10  |
 None|  false   | |
  | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available |   emptyVol   |  1   |
 None|  false   | |
  | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage |  1   |
 None|   true   | |
  
+--+---+--+--+-+--+-+

  [root@host ~(keystone_admin)]# cinder readonly-mode-update 
51c841ec-24a5-49fe-8441-01593b39b2f7 true
  [root@host ~(keystone_admin)]# cinder list 
  
+--+---+--+--+-+--+-+
  |  ID  |   Status  | Display Name | Size | 
Volume Type | Bootable | Attached to |
  
+--+---+--+--+-+--+-+
  | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available |dafna |  10  |
 None|  false   | |
  | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available |   emptyVol   |  1   |
 None|  false   | |
  | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage |  1   |
 None|   true   | |
  
+--+---+--+--+-+--+-+
  [root@host ~(keystone_admin)]# cinder show 
51c841ec-24a5-49fe-8441-01593b39b2f7
  ++--+
  |Property|Value |
  ++--+
  |  attachments   |  []  |
  |   availability_zone| nova |
  |bootable|false |
  |   created_at   |  2014-04-03T13:16:03.00  |
  |  display_description   | None |
  |  display_name  |dafna |
  |   encrypted|False |
  |   id   | 51c841ec-24a5-49fe-8441-01593b39b2f7 |
  |metadata|{u'readonly': u'True'}|
  | os-vol-host-attr:host  |  orange-vdsf.qa.lab.tlv.redhat.com   |
  | os-vol-mig-status-attr:migstat | None |
  | 

[Yahoo-eng-team] [Bug 1525410] [NEW] Volume Manage QoS Specs table is too small

[Cindy Lu]

Public bug reported:

The table should stretch across the size of the browser window.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "Screen Shot 2015-12-11 at 1.27.10 PM.png"
   
https://bugs.launchpad.net/bugs/1525410/+attachment/4533420/+files/Screen%20Shot%202015-12-11%20at%201.27.10%20PM.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/1525410

Title:
  Volume Manage QoS Specs table is too small

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The table should stretch across the size of the browser window.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525410/+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 1525439] [NEW] Glance V2 API is not backwards compatible and breaks Cinder solidfire driver

[Ed Balduf]

Public bug reported:

In stable/kilo

Glance API V2 change of image-metadata is_public flag to visibility =
Public breaks the SolidFire (and maybe other, NetApp?) drivers that
depend on is_public flag. Specifically this breaks the ability
efficiently handle images by caching images in the SolidFire cluster.

Changing the API back to V1 through the cinder.conf file then breaks
Ceph which depends on V2 and the image-metadata direct_url and locations
to determine if it can clone a image to a volume.  So this breaks Ceph's
ability to efficiently handle images

This version mismatch does not allow for SolidFire and Ceph to both be
used efficiently in the same OpenStack cloud.

NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which
allows Ceph efficientcy to work and not SolidFire (and others).

Mainly Opening this Bug to document this problem since no changes are
allowed to Kilo there is probably no way to fix this.

Code locations:

cinder/cinder/image/glance.py line 250-256
cinder/cinder/volume/drivers/rbd.py line 827
cinder/cinder/volume/drivers/solidfire.py line 647
puppet-cinder/manifests/glance.pp line 59

** Affects: cinder
 Importance: Undecided
 Assignee: John Griffith (john-griffith)
 Status: Triaged

** Affects: glance
 Importance: Undecided
 Status: New

** Affects: puppet-cinder
 Importance: Undecided
 Status: New


** Tags: cinder puppet

** Also affects: cinder
   Importance: Undecided
   Status: New

** Also affects: puppet-cinder
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1525439

Title:
  Glance V2 API is not backwards compatible and breaks Cinder solidfire
  driver

Status in Cinder:
  Triaged
Status in Glance:
  New
Status in puppet-cinder:
  New

Bug description:
  In stable/kilo

  Glance API V2 change of image-metadata is_public flag to visibility =
  Public breaks the SolidFire (and maybe other, NetApp?) drivers that
  depend on is_public flag. Specifically this breaks the ability
  efficiently handle images by caching images in the SolidFire cluster.

  Changing the API back to V1 through the cinder.conf file then breaks
  Ceph which depends on V2 and the image-metadata direct_url and
  locations to determine if it can clone a image to a volume.  So this
  breaks Ceph's ability to efficiently handle images

  This version mismatch does not allow for SolidFire and Ceph to both be
  used efficiently in the same OpenStack cloud.

  NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which
  allows Ceph efficientcy to work and not SolidFire (and others).

  Mainly Opening this Bug to document this problem since no changes are
  allowed to Kilo there is probably no way to fix this.

  Code locations:

  cinder/cinder/image/glance.py line 250-256
  cinder/cinder/volume/drivers/rbd.py line 827
  cinder/cinder/volume/drivers/solidfire.py line 647
  puppet-cinder/manifests/glance.pp line 59

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1525439/+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 1525408] [NEW] form error background color not showing

[Cindy Lu]

Public bug reported:

How to reproduce:

- Open up the Create Instance model
- Leave fields blank
- Click on create user
- See errors show up

The error message shows up but the usual red background is gone.
Possibly caused by the refactoring of CSS.

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
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/1525408

Title:
  form error background color not showing

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  How to reproduce:

  - Open up the Create Instance model
  - Leave fields blank
  - Click on create user
  - See errors show up

  The error message shows up but the usual red background is gone.
  Possibly caused by the refactoring of CSS.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525408/+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 1524164] Re: Decompose OFAgent mechanism driver from neutron tree completely

[OpenStack Infra]

Reviewed:  https://review.openstack.org/255579
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=ee78b063c7652d52be81fcc8eb41dbf24d459ecc
Submitter: Jenkins
Branch:master

commit ee78b063c7652d52be81fcc8eb41dbf24d459ecc
Author: fumihiko kakuma 
Date:   Wed Dec 9 13:00:39 2015 +0900

Decompose OFAgent mechanism driver from neutron tree completely

All 3rd-party code is required to be removed from the neutron tree.
This change removes definition for ofagent mechanism driver from
neutron repository.

Change-Id: Ia21387eeaed71f38822356e22e4adbd237c1e64c
Closes-Bug: #1524164
Depends-On: I04c741daf12e7628e2c1e2d1b81b2b2ce1310542


** 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/1524164

Title:
  Decompose OFAgent mechanism driver from neutron tree completely

Status in networking-ofagent:
  Fix Released
Status in neutron:
  Fix Released

Bug description:
  All 3rd-party code is required to be removed from the neutron tree[1].
  We move the definition for ofagent mechanism driver to networking-ofagent
  from neutron tree.

  [1] http://docs.openstack.org/developer/neutron/devref/contribute.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-ofagent/+bug/1524164/+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 1450658] Re: VolumeBackendAPIException during _shutdown_instance are not handled

[Sean McGinnis]

** No longer affects: python-cinderclient

-- 
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/1450658

Title:
  VolumeBackendAPIException during _shutdown_instance are not handled

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Use rally for cinder boot from voume test, after test completed, found a lot 
of VMs were deleted failed with error status, manual retry a few times to 
delete VM, but can't work.
  [root@abba-n04 home]#  nova list --all-tenants
  
+--+---+--+++-+--+
  | ID   | Name  | 
Tenant ID| Status | Task State | Power State | Networks 
|
  
+--+---+--+++-+--+
  | 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 | rally_novaserver_aftvfqejftusyflf | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 888aa512-07f0-42ad-ae5e-255bbca6fe34 | rally_novaserver_ajqhjxjxnjojelgm | 
7e05339543e743c3b023cee8128e | ERROR  | -  | NOSTATE |  
|
  | 84b32483-2997-4a2a-8d75-236395b4ef2f | rally_novaserver_arycquunqovvyxnl | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 535f1ce1-63fe-4681-b215-e21d38f77fbb | rally_novaserver_arzjesynagiqfjgt | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 6ef3fa37-e5a9-4a21-8996-d291070c246a | rally_novaserver_aufevkgzvynumwwo | 
d37e8219a3de4e5b985828a0b959f1d6 | ERROR  | -  | NOSTATE |  
|
  | e5d2dc5f-6e86-43e2-8f1f-1a3f6d4951bc | rally_novaserver_ayzjeqcplouwcaht | 
d37e8219a3de4e5b985828a0b959f1d6 | ERROR  | -  | NOSTATE |  
|
  | 2dcb294a-e2cc-4989-9e87-74081f1567db | rally_novaserver_bbphsjrexkcgcjtt | 
7e05339543e743c3b023cee8128e | ERROR  | -  | NOSTATE |  
|
  | 88053991-2fab-4442-86c7-7825ed47ff0a | rally_novaserver_beveqwdokixwdbgi | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 1e109862-34ea-4686-a099-28f5840244cf | rally_novaserver_bimlwsfkndjbrczv | 
d37e8219a3de4e5b985828a0b959f1d6 | ERROR  | -  | NOSTATE |  
|
  | 6143bbb2-d3eb-4635-9554-85b30fbb5aa5 | rally_novaserver_bmycsptyoicymdmb | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 5e9308ae-9736-485f-92b7-e6783c613ba1 | rally_novaserver_bsvcnsqeyawcnbgp | 
d37e8219a3de4e5b985828a0b959f1d6 | ERROR  | -  | NOSTATE |  
|
  | 13fb2413-15b6-41a3-a8a0-a0b775747261 | rally_novaserver_bvfyfnnixwgisbkk | 
d37e8219a3de4e5b985828a0b959f1d6 | ERROR  | -  | NOSTATE |  
|
  | d5ce6fa3-99b5-4d61-ac7c-4b5bc13d1c27 | rally_novaserver_cpbevhulxylepvql | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  | 23ce9007-ab43-4b57-8686-4aa1ce336f09 | rally_novaserver_cswudaopawepnmms | 
7e05339543e743c3b023cee8128e | ERROR  | -  | NOSTATE |  
|

  [root@abba-n04 home]# nova delete 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89
  Request to delete server 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 has been 
accepted.
  [root@abba-n04 home]# nova  list --all | grep  
335f2ca0-a86d-45a5-b4a6-4d4ea1930e89
  | 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 | rally_novaserver_aftvfqejftusyflf | 
3e87ac6d12264286a10ac68eb913dacb | ERROR  | -  | NOSTATE |  
|
  [root@abba-n04 home]#

  The system is using local LVM volumes attached via iSCSI.  It appears
  that something is going wrong when the attempt to detach the volume is
  being made:

  2015-04-29 07:26:02.680 21775 DEBUG oslo_concurrency.processutils 
[req-fec5ff89-5465-4e76-b573-6a5afc0d4ee2 a9d0160b91f2412d84972a615b7547dc 
828348052e494d76a401f669f85829f3 - - -] Running cmd (subprocess): sudo 
cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool delete-initiator 
iqn.2010-10.org.openstack:volume-a2907017-dda6-4243-bc50-85fe2164f05f 
iqn.1994-05.com.redhat:734fb33285d0 execute 
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:199
  2015-04-29 07:26:02.813 21775 DEBUG oslo_concurrency.processutils 
[req-fec5ff89-5465-4e76-b573-6a5afc0d4ee2 a9d0160b91f2412d84972a615b7547dc 
828348052e494d76a401f669f85829f3 - - -] CMD "sudo cinder-rootwrap 
/etc/cinder/rootwrap.conf cinder-rtstool delete-initiator 
iqn.2010-10.org.openstack:volume-a2907017-dda6-4243-bc50-85fe2164f05f 
iqn.1994-05.com.redhat:734fb33285d0" returned: 1 in 0.133s execute 
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:225
  2015-04-29 07:26:02.814 21775 DEBUG oslo_concurrency.processutils 

[Yahoo-eng-team] [Bug 1464259] Re: Volumes tests fails often with rbd backend

[OpenStack Infra]

Reviewed:  https://review.openstack.org/254428
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=4f2a46987cf705d5dea84e97ef2006342cc5d9c4
Submitter: Jenkins
Branch:master

commit 4f2a46987cf705d5dea84e97ef2006342cc5d9c4
Author: Matt Riedemann 
Date:   Mon Dec 7 14:49:18 2015 -0800

Make sure bdm.volume_id is set after auto-creating volumes

The test_create_ebs_image_and_check_boot test in Tempest does the
following:

1. create volume1 from an image
2. boot server1 from volume1 with delete_on_termination=True and wait
   for the server to be ACTIVE
3. create snapshot from server1 (creates image and volume snapshots)
4. delete server1
5. create server2 from the image snapshot (don't wait for it to be
   ACTIVE - this auto-creates volume2 from the volume snapshot in
   cinder and attaches server2 to it)
6. delete server2 (could still be building/attaching volumes in the
   background)
7. cleanup

There is a race when booting server2, which creates and attaches
volume2, and deleting server2 before it's active.

The volume attach completes and updates the bdm.volume_id in the DB before
we get to _shutdown_instance, but after the delete request is in the API.
The compute API gets potentially stale BDMs and passes those over RPC to
the compute. So we add a check in _shutdown_instance to see if we have
potentially stale volume BDMs and refresh that list if so.

The instance.uuid locks in build_and_run_instance and terminate_instance
create the mutex on the compute host such that the bdm.volume_id should
be set in the database after the volume attach and before terminate_instance
gets the lock. The bdm.volume_id could still be None in _shutdown_instance
if the volume create fails, but we don't have anything to teardown in cinder
in that case anyway.

In the case of the race bug, deleting the volume snapshot in cinder fails
because volume2 was never deleted by nova, so the test fails in
teardown. Note that there is still potential for a race here, this does
not eliminate it, but should narrow the race window.

This also cleans up the logging in attach_block_devices since there
may not be a volume_id at that point (depending on bdm.source_type).

Closes-Bug: #1464259

Change-Id: Ib60d60a5af35be89ad8afbcf44fcffe0b0ce2876


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1464259

Title:
  Volumes tests fails often with rbd backend

Status in Cinder:
  Triaged
Status in OpenStack Compute (nova):
  Fix Released
Status in tempest:
  Invalid

Bug description:
  http://logs.openstack.org/02/173802/5/check/check-tempest-dsvm-full-
  ceph/a72aac1/logs/screen-n-api.txt.gz?level=TRACE#_2015-06-11_09_04_19_511

  2015-06-11 09:04:19.511 ERROR nova.api.ec2 
[req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008 
EC2VolumesTest-1066393631] Unexpected InvalidInput raised: Invalid input 
received: Invalid volume: Volume still has 1 dependent snapshots. (HTTP 400) 
(Request-ID: req-4586b5d2-7212-4ddd-af79-43ad8ba7ea58)
  2015-06-11 09:04:19.511 ERROR nova.api.ec2 
[req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008 
EC2VolumesTest-1066393631] Environment: {"HTTP_AUTHORIZATION": 
"AWS4-HMAC-SHA256 
Credential=a5e9253350ce4a249ddce8b7c1c798c2/20150611/0/127/aws4_request,SignedHeaders=host;x-amz-date,Signature=304830ed947f7fba3143887b08d1e47faa18d4b59782c0992727cb7593f586b4",
 "SCRIPT_NAME": "", "REQUEST_METHOD": "POST", "HTTP_X_AMZ_DATE": 
"20150611T090418Z", "PATH_INFO": "/", "SERVER_PROTOCOL": "HTTP/1.0", 
"CONTENT_LENGTH": "60", "HTTP_USER_AGENT": "Boto/2.38.0 Python/2.7.6 
Linux/3.13.0-53-generic", "RAW_PATH_INFO": "/", "REMOTE_ADDR": "127.0.0.1", 
"wsgi.url_scheme": "http", "SERVER_PORT": "8773", "CONTENT_TYPE": 
"application/x-www-form-urlencoded; charset=UTF-8", "HTTP_HOST": 
"127.0.0.1:8773", "SERVER_NAME": "127.0.0.1", "GATEWAY_INTERFACE": "CGI/1.1", 
"REMOTE_PORT": "45819", "HTTP_ACCEPT_ENCODING": "identity"}

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRUMyVm9sdW1lc1Rlc3RcIiBBTkQgbWVzc2FnZTpcIlVuZXhwZWN0ZWQgSW52YWxpZElucHV0IHJhaXNlZDogSW52YWxpZCBpbnB1dCByZWNlaXZlZDogSW52YWxpZCB2b2x1bWU6IFZvbHVtZSBzdGlsbCBoYXMgMSBkZXBlbmRlbnQgc25hcHNob3RzXCIgQU5EIHRhZ3M6XCJzY3JlZW4tbi1hcGkudHh0XCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzQwMzAyMTUwODd9

  10 hits in 7 days, check and gate, hitting on the ceph and glusterfs
  jobs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1464259/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to  

[Yahoo-eng-team] [Bug 1525423] [NEW] get_networks performance hindered by segment lookups

[Kevin Benton]

Public bug reported:

During the get_networks method of ML2, we iterate over each network and
do a database call to lookup the segments for that network. This scales
the number of database calls linearly with the number of retrieved
networks.

** Affects: neutron
 Importance: Undecided
 Assignee: Kevin Benton (kevinbenton)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525423

Title:
  get_networks performance hindered by segment lookups

Status in neutron:
  In Progress

Bug description:
  During the get_networks method of ML2, we iterate over each network
  and do a database call to lookup the segments for that network. This
  scales the number of database calls linearly with the number of
  retrieved networks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525423/+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 1525424] [NEW] Automatically generate neutron VPNaaS configuration files

[OpenStack Infra]

Public bug reported:

https://review.openstack.org/253399
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.

commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71
Author: Martin Hickey 
Date:   Fri Dec 4 09:10:04 2015 +

Automatically generate neutron VPNaaS configuration files

This adds a new tox environment, genconfig, which generates sample
neutron VPNaaS configuration file using oslo-config-generator.

Updates to some configuration option help messages to reflect useful
details that were missing in the code but were present in config files.

DocImpact: Update the docs that VPNaaS no longer includes static example
configuration files. Instead, use tools/generate_config_file_samples.sh
to generate them and the files generated now end with .sample extension.

Partially-Implements: blueprint autogen-neutron-conf-file

Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551
Partial-bug: #1199963

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: neutron-vpnaas

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525424

Title:
  Automatically generate neutron VPNaaS configuration files

Status in neutron:
  New

Bug description:
  https://review.openstack.org/253399
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71
  Author: Martin Hickey 
  Date:   Fri Dec 4 09:10:04 2015 +

  Automatically generate neutron VPNaaS configuration files
  
  This adds a new tox environment, genconfig, which generates sample
  neutron VPNaaS configuration file using oslo-config-generator.
  
  Updates to some configuration option help messages to reflect useful
  details that were missing in the code but were present in config files.
  
  DocImpact: Update the docs that VPNaaS no longer includes static example
  configuration files. Instead, use tools/generate_config_file_samples.sh
  to generate them and the files generated now end with .sample extension.
  
  Partially-Implements: blueprint autogen-neutron-conf-file
  
  Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551
  Partial-bug: #1199963

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525424/+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 1525430] [NEW] neutron-lbaas tempest v2 api tests not passing config to serviceclient

[James Arendt]

Public bug reported:

Current lbaas tempest v2 api tests do not pass on certain configuration 
information
to the underlyiing ServiceClient used to make a connection, so tests do not
work if values like the endpoint_type or region for the network are changed
in the tempest.conf.  Similarly cannot change control values like the 
build_timeout.

For example, run tempest tests from the neuton_lbaas tree via OS_TEST_PATH
with TEMPEST_CONFIG_DIR set to a tempest.conf that has modified network
values:
endpoint_type = internalURL

The existing code will not honor this endpoint_type for the client.  Fix is to 
pass
on the info.  I.e. instead of the current code:
client_args = [auth_provider, 'network', 'regionOne']

cls.load_balancers_client = (
load_balancers_client.LoadBalancersClientJSON(*client_args))

Read configuration and pass on the parameters if they exist
thru to the ServiceClient base class underling the client connection with
method signature:
def __init__(self, auth_provider, service, region,
 endpoint_type=None, build_interval=None, build_timeout=None,
 disable_ssl_certificate_validation=None, ca_certs=None,
 trace_requests=None):

** Affects: neutron
 Importance: Undecided
 Assignee: James Arendt (james-arendt-7)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => James Arendt (james-arendt-7)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525430

Title:
  neutron-lbaas tempest v2 api tests not passing config to serviceclient

Status in neutron:
  New

Bug description:
  Current lbaas tempest v2 api tests do not pass on certain configuration 
information
  to the underlyiing ServiceClient used to make a connection, so tests do not
  work if values like the endpoint_type or region for the network are changed
  in the tempest.conf.  Similarly cannot change control values like the 
build_timeout.

  For example, run tempest tests from the neuton_lbaas tree via OS_TEST_PATH
  with TEMPEST_CONFIG_DIR set to a tempest.conf that has modified network
  values:
  endpoint_type = internalURL

  The existing code will not honor this endpoint_type for the client.  Fix is 
to pass
  on the info.  I.e. instead of the current code:
  client_args = [auth_provider, 'network', 'regionOne']

  cls.load_balancers_client = (
  load_balancers_client.LoadBalancersClientJSON(*client_args))

  Read configuration and pass on the parameters if they exist
  thru to the ServiceClient base class underling the client connection with
  method signature:
  def __init__(self, auth_provider, service, region,
   endpoint_type=None, build_interval=None, build_timeout=None,
   disable_ssl_certificate_validation=None, ca_certs=None,
   trace_requests=None):

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525430/+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 1504939] Re: Instance failed to spawn with qemu

[Launchpad Bug Tracker]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

-- 
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/1504939

Title:
  Instance failed to spawn with qemu

Status in OpenStack Compute (nova):
  Expired

Bug description:
  I installed Kilo following the instructions on 
http://docs.openstack.org/kilo/install-guide/install/apt/content/
  It failed to spawn an instance with qemu.

  The nova.conf on compute node was as following:

  root@cmp1:~# cat /etc/nova/nova.conf 
  [DEFAULT]
  dhcpbridge_flagfile=/etc/nova/nova.conf
  dhcpbridge=/usr/bin/nova-dhcpbridge
  log_dir=/var/log/nova
  state_path=/var/lib/nova
  lock_path=/var/lock/nova
  force_dhcp_release=True
  libvirt_use_virtio_for_bridges=True
  verbose=True
  ec2_private_dns_show_ip=True
  api_paste_config=/etc/nova/api-paste.ini
  enabled_apis=ec2,osapi_compute,metadata

  rpc_backend=rabbit

  auth_strategy = keystone

  my_ip = 192.168.201.102
  vnc_enabled = True
  vncserver_listen = 0.0.0.0
  vncserver_proxyclient_address = 192.168.201.102
  novncproxy_base_url = http://ctl:6080/vnc_auto.html

  network_api_class = nova.network.neutronv2.api.API
  security_group_api = neutron
  linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
  firewall_driver = nova.virt.firewall.NoopFirewallDriver

  compute_driver = libvirt.LibvirtDriver

  [glance]
  host = ctl

  [oslo_concurrency]
  lock_path = /var/lib/nova/tmp

  [keystone_authtoken]
  auth_uri = http://ctl:5000
  auth_url = http://ctl:35357
  auth_plugin = password
  project_domain_id = default
  user_domain_id = default
  project_name = service
  username = nova
  password = 1

  
  [oslo_messaging_rabbit]
  rabbit_host = ctl
  rabbit_userid = openstack
  rabbit_password = 1

  [libvirt]
  virt_type = qemu

  
  [neutron]
  url = http://ctl:9696
  auth_strategy = keystone
  admin_auth_url = http://ctl:35357/v2.0
  admin_tenant_name = service
  admin_username = neutron
  admin_password = 1


  The error logs were as following:

  2015-10-11 20:58:13.239 31702 ERROR nova.virt.libvirt.driver 
[req-5e9ccf17-f58a-4d4b-82ba-e028da6daff2 311571301159432787db5e3ed1078ee8 
8fab0e9be9164f69a2d14ac383175cdc - - -] Error defining a domain with XML: 

f530cc86-ee2e-4ef4-8655-83f60bfed7fa
instance-0006
65536
1

  http://openstack.org/xmlns/libvirt/nova/1.0;>

an-instance
2015-10-11 12:58:12

  64
  0
  0
  0
  1


  administrator
  training


  


  
OpenStack Foundation
OpenStack Nova
2015.1.1
564db6eb-b1e8-9c2d-85a4-f5fdc0775533
f530cc86-ee2e-4ef4-8655-83f60bfed7fa
  


  hvm
  
  


  
  


  1024


  
  
  


  


  



  
  




  
  

  
  
  
  
  

  
  

  

  

  2015-10-11 20:58:13.240 31702 ERROR nova.compute.manager 
[req-5e9ccf17-f58a-4d4b-82ba-e028da6daff2 311571301159432787db5e3ed1078ee8 
8fab0e9be9164f69a2d14ac383175cdc - - -] [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa] Instance failed to spawn
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa] Traceback (most recent call last):
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa]   File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2461, in 
_build_resources
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa] yield resources
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa]   File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2333, in 
_build_and_run_instance
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa] block_device_info=block_device_info)
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa]   File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2385, in 
spawn
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa] block_device_info=block_device_info)
  2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: 
f530cc86-ee2e-4ef4-8655-83f60bfed7fa]   File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 4403, in 
_create_domain_and_network
  2015-10-11 20:58:13.240 31702 TRACE 

[Yahoo-eng-team] [Bug 1334226] Re: Lock wait timeout updating ipavailabilityranges

[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/1334226

Title:
  Lock wait timeout updating ipavailabilityranges

Status in neutron:
  Expired

Bug description:
  Note that this is different from bug
  https://bugs.launchpad.net/neutron/+bug/1330638

  Traceback:
   neutron.api.v2.resource Traceback (most recent call last):
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 87, in resource
   neutron.api.v2.resource result = method(request=request, **args)
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 447, in create
   neutron.api.v2.resource obj = obj_creator(request.context, **kwargs)
   neutron.api.v2.resource   File "/opt/stack/new/neutron/neutron/db/l3_db.py", 
line 148, in create_router
   neutron.api.v2.resource self._update_router_gw_info(context, 
router_db['id'], gw_info)
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/l3_gwmode_db.py", line 58, in 
_update_router_gw_info
   neutron.api.v2.resource context, router_id, info, router=router)
   neutron.api.v2.resource   File "/opt/stack/new/neutron/neutron/db/l3_db.py", 
line 316, in _update_router_gw_info
   neutron.api.v2.resource self._create_gw_port(context, router_id, router, 
network_id)
   neutron.api.v2.resource   File "/opt/stack/new/neutron/neutron/db/l3_db.py", 
line 306, in _create_gw_port
   neutron.api.v2.resource self._create_router_gw_port(context, router, 
new_network)
   neutron.api.v2.resource   File "/opt/stack/new/neutron/neutron/db/l3_db.py", 
line 255, in _create_router_gw_port
   neutron.api.v2.resource 'name': ''}})
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 644, in create_port
   neutron.api.v2.resource result = super(Ml2Plugin, 
self).create_port(context, port)
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/db_base_plugin_v2.py", line 1464, in 
create_port
   neutron.api.v2.resource context.session.add(allocated)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 463, 
in __exit__
   neutron.api.v2.resource self.rollback()
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 
57, in __exit__
   neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 460, 
in __exit__
   neutron.api.v2.resource self.commit()
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 370, 
in commit
   neutron.api.v2.resource self._prepare_impl()
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 350, 
in _prepare_impl
   neutron.api.v2.resource self.session.flush()
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py", 
line 439, in _wrap
   neutron.api.v2.resource return f(self, *args, **kwargs)
   neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py", 
line 705, in flush
   neutron.api.v2.resource return super(Session, self).flush(*args, 
**kwargs)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1907, 
in flush
   neutron.api.v2.resource self._flush(objects)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 2025, 
in _flush
   neutron.api.v2.resource transaction.rollback(_capture_exception=True)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 
57, in __exit__
   neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1989, 
in _flush
   neutron.api.v2.resource flush_context.execute()
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 
371, in execute
   neutron.api.v2.resource rec.execute(self)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 
524, in execute
   neutron.api.v2.resource uow
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 
59, in save_obj
   neutron.api.v2.resource mapper, table, update)
   neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", 

[Yahoo-eng-team] [Bug 1525424] Re: Automatically generate neutron VPNaaS configuration files

[Henry Gessau]

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: New => 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/1525424

Title:
  Automatically generate neutron VPNaaS configuration files

Status in neutron:
  Fix Released
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/253399
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71
  Author: Martin Hickey 
  Date:   Fri Dec 4 09:10:04 2015 +

  Automatically generate neutron VPNaaS configuration files
  
  This adds a new tox environment, genconfig, which generates sample
  neutron VPNaaS configuration file using oslo-config-generator.
  
  Updates to some configuration option help messages to reflect useful
  details that were missing in the code but were present in config files.
  
  DocImpact: Update the docs that VPNaaS no longer includes static example
  configuration files. Instead, use tools/generate_config_file_samples.sh
  to generate them and the files generated now end with .sample extension.
  
  Partially-Implements: blueprint autogen-neutron-conf-file
  
  Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551
  Partial-bug: #1199963

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525424/+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 1525472] [NEW] Taking into account the exception with status_code

[javeme]

Public bug reported:

When an exception occurs in ajax[1], we get status code from only two
kinds of exceptions: exception with property 'http_status' or 'code'.

To make it easier to distinguish between different error, we should take
into account the exception with 'status_code', such as NotAuthorized[2].

[1]: 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136
[2]: https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119

** Affects: horizon
 Importance: Undecided
 Assignee: javeme (javaloveme)
 Status: In Progress

** Description changed:

- 
- When an exception occurs in ajax[1], we get status code from only two kinds of
- exceptions: exception with property 'http_status' or 'code'.
+ When an exception occurs in ajax[1], we get status code from only two
+ kinds of exceptions: exception with property 'http_status' or 'code'.
  
  To make it easier to distinguish between different error, we should take
  into account the exception with 'status_code', such as NotAuthorized[2].
  
- 
  [1]: 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136
  [2]: 
https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119

** Changed in: horizon
 Assignee: (unassigned) => javeme (javaloveme)

-- 
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/1525472

Title:
  Taking into account the exception with status_code

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  When an exception occurs in ajax[1], we get status code from only two
  kinds of exceptions: exception with property 'http_status' or 'code'.

  To make it easier to distinguish between different error, we should take
  into account the exception with 'status_code', such as NotAuthorized[2].

  [1]: 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136
  [2]: 
https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525472/+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 1525464] [NEW] Release request of networking-cisco and creation of stable/liberty 2.0.0

[Brian Demers]

Public bug reported:

networking-cisco has NOT yet been branched for stable/liberty this needs
to be done alone with tagging the first release at 2.0.0

Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d

** Affects: networking-cisco
 Importance: High
 Status: New

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: release-subproject

** Changed in: networking-cisco
Milestone: None => 2.0.0

** 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/1525464

Title:
  Release request of networking-cisco and creation of stable/liberty
  2.0.0

Status in networking-cisco:
  New
Status in neutron:
  New

Bug description:
  networking-cisco has NOT yet been branched for stable/liberty this
  needs to be done alone with tagging the first release at 2.0.0

  Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-cisco/+bug/1525464/+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 1489059] Re: "db type could not be determined" running py34

[OpenStack Infra]

Reviewed:  https://review.openstack.org/252164
Committed: 
https://git.openstack.org/cgit/openstack/tempest/commit/?id=768c80765717ce3c4ce224a35389b337c43591ef
Submitter: Jenkins
Branch:master

commit 768c80765717ce3c4ce224a35389b337c43591ef
Author: lvdongbing 
Date:   Tue Dec 1 22:38:57 2015 -0500

Put py34 first in the env order of tox

To solve the problem of "db type could not be determined" on py34
we have to run first the py34 env to, then, run py27. This patch
puts py34 first in the tox.ini list of envs to avoid this problem
to happen.
Closes-bug: #1489059
Change-Id: Ia11ecf7bd147e35b7c8ad3db0eaad17f893e78ba


** Changed in: tempest
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in cloudkitty:
  Fix Committed
Status in Glance:
  Fix Committed
Status in glance_store:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Ironic:
  Fix Released
Status in ironic-lib:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Committed
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Committed
Status in Manila:
  Fix Released
Status in networking-midonet:
  In Progress
Status in networking-ofagent:
  New
Status in neutron:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Committed
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Committed
Status in tap-as-a-service:
  New
Status in tempest:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1525132] [NEW] doc error about inject files to new build

[jichenjc]

Public bug reported:

we tell user  'You cannot inject binary or zip files into a new build' in 
following
https://github.com/openstack/nova/blob/master/api-guide/source/server_concepts.rst
http://developer.openstack.org/api-ref-compute-v2.1.html


ichen@devstack1:/opt/stack/nova$ nova boot --file 
/abc.tgz=/home/jichen/cert.tgz --image 9eee793a-25e5-4f42-bd9e-b869e60d3dbd 
--flavor m1.micro t5
+--++
| Property | Value  
|
+--++
| OS-DCF:diskConfig| MANUAL 
|
| OS-EXT-AZ:availability_zone  |
|
| OS-EXT-STS:power_state   | 0  
|
| OS-EXT-STS:task_state| scheduling 
|
| OS-EXT-STS:vm_state  | building   
|
| OS-SRV-USG:launched_at   | -  
|
| OS-SRV-USG:terminated_at | -  
|
| accessIPv4   |
|
| accessIPv6   |
|
| adminPass| KcGDaWG7SdFZ   
|
| config_drive |
|
| created  | 2015-12-11T09:04:33Z   
|
| flavor   | m1.micro (84)  
|
| hostId   |
|
| id   | ec9b463d-0670-4bb0-8e1b-494007fc5cfc   
|
| image| cirros-0.3.4-x86_64-uec 
(9eee793a-25e5-4f42-bd9e-b869e60d3dbd) |
| key_name | -  
|
| metadata | {} 
|
| name | t5 
|
| os-extended-volumes:volumes_attached | [] 
|
| os-pci:pci_devices   | [] 
|
| progress | 0  
|
| security_groups  | default
|
| status   | BUILD  
|
| tenant_id| d1c5aa58af6c426492c642eb649017be   
|
| updated  | 2015-12-11T09:04:33Z   
|
| user_id  | 53a9e08a52eb4486aa4457f325e62b8a   
|
+--++
jichen@devstack1:/opt/stack/nova$ nova list
+--+--+++-+--+
| ID   | Name | Status | Task State | Power 
State | Networks |
+--+--+++-+--+
| ec9b463d-0670-4bb0-8e1b-494007fc5cfc | t5   | BUILD  | spawning   | NOSTATE   
  |  |
+--+--+++-+--+
jichen@devstack1:/opt/stack/nova$ nova list
+--+--+++-+---+
| ID   | Name | Status | Task State | Power 
State | Networks  |
+--+--+++-+---+
| ec9b463d-0670-4bb0-8e1b-494007fc5cfc | t5   | ACTIVE | -  | Running   
  | private=10.0.0.13 |


jichen@devstack1:/opt/stack/nova$ ssh cirros@10.0.0.13
The authenticity of host '10.0.0.13 (10.0.0.13)' can't be established.
RSA key fingerprint is 8f:11:52:54:88:d6:40:7b:95:90:2f:bb:44:c6:36:16.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.13' (RSA) 

[Yahoo-eng-team] [Bug 1525317] [NEW] IdP doesn't support field based DB filtering

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Currently, IdP doesn't support to filter the DB records based on the
field,  for example,

If configure the DB like this,
mysql> select * from identity_provider;
+--+-+-+
| id   | enabled | description |
+--+-+-+
| idp1 |   1 | NULL|
| idp2 |   1 | NULL|
+--+-+-+
2 rows in set (0.00 sec)

And I query the IdP by this curl, I get all of the records from DB,

curl -g -i -X GET http://127.0.0.1:35357/v3/OS-
FEDERATION/identity_providers?id=idontexist -H "User-Agent: python-
keystoneclient" -H "Accept: application/json" -H "X-Auth-Token:
f74ac35177cb4720891a9cfed5ea1b9c"

{
 "links": {
  "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers?id=idp1;,
  "previous": null,
  "next": null
 },
 "identity_providers": [{
  "remote_ids": [],
  "enabled": true,
  "id": "idp1",
  "links": {
   "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1;,
   "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1/protocols;
  },
  "description": null
 }, {
  "remote_ids": [],
  "enabled": true,
  "id": "idp2",
  "links": {
   "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2;,
   "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2/protocols;
  },
  "description": null
 }]
}

This feature should be supported since OSC depends on this to filter the
DB records wanted.

Noted: Open this bug since it's different with
https://bugs.launchpad.net/python-openstackclient/+bug/1479837, they are
two different things, and I think this more sound like a feature that
keystone should support.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

-- 
IdP doesn't support field based DB filtering
https://bugs.launchpad.net/bugs/1525317
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Identity (keystone).

-- 
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 1525317] Re: IdP doesn't support field based DB filtering

[Dave Chen]

** Project changed: python-openstackclient => keystone

-- 
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/1525317

Title:
  IdP doesn't support field based DB filtering

Status in OpenStack Identity (keystone):
  New

Bug description:
  Currently, IdP doesn't support to filter the DB records based on the
  field,  for example,

  If configure the DB like this,
  mysql> select * from identity_provider;
  +--+-+-+
  | id   | enabled | description |
  +--+-+-+
  | idp1 |   1 | NULL|
  | idp2 |   1 | NULL|
  +--+-+-+
  2 rows in set (0.00 sec)

  And I query the IdP by this curl, I get all of the records from DB,

  curl -g -i -X GET http://127.0.0.1:35357/v3/OS-
  FEDERATION/identity_providers?id=idontexist -H "User-Agent: python-
  keystoneclient" -H "Accept: application/json" -H "X-Auth-Token:
  f74ac35177cb4720891a9cfed5ea1b9c"

  {
   "links": {
    "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers?id=idp1;,
    "previous": null,
    "next": null
   },
   "identity_providers": [{
    "remote_ids": [],
    "enabled": true,
    "id": "idp1",
    "links": {
     "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1;,
     "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1/protocols;
    },
    "description": null
   }, {
    "remote_ids": [],
    "enabled": true,
    "id": "idp2",
    "links": {
     "self": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2;,
     "protocols": 
"http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2/protocols;
    },
    "description": null
   }]
  }

  This feature should be supported since OSC depends on this to filter
  the DB records wanted.

  Noted: Open this bug since it's different with
  https://bugs.launchpad.net/python-openstackclient/+bug/1479837, they
  are two different things, and I think this more sound like a feature
  that keystone should support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1525317/+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 1525209] [NEW] Windows interface polling manager doesn't use ovsdb client monitor

[Sayali Lunkad]

Public bug reported:

In Linux the OVS agent uses the class InterfacePollingMinimizer that
notifies the agent when a new port is plugged or unplugged and passes
the related events (port added or deleted). For Windows it uses the
class AlwaysPoll that doesn't notify any specific event, it returns
always true. The OVS agent in Windows is forced to rescan the devices
currently in the machine to infer which were added. This is because the
current Windows implementation of the interface polling manager doesn't
use ovsdb client monitor. Fix this by using ovsdb client monitor also
for Windows and make sure that the events are passed correctly to the
OVS agent.

** Affects: neutron
 Importance: Undecided
 Assignee: Sayali Lunkad (sayalilunkad)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Sayali Lunkad (sayalilunkad)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1525209

Title:
  Windows interface polling manager doesn't use ovsdb client monitor

Status in neutron:
  In Progress

Bug description:
  In Linux the OVS agent uses the class InterfacePollingMinimizer that
  notifies the agent when a new port is plugged or unplugged and passes
  the related events (port added or deleted). For Windows it uses the
  class AlwaysPoll that doesn't notify any specific event, it returns
  always true. The OVS agent in Windows is forced to rescan the devices
  currently in the machine to infer which were added. This is because
  the current Windows implementation of the interface polling manager
  doesn't use ovsdb client monitor. Fix this by using ovsdb client
  monitor also for Windows and make sure that the events are passed
  correctly to the OVS agent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525209/+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 1524418] Re: gate-grenade-dsvm-multinode fails with "AttributeError: 'LocalManager' object has no attribute 'l3driver'"

[Davanum Srinivas (DIMS)]

This was not a Nova problem

** Changed in: nova
   Status: Confirmed => 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/1524418

Title:
  gate-grenade-dsvm-multinode fails with "AttributeError: 'LocalManager'
  object has no attribute 'l3driver'"

Status in OpenStack Compute (nova):
  Invalid
Status in oslo.messaging:
  Fix Released

Bug description:
  Seen here:

  http://logs.openstack.org/38/249138/9/check/gate-grenade-dsvm-
  multinode/5b991dc/logs/new/screen-n-api.txt.gz?level=TRACE

  2015-12-09 12:44:56.998 ERROR nova.api.openstack.extensions 
[req-e2625ff8-3f5c-494c-8d84-a91d6d9c862b cinder_grenade cinder_grenade] 
Unexpected exception in API method
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 478, in wrapped
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/floating_ips.py", line 291, in 
_remove_floating_ip
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
disassociate_floating_ip(self, context, instance, address)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/floating_ips.py", line 79, in 
disassociate_floating_ip
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
self.network_api.disassociate_floating_ip(context, instance, address)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/api.py", line 49, in wrapped
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
func(self, context, *args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/base_api.py", line 77, in wrapper
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions res = 
f(self, context, *args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/api.py", line 240, in disassociate_floating_ip
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
affect_auto_assigned)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/utils.py", line 1100, in wrapper
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 
150, in inner
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/floating_ips.py", line 456, in 
disassociate_floating_ip
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
fixed_ip.instance_uuid)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/floating_ips.py", line 490, in 
_disassociate_floating_ip
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
do_disassociate()
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
271, in inner
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/network/floating_ips.py", line 483, in do_disassociate
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
self.l3driver.remove_floating_ip(address, fixed.address,
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 
AttributeError: 'LocalManager' object has no attribute 'l3driver'
  2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions 


  Started in the last 24 hours:

  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22AttributeError:%20'LocalManager'%20object%20has%20no%20attribute%20'l3driver'%5C%22%20AND%20tags:%5C%22screen-n-api.txt%5C%22

  Thinking it's something in oslo.messaging 3.1.0 that was merged into
  upper-constraints on 12/8:

  https://review.openstack.org/#/c/254571/

To manage 

[Yahoo-eng-team] [Bug 1525375] [NEW] Horizon-liberty in a mixed version env throws 'TypeError at /admin/networks/'

[Doug Hernandez]

Public bug reported:

I'm implementing Horizon (Liberty) in a mixed environment cloud so we
can switch to v3 Identity API. I have the following components:

Horizon : Liberty
Keystone : Kilo
Everything Else: Icehouse

I have pretty good results until I click the Admin->System->Networks link, 
after which I get a very prominent error:
TypeError at /admin/networks/

... followed by lots of other cruft.

The cruft from my browser screen can be found here: 
http://paste.openstack.org/show/481701/ 
 -(sorry... its poorly formatted. Just a copy and paste from the browser, no 
formatting preserved)

The stacktrace from /var/log/apache2/error.log is found here:
http://paste.openstack.org/show/481700/

Thanks

** Affects: horizon
 Importance: Medium
 Status: New


** Tags: sweetjeebus

-- 
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/1525375

Title:
  Horizon-liberty in a mixed version env throws 'TypeError at
  /admin/networks/'

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I'm implementing Horizon (Liberty) in a mixed environment cloud so we
  can switch to v3 Identity API. I have the following components:

  Horizon : Liberty
  Keystone : Kilo
  Everything Else: Icehouse

  I have pretty good results until I click the Admin->System->Networks link, 
after which I get a very prominent error:
  TypeError at /admin/networks/

  ... followed by lots of other cruft.

  The cruft from my browser screen can be found here: 
http://paste.openstack.org/show/481701/ 
   -(sorry... its poorly formatted. Just a copy and paste from the browser, no 
formatting preserved)

  The stacktrace from /var/log/apache2/error.log is found here:
  http://paste.openstack.org/show/481700/

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525375/+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 1525387] [NEW] Wrong naming of nova extension

[Sergey Kraynev]

Public bug reported:

I use Heat for creating VMs, and one part of new  Heat code (in
stable/liberty and in master) uses nova extensions:

https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server_network_mixin.py#L188

I wanted to find this extension, but faced with following issue:
1. All nova documentation tells about "os-interface" extension instead of 
"os-attach-interfaces"
2. Also I founded, that nova code has some misunderstanding between alias and 
name:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L196

it has: alias = "os-attach-interfaces"

But in the same time uses different key for creating extension:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L203

os-interface

The same issue is in name option - it's AttachInterfaces

It looks like bug in naming, because another nova extension has clear naming 
without such confusion:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/server_password.py#L54-L64

I'm not sure where it should be fixed: doc vs nova code.

P.s. if you will fix it in code, don't forget to backport it in
stable/liberty too, please.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: liberty-backport-potential

-- 
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/1525387

Title:
  Wrong naming of nova extension

Status in OpenStack Compute (nova):
  New

Bug description:
  I use Heat for creating VMs, and one part of new  Heat code (in
  stable/liberty and in master) uses nova extensions:

  
https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server_network_mixin.py#L188

  I wanted to find this extension, but faced with following issue:
  1. All nova documentation tells about "os-interface" extension instead of 
"os-attach-interfaces"
  2. Also I founded, that nova code has some misunderstanding between alias and 
name:

  
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L196

  it has: alias = "os-attach-interfaces"

  But in the same time uses different key for creating extension:

  
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L203

  os-interface

  The same issue is in name option - it's AttachInterfaces

  It looks like bug in naming, because another nova extension has clear naming 
without such confusion:
  
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/server_password.py#L54-L64

  I'm not sure where it should be fixed: doc vs nova code.

  P.s. if you will fix it in code, don't forget to backport it in
  stable/liberty too, please.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1525387/+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 1525397] [NEW] Integration tests (both tempest and selenium) don't respect Depends-On: Zuul feature

[Timur Sufiev]

Public bug reported:

Here are 2 patches https://review.openstack.org/#/c/224759/ for Horizon
and its django-openstack-auth dependency
https://review.openstack.org/#/c/224756/

Although dependency is explicitly mentioned in Horizon patch,
integration tests of all kinds still fail to use django-openstack-commit
while testing Horizon patch.

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
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/1525397

Title:
  Integration tests (both tempest and selenium) don't respect Depends-
  On: Zuul feature

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Here are 2 patches https://review.openstack.org/#/c/224759/ for
  Horizon and its django-openstack-auth dependency
  https://review.openstack.org/#/c/224756/

  Although dependency is explicitly mentioned in Horizon patch,
  integration tests of all kinds still fail to use django-openstack-
  commit while testing Horizon patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1525397/+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 1380787] Re: remove XML support

[OpenStack Infra]

Reviewed:  https://review.openstack.org/144439
Committed: 
https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=54a4aea969fe06422f64005652ce23ac7b616d98
Submitter: Jenkins
Branch:master

commit 54a4aea969fe06422f64005652ce23ac7b616d98
Author: Elena Ezhova 
Date:   Fri Dec 4 16:45:47 2015 +0300

Remove XML support

As XML support has been removed from neutron, there is no need
to keep it in client.

Dropped XML serializer and deserializer and deprecated "request-format"
CLI option, making JSON the default and the only supported request
format.

DocImpact

Change-Id: I88b0fdd65a649694252d5ff43a174e75026df5b1
Closes-Bug: #1380787


** Changed in: python-neutronclient
   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/1380787

Title:
  remove XML support

Status in neutron:
  Fix Released
Status in python-neutronclient:
  Fix Released

Bug description:
  XML support has been deprecated for Icehouse[1] and Juno[2]. It is
  time to remove it in Kilo.

  [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#Upgrade_Notes_6
  [2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_6

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1380787/+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 1525124] [NEW] attach port when VM is down，port status is active

[neutron]

Public bug reported:

1 Create a OVS port.
2 Attach this port to a vm,whic is shutdown.
3 Use nova interface-list ,we found the status of this port is 'ACTIVE' if fact 
this should be 'DOWN'

** 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/1525124

Title:
  attach port when VM is down，port status is active

Status in neutron:
  New

Bug description:
  1 Create a OVS port.
  2 Attach this port to a vm,whic is shutdown.
  3 Use nova interface-list ,we found the status of this port is 'ACTIVE' if 
fact this should be 'DOWN'

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525124/+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 1458541] Re: Decomposite DVR router compute node and network node functionallity to two classes

[Armando Migliaccio]

I'd be ok not to track a sequence of minor refactoring without a bug
report

** Changed in: neutron
   Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1458541

Title:
  Decomposite DVR router compute node and network node functionallity to
  two classes

Status in neutron:
  Invalid

Bug description:
  Currently the same dvr router class is used both by the L3 Agent in the 
compute nodes that is responsible for the virtual routers 
  namespace and the fip namespace and also used by the centralized SNAT L3 
Agent in the network node.

  This bug address splitting the above functionality into two different
  classes

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1458541/+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 1501597] Re: Adding Brocade Vyatta 5600 support in Neutron-Fwaas

[Armando Migliaccio]

FWaaS is being rebooted.

** Changed in: neutron
   Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1501597

Title:
  Adding Brocade Vyatta 5600 support in Neutron-Fwaas

Status in neutron:
  Invalid

Bug description:
  Currently Brocade support only vyatta 5400. Changes are required in
  Neutron-Fwaas to support Vyatta 5600 image

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1501597/+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 1515069] Re: VXLAN is too slow due because gro does't work

[Armando Migliaccio]

Needs a new owner.

** Tags added: needs-attention

** Changed in: neutron
   Status: In Progress => Invalid

** Changed in: neutron
   Status: Invalid => Incomplete

** Changed in: neutron
 Assignee: okamototk (toraneko) => (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1515069

Title:
  VXLAN is too slow due because gro does't work

Status in neutron:
  Incomplete

Bug description:
  VXLAN + Linux Bridge is too slow because
  VXLAN outer header check sum is zero and gro is not work 
  on the reciever. This make VXLAN slow. 
  Adding udp checksum in outer header resolve this problem.

  Open vSwitch agent already resolved by #1492111.

  Linux Bridge should support outer udp checksum.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1515069/+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