[Yahoo-eng-team] [Bug 1708092] Re: ovsfw sometimes rejects legitimate traffic when multiple remote SG rules are in use

2017-11-23 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/494428
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=4ac4c22a646799aaecca61334a8bb44147ab881a
Submitter: Zuul
Branch:master

commit 4ac4c22a646799aaecca61334a8bb44147ab881a
Author: IWAMOTO Toshihiro 
Date:   Thu Aug 17 15:13:53 2017 +0900

ovsfw: Use multiple priorities in RULES_*_TABLE

The OpenFlow spec says packets shouldn't match against multiple flows
at the same priority or the result is undefined. In ovsfw, 8 priority
levels are needed to comply with this rule.

Note: unlike overlapping TCP port ranges cases, the current version
of OVS seems to handle this case magically.

Change-Id: I6deaee8dbe81453285b1fc685282952bc9456949
Closes-bug: #1708092


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

Title:
  ovsfw sometimes rejects legitimate traffic when multiple remote SG
  rules are in use

Status in neutron:
  Fix Released

Bug description:
  ovsfw uses conjunction to represent SG rules with remote_group_id.
  When there are multiple rules which differ only in remote_group_id, the ovsfw 
code generates flows with the same match fields and different conjuction 
actions. Such flows don't work well as the openflow spec says so.

  An sequence to reproduce the bug:

  $ openstack security group create sg1
  $ openstack security group create sg2
  $ openstack security group rule create --remote-group sg2 --dst-port 22:80 
--protocol tcp --ingress sg1
  $ openstack security group rule create --remote-group sg1 --dst-port 80 
--protocol tcp --ingress sg1

  Boot 3 instances: hoge1 (sg1), hoge2 (sg2), hoge12 (sg1 and sg2)

  Start "nc -l -p 80" on hoge12.
  Try to connect to hoge12:80 from hoge1 and hoge2. Either one should fail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1708092/+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 1734265] [NEW] neutron-dynamic-routing needs an update for agent extension rehome

2017-11-23 Thread YAMAMOTO Takashi 
Public bug reported:

the following seen on networking-midonet gate.

http://logs.openstack.org/00/522700/1/check/openstack-tox-
py27/3a80d2d/testr_results.html.gz

ft2.5: 
midonet.neutron.tests.unit.db.test_migrations.TestModelsMigrationsPostgresql.test_models_sync_StringException:
 Traceback (most recent call last):
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/tests/base.py", 
line 132, in func
return f(self, *args, **kwargs)
  File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_migrations.py",
 line 603, in test_models_sync
self.db_sync(self.get_engine())
  File "midonet/neutron/tests/unit/db/test_migrations.py", line 108, in db_sync
migration.do_alembic_command(conf, 'upgrade', 'heads')
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/migration/cli.py",
 line 74, in do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/command.py",
 line 254, in upgrade
script.run_env()
  File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 425, in run_env
util.load_python_file(self.dir, 'env.py')
  File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file
module = load_module_py(module_id, path)
  File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/util/compat.py",
 line 141, in load_module_py
mod = imp.load_source(module_id, path, fp)
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/db/migration/alembic_migrations/env.py",
 line 24, in 
from neutron_dynamic_routing.db.migration.models import head  # noqa
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/db/migration/models/head.py",
 line 18, in 
from neutron_dynamic_routing.db import bgp_dragentscheduler_db  # noqa
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/db/bgp_dragentscheduler_db.py",
 line 31, in 
from neutron_dynamic_routing.extensions import bgp_dragentscheduler as 
bgp_dras_ext  # noqa
  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/extensions/bgp_dragentscheduler.py",
 line 43, in 
class DrAgentInvalid(agent.AgentNotFound):
AttributeError: 'module' object has no attribute 'AgentNotFound'

** Affects: neutron
 Importance: Undecided
 Assignee: YAMAMOTO Takashi (yamamoto)
 Status: In Progress


** Tags: gate-failure midokura-jira-tracked

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

** Changed in: neutron
 Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto)

** Tags added: gate-failure midokura-jira-tracked

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

Title:
  neutron-dynamic-routing needs an update for agent extension rehome

Status in neutron:
  In Progress

Bug description:
  the following seen on networking-midonet gate.

  http://logs.openstack.org/00/522700/1/check/openstack-tox-
  py27/3a80d2d/testr_results.html.gz

  ft2.5: 
midonet.neutron.tests.unit.db.test_migrations.TestModelsMigrationsPostgresql.test_models_sync_StringException:
 Traceback (most recent call last):
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/tests/base.py", 
line 132, in func
  return f(self, *args, **kwargs)
File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_migrations.py",
 line 603, in test_models_sync
  self.db_sync(self.get_engine())
File "midonet/neutron/tests/unit/db/test_migrations.py", line 108, in 
db_sync
  migration.do_alembic_command(conf, 'upgrade', 'heads')
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/migration/cli.py",
 line 74, in do_alembic_command
  getattr(alembic_command, cmd)(config, *args, **kwargs)
File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/command.py",
 line 254, in upgrade
  script.run_env()
File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 425, in run_env
  util.load_python_file(self.dir, 'env.py')
File 
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file

[Yahoo-eng-team] [Bug 1734244] [NEW] keystone raise 500 error when create trust with invalid role key

2017-11-23 Thread wangxiyuan 
Public bug reported:

When a user try to create a trust, if the "roles" in the request body
contains some invalid keys(except "id" and "name"), Keystone will raise
500 error.

an example:

curl -g -i -X POST http://10.3.150.25/identity/v3/OS-TRUST/trusts -H
"User-Agent: python-keystoneclient" -H "Content-Type: application/json"
-H "Accept: application/json" -H "X-Auth-Token:
gABaF5Odiawpf1t9BAAhyS3_FBZCKDPycpOnSndiC0TEmqemZvnINxcTPHLGR0J3mnjf60TdqIpct7SgO5movr5uWY-
hmTT4R2Sr_5rYOPC_-w0y6XWbNn265U5IKVz0qMRr-
1VagtuA3iPmyZkjCbFweZsP8yFkwWSxkY4_I0U6JTPzllM" -d '{"trust":
{"impersonation": false, "project_id":
"d88a1e3ce2504a10a5340225b85a844c", "trustor_user_id":
"f98b4cc01a554453a84fa4b9ccf5a1f0", "roles": [{"fake_key": "123"}],
"trustee_user_id": "c8b34ea0d6d6406aae5993061de92e77"}}'

** Affects: keystone
 Importance: Undecided
 Assignee: wangxiyuan (wangxiyuan)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => wangxiyuan (wangxiyuan)

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

Title:
  keystone raise 500 error when create trust with invalid role key

Status in OpenStack Identity (keystone):
  New

Bug description:
  When a user try to create a trust, if the "roles" in the request body
  contains some invalid keys(except "id" and "name"), Keystone will
  raise 500 error.

  an example:

  curl -g -i -X POST http://10.3.150.25/identity/v3/OS-TRUST/trusts -H
  "User-Agent: python-keystoneclient" -H "Content-Type:
  application/json" -H "Accept: application/json" -H "X-Auth-Token:
  
gABaF5Odiawpf1t9BAAhyS3_FBZCKDPycpOnSndiC0TEmqemZvnINxcTPHLGR0J3mnjf60TdqIpct7SgO5movr5uWY-
  hmTT4R2Sr_5rYOPC_-w0y6XWbNn265U5IKVz0qMRr-
  1VagtuA3iPmyZkjCbFweZsP8yFkwWSxkY4_I0U6JTPzllM" -d '{"trust":
  {"impersonation": false, "project_id":
  "d88a1e3ce2504a10a5340225b85a844c", "trustor_user_id":
  "f98b4cc01a554453a84fa4b9ccf5a1f0", "roles": [{"fake_key": "123"}],
  "trustee_user_id": "c8b34ea0d6d6406aae5993061de92e77"}}'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1734244/+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 1734204] [NEW] Insufficient free host memory pages available to allocate guest RAM with Open vSwitch DPDK in Newton

2017-11-23 Thread Andreas Karis 
Public bug reported:

When spawning an instance and scheduling it onto a compute node which still has 
sufficient pCPUs for the instance and also sufficient free huge pages for the 
instance memory, nova returns:
Raw

[stack@undercloud-4 ~]$ nova show 1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc
(...)
| fault| {"message": "Exceeded maximum number 
of retries. Exceeded max scheduling attempts 3 for instance 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc. Last exception: internal error: process 
exited while connecting to monitor: 2017-11-23T19:53:20.311446Z qemu-kvm: 
-chardev pty,id=cha", "code": 500, "details": "  File 
\"/usr/lib/python2.7/site-packages/nova/conductor/manager.py\", line 492, in 
build_instances |
|  | filter_properties, 
instances[0].uuid)  



 |
|  |   File 
\"/usr/lib/python2.7/site-packages/nova/scheduler/utils.py\", line 184, in 
populate_retry  


  |
|  | raise 
exception.MaxRetriesExceeded(reason=msg)



  |
|  | ", "created": "2017-11-23T19:53:22Z"} 
(...)   


   

And /var/log/nova/nova-compute.log on the compute node gives the following 
ERROR message:
Raw

2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager 
[req-2ad59cdf-4901-4df1-8bd7-ebaea20b9361 5d1785ee87294a6fad5e2b91cc20 
8c307c08d2234b339c504bfdd896c13e - - -] [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] Instance failed 
to spawn
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] Traceback (most recent call last):
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2087, in 
_build_resources
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] yield resources
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1928, in 
_build_and_run_instance
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] block_device_info=block_device_info)
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2674, in 
spawn
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] destroy_disks_on_failure=True)
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5013, in 
_create_domain_and_network
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] destroy_disks_on_failure)
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] self.force_reraise()
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc]   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-11-23 19:53:21.021 153615 ERROR nova.compute.manager [instance: 
1b72e7a1-c298-4c92-8d2c-0a9fe886e9bc] six.reraise(self

[Yahoo-eng-team] [Bug 1734167] [NEW] DNS doesn't work in no-cloud as launched by ubuntu

2017-11-23 Thread Michael Lyle 
Public bug reported:

I use no-cloud to test the kernel in CI (I am maintainer of the bcache
subsystem), and have been running it successfully under 16.04 cloud
images from qemu, using a qemu command that includes:

-smbios "type=1,serial=ds=nocloud-
net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
metadata/linuxtst/"

As documented here:

http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

Under the new 17.10 cloud images, this doesn't work: the network comes
up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to
a nonexistent file at this point of the boot and systemd-resolved is not
running.  When I manually hack /etc/resolv.conf in the cloud image to
point to 4.2.2.1 it works fine.

I don't know if nameservice not working is by design, but it seems like
it should work.  The documentation states:

"With ds=nocloud-net, the seedfrom value must start with http://,
https:// or ftp://";

And https is not going to work for a raw IP address.

** Affects: cloud-init
 Importance: Undecided
 Status: New

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

Title:
  DNS doesn't work in no-cloud as launched by ubuntu

Status in cloud-init:
  New

Bug description:
  I use no-cloud to test the kernel in CI (I am maintainer of the bcache
  subsystem), and have been running it successfully under 16.04 cloud
  images from qemu, using a qemu command that includes:

  -smbios "type=1,serial=ds=nocloud-
  net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
  metadata/linuxtst/"

  As documented here:

  http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

  Under the new 17.10 cloud images, this doesn't work: the network comes
  up, but name resolution doesn't work-- /etc/resolv.conf is a symlink
  to a nonexistent file at this point of the boot and systemd-resolved
  is not running.  When I manually hack /etc/resolv.conf in the cloud
  image to point to 4.2.2.1 it works fine.

  I don't know if nameservice not working is by design, but it seems
  like it should work.  The documentation states:

  "With ds=nocloud-net, the seedfrom value must start with http://,
  https:// or ftp://";

  And https is not going to work for a raw IP address.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1734167/+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 1734154] [NEW] bad file path but accepted in a container by Horizon after uploading file

2017-11-23 Thread Besbiss 
Public bug reported:

I uploaded a file with a bad path which contains a double slash (example: 
'/my/file//path') in an object storage container.
The problem is that Horizon accepted this bad path as if it was a valid path, 
there was no control or validation on the path made by OpenStack Horizon. In 
the URL if I put '/containers/container/my-container/A/b/12/s' which doesn't 
exist, Horizon still open the container with the following path.

Steps to reproduce : 
- use "pkgcloud" module available on GitHub with node.JS to upload a file in a 
container in Horizon
- upload a file with a bad path
- get all files and you see that the file has been saved in a fake URL

Optionally: put a bad path on URL after '/containers/container/' and
Horizon will open this false container with false file

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: bad container file horizon node object openstack path pkgcloud storage

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

Title:
  bad file path but accepted in a container by Horizon after uploading
  file

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I uploaded a file with a bad path which contains a double slash (example: 
'/my/file//path') in an object storage container.
  The problem is that Horizon accepted this bad path as if it was a valid path, 
there was no control or validation on the path made by OpenStack Horizon. In 
the URL if I put '/containers/container/my-container/A/b/12/s' which doesn't 
exist, Horizon still open the container with the following path.

  Steps to reproduce : 
  - use "pkgcloud" module available on GitHub with node.JS to upload a file in 
a container in Horizon
  - upload a file with a bad path
  - get all files and you see that the file has been saved in a fake URL

  Optionally: put a bad path on URL after '/containers/container/' and
  Horizon will open this false container with false file

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1734154/+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 1734136] [NEW] Openstack Neutron is not sending complete data during qos-policy-name update

2017-11-23 Thread Vamsi Krishna 
Public bug reported:

1.create a qos-policy with bandwidth limit rule and dscp marking rule

2.update the qos-policy-name

3.After updating the qos-policy name, bandwidth limit rules and dscp
marking rules are missing. Only the qos-policy-name is getting updated.

Openstack neutron is not sending bandwidth_limit_rules &
dscp_marking_rules along with the updated qos policy name when I have
updated the qos-policy-name from Vamsi to Krish.

Expected behavior is to have the updated policy name along with
bandwidth_limit_rules & dscp_marking_rules same as that in old qos-
policy-name.

Version: Stable/Newton
192.168.56.102 --> Openstack
192.168.56.1 --> ODL

JavaScript Object Notation: application/json
Object
Member Key: policy
Object
Member Key: bandwidth_limit_rules
Array
Key: bandwidth_limit_rules
Member Key: name
String value: Krish
Key: name
Member Key: created_at
String value: 2017-11-20T19:27:06Z
Key: created_at
Member Key: updated_at
String value: 2017-11-20T19:27:15Z
Key: updated_at
Member Key: dscp_marking_rules
Array
Key: dscp_marking_rules
Member Key: revision_number
Number value: 4
Key: revision_number
Member Key: shared
False value
Key: shared
Member Key: project_id
String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0
Key: project_id
Member Key: id
String value: 066fd21e-2041-43f6-956a-6bec0948bf15
Key: id
Member Key: description
String value:
Key: description
Key: policy

Attached the wireshark cap for this issue.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: qos

** Tags added: qos

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

Title:
  Openstack Neutron is not sending complete data during qos-policy-name
  update

Status in neutron:
  New

Bug description:
  1.create a qos-policy with bandwidth limit rule and dscp marking rule

  2.update the qos-policy-name

  3.After updating the qos-policy name, bandwidth limit rules and dscp
  marking rules are missing. Only the qos-policy-name is getting
  updated.

  Openstack neutron is not sending bandwidth_limit_rules &
  dscp_marking_rules along with the updated qos policy name when I have
  updated the qos-policy-name from Vamsi to Krish.

  Expected behavior is to have the updated policy name along with
  bandwidth_limit_rules & dscp_marking_rules same as that in old qos-
  policy-name.

  Version: Stable/Newton
  192.168.56.102 --> Openstack
  192.168.56.1 --> ODL

  JavaScript Object Notation: application/json
  Object
  Member Key: policy
  Object
  Member Key: bandwidth_limit_rules
  Array
  Key: bandwidth_limit_rules
  Member Key: name
  String value: Krish
  Key: name
  Member Key: created_at
  String value: 2017-11-20T19:27:06Z
  Key: created_at
  Member Key: updated_at
  String value: 2017-11-20T19:27:15Z
  Key: updated_at
  Member Key: dscp_marking_rules
  Array
  Key: dscp_marking_rules
  Member Key: revision_number
  Number value: 4
  Key: revision_number
  Member Key: shared
  False value
  Key: shared
  Member Key: project_id
  String value: eacd04d3ff4b4e1d9dc2f5282edbb9e0
  Key: project_id
  Member Key: id
  String value: 066fd21e-2041-43f6-956a-6bec0948bf15
  Key: id
  Member Key: description
  String value:
  Key: description
  Key: policy

  Attached the wireshark cap for this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1734136/+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 1733515] Re: use_journal option not available in ocata

2017-11-23 Thread Petr Kovar 
** 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/1733515

Title:
  use_journal option not available in ocata

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

Bug description:
  The config documentation for Nova Ocata lists the "use_journal"
  option[1], however that option was added to oslo.log only for the Pike
  cycle[2] in oslo.log==3.24.0. It isn't available e.g. in Ubuntu Ocata
  UCA with python-oslo.log=3.20.1-0ubuntu1~cloud0.

  [1] 
https://docs.openstack.org/ocata/config-reference/compute/config-options.html
  [2] https://docs.openstack.org/releasenotes/oslo.log/pike.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1733515/+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 1732685] Re: instance.snapshot notification samples are assigned to two different Notification classes

2017-11-23 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/520579
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=ff4f58fcd279605998de21405facb2cfcf8ba385
Submitter: Zuul
Branch:master

commit ff4f58fcd279605998de21405facb2cfcf8ba385
Author: Balazs Gibizer 
Date:   Thu Nov 16 13:55:39 2017 +0100

Fix the usage of instance.snapshot notification sample

The instance.snapshot.start and .end notification sample file was
attached to two different Notification ovo by mistake. This caused that
the samples are appeared in the notification dev-ref twice.

This patch removes the duplication and adds a simple check to the doc
generation code to detech such problems in the future.

Change-Id: I8478c134f9cdb08c02a44e1838dbacede5523914
Closes-Bug: #1732685


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

Title:
  instance.snapshot notification samples are assigned to two different
  Notification classes

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Here attached to the wrong class:
  
https://github.com/openstack/nova/blob/b28924b8e4115f436d46812877066d5d03ad272a/nova/notifications/objects/instance.py#L414-L415

  Here attached to the correct class:
  
https://github.com/openstack/nova/blob/b28924b8e4115f436d46812877066d5d03ad272a/nova/notifications/objects/instance.py#L522-L523

  This causes that the sample will appear twice in the table of
  versioned notifications in the devref:
  https://docs.openstack.org/nova/latest/reference/notifications.html
  #existing-versioned-notifications

  It also makes both occurrences shown by default instead of hidden as
  the rest of the sample by default.

  The bug only effects the master branch as the patch
  https://review.openstack.org/#/c/453077/ that caused this was merged
  after Pike.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1732685/+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 1734117] [NEW] Scoping to project which is not on authentication domain is not working as expected

2017-11-23 Thread Evgeny Fedoruk 
Public bug reported:


Having user "U" on domain "X" which has admin role on domain "X" and domain "Y"
domain "X" and domain "Y" have projects "X1" and "Y1" respectively.

Authenticating with user "U" on domain "X" and scoping to domain "X"
OK.

Authenticating with user "U" on domain "X" and scoping to domain "Y"
OK.

Authenticating with user "U" on domain "X" and scoping to project "X1" 
belonging to domain "X"
OK.

Authenticating with user "U" on domain "X" and scoping to project "Y1" 
belonging to domain "Y"
FAILS.

I expect the last authentication to succeed, since user has admin role
on the domain of the project.

This kind of authentication will succeed if admin role on project "Y"
will be granted to the user.

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

Title:
  Scoping to project which is not on authentication domain is not
  working as expected

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  Having user "U" on domain "X" which has admin role on domain "X" and domain 
"Y"
  domain "X" and domain "Y" have projects "X1" and "Y1" respectively.

  Authenticating with user "U" on domain "X" and scoping to domain "X"
  OK.

  Authenticating with user "U" on domain "X" and scoping to domain "Y"
  OK.

  Authenticating with user "U" on domain "X" and scoping to project "X1" 
belonging to domain "X"
  OK.

  Authenticating with user "U" on domain "X" and scoping to project "Y1" 
belonging to domain "Y"
  FAILS.

  I expect the last authentication to succeed, since user has admin role
  on the domain of the project.

  This kind of authentication will succeed if admin role on project "Y"
  will be granted to the user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1734117/+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 1679941] Re: Data still exsits in instance_mappings when delete instance

2017-11-23 Thread Surya Seetharaman 
A fix has been released which solves this bug :
https://review.openstack.org/#/c/515034/ . Bottom line is that we delete
the Instance Mappings once the instance is archived, and not when its
deleted.

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

Title:
  Data still exsits in instance_mappings when delete instance

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  I have boot a new instance in devstack:
  nova boot demo_vm4 --image 14c388ea-797d-4fc5-99a7-bb8452c53d22 --flavor c1

  and then i will add a record in db table instance_mappings:
  mysql> select * from instance_mappings where instance_uuid = 
'df4c6cc9-aee6-4a7d-bc03-7e75f8cddca5'\G;
  *** 1. row ***
 created_at: 2017-04-05 06:53:59
 updated_at: 2017-04-05 06:54:00
 id: 39
  instance_uuid: df4c6cc9-aee6-4a7d-bc03-7e75f8cddca5
cell_id: 2
 project_id: bad99b731c09492cb5c9b9d876c5004c

  Now i have delete this instance:
  nova delete demo_vm4

  this db record still exsits
  should we delete from instance_mappings when delete the instance?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1679941/+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 1672792] Re: Nova with ceph backend instance creation fails with: the name of the pool must be a string

2017-11-23 Thread Dr. Jens Harbott 
** Changed in: nova/ocata
   Status: Fix Committed => 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/1672792

Title:
  Nova with ceph backend instance creation fails with: the name of the
  pool must be a string

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released

Bug description:
  Situation: Ocata (RDO), Nova configured with ceph backend as follows:

  [libvirt]
  images_type = rbd
  images_rbd_pool = nova
  images_rbd_ceph_conf = /etc/ceph/ceph.conf
  rbd_user = nova_cinder
  rbd_secret_uuid = 

  When launching an image backed instance (so not backed by a cinder
  volume), instance creation fails with: 'the name of the pool must be a
  string'.

  After some digging I found that in: /usr/lib/python2.7/site-
  packages/nova/virt/libvirt/storage/rbd_utils.py in _connect_to_rados
  in the call ioctx = client.open_ioctx(pool_to_open)

  pool_to_open is passed as unicode and in /usr/lib/python2.7/site-
  packages/rados.py a check is done which fails if ioctx_name is not a
  string.

  Easy fix seems to be to do a cast to string in _connect_to_rados:

  ioctx = client.open_ioctx(str(pool_to_open))

  This fixes the issue for me.

  Creating an instance with a ceph backed volume is not affected by this
  issue, this works fine.

  Versions:

  openstack-nova-compute-15.0.0-1.el7.noarch
  python-nova-15.0.0-1.el7.noarch
  python-rados-0.94.10-0.el7.x86_64

  Stacktrace:

  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager 
[req-90b9607f-01e9-4586-a083-c4f2051294ff - - - - -] [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] Instance failed to spawn  

  │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] Traceback (most recent call last):


   │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2125, in 
_build_resources
│
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] yield resources   


   │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1930, in 
_build_and_run_instance 
│
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] block_device_info=block_device_info)  


   │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2676, in 
spawn   
│
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] block_device_info=block_device_info)  


   │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3081, in 
_create_image   
│
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359] fallback_from_host)   


   │
  2017-03-14 15:48:33.480 6668 ERROR nova.compute.manager [instance: 
87145bc6-61fc-4068-a135-fccfd8aed359]   File 
"/usr/lib/python2.7/site-

[Yahoo-eng-team] [Bug 1734066] [NEW] Volume is not unreserved after creating is failed

2017-11-23 Thread Li Xipeng 
Public bug reported:

For creating instance with booting from a volume, the volume is reserved
when before schedule and build in nova compute. When block-device-
mapping failed due to cinder volume busy or other reason, the instance
gets in ERROR state and the volume is kept in 'attaching' state. The
volume reservation is not removed even if the instance is deleted.


This bug seems like bug https://bugs.launchpad.net/nova/+bug/1713641。

** Affects: nova
 Importance: Undecided
 Assignee: Li Xipeng (lixipeng)
 Status: In Progress

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

** Changed in: nova
 Assignee: (unassigned) => Li Xipeng (lixipeng)

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

Title:
  Volume is not unreserved after creating is failed

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  For creating instance with booting from a volume, the volume is
  reserved when before schedule and build in nova compute. When block-
  device-mapping failed due to cinder volume busy or other reason, the
  instance gets in ERROR state and the volume is kept in 'attaching'
  state. The volume reservation is not removed even if the instance is
  deleted.

  
  This bug seems like bug https://bugs.launchpad.net/nova/+bug/1713641。

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1734066/+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 1734054] [NEW] logging report UnicodeDecodeError when create vm with non-ascii

2017-11-23 Thread Jiang 
Public bug reported:

When create a vm with non-ascii name in devstack, logging report
UnicodeDecodeError in nova-compute.log.

Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
msg = self.format(record)
  File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 161, 
in format
return logging.StreamHandler.format(self, record)
  File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
return fmt.format(record)
  File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
457, in format
return logging.Formatter.format(self, record)
  File "/usr/lib/python2.7/logging/__init__.py", line 476, in format
raise e
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 317: 
ordinal not in range(128)
Logged from file driver.py, line 5061

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1734054

Title:
  logging report UnicodeDecodeError when create vm with non-ascii

Status in OpenStack Compute (nova):
  New

Bug description:
  When create a vm with non-ascii name in devstack, logging report
  UnicodeDecodeError in nova-compute.log.

  Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
  msg = self.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 
161, in format
  return logging.StreamHandler.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
  return fmt.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
457, in format
  return logging.Formatter.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 476, in format
  raise e
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 317: 
ordinal not in range(128)
  Logged from file driver.py, line 5061

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