[Yahoo-eng-team] [Bug 1403678] Re: Selecting an Image File resets the value of Format field

[Lin Hua Cheng]

Image format is actually getting selected automatically based on the
extension of the File selected.

User error, bug can be closed


** Changed in: horizon
   Status: New => Invalid

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

Title:
  Selecting an Image File resets the value of Format field

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  From the create image page
  1. Set the format to Raw
  2. Set Source to Image File
  3. Click Browse on the Image File to select a file

  Result: The value of Format is reset

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403678/+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 1341954] Re: suds client subject to cache poisoning by local attacker

[Nathan Kinder]

This has been published as OSSN-0038 to the openstack and openstack-dev
mailing lists as well as the wiki:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0038

** Changed in: ossn
   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/1341954

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default 
cache implementation stores pickled objects to a predictable path in /tmp. This 
can be used by a local attacker to redirect SOAP requests via symlinks or run a 
privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1341954/+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 1403747] [NEW] No error message when trying to delete default security group

[Abhishek Talwar]

Public bug reported:

Trying to delete default security group from a non-admin user gives an error 
"Conflict (HTTP 409) (Request-ID: req-152c2ec3-1f32-406f-9eeb-bb8ea48a4d11)" 
but no messgae is displayed to the user.
This is confusing as the user does not get to know why is he not allowed to 
remove the defaulty security group.

We should display a error message that tells the user that why is he not
allowed to do so.

Expected Message : " Only admin allowed to remove default security
group. (HTTP 400) (Request-ID: req-XYZ) "

** Affects: neutron
 Importance: Undecided
 Assignee: Abhishek Talwar (abhishek-talwar)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Abhishek Talwar (abhishek-talwar)

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

Title:
  No error message when trying to delete default security group

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Trying to delete default security group from a non-admin user gives an error 
"Conflict (HTTP 409) (Request-ID: req-152c2ec3-1f32-406f-9eeb-bb8ea48a4d11)" 
but no messgae is displayed to the user.
  This is confusing as the user does not get to know why is he not allowed to 
remove the defaulty security group.

  We should display a error message that tells the user that why is he
  not allowed to do so.

  Expected Message : " Only admin allowed to remove default security
  group. (HTTP 400) (Request-ID: req-XYZ) "

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403747/+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 1403743] [NEW] Confusing message for deleting default security group

[Abhishek Talwar]

Public bug reported:

Trying to delete default security group from a non-admin user gives an
error "Removing default security group not allowed. (HTTP 400) (Request-
ID: req-208b1911-99f6-411f-8429-e05051e71cba) ". But this messgae is not
clear as the user does not get to know  why is he not allowed to remove
the defaulty security group.

We should modify the error message to something that tells the user that
it is only an admin operation. This way the user will not be confused as
why is he not allowed.

Expected Message : "  Only admin allowed to remove default security
group. (HTTP 400) (Request-ID: req-XYZ) "

** Affects: neutron
 Importance: Undecided
 Assignee: Abhishek Talwar (abhishek-talwar)
 Status: New

** Project changed: nova => neutron

** Changed in: neutron
 Assignee: (unassigned) => Abhishek Talwar (abhishek-talwar)

** Description changed:

  Trying to delete default security group from a non-admin user gives an
  error "Removing default security group not allowed. (HTTP 400) (Request-
  ID: req-208b1911-99f6-411f-8429-e05051e71cba) ". But this messgae is not
- clear as the does not get to know  why is he not allowed to remove the
- defaulty security group.
+ clear as the user does not get to know  why is he not allowed to remove
+ the defaulty security group.
  
  We should modify the error message to something that tells the user that
  it is only an admin operation. This way the user will not be confused as
  why is he not allowed.
  
  Expected Message : "  Only admin allowed to remove default security
  group. (HTTP 400) (Request-ID: req-XYZ) "

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

Title:
  Confusing message for deleting default security group

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Trying to delete default security group from a non-admin user gives an
  error "Removing default security group not allowed. (HTTP 400)
  (Request-ID: req-208b1911-99f6-411f-8429-e05051e71cba) ". But this
  messgae is not clear as the user does not get to know  why is he not
  allowed to remove the defaulty security group.

  We should modify the error message to something that tells the user
  that it is only an admin operation. This way the user will not be
  confused as why is he not allowed.

  Expected Message : "  Only admin allowed to remove default security
  group. (HTTP 400) (Request-ID: req-XYZ) "

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403743/+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 1403741] [NEW] integration tests - Can't create user under Identity->Users

[Wu Hong Guang]

Public bug reported:

integration tests will meet problem if they are executed concurrently by
the same user because bug 1403725.

we need  create user  automated to setup a multi-user  integration
testing environment

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: integration-tests

** Tags added: low-hanging-fruit

** Tags removed: low-hanging-fruit
** Tags added: integration-tests

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

Title:
  integration tests - Can't create user under Identity->Users

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  integration tests will meet problem if they are executed concurrently
  by the same user because bug 1403725.

  we need  create user  automated to setup a multi-user  integration
  testing environment

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403741/+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 1403729] [NEW] SecurityGroup rules not removed causes port build slowly

[max...@unitedstack.com]

Public bug reported:

When our public cloud services run about 1 year, we found there are a
lot of security group rules not removed but the related port had been
deleted. Those security group left in iptables and has no way to clear
up. This makes port build very slowly because the iptables rules too
many.

** Affects: neutron
 Importance: Undecided
 Assignee: max...@unitedstack.com (maxiao)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => max...@unitedstack.com (maxiao)

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

Title:
  SecurityGroup rules not removed causes port build slowly

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When our public cloud services run about 1 year, we found there are a
  lot of security group rules not removed but the related port had been
  deleted. Those security group left in iptables and has no way to clear
  up. This makes port build very slowly because the iptables rules too
  many.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403729/+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 1403725] [NEW] The same user in chrome got Error: Unauthorized: when the user password is updated in firefox

[Wu Hong Guang]

Public bug reported:

Testing step:
1: demo login from firefox
2:demo login from chrome
3:demo update password in firefox
4:demo got Error: Unauthorized in chrome

** Affects: horizon
 Importance: Undecided
 Status: New

** Summary changed:

- The same user in one browser got Error: Unauthorized: when the user password 
is updated in another browser 
+ The same user in chrome got Error: Unauthorized: when the user password is 
updated in firefox

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

Title:
  The same user in chrome got Error: Unauthorized: when the user
  password is updated in firefox

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Testing step:
  1: demo login from firefox
  2:demo login from chrome
  3:demo update password in firefox
  4:demo got Error: Unauthorized in chrome

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403725/+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 1400770] Re: fail to upload object if swift proxy-server is deployed in apache 2.4

[LIU Yulong]

** Also affects: python-swiftclient
   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/1400770

Title:
  fail to upload object if swift proxy-server is deployed in apache 2.4

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Python client library for Swift:
  New

Bug description:
  fail to upload object if swift proxy-server is deployed in apache 2.4:

  Environment:

  Ubuntu 14.04.1 LTS

  horizon (github master branch source code install)
  python-swiftclient (github master branch source code install)
  swift (github master branch source code install)

  Apache/2.4.7 log:
  [Sun Dec 07 00:26:55.329422 2014] [:error] [pid 18608:tid 140692826650368] 
WARNING:urllib3.connectionpool:HttpConnectionPool is full, discarding 
connection: 192.168.1.151
  [Sun Dec 07 00:26:55.329525 2014] [:error] [pid 18608:tid 140692826650368] 
REQ: curl -i 
http://192.168.1.151:8080/v1/AUTH_faf24933fa804ece91c2da2afdfa4127/testestset/setup.py
 -X PUT -H "X-Auth-Token: 312a22b6c61b43e08455303003fc72a0"
  [Sun Dec 07 00:26:55.329935 2014] [:error] [pid 18608:tid 140692826650368] 
RESP STATUS: 411 Length Required
  [Sun Dec 07 00:26:55.330003 2014] [:error] [pid 18608:tid 140692826650368] 
RESP HEADERS: [('date', 'Sat, 06 Dec 2014 16:26:55 GMT'), ('content-length', 
'318'), ('content-type', 'text/html; charset=iso-8859-1'), ('connection', 
'close'), ('server', 'Apache/2.4.7 (Ubuntu)')]
  [Sun Dec 07 00:26:55.330050 2014] [:error] [pid 18608:tid 140692826650368] 
RESP BODY: 
  [Sun Dec 07 00:26:55.330058 2014] [:error] [pid 18608:tid 140692826650368] 

  [Sun Dec 07 00:26:55.330063 2014] [:error] [pid 18608:tid 140692826650368] 
411 Length Required
  [Sun Dec 07 00:26:55.330068 2014] [:error] [pid 18608:tid 140692826650368] 

  [Sun Dec 07 00:26:55.330073 2014] [:error] [pid 18608:tid 140692826650368] 
Length Required
  [Sun Dec 07 00:26:55.330078 2014] [:error] [pid 18608:tid 140692826650368] 
A request of the requested method PUT requires a valid Content-length.
  [Sun Dec 07 00:26:55.330083 2014] [:error] [pid 18608:tid 140692826650368] 

  [Sun Dec 07 00:26:55.330088 2014] [:error] [pid 18608:tid 140692826650368] 

  [Sun Dec 07 00:26:55.330093 2014] [:error] [pid 18608:tid 140692826650368] 
Apache/2.4.7 (Ubuntu) Server at 192.168.1.151 Port 8080
  [Sun Dec 07 00:26:55.330098 2014] [:error] [pid 18608:tid 140692826650368] 

  [Sun Dec 07 00:26:55.330103 2014] [:error] [pid 18608:tid 140692826650368]
  [Sun Dec 07 00:26:55.330295 2014] [:error] [pid 18608:tid 140692826650368] 
Object PUT failed: 
http://192.168.1.151:8080/v1/AUTH_faf24933fa804ece91c2da2afdfa4127/testestset/setup.py
 411 Length Required  [first 60 chars of response] 
  [Sun Dec 07 00:26:55.330306 2014] [:error] [pid 18608:tid 140692826650368] 
http://192.168.1.151:8080/v1/AUTH_faf24933fa804ece91c2da2afdfa4127/testestset/setup.py
 411 Length Required  [first 60 chars of response] 
  [Sun Dec 07 00:26:55.330343 2014] [:error] [pid 18608:tid 140692826650368] 
http://192.168.1.151:8080/v1/AUTH_faf24933fa804ece91c2da2afdfa4127/testestset/setup.py
 411 Length Required  [first 60 chars of response] 
  [Sun Dec 07 00:26:55.330525 2014] [:error] [pid 18608:tid 140692826650368] 
http://192.168.1.151:8080/v1/AUTH_faf24933fa804ece91c2da2afdfa4127/testestset/setup.py
  -X PUT -H "X-Auth-Token: 312a22b6c61b43e08455303003fc72a0"

  HTTP/1.1 411 Length Required
  Date: Sat, 06 Dec 2014 16:41:14 GMT
  Server: Apache/2.4.7 (Ubuntu)
  X-Trans-Id: tx0bff2b699baa499baddbd-00548331aa
  Content-Length: 30
  Connection: close
  Content-Type: text/plain

  Missing Content-Length header.

  Horizon Code:
  openstack_dashboard/dashboards/swift.py:
  def swift_upload_object(request, container_name, object_name,
  object_file=None):
  headers = {}
  size = 0
  if object_file:
  headers['X-Object-Meta-Orig-Filename'] = object_file.name
  size = object_file.size

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1400770/+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 1403701] [NEW] Fix consistency on panel visibility check

[Lin Hua Cheng]

Public bug reported:

There are two patterns used in defined if panels are visible:
1. overriding allowed

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/firewalls/panel.py#L26

2. overriding can_access()

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/aggregates/panel.py#L26

One of this is wrong and must be consistent with the other.

** Affects: horizon
 Importance: Undecided
 Assignee: Lin Hua Cheng (lin-hua-cheng)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Lin Hua Cheng (lin-hua-cheng)

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

Title:
  Fix consistency on panel visibility check

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  There are two patterns used in defined if panels are visible:
  1. overriding allowed

  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/firewalls/panel.py#L26

  2. overriding can_access()

  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/aggregates/panel.py#L26

  One of this is wrong and must be consistent with the other.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403701/+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 1403686] [NEW] Allow using auth plugins to talk to nova

[Jamie Lennox]

Public bug reported:

When neutron communicates with nova it authenticates using the options:

# URL for connection to nova (Only supports one nova region currently).
# nova_url = http://127.0.0.1:8774/v2

# Name of nova region to use. Useful if keystone manages more than one region
# nova_region_name =

# Username for connection to nova in admin context
# nova_admin_username =

# The uuid of the admin nova tenant
# nova_admin_tenant_id =

# The name of the admin nova tenant. If the uuid of the admin nova tenant
# is set, this is optional.  Useful for cases where the uuid of the admin
# nova tenant is not available when configuration is being done.
# nova_admin_tenant_name =

# Password for connection to nova in admin context.
# nova_admin_password =

# Authorization URL for connection to nova in admin context.
# nova_admin_auth_url =


This is restricted to only keystone v2 auth and means it can only be used with 
user and password authentication. 

Keystoneclient provides a generic way to handle loading authentication
from a config file that will support abritrary future authentication
mechanisms. Neutron should use that.

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

Title:
  Allow using auth plugins to talk to nova

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When neutron communicates with nova it authenticates using the
  options:

  # URL for connection to nova (Only supports one nova region currently).
  # nova_url = http://127.0.0.1:8774/v2

  # Name of nova region to use. Useful if keystone manages more than one region
  # nova_region_name =

  # Username for connection to nova in admin context
  # nova_admin_username =

  # The uuid of the admin nova tenant
  # nova_admin_tenant_id =

  # The name of the admin nova tenant. If the uuid of the admin nova tenant
  # is set, this is optional.  Useful for cases where the uuid of the admin
  # nova tenant is not available when configuration is being done.
  # nova_admin_tenant_name =

  # Password for connection to nova in admin context.
  # nova_admin_password =

  # Authorization URL for connection to nova in admin context.
  # nova_admin_auth_url =

  
  This is restricted to only keystone v2 auth and means it can only be used 
with user and password authentication. 

  Keystoneclient provides a generic way to handle loading authentication
  from a config file that will support abritrary future authentication
  mechanisms. Neutron should use that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403686/+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 1403678] [NEW] Selecting an Image File resets the value of Format field

[Lin Hua Cheng]

Public bug reported:

>From the create image page
1. Set the format to Raw
2. Set Source to Image File
3. Click Browse on the Image File to select a file

Result: The value of Format is reset

** Affects: horizon
 Importance: Undecided
 Assignee: Lin Hua Cheng (lin-hua-cheng)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Lin Hua Cheng (lin-hua-cheng)

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

Title:
  Selecting an Image File resets the value of Format field

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  From the create image page
  1. Set the format to Raw
  2. Set Source to Image File
  3. Click Browse on the Image File to select a file

  Result: The value of Format is reset

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403678/+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 1403660] [NEW] Resource Usage Map Keys overrun

[Aaron Sahlin]

Public bug reported:

The Resource Map Stat's Map Key overruns its bounds.   Image attached to
clarify.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "ResourceUsageMapKey.png"
   
https://bugs.launchpad.net/bugs/1403660/+attachment/4283160/+files/ResourceUsageMapKey.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/1403660

Title:
  Resource Usage Map Keys overrun

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The Resource Map Stat's Map Key overruns its bounds.   Image attached
  to clarify.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403660/+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 1370477] Re: response examples of lists role APIs are lacking

[Anne Gentle]

Where do you see these response examples? That will help us know where
to fix.

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

** Changed in: openstack-api-site
   Status: New => Incomplete

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

Title:
  response examples of lists role APIs are lacking

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack API documentation site:
  Incomplete

Bug description:
  Some listing roles APIs of responce examples are lacking.

  For example:
  Lists role for a user on a domain API's example is 

  [
  {
  "id": "--role-id--",
  "name": "--role-name--"
  },
  {
  "id": "--role-id--",
  "name": "--role-name--"
  }
  ]

  but the actual API's response is 
  {
  "links": {
  "next": null, 
  "previous": null, 
  "self": 
"http://192.168.56.10:5000/v3/domains/716d729b22d647e5a04a2405d66c5eff/users/21de7aaafeb9454ba4c5b40b19016199/roles";
  }, 
  "roles": [
  {
  "id": "3d4b58f4be7649a497bb18b3f2e25d76", 
  "links": {
  "self": 
"http://192.168.56.10:5000/v3/roles/3d4b58f4be7649a497bb18b3f2e25d76";
  }, 
  "name": "Member"
  }
  ]
  }

  
  Same lacks exist in 
  - Lists roles for a user on a domain. 
  - Lists roles for a specified domain group. 
  - Lists roles for a user in a project.
  - Lists roles for a project group. 
  - Lists roles.
  - Lists policies.

  These API's response examples don't have "roles", "links", "next",
  "previous" and "self" keys.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1370477/+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 1403626] [NEW] SRIOV mechanism driver doesn't support flat networks

[Maru Newby]

Public bug reported:

The SRIOV mechanism driver only supports vlan networking at present.  It
would be useful to support flat networking as well.

I have a report that omitting the vlan id from the libvirt xml (by
commenting out [1]) allows flat networking to work.  It's not clear
whether neutron providing a vlan id of 0 would have the same effect.

1:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L129

** Affects: neutron
 Importance: Medium
 Assignee: Irena Berezovsky (irenab)
 Status: New

** Description changed:

  The SRIOV mechanism driver only supports vlan networking at present.  It
  would be useful to support flat networking as well.
  
  I have a report that omitting the vlan id from the libvirt xml (by
  commenting out [1]) allows flat networking to work.  It's not clear
  whether neutron providing a vlan id of 0 would have the same effect.
+ 
+ 1:
+ 
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L129

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

Title:
  SRIOV mechanism driver doesn't support flat networks

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The SRIOV mechanism driver only supports vlan networking at present.
  It would be useful to support flat networking as well.

  I have a report that omitting the vlan id from the libvirt xml (by
  commenting out [1]) allows flat networking to work.  It's not clear
  whether neutron providing a vlan id of 0 would have the same effect.

  1:
  
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L129

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403626/+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 1403625] [NEW] devstack defaults to VXLAN even though ENABLE_TENANT_TUNNELS is False in local.conf

[Syd Logan]

Public bug reported:

Branch info:

slogan@slogan-virtual-machine:~/devstack$ git branch
* master
slogan@slogan-virtual-machine:~/devstack$ git log | head
commit 062e8f14874ab254aa756aabb4f50db77431
Merge: 7f80280 7bb9a73
Author: Jenkins 
Date:   Tue Dec 16 22:02:41 2014 +

Merge "Adds missing rabbit_userid to trove configs"

commit 7f8028069883b8214bd2aae56f78514a4fbe
Merge: affcf87 dc31f76
Author: Jenkins 

local.conf:

[[local|localrc]]
disable_service n-net
enable_service q-l3
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-meta
enable_service neutron
ADMIN_PASSWORD=password
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
FIXED_RANGE=10.4.128.0/20
#FLOATING_RANGE=192.168.1.20/30
#HOST_IP=localhost
HOST_IP=192.168.1.220
PUBLIC_INTERFACE=eth0
FLAT_INTERFACE=br-int
FLAT_NETWORK_BRIDGE=br-eth0
NETWORK_GATEWAY=10.4.128.1
FIXED_NETWORK_SIZE=4096
SCHEDULER=nova.scheduler.filter_scheduler.FilterScheduler
Q_PLUGIN=ml2
OFFLINE=True
ACTIVE_TIMEOUT=120
ASSOCIATE_TIMEOUT=60
BOOT_TIMEOUT=120
SERVICE_TIMEOUT=120
EXTRA_OPTS=(metadata_host=$HOST_IP)

# Allow tenants to create vlans

ENABLE_TENANT_VLANS=True
ENABLE_TENANT_TUNNELS=False
ML2_VLAN_RANGES=physnet1:1100:2999

# these are needed fo VLANs for tenants to connect to physical switch

PHYSICAL_NETWORK=default
OVS_PHYSICAL_BRIDGE=br-int

Q_DHCP_EXTRA_DEFAULT_OPTS=(enable_metadata_network=True
enable_isolated_metadata=True)

Notice I don't have Q_ML2_TENANT_NETWORK_TYPE setm but I am saying I
want VLANS and I don't want tunnels (and I haven't defined anything else
related to tunnels, e.g., VNI ranges).

When I run ./stack.sh with the above, I noticed that br-tun is created:

slogan@slogan-virtual-machine:~/devstack$ sudo ovs-vsctl show
2d7ac7cc-4358-41e7-afd4-3c5a0081d79f
Bridge br-ex
Port br-ex
Interface br-ex
type: internal
Port "qg-db338515-8c"
Interface "qg-db338515-8c"
type: internal
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Bridge br-int
...

Also, in ml2_conf.ini:

[ml2]
tenant_network_types = vxlan
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,linuxbridge
...

The code in question is in devstack/lib/neutron_plugins/ml2:

Q_ML2_TENANT_NETWORK_TYPE=${Q_ML2_TENANT_NETWORK_TYPE:-"vxlan"}
# This has to be set here since the agent will set this in the config file
if [[ "$Q_ML2_TENANT_NETWORK_TYPE" == "gre" || "$Q_ML2_TENANT_NETWORK_TYPE" == 
"vxlan" ]]; then
Q_TUNNEL_TYPES=$Q_ML2_TENANT_NETWORK_TYPE
elif [[ "$ENABLE_TENANT_TUNNELS" == "True" ]]; then
Q_TUNNEL_TYPES=gre
fi

The above code sets the tenant network type to vxlan if not specified
(as a default). I think the code should account for the
ENABLE_TENANT_TUNNELS and ENABLE_TENANT_VLANS when defining the default.

Notice that the wiki has a devstack sample that led me down this path,
I'd like to see the code match this wiki by fixing this bug (I think the
wiki is fine, it's the script that needs fixing).

Configure devstack for ML2 with VLANs
An example control and compute node localrc file is shown here for configuring 
ML2 to run with VLANs with devstack. This is equivalent to running the OVS or 
LinuxBridge plugins in VLAN mode.

Add the following to your control node localrc:
Q_PLUGIN=ml2
ENABLE_TENANT_VLANS=True
ML2_VLAN_RANGES=mynetwork:100:200
To set special VLAN parameters for the VLAN TypeDriver, the following variable 
in localrc can be used. This is a space separate list of assignment values:
Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS=(network_vlan_ranges=600:700)

(the above is from https://wiki.openstack.org/wiki/Neutron/ML2

** Affects: neutron
 Importance: Undecided
 Assignee: slogan621 (slogan621)
 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/1403625

Title:
  devstack defaults to VXLAN even though ENABLE_TENANT_TUNNELS is False
  in local.conf

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Branch info:

  slogan@slogan-virtual-machine:~/devstack$ git branch
  * master
  slogan@slogan-virtual-machine:~/devstack$ git log | head
  commit 062e8f14874ab254aa756aabb4f50db77431
  Merge: 7f80280 7bb9a73
  Author: Jenkins 
  Date:   Tue Dec 16 22:02:41 2014 +

  Merge "Adds missing rabbit_userid to trove configs"

  commit 7f8028069883b8214bd2aae56f78514a4fbe
  Merge: affcf87 dc31f76
  Author: Jenkins 

  local.conf:

  [[local|localrc]]
  disable_service n-net
  enable_service q-l3
  enable_service q-svc
  enable_service q-agt
  enable_service q-dhcp
  enable_service q-meta
  enable_ser

[Yahoo-eng-team] [Bug 1403585] [NEW] Restore VMware unit tests

[Salvatore Orlando]

Public bug reported:

As plugin decomposition is still in progress, vmware unit tests should
be unskipped.

In order to complete advanced services spin off they were completely disabled.
In order to reenable these tests, the 'advanced services' NSX plugin must be 
removed.

** Affects: neutron
 Importance: High
 Assignee: Salvatore Orlando (salvatore-orlando)
 Status: New


** Tags: vmware

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

Title:
  Restore VMware unit tests

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  As plugin decomposition is still in progress, vmware unit tests should
  be unskipped.

  In order to complete advanced services spin off they were completely disabled.
  In order to reenable these tests, the 'advanced services' NSX plugin must be 
removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403585/+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 1403586] [NEW] 'Controller.create' is too complex

[Pasquale Porreca]

Public bug reported:

The method Controller.create in nova/api/openstack/compute/servers.py
has a complexity of 46 that is the most complex in Nova code and it is
equal to the limit specified in tox.ini. This cause a pep8 error if
someone tries to add a new api for server create action. This fail is
unavoidable if one wants to keep consistency with the way other
extensions are loaded, so a refactoring is necessary to lower the
complexity.

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  The method Controller.create in nova/api/openstack/compute/servers.py
  has a complexity of 46 that is the most complex in Nova code and it is
  equal to the limit specified in tox.ini. This cause a pep8 error if
  someone tries to add a new api for server create action. This fail is
- unavoidable if one want keep consistency with the way other extensions
- are loaded, so a refractoring is necessary to lower the complexity.
+ unavoidable if one wants to keep consistency with the way other
+ extensions are loaded, so a refactoring is necessary to lower the
+ complexity.

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

Title:
  'Controller.create' is too complex

Status in OpenStack Compute (Nova):
  New

Bug description:
  The method Controller.create in nova/api/openstack/compute/servers.py
  has a complexity of 46 that is the most complex in Nova code and it is
  equal to the limit specified in tox.ini. This cause a pep8 error if
  someone tries to add a new api for server create action. This fail is
  unavoidable if one wants to keep consistency with the way other
  extensions are loaded, so a refactoring is necessary to lower the
  complexity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403586/+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 1403564] [NEW] nova.tests.unit.conductor.test_conductor._BaseTaskTestCase.test_build_instances_scheduler_failure is racy

[Matt Riedemann]

Public bug reported:

This could be related to bug 1360320 which sounds like a similar
failure, handle_scheduler_error is getting an unexpected instance uuid,
but bug 1360320 was closed simply because we weren't seeing the failure
in the gate anymore.

http://logs.openstack.org/13/140713/2/gate//gate-nova-
python27/6e6b3fb/console.html#_2014-12-15_23_48_28_487

message:"-
function.__call__( Confirmed

** Changed in: nova
   Importance: Undecided => Medium

** Tags added: gate-failure testing

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

Title:
  
nova.tests.unit.conductor.test_conductor._BaseTaskTestCase.test_build_instances_scheduler_failure
  is racy

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  This could be related to bug 1360320 which sounds like a similar
  failure, handle_scheduler_error is getting an unexpected instance
  uuid, but bug 1360320 was closed simply because we weren't seeing the
  failure in the gate anymore.

  http://logs.openstack.org/13/140713/2/gate//gate-nova-
  python27/6e6b3fb/console.html#_2014-12-15_23_48_28_487

  message:"-
  function.__call__(

[Yahoo-eng-team] [Bug 1155092] Re: Namespace doesn't get deleted on vip/pool removal

[OpenStack Infra]

Fix proposed to branch: master
Review: https://review.openstack.org/142471

** Changed in: neutron
   Status: Won't Fix => 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/1155092

Title:
  Namespace doesn't get deleted on vip/pool removal

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Steps to reproduce (in Horizon):
  1. Create one pool.
  2. Create vip for it.
  3. Create another pool.
  4. Create vip for it.
  5. Delete one vip.
  6. Delete another vip.
  7. Delete two pools at once.
  8. Check qlbaas- namespaces. One namespace of corresponding pool doesn't get 
deleted and is unusable because of cleared permissions in /var/run/netns/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1155092/+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 1403547] [NEW] flavor extra_specs are not passed to any of the filters

[Nikola Đipanov]

Public bug reported:

https://review.openstack.org/#/c/122557/7/nova/scheduler/utils.py broke
this by removing the 2 lines that would make sure extra_specs are dug up
from the DB before passing adding the instance_type to the request_spec,
which eventually get's passed as part of the filter_properties
(wrongfully, but that's a different bug) to all filters.

The fix is to either put this line back, or alternatively remove
instance_type from the update call here:

https://github.com/openstack/nova/blob/fec5ff129465ab35ca8cc37fa8dafd368233b7b6/nova/scheduler/filter_scheduler.py#L119

The consequence is that AggregateInstanceExtraSpecsFilter,
ComputeCapabilitiesFilter, TrustedFilter and trusted filters are broken
in master since cb338cb7692e12cc94515f1f09008d0e328c1505

** Affects: nova
 Importance: Critical
 Status: Confirmed


** Tags: scheduler

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

Title:
  flavor extra_specs are not passed to any of the filters

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  https://review.openstack.org/#/c/122557/7/nova/scheduler/utils.py
  broke this by removing the 2 lines that would make sure extra_specs
  are dug up from the DB before passing adding the instance_type to the
  request_spec, which eventually get's passed as part of the
  filter_properties (wrongfully, but that's a different bug) to all
  filters.

  The fix is to either put this line back, or alternatively remove
  instance_type from the update call here:

  
https://github.com/openstack/nova/blob/fec5ff129465ab35ca8cc37fa8dafd368233b7b6/nova/scheduler/filter_scheduler.py#L119

  The consequence is that AggregateInstanceExtraSpecsFilter,
  ComputeCapabilitiesFilter, TrustedFilter and trusted filters are
  broken in master since cb338cb7692e12cc94515f1f09008d0e328c1505

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403547/+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 1403544] [NEW] Empty string in key_name treated as None but gets into DB

[Alexey I. Froloff]

Public bug reported:

When creating instance, it is possible to specify "'key_name': ''".
This empty string is treated as None by
nova.compute.api._validate_and_build_base_options(), but gets written to
DB.  Then it breaks Horizon when it creates the "Decrypt Password"
button for instance details view, because 'key_name' is checked to be
not None.

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

Title:
  Empty string in key_name treated as None but gets into DB

Status in OpenStack Compute (Nova):
  New

Bug description:
  When creating instance, it is possible to specify "'key_name': ''".
  This empty string is treated as None by
  nova.compute.api._validate_and_build_base_options(), but gets written
  to DB.  Then it breaks Horizon when it creates the "Decrypt Password"
  button for instance details view, because 'key_name' is checked to be
  not None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403544/+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 1403539] [NEW] Can't create both inherited and direct role assignment on same entities

[Samuel de Medeiros Queiroz]

Public bug reported:

This bug applies to backend SQL, since it is the only that supports
inherited role assignments.

Given a role assignment (actor_id, target_id, role_id, inherited), it should be 
possible to grant it as both direct and inherited:
- (actor_id, target_id, role_id, inherited=False)
- (actor_id, target_id, role_id, inherited=True)

Currently, it isn't possible since the RoleAssignment table constraint
does not include inherited column as primary key [1].

This bug affects inherited functionality on both domains and projects.

[1]
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L776-L777

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  Can't create both inherited and direct role assignment on same
  entities

Status in OpenStack Identity (Keystone):
  New

Bug description:
  This bug applies to backend SQL, since it is the only that supports
  inherited role assignments.

  Given a role assignment (actor_id, target_id, role_id, inherited), it should 
be possible to grant it as both direct and inherited:
  - (actor_id, target_id, role_id, inherited=False)
  - (actor_id, target_id, role_id, inherited=True)

  Currently, it isn't possible since the RoleAssignment table constraint
  does not include inherited column as primary key [1].

  This bug affects inherited functionality on both domains and projects.

  [1]
  
https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L776-L777

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1403539/+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 1403528] [NEW] neutron-server hangs at initializing driver for type vlan

[Jerry Zhao]

Public bug reported:

i used nova boot to launch about 50 vms. some of them were active eventually 
while the rest were in error state.
I later found that neutron-server was not returning  anything for wget 
neutron-host:9696
in the neutron-server log:
Dec 17 14:14:57 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:14:57.099 13651 WARNING neutron.db.l3_agentschedulers_db [-] Time 
since last L3 agent reschedule check has exceeded the interval between checks. 
Waiting before check to allow agents to send a heartbeat in case there was a 
clock adjustment.

That's it. the last log that was printed.

then i tried to restart neutron-server with service neutron-server
restart.However, nothing was printed.

i later enabled debug level for the log and the following logs were
printed:


Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.852 25846 DEBUG neutron.openstack.common.lockutils [-] 
Created new semaphore "manager" internal_lock 
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/openstack/common/lockutils.py:206
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.852 25846 DEBUG neutron.openstack.common.lockutils [-] 
Acquired semaphore "manager" lock 
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/openstack/common/lockutils.py:229
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.853 25846 DEBUG neutron.openstack.common.lockutils [-] Got 
semaphore / lock "_create_instance" inner 
/opt/stack/venvs/openstack/local/lib/python2.7/site-packages/neutron/openstack/common/lockutils.py:271
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.853 25846 INFO neutron.manager [-] Loading core plugin: 
neutron.plugins.ml2.plugin.Ml2Plugin
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.992 25846 INFO neutron.plugins.ml2.managers [-] Configured 
type driver names: ['local', 'flat', 'vlan', 'gre', 'vxlan']
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.994 25846 INFO neutron.plugins.ml2.drivers.type_flat [-] 
Allowable flat physical_network names: ['datacentre']
Dec 17 14:34:42 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:42.998 25846 INFO neutron.plugins.ml2.drivers.type_local [-] 
ML2 LocalTypeDriver initialization complete
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.003 25846 INFO neutron.plugins.ml2.drivers.type_vlan [-] 
Network VLAN ranges: {'datacentre': []}
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.003 25846 INFO neutron.plugins.ml2.managers [-] Loaded type 
driver names: ['flat', 'gre', 'local', 'vxlan', 'vlan']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.003 25846 INFO neutron.plugins.ml2.managers [-] Registered 
types: ['vlan', 'flat', 'gre', 'local', 'vxlan']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.004 25846 INFO neutron.plugins.ml2.managers [-] Tenant 
network_types: ['gre']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.004 25846 INFO neutron.plugins.ml2.managers [-] Configured 
extension driver names: []
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.004 25846 INFO neutron.plugins.ml2.managers [-] Loaded 
extension driver names: []
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.004 25846 INFO neutron.plugins.ml2.managers [-] Registered 
extension drivers: []
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.005 25846 INFO neutron.plugins.ml2.managers [-] Configured 
mechanism driver names: ['openvswitch']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.006 25846 INFO neutron.plugins.ml2.managers [-] Loaded 
mechanism driver names: ['openvswitch']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.006 25846 INFO neutron.plugins.ml2.managers [-] Registered 
mechanism drivers: ['openvswitch']
Dec 17 14:34:43 ci-overcloud-controller1-mqrd73cq4fgs neutron-server: 
2014-12-17 14:34:43.019 25846 INFO neutron.plugins.ml2.managers [-] 
Initializing driver for type 'vlan'

The neutron server seems to be stuck at initializing driver for type
vlan.

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

Title:
  neutron-server hangs at initializing driver for type vlan

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  i used nova boot to laun

[Yahoo-eng-team] [Bug 1403509] [NEW] Test cases in test_content_types.py assert 200 on POST operations

[Lance Bragstad]

Public bug reported:

When adding a positive test case to keystone/tests/test_content_types.py
it was discovered that several test cases in that module assert 200 OK
response codes for POST operations [1]. According to the v2.0 API
documentation, POST operations should result in a 201 Created response
code [2].

I've submitted a patch that changes all 200 OK response codes to 201 and
showcases the failures [3].

[1] 
https://github.com/openstack/keystone/blob/7f52036bd4dd1b8d911d56d3019fc9d8a7337d64/keystone/tests/test_content_types.py#L119-L131
[2] http://developer.openstack.org/api-ref-identity-v2.html#admin-users
[3] https://review.openstack.org/#/c/142440/

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  Test cases in test_content_types.py assert 200 on POST operations

Status in OpenStack Identity (Keystone):
  New

Bug description:
  When adding a positive test case to
  keystone/tests/test_content_types.py it was discovered that several
  test cases in that module assert 200 OK response codes for POST
  operations [1]. According to the v2.0 API documentation, POST
  operations should result in a 201 Created response code [2].

  I've submitted a patch that changes all 200 OK response codes to 201
  and showcases the failures [3].

  [1] 
https://github.com/openstack/keystone/blob/7f52036bd4dd1b8d911d56d3019fc9d8a7337d64/keystone/tests/test_content_types.py#L119-L131
  [2] http://developer.openstack.org/api-ref-identity-v2.html#admin-users
  [3] https://review.openstack.org/#/c/142440/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1403509/+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 1368637] Re: Error attaching NetApp iSCSI volume to Hyper-V compute node

[Luis Fernandez]

I think we can close this bug, the one reported in Cinder is now fixed
and solves this issue:

https://bugs.launchpad.net/cinder/+bug/1372808
https://review.openstack.org/141834

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

Title:
  Error attaching NetApp iSCSI volume to Hyper-V compute node

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  If you try to attach a NetApp iSCSI volume to a Hyper-V compute host,
  the request is not performed due to a type missmatch in the following
  line:

  
https://github.com/openstack/nova/blob/b6a5ce00a0f767da2538b70d5e6d4c998a8e15e0/nova/virt/hyperv/basevolumeutils.py#L135

  "if device.ScsiLun == target_lun:"

  'device.ScsiLun' returned by WMI is an 'integer', while 'target_lun'
  reported by the Cinder NetApp iSCSI driver is an 'unicode' string.

  I'm not sure if this should be also reported to Cinder. Is there any
  specification on the Cinder side that specifies the expected data type
  for that field?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368637/+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 1403431] Re: nova list --all-tenants should display tenant name/uuid as well

[Matthew Gilliard]

Confirmed:

ubuntu@cont:~/devstack$ nova list --all-tenants
+--+--+++-+--+
| ID   | Name | Status | Task State | Power 
State | Networks |
+--+--+++-+--+
| 2350ea5e-726c-497f-9300-7290b63407b6 | s2   | PAUSED | -  | Paused
  | private=10.0.0.4 |
+--+--+++-+--+

I think this would be a nice addition.  It seems that tenant_id is
already sent back to the client as part of the HTTP response, so at
least that could be shown easily.

** Also affects: python-novaclient
   Importance: Undecided
   Status: New

** Changed in: python-novaclient
   Status: New => Confirmed

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

Title:
  nova list --all-tenants should display tenant name/uuid as well

Status in OpenStack Compute (Nova):
  Confirmed
Status in Python client library for Nova:
  In Progress

Bug description:
  nova list --all-tenants (which is an admin command) does not display
  the Tenant Name/UUID. In order to find out which tenant the server
  belongs to, we have to run nova show command passing it the server
  UUID.

  In order to prevent this extra step, the nova list --all-tenants
  should display the Tenant Name/UUID as well. This will also make it
  consistent with the horizon Admin -> System -> Instances -> All
  Instances tabular display.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403431/+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 1403455] [NEW] neutron-netns-cleanup doesn't clean up all L3 agent spawned processes

[Assaf Muller]

Public bug reported:

neutron-netns-cleanup cleans all DHCP resources by invoking a command on
the DHCP driver. However, in the L3 agent case, it merely tries to
remove the router namespaces. Any child processes that we've added over
the years (Specifically metadata proxy, radvd, keepalived at this point)
are not cleaned up. I think that netns-cleanup should remove any routers
on the system the same way we remove DHCP resources, by invoking a
method on a L3 agent instance.

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

Title:
  neutron-netns-cleanup doesn't clean up all L3 agent spawned processes

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  neutron-netns-cleanup cleans all DHCP resources by invoking a command
  on the DHCP driver. However, in the L3 agent case, it merely tries to
  remove the router namespaces. Any child processes that we've added
  over the years (Specifically metadata proxy, radvd, keepalived at this
  point) are not cleaned up. I think that netns-cleanup should remove
  any routers on the system the same way we remove DHCP resources, by
  invoking a method on a L3 agent instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403455/+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 1403442] [NEW] remove detail method from the LimitsController class

[zhangtralon]

Public bug reported:

we should remove the detail method from the LimitsController class
because the detail is not the default method and it doesn't add the
detail  operation in the _setup_routes method from the class APIRouter

** Affects: nova
 Importance: Undecided
 Assignee: zhangtralon (zhangchunlong1)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => zhangtralon (zhangchunlong1)

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

Title:
  remove detail method from the LimitsController class

Status in OpenStack Compute (Nova):
  New

Bug description:
  we should remove the detail method from the LimitsController class
  because the detail is not the default method and it doesn't add the
  detail  operation in the _setup_routes method from the class APIRouter

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403442/+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 1403441] [NEW] remove detail method from the LimitsController class

[zhangtralon]

Public bug reported:

we should remove the detail method from the LimitsController class
because the detail is not the default method and it doesn't add the
detail  operation in the _setup_routes method from the class APIRouter

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

Title:
  remove detail method from the LimitsController class

Status in OpenStack Compute (Nova):
  New

Bug description:
  we should remove the detail method from the LimitsController class
  because the detail is not the default method and it doesn't add the
  detail  operation in the _setup_routes method from the class APIRouter

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403441/+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 1403431] [NEW] nova list --all-tenants should display tenant name/uuid as well

[Yamini Sardana]

Public bug reported:

nova list --all-tenants (which is an admin command) does not display the
Tenant Name/UUID. In order to find out which tenant the server belongs
to, we have to run nova show command passing it the server UUID.

In order to prevent this extra step, the nova list --all-tenants should
display the Tenant Name/UUID as well. This will also make it consistent
with the horizon Admin -> System -> Instances -> All Instances tabular
display.

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

Title:
  nova list --all-tenants should display tenant name/uuid as well

Status in OpenStack Compute (Nova):
  New

Bug description:
  nova list --all-tenants (which is an admin command) does not display
  the Tenant Name/UUID. In order to find out which tenant the server
  belongs to, we have to run nova show command passing it the server
  UUID.

  In order to prevent this extra step, the nova list --all-tenants
  should display the Tenant Name/UUID as well. This will also make it
  consistent with the horizon Admin -> System -> Instances -> All
  Instances tabular display.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1403431/+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 1403424] [NEW] Fixed ip info shown for port even when dhcp is disabled

[Pasquale Porreca]

Public bug reported:

As a user it is very confusing (especially in Horizon dashboard) having
the IP address displayed even when the DHCP is disabled for the subnet
the port belongs to: the user would expect that the IP address shown is
actually assigned to the instance, but this is not the case, since the
DHCP is disabled.

I asked in the ML about this issue (http://lists.openstack.org/pipermail
/openstack-dev/2014-December/053069.html) and I understood that neutron
needs to reserve an IP address for a port even in the case it is not
assigned, anyway I think this info should not be displayed or should be
differently specified.

In a first moment I thought about raising the bug against Horizon, but I
feel the correct place to fix this is in neutron. Before to assign this
bug to myself I would like to get some feedback by other developers, my
idea for a possible solution is to add a boolean element "assigned" to
"fixed_ip" dict with value False when in the subnet identified by
"subnet_id"  DHCP is disabled.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: ui

** Tags added: ui

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

Title:
  Fixed ip info shown for port even when dhcp is disabled

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  As a user it is very confusing (especially in Horizon dashboard)
  having the IP address displayed even when the DHCP is disabled for the
  subnet the port belongs to: the user would expect that the IP address
  shown is actually assigned to the instance, but this is not the case,
  since the DHCP is disabled.

  I asked in the ML about this issue
  (http://lists.openstack.org/pipermail/openstack-
  dev/2014-December/053069.html) and I understood that neutron needs to
  reserve an IP address for a port even in the case it is not assigned,
  anyway I think this info should not be displayed or should be
  differently specified.

  In a first moment I thought about raising the bug against Horizon, but
  I feel the correct place to fix this is in neutron. Before to assign
  this bug to myself I would like to get some feedback by other
  developers, my idea for a possible solution is to add a boolean
  element "assigned" to "fixed_ip" dict with value False when in the
  subnet identified by "subnet_id"  DHCP is disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403424/+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 1403426] [NEW] The MetadefPropery Proxy object is missing created_at, updated_at

[Wayne]

Public bug reported:

In the glance/domain/proxy.py module, the MetadefProperty class doesn't contain 
the created_at nor updated_at fields.
They should be added to match the other classes.

** Affects: glance
 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/1403426

Title:
  The MetadefPropery Proxy object is missing created_at, updated_at

Status in OpenStack Image Registry and Delivery Service (Glance):
  New

Bug description:
  In the glance/domain/proxy.py module, the MetadefProperty class doesn't 
contain the created_at nor updated_at fields.
  They should be added to match the other classes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1403426/+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 1403422] [NEW] Running "glance --os-image-api-version 2 image-list --visibility test" with incorrect --visibility option throws unclear error.

[Kanchan Gupta]

Public bug reported:

I was trying to check image-list based on visibility by using the
following command:

glance --os-image-api-version 2 image-list --visibility test

But I got output:


 
  400 Bad Request
 
 
  400 Bad Request
  Invalid visibility value: test

 
 (HTTP 400)

which does not provide any clear information.

Expected result:
Glance should throw an exception with proper message.

** Affects: glance
 Importance: Undecided
 Assignee: Kanchan Gupta (kanchan-gupta1)
 Status: New

** Changed in: glance
 Assignee: (unassigned) => Kanchan Gupta (kanchan-gupta1)

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

Title:
  Running "glance --os-image-api-version 2 image-list --visibility test"
  with incorrect --visibility option throws unclear error.

Status in OpenStack Image Registry and Delivery Service (Glance):
  New

Bug description:
  I was trying to check image-list based on visibility by using the
  following command:

  glance --os-image-api-version 2 image-list --visibility test

  But I got output:

  
   
400 Bad Request
   
   
400 Bad Request
Invalid visibility value: test

   
   (HTTP 400)

  which does not provide any clear information.

  Expected result:
  Glance should throw an exception with proper message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1403422/+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 1369574] Re: Sahara doesn't support cinder volume type

[Thierry Carrez]

** Changed in: sahara
   Status: Fix Committed => Fix Released

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

Title:
  Sahara doesn't support cinder volume type

Status in Orchestration API (Heat):
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in Python client library for Sahara (ex. Savanna):
  Fix Committed
Status in OpenStack Data Processing (Sahara, ex. Savanna):
  Fix Released

Bug description:
  When creating node group template you can set cinder as storage for clusters, 
but you can not set type of cinder volumes.
  By default uses 'default' cinder backend with 'default' type.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1369574/+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 1403408] [NEW] Redundant endpoints found in the table "endpoint"

[Dave Chen]

Public bug reported:

MariaDB [keystone]> select * from endpoint where url = 
"http://10.239.1.1:5010/v2.0"; and interface = "admin";
+--+--+---+--+-+---+-+---+
| id   | legacy_endpoint_id   | 
interface | service_id   | url | 
extra | enabled | region_id |
+--+--+---+--+-+---+-+---+
| 38a55638f08c4be1afdd3172f15c4144 | 2dcb5c14c4da4a22a060c78f073decac | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | RegionOne |
| a365f3fd58eb482fa44603fe83f8b2e0 | 26ef22b4dd8b487bb2f29f52cbbb2fec | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | regionOne |
| b0f41268a6b2438b92d977a464fd7f2d | 97b1ce4adc794b3598fb5a521e63276b | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | RegionOne |
| dd3c0c9880e74d55b4d7de71ac5207ac | 6d994b06ed8942cda56bd2c03cbc56c8 | admin   
  | a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|
   1 | regionOne |
+--+--+---+--+-+---+-+---+
4 rows in set (0.00 sec)

These entries has the same interface, same url etc. except "id" and
"legacy_endpoint_id". User can create many redundant endpoints as long
as he/she wants to, just via the command like following:

keystone --debug endpoint-create --region RegionOne  --service
a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.239.1.1:5010/v2.0
--adminurl http://10.239.1.1:5010/v2.0 --internalurl
http://10.239.1.1:5010/v2.0

I'm not sure whether this is an intentional behavior, existed endpoints
check to avoid redundant entries seems is needed here.

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

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

** Summary changed:

- Redundant endpoints found in table "endpoint"
+ Redundant endpoints found in the table "endpoint"

** Description changed:

  MariaDB [keystone]> select * from endpoint where url = 
"http://10.239.1.1:5010/v2.0"; and interface = "admin";
  
+--+--+---+--+-+---+-+---+
  | id   | legacy_endpoint_id   | 
interface | service_id   | url | 
extra | enabled | region_id |
  
+--+--+---+--+-+---+-+---+
  | 38a55638f08c4be1afdd3172f15c4144 | 2dcb5c14c4da4a22a060c78f073decac | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | RegionOne |
  | a365f3fd58eb482fa44603fe83f8b2e0 | 26ef22b4dd8b487bb2f29f52cbbb2fec | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | regionOne |
  | b0f41268a6b2438b92d977a464fd7f2d | 97b1ce4adc794b3598fb5a521e63276b | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | RegionOne |
  | dd3c0c9880e74d55b4d7de71ac5207ac | 6d994b06ed8942cda56bd2c03cbc56c8 | admin 
| a1663c0dbba64425b5767688ac86fa10 | http://10.239.1.1:5010/v2.0 | {}|  
 1 | regionOne |
  
+--+--+---+--+-+---+-+---+
  4 rows in set (0.00 sec)
  
- 
  These entries has the same interface, same url etc. except "id" and
  "legacy_endpoint_id". User can create many redundant endpoints as long
- as he/she wants, just via the command like following:
+ as he/she wants to, just via the command like following:
  
  keystone --debug endpoint-create --region RegionOne  --service
  a1663c0dbba64425b5767688ac86fa10 --publicurl http://10.239.1.1:5010/v2.0
  --adminurl http://10.239.1.1:5010/v2.0 --internalurl
  http://10.239.1.1:5010/v2.0
  
- 
- I'm not sure whether this is an intentional behavior, existed endpoints check 
to avoid redundant entries seems is needed here.
+ I'm not sure whether this is an intentional behavior, existed endpoints
+ check to avoid redundant entries seems is needed here.

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

[Yahoo-eng-team] [Bug 1403411] [NEW] Can't get the list of router with the filter of "distributed" or "ha"

[KaiLin]

Public bug reported:

SYMPTOM:
GET  /v2.0/routers?distributed=false
response:
"routers": [
{
"status": "ACTIVE",
"external_gateway_info": {
"network_id": "bb935f5c-c72e-4abc-9550-2ce7b90c14c8",
"enable_snat": true,
"external_fixed_ips": [
{
"subnet_id": "7b49431e-f1c2-473e-b919-135ead0274e0",
"ip_address": "172.24.4.102"
}
]
},
"name": "router2",
"admin_state_up": true,
"tenant_id": "475660789a404a0e9294eb92a0cecb0e",
"distributed": true,
"routes": [],
"ha": false,
"id": "f77809c6-05ae-446a-b497-1b4392f29bc8"
}
]
}

and the same with "ha"

In some case,we need get the list of router with the filter of
"distributed" or "ha".So we need to fix it.

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

Title:
  Can't get the list of router with the filter of "distributed" or "ha"

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  SYMPTOM:
  GET  /v2.0/routers?distributed=false
  response:
  "routers": [
  {
  "status": "ACTIVE",
  "external_gateway_info": {
  "network_id": "bb935f5c-c72e-4abc-9550-2ce7b90c14c8",
  "enable_snat": true,
  "external_fixed_ips": [
  {
  "subnet_id": "7b49431e-f1c2-473e-b919-135ead0274e0",
  "ip_address": "172.24.4.102"
  }
  ]
  },
  "name": "router2",
  "admin_state_up": true,
  "tenant_id": "475660789a404a0e9294eb92a0cecb0e",
  "distributed": true,
  "routes": [],
  "ha": false,
  "id": "f77809c6-05ae-446a-b497-1b4392f29bc8"
  }
  ]
  }

  and the same with "ha"

  In some case,we need get the list of router with the filter of
  "distributed" or "ha".So we need to fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1403411/+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 968696] Re: "admin"-ness not properly scoped

[Song Li]

Admin of one tenant can also create networks, routers and so on in other 
tenants, and take other actions. It might be a big risk for the security.
So I think it also affect the Neutron.

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

Title:
  "admin"-ness not properly scoped

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/968696/+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 1403397] [NEW] Flavors page and create flavor test

[Daniel Korn]

Public bug reported:

Integration tests should include a flavorpage under the admin tab,
containing the flavors table and functionalities,  create flavor in
particular.

There also should be a basic test verifying that creating and deleting a
flavor works.

** Affects: horizon
 Importance: Undecided
 Assignee: Daniel Korn (dkorn)
 Status: New


** Tags: flavors integration-tests

** Changed in: horizon
 Assignee: (unassigned) => Daniel Korn (dkorn)

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

Title:
  Flavors page and create flavor test

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Integration tests should include a flavorpage under the admin tab,
  containing the flavors table and functionalities,  create flavor in
  particular.

  There also should be a basic test verifying that creating and deleting
  a flavor works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1403397/+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 1403379] [NEW] can not delete an instance with Chinese name

[Eli Qiao]

Public bug reported:

can not delete an instance which display name is Chinese.
[tagett@stack-01 devstack]$ nova --debug delete 测试

'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
DEBUG (shell:908) Unable to delete the specified server(s).
Traceback (most recent call last):
  File "/opt/stack/python-novaclient/novaclient/shell.py", line 905, in main
OpenStackComputeShell().main(argv)
  File "/opt/stack/python-novaclient/novaclient/shell.py", line 832, in main
args.func(self.cs, args)
  File "/opt/stack/python-novaclient/novaclient/v1_1/shell.py", line 1876, in 
do_delete
_("Unable to delete the specified server(s)."))
  File "/opt/stack/python-novaclient/novaclient/utils.py", line 320, in 
do_action_on_many
raise exceptions.CommandError(error_msg)

** Affects: python-novaclient
 Importance: Undecided
 Status: New

** Project changed: nova => python-novaclient

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

Title:
  can not delete an instance with Chinese name

Status in Python client library for Nova:
  New

Bug description:
  can not delete an instance which display name is Chinese.
  [tagett@stack-01 devstack]$ nova --debug delete 测试

  'ascii' codec can't encode characters in position 0-1: ordinal not in 
range(128)
  DEBUG (shell:908) Unable to delete the specified server(s).
  Traceback (most recent call last):
File "/opt/stack/python-novaclient/novaclient/shell.py", line 905, in main
  OpenStackComputeShell().main(argv)
File "/opt/stack/python-novaclient/novaclient/shell.py", line 832, in main
  args.func(self.cs, args)
File "/opt/stack/python-novaclient/novaclient/v1_1/shell.py", line 1876, in 
do_delete
  _("Unable to delete the specified server(s)."))
File "/opt/stack/python-novaclient/novaclient/utils.py", line 320, in 
do_action_on_many
  raise exceptions.CommandError(error_msg)

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-novaclient/+bug/1403379/+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 1392155] Re: The cloud_admin should be able to get the list of projects in all domains.

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  The cloud_admin should be able to get the list of projects in all
  domains.

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When using policy.v3cloudsample.json without change (except 
'admin_domain_id'), 
  the cloud_admin cannot get the list of projects(list_projects) in domains 
other than its own domain.
  The cloud_admin is an administrator for the entire keystone system,
  so the cloud_admin should be able to get the list of projects in all domains.

  The 'policy.v3cloudsample.json' is a sample file, but it should be
  corrected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1392155/+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 1390100] Re: do not depend on protocol specific id's when creating a federation token

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  do not depend on protocol specific id's when creating a federation
  token

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  If token.provider.common we have a check before issuing a federation
  that checks if the method name used agrees with a hard coded protocol
  name.

i.e.: if 'saml2' in method_names or 'oidc' in method_names

  
  this should be done in a more dynamic way, so if more auth methods are 
supported, then they are automatically seen as federation methods.

  fix 1: potentially have a federation_methods in [auth] that lists valid 
federation methods (very similar to methods in [auth])
  fix 2: check the method name against protocol list ids

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1390100/+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 1384457] Re: Self value in Link is wrong in GET /OS-REVOKE/events

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Self value in Link  is wrong in  GET /OS-REVOKE/events

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  There are 2 events in the path

  
  # curl -k -H "X-Auth-Token:SomeToken"   
http://localhost:35357/v3/OS-REVOKE/events  | python -mjson.tool
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   304  100   3040 0313  0 --:--:-- --:--:-- --:--:--   313
  {
  "events": [
  {
  "issued_before": "2014-10-22T20:26:14.00Z",
  "project_id": "f5590b050dc14795b5e8447a223bd696"
  },
  {
  "audit_id": "cAV3qiytQkuzpANJ3CPFRg",
  "issued_before": "2014-10-22T20:29:44.00Z"
  }
  ],
  "links": {
  "next": null,
  "previous": null,
  "self": "http://localhost:35357/v3/OS-REVOKE/events/events";
  }
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384457/+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 1384409] Re: UnicodeDecodeError when trying to create a user with DEBUG logging turned on

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  UnicodeDecodeError when trying to create a user with DEBUG logging
  turned on

Status in OpenStack Identity (Keystone):
  Fix Released
Status in The Oslo library incubator:
  Invalid

Bug description:
  The mask_password function of openstack.common.log and/or
  openstack.common.strutils (depending on OpenStack version) seems to
  choke on unicode characters. This actually prevents proper function
  when logging level is set to DEBUG.

  When submitting a POST request to create a user with the unicode
  snowman character in the name (for testing purposes), I get the
  following traceback:

  2014-10-22 18:12:01.973 21263 DEBUG keystone.common.wsgi [-] 
 REQUEST BODY  _call_ 
/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py:430
  2014-10-22 18:12:01.974 21263 ERROR keystone.common.wsgi [-] 'ascii' codec 
can't decode byte 0xe2 in position 36: ordinal not in range(128)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi Traceback (most 
recent call last):
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 396, in _call_
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi response = 
request.get_response(self.application)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1296, in send
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi application, 
catch_exc_info=False)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1260, in 
call_application
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi app_iter = 
application(self.environ, start_response)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in _call_
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi return resp(environ, 
start_response)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in _call_
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi resp = 
self.call_func(req, *args, **self.kwargs)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi return 
self.func(req, *args, **kwargs)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 432, in _call_
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi LOG.debug('%s', 
log.mask_password(line))
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi File 
"/usr/lib/python2.7/dist-packages/keystone/openstack/common/log.py", line 266, 
in mask_password
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi message = 
six.text_type(message)
  2014-10-22 18:12:01.974 21263 TRACE keystone.common.wsgi UnicodeDecodeError: 
'ascii' codec can't decode byte 0xe2 in position 36: ordinal not in range(128)

  That trace is from an Icehouse install, but the code in mask_password
  appears to suffer the same issue in Juno.

  A simpler repro case:

  >>> from keystone.openstack.common.log import mask_password
  >>> mask_password('"password": "foo"')
  u'"password": "***"'
  >>> mask_password('"password": "f☃o"')
  Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/log.py", 
line 266, in mask_password
  message = six.text_type(message)
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 14: 
ordinal not in range(128)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384409/+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 1389623] Re: Duplicate code in test_v3_federation

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Duplicate code in test_v3_federation

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In the set set up of sample data, there exists the following:

  self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request(
  self.tokens['CUSTOMER_ASSERTION'], 'domain', self.domainB['id'])

  self.TOKEN_SCOPE_DOMAIN_B_FROM_CUSTOMER = self._scope_request(
  self.tokens['CUSTOMER_ASSERTION'], 'domain',
  self.domainB['id']

  The second statement is a duplicate of the first (formatting aside).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1389623/+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 1397207] Re: keystone-manage db_version --extension shows incorrect help info

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  keystone-manage db_version --extension shows incorrect help info

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  keystone-manage  db_version  -h

  usage: keystone-manage 
[db_sync|db_version|mapping_purge|pki_setup|saml_idp_metadata|ssl_setup|token_flush]
 db_version
 [-h] [--extension EXTENSION]

  optional arguments:
-h, --helpshow this help message and exit
--extension EXTENSION
  Migrate the database for the specified extension. If
  not provided, db_sync will migrate the common
  repository.

  this msg is simlpy copy-pasted from db_sync.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1397207/+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 1348262] Re: PKI and PKIZ tokens contain unnecessary whitespace

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  PKI and PKIZ tokens contain unnecessary whitespace

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In the race to produce smaller PKI tokens, we've overlooked that we
  can produce smaller JSON bodies by removing all whitespace between
  structural characters. For example, the following JSON blobs are all
  equally valid:

{ "key" : "value" }

  ... as compared to what we're producing today:

{"key":"value"}

  ... as compared to all unnecessary whitespace removed:

{"key":"value"}

  This optimization would save us a few bytes in both PKI and PKIZ
  tokens.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1348262/+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 1394816] Re: sample_data.sh does not work with default options in keystone.conf

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  sample_data.sh does not work with default options in keystone.conf

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Looks like sample_data.sh does not account for the default options
  (commented out) in keystone.conf. See

  https://github.com/openstack/keystone/blob/master/tools/sample_data.sh#L70

  Simple fix would be to also grep for '#admin_token='.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1394816/+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 1390484] Re: Missing "s" in keystone configuration document.

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Missing "s" in keystone configuration document.

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:

  The keystone doc
  http://docs.openstack.org/developer/keystone/configuration.html#token-
  persistence-driver, in "Token Persistence Driver", has a mistype in
  the red warning box:

  ```
  keystone.token.persistence.backend.memcache_pool.Token
  keystone.token.persistence.backend.memcache.Token
  ```

  They should have been

  ```
  keystone.token.persistence.backends.memcache_pool.Token
  keystone.token.persistence.backends.memcache.Token
  ```

  It is the missing "s". You can ctrl+f in this document, with or
  without "s". You will find the mismatch.

  

  If you fill /etc/keystone.conf with the missing "s"
  keystone.token.persistence.backend.memcache_pool.Token (as I did)

  ```
  ...
  [token]
  provider = keystone.token.providers.uuid.Provider
  driver = keystone.token.persistence.backend.memcache_pool.Token
  ...
  ```

  The command below will causes keystone to raise "No module named
  backend.memcache_pool" error (token is faked)

  ```
  $ keystone --debug --os-token 135abcdef --os-endpoint 
http://127.0.0.1:35357/v2.0/ user-list
  DEBUG:keystoneclient.session:REQ: curl -i -X GET 
http://127.0.0.1:35357/v2.0/users -H "User-Agent: python-keystoneclient" -H 
"X-Auth-Token: {SHA1}ce791127cf84307aa59d7a8ba8829f00d5d91570"
  INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection 
(1): 127.0.0.1
  DEBUG:requests.packages.urllib3.connectionpool:"GET /v2.0/users HTTP/1.1" 500 
143
  DEBUG:keystoneclient.session:RESP:
  DEBUG:keystoneclient.session:Request returned failure status: 500
  An unexpected error prevented the server from fulfilling your request. (HTTP 
500)
  ```

  The error raised from keystone service

  ```
  $ keystone-all
  ...
  2014-11-07 13:41:06.676 20275 ERROR keystone.common.wsgi [-] No module named 
backend.memcache_pool
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi Traceback (most 
recent call last):
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 430, in 
__call__
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi response = 
self.process_request(request)
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/middleware/core.py", line 279, in 
process_request
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi auth_context = 
self._build_auth_context(request)
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/middleware/core.py", line 259, in 
_build_auth_context
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi 
token_data=self.token_provider_api.validate_token(token_id))
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 225, in 
validate_token
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi token = 
self._validate_token(unique_id)
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 1013, in 
decorate
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi should_cache_fn)
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 640, in 
get_or_create
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi async_creator) 
as value:
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/core/dogpile.py", line 158, in 
__enter__
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi return 
self._enter()
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/core/dogpile.py", line 98, in _enter
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi generated = 
self._enter_create(createdtime)
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/core/dogpile.py", line 149, in 
_enter_create
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi created = 
self.creator()
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 612, in 
gen_value
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi created_value = 
creator()
  2014-11-07 13:41:06.676 20275 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/dogpile/cache/region.py", line 1009, in 
creator
  2014-11-07 13:41:06.67

[Yahoo-eng-team] [Bug 1380477] Re: a tiny issue in docstring

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  a tiny issue in docstring

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  This line[0] should not be "Start a WSGI server in a new green
  thread." I think.

  The truth is the python process spawn many green threads to handle
  incoming request from a greenlet pool. So the WSGI server itself
  should be a normal python process[1], but the handling jobs is in
  green thread (greenlet). I think we could say "Start a WSGI server
  with a new green thread pool" or something else.

  Above is from my understanding for os-thread and green thread, maybe
  with some mistakes.

  [0] 
https://github.com/openstack/keystone/blob/master/keystone/common/environment/eventlet_server.py#L177
  [1] 
https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L781-L801

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1380477/+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 1377101] Re: Obsolete deployment docs

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Obsolete deployment docs

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Section "Preparing your deployment" of configuration.rst suggests
  configuration in [sql] section, which is not used any more.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1377101/+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 1385405] Re: Domain backed by a populated read-only domain-specific LDAP identity backend cannot be deleted

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Domain backed by a populated read-only domain-specific LDAP identity
  backend cannot be deleted

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  I've set up a DevStack with Keystone using domain-specific backends.

  I've then created a Domain-A with its domain-specific configuration
  being:

  [ldap]
  url=ldap://ldap.server.com:389
  user=cn=admin,dc=example,dc=com
  password=secret
  suffix=dc=example,dc=com

  user_tree_dn="ou=Users,dc=example,dc=com" 
  user_id_attribute=cn
  user_name_attribute=cn
  user_objectclass=organizationalPerson
  user_allow_create=false
  user_allow_update=false
  user_allow_delete=false

  group_tree_dn=ou=Groups,dc=example,dc=com
  group_id_attribute=cn
  group_name_attribute=cn
  group_objectclass=*
  group_allow_create=false
  group_allow_update=false
  group_allow_delete=false

  [identity]
  driver = keystone.identity.backends.ldap.Identity

  
  Now I cannot delete this domain. When I try that, Keystone returns this error:
  {"error": {"message": "You are not authorized to perform the requested 
action: LDAP group delete (Disable debug mode to suppress these details.)", 
"code": 403, "title": "Forbidden"}

  
  As I configured it not to allow the information to be deleted by Keystone, 
I'd expect it to ignore the fact that it cannot delete the groups and users and 
then delete the domain.

  On the other hand, it is good to have it blocked until the not-needed-
  anymore configuration file is removed.

  
  See also the chat below on 2014-10-22 on #openstack-keystone:

  14:53:45 gabriel-bezerra | ayoung: I cannot delete a domain that is backed by 
a populated read-only LDAP database. It is a bug, right? (just asking before 
filing)
  14:56:11  ayoung | gabriel-bezerra, multi-backend?
  14:56:52 gabriel-bezerra | ayoung: yes, domain-specific
  14:57:37  ayoung | gabriel-bezerra, what error do you get?  I'm not 
certain its a bug or not.  Suspect a foreign key constraint
  14:57:50  ayoung | but you need to disable a domain before deleting 
no matter what
  14:58:15 gabriel-bezerra | ayoung: {"error": {"message": "You are not 
authorized to perform the requested action: LDAP group delete (Disable debug 
mode to suppress these details.)", "code": 403, "title": "Forbidden"}
  14:58:39  ayoung | gabriel-bezerra, cuz deleting the domain trys to 
delete all of the objects inside it
  14:58:48 gabriel-bezerra | ayoung: it is being disabled
  14:59:00  ayoung | You'd have to unmap the domain specific backend 
part first 
  14:59:30  ayoung | so remove the file, restart the server,and I bet 
it works...and I think that is as it should be under current ways of thinking
  15:00:07 gabriel-bezerra | ayoung: ok. no bug then. thank you.
  15:00:21  ayoung | yeah...but maybe something to document
  15:00:59  ayoung | gabriel-bezerra, until we make the configuration 
something that can be done on the fly and without restarting the server, I'd 
say it "works as designed"
  15:07:41 gabriel-bezerra | ayoung: I'll file the bug then, just to keep track 
of the issue.
  15:07:50  ayoung | ++

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1385405/+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 1389586] Re: lack of debug logging for federation flows

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  lack of debug logging for federation flows

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  There is a distinct lack of debug logging in the federation branch of
  the code, making debugging certain mapping assertions harder than it
  needs to be:

  steve:keystone$ grep 'LOG' -r keystone/contrib/federation/*
  keystone/contrib/federation/core.py:LOG = logging.getLogger(__name__)
  keystone/contrib/federation/idp.py:LOG = log.getLogger(__name__)
  keystone/contrib/federation/idp.py:LOG.error(msg)
  keystone/contrib/federation/idp.py:LOG.error(msg)
  keystone/contrib/federation/utils.py:LOG = log.getLogger(__name__)
  keystone/contrib/federation/utils.py:
LOG.warning(_('Ignoring user name %s'),

  We should add some more debug logging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1389586/+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 1395117] Re: Create SAML assertion using domain scoped tokens returns 500 (Internal Server Error)

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Create SAML assertion using domain scoped tokens returns 500 (Internal
  Server Error)

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When using a domain scoped token to request a SAML assertion, Keystone
  responds with a Internal Server Error. Here is where this condition is
  handled:
  
https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L279

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1395117/+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 1389583] Re: _handle_saml2_tokens() should be renamed to something more generic

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  _handle_saml2_tokens() should be renamed to something more generic

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In file
  
https://github.com/openstack/keystone/blob/master/keystone/token/providers/common.py#L433
  there is a function called _handle_saml2_tokens(), but since bp
  generic-mapping-federation and spec
  http://specs.openstack.org/openstack/keystone-specs/specs/juno
  /generic-mapping-federation.html, the federation process was
  standardized. So it should be renamed accordingly, possibly either
  _handle_federation_tokens() or _handle_mapped_tokens()

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1389583/+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 1385694] Re: /auth/projects fails to include any projects that have inherited group roles

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  /auth/projects fails to include any projects that have inherited group
  roles

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The /auth/projects API call is meant to return list of projects for
  which the user could ask for a project-scoped token - i.e. any project
  on which they have a role. However, the code does not look at any
  roles that a group may have on a domain that are marked as inherited
  to projects - hence failing to include these projects in the list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1385694/+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 1381768] Re: AttributeError: 'module' object has no attribute 'LDAP_CONTROL_PAGE_OID' with python-ldap 2.4

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  AttributeError: 'module' object has no attribute
  'LDAP_CONTROL_PAGE_OID' with python-ldap 2.4

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone juno series:
  Fix Released
Status in keystone package in Ubuntu:
  Confirmed

Bug description:
  When using LDAP backend with keystone Juno RC2, the following error
  occurs:

  AttributeError: 'module' object has no attribute
  'LDAP_CONTROL_PAGE_OID'

  It looks like that attribute was removed in python-ldap 2.4 which
  breaks Ubuntu Trusty and Utopic and probably RHEL7.

  
  More details on this change here in the library are here:

  https://mail.python.org/pipermail//python-ldap/2012q1/003105.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1381768/+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 1386376] Re: Validation parameter_type.url regex doesn't pass validation for IPv6 addresses

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Validation parameter_type.url regex doesn't pass validation for IPv6
  addresses

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone juno series:
  Fix Released

Bug description:
  Can't create an endpoint with an IPv6 address in the URL. E.g.:

  [root@ ~]# curl -k -i -X POST https://localhost:35357/v3/endpoints -H 
"Accept: application/json" -H "X-Auth-Token: 96d82b1a36a94b439fd91d2a875380be" 
-H "Content-Type: application/json" -d '{"endpoint": {"interface": "admin", 
"name": "metering", "region": "RegionOne", "url": 
"https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2";, "service_id": 
"57118ebd91094d7d8d609136d185f0dd"}}'; echo
  HTTP/1.1 400 Bad Request
  Date: Mon, 27 Oct 2014 18:42:32 GMT
  Server: Apache/2.2.15 (Red Hat)
  Vary: X-Auth-Token
  Content-Length: 182
  Connection: close
  Content-Type: application/json

  {"error": {"message": "Invalid input for field 'url'. The value is
  'https://[fd55:faaf:e1ab:3ea:9:114:251:134]:8777/v2'.", "code": 400,
  "title": "Bad Request"}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1386376/+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 1384789] Re: XmlBodyMiddleware driver is deprecated, probably shouldn't still be the default

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
Milestone: None => kilo-1

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

Title:
  XmlBodyMiddleware driver is deprecated, probably shouldn't still be
  the default

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The XmlBodyMiddleware driver claims to have been deprecated since
  Icehouse and claims that it will be removed, so it shouldnt be the
  default because scary messages like this imply that Keystone will stop
  working in the next version for us...

  2014-10-23 14:52:20.754 1236 WARNING
  keystone.openstack.common.versionutils [-] Deprecated:
  keystone.middleware.core.XmlBodyMiddleware is deprecated as of
  Icehouse in favor of support for "application/json" only and may be
  removed in Kilo.

  I assume but am not sure that this is related to the api-paste
  options? If this is not a bug, what can I do to modify my config to
  get rid of this warning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384789/+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 1383817] Re: Deprecate catalog replacements and whitelists

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Deprecate catalog replacements and whitelists

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Bug #1354208 reported a security flaw in the way that we performed
  substitution for catalog URLs. The immediate solution was to add a
  whitelist of config fields that are safe to use with substitution. The
  long term goal is to get rid of this feature and only allow tenant_id
  and user_id to be used for substitution.

  The first step for the Kilo release is to deprecate the feature.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1383817/+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 1367778] Re: Extract Assignment related tests from IdentityTestCase

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Extract Assignment related tests from IdentityTestCase

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  IdentityTestCase is intended to have only tests for user and groups.
  However it also has tests for domains, projects, roles and grants/role 
assignments.

  Every test that are not for users or groups have to be extracted from
  IdentityTestCase (test_v3_identity) and to be put in
  AssignmentTestCase (test_v3_assignment, to be created).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1367778/+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 1365147] Re: No test for tokens using inherited domain role

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  No test for tokens using inherited domain role

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  If a user has an inherited role in a domain, he is able to get a token
  on every project inside that domain, even if he doesn't have a
  specific grant on that project.

  Currently, there is no test for this feature, we should create it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1365147/+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 1387401] Re: token_flush can hang if lots of tokens

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  token_flush can hang if lots of tokens

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone juno series:
  Fix Released

Bug description:
  
  If you've got a system that can generate lots of tokens, token_flush can 
hang. For DB2, this happens if you create > 100 tokens in a second (for mysql 
it's 1000 tokens in a second). The query to get the time to delete returns the 
100th timestamp which is the same as the min timestamp, and then it goes to 
delete < min timestamp and none match, so none are deleted, then it gets stuck 
in a loop since the function always returns the min timestamp.

  This could be fixed easily by using <= rather than < for the deletion
  comparison.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1387401/+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 1385533] Re: Domain tokens issued from a saml2 auth incorrectly includes group roles marked as inherited

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Domain tokens issued from a saml2 auth incorrectly includes group
  roles marked as inherited

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When building the roles in a Keystone  token from a saml2 token, we
  call assignment_api.get_roles_for_groups() to add in any group roles.
  This appears to ignore the inheritance flag on the assignment - and
  puts in all group roles whether inherited or not.  This means the
  wrong roles can end up in the resulting Keystone token.

  The implication is that domain scoped tokens would incorrectly get
  roles that were meant to be inherited (only) to projects within that
  domain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1385533/+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 1389752] Re: Project tokens issued from a saml2 auth are missing inherited group roles

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Project tokens issued from a saml2 auth are missing inherited group
  roles

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When building the roles in a Keystone token from a saml2 token, we
  call assignment_api.get_roles_for_groups() to add in any group roles.
  This appears to ignore the inheritance flag on the assignment - and
  puts in all group roles whether inherited or not. This means the wrong
  roles can end up in the resulting Keystone token.

  The implication is that project scoped tokens would not get any group
  roles that should be inherited from the domain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1389752/+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 1385643] Re: /auth/domains incorrectly includes domains with only group inherited roles

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  /auth/domains incorrectly includes domains with only group inherited
  roles

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The /auth/domains API call is meant to return list of domains for
  which the user could ask for a domain-scoped token - i.e. any domain
  on which they have a role.  However, the code does not differentiate
  between inherited and non-inherited group roles - and hence might
  include domains for which the user has no effective role (a domain
  inherited role ONLY applies to the projects within that domain, not to
  the domain itself).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1385643/+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 1177623] Re: keystone reports internal error when policy.json is broken

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  keystone reports internal error when policy.json is broken

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  if policy.json is broken, when using keystone apis, will return HTTP
  500 (internal error).

  For better user experience, we need to provide:
  1). a better response for use to explain what had happend
  and
  2). a default policy list to use in case the policy.json is broken.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1177623/+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 1241134] Re: Using LDAP with enabled ignored, no error when attempt to change

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
Milestone: None => kilo-1

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

Title:
  Using LDAP with enabled ignored, no error when attempt to change

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  
  When the Keystone server is configured to use LDAP as the identity backend 
and 'enabled' is in user_attribute_ignore and then the user is disabled (for 
example with keystone user-update --enabled false), the server returns 
successful and the command doesn't report an error even though the user remains 
enabled.

  The server should report an error like 403 Forbidden or 501 Not
  Implemented if the user tries to change the enabled attribute and it's
  ignored.

  This would improve security since the way it is now Keystone gives the
  impression that the user has been disabled even when they have not
  been.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1241134/+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 1384775] Re: revoke driver default should be the non-deprecated driver

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  revoke driver default should be the non-deprecated driver

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The revoke driver default in the sample config and in config.py is
  still using the deprecated driver, causing deprecation warnings and
  scary messages about removal to show up in log files.

  2014-10-23 14:52:20.787 1236 WARNING
  keystone.openstack.common.versionutils [-] Deprecated:
  keystone.contrib.revoke.backends.kvs is deprecated as of Juno in favor
  of keystone.contrib.revoke.backends.sql and may be removed in Kilo.

  class Revoke(revoke.Driver):

  @versionutils.deprecated(
  versionutils.deprecated.JUNO,
  in_favor_of='keystone.contrib.revoke.backends.sql',
  remove_in=+1,
  what='keystone.contrib.revoke.backends.kvs')

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384775/+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 1330132] Re: Creation of Member role is no longer required

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Creation of Member role is no longer required

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in Tempest:
  Confirmed

Bug description:
  Since Grizzly the Keystone service's SQL creation/migration scripts
  automatically create a role named _member_ for use as the default
  member role. Since Icehouse (backported to Havana) Horizon uses this
  as the default member role.

  Devstack still creates a Member role, as was previously required:

  318 # The Member role is used by Horizon and Swift so we need to keep it:
  319 MEMBER_ROLE=$(openstack role create \
  320 Member \
  321 | grep " id " | get_field 2)

  As noted above, Horizon no longer uses such a role in the default
  configuration and on investigation the Swift dependency appears to be
  introduced by the way devstack configures Swift.

  As such it should now be possible to stop creating this role (with
  corresponding changes to the Swift setup in devstack) and use _member_
  instead, avoiding the creation (and confusion) of having two member
  roles with different names.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1330132/+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 1308778] Re: keystone-manage ssl_setup does not overwrite existing files

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  keystone-manage ssl_setup does not overwrite existing files

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  If you run "keystone-manage ssl_setup" more than once, it does not
  overwrite existing files under /etc/keystone/ssl, and does not print
  or log an error message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1308778/+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 1390085] Re: if REMOTE_USER is returned from apache plugin, it shouldn't need to be mapped

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  if REMOTE_USER is returned from apache plugin, it shouldn't need to be
  mapped

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  With mod_auth_openidc (and many other apache plugins) the authN'ed
  user name is set in the REMOTE_USER field of the environment. The
  current code somewhat accounts for this, but the value is in the end,
  ignored.  The user still needs to have a map that sets the user name.

  
  For instance, the following mapping:

  [
{
  "local": [
  {
  "user": {
  "name": "{0}"
  }
  }
  ],
  "remote": [
  {
  "type": "HTTP_OIDC_EMAIL"
  }
  ]
  },
  {
  "local": [
  {
  "group": {
  "id": "238c44612bcb411f86503cd2f91fd5db"
  }
  }
  ],
  "remote": [
  {
  "type": "HTTP_OIDC_ISS",
  "any_one_of": [
  "accounts.google.com"
  ]
  }
  ]
  }
  ]

  
  should be reduced to just, since the username is set in the REMOTE_USER field.

  [
{
  {
  "local": [
  {
  "group": {
  "id": "238c44612bcb411f86503cd2f91fd5db"
  }
  }
  ],
  "remote": [
  {
  "type": "HTTP_OIDC_ISS",
  "any_one_of": [
  "accounts.google.com"
  ]
  }
  ]
  }
  ]

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1390085/+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 1381809] Re: Domain aware policy should restrict certain operations to cloud admin

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Domain aware policy should restrict certain operations to cloud admin

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The domain aware policy that is provided as a part of keystone
  (policy.v3cloudsample.json) attempts to define a few layers of
  administrative roles:

cloud admin - responsible for overall cloud management
domain admin - responsible for management within a domain
project admin/owner - responsible for management of a project

  There are some APIs that should be restricted to the cloud admin, but
  they are currently allowed to any user with the "admin" role that is
  defined at any scope, such as the administrator of a project.  Some
  examples are the region and federation APIs:

  -
  "identity:get_region": "",
  "identity:list_regions": "",
  "identity:create_region": "rule:admin_or_cloud_admin",
  "identity:update_region": "rule:admin_or_cloud_admin",
  "identity:delete_region": "rule:admin_or_cloud_admin",

  
  "identity:create_identity_provider": "rule:admin_required",
  "identity:list_identity_providers": "rule:admin_required",
  "identity:get_identity_providers": "rule:admin_required",
  "identity:update_identity_provider": "rule:admin_required",
  "identity:delete_identity_provider": "rule:admin_required",

  "identity:create_protocol": "rule:admin_required",
  "identity:update_protocol": "rule:admin_required",
  "identity:get_protocol": "rule:admin_required",
  "identity:list_protocols": "rule:admin_required",
  "identity:delete_protocol": "rule:admin_required",

  "identity:create_mapping": "rule:admin_required",
  "identity:get_mapping": "rule:admin_required",
  "identity:list_mappings": "rule:admin_required",
  "identity:delete_mapping": "rule:admin_required",
  "identity:update_mapping": "rule:admin_required",
  ---

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1381809/+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 1384382] Re: GET /OS-FEDERATION/saml2/metadata does not work

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
Milestone: None => kilo-1

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

Title:
  GET /OS-FEDERATION/saml2/metadata does not work

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In Kestone-to-Keystone federation, the metadata from Keystone Identity
  Provider needs to be exchanged with the Keystone Service Provider.
  This is done via the GET /OS-FEDERATION/saml2/metadata endpoint, which
  is returning an internal server error (500).

  Looking in the log files, seems that keystone.middleware.core is
  trying to parse the XML body into JSON, which fails:

  2014-10-22 18:15:32.177590 20576 DEBUG keystone.common.wsgi [-] arg_dict: {} 
__call__ /opt/stack/keystone/keystone/common/wsgi.py:191
  2014-10-22 18:15:32.184124 20576 ERROR keystone.middleware.core [-] 
Serializer failed
  2014-10-22 18:15:32.184148 20576 TRACE keystone.middleware.core Traceback 
(most recent call last):
  2014-10-22 18:15:32.184155 20576 TRACE keystone.middleware.core   File 
"/opt/stack/keystone/keystone/middleware/core.py", line 183, in process_response
  2014-10-22 18:15:32.184168 20576 TRACE keystone.middleware.core body_obj 
= jsonutils.loads(response.body)
  2014-10-22 18:15:32.184185 20576 TRACE keystone.middleware.core   File 
"/usr/local/lib/python2.7/dist-packages/oslo/serialization/jsonutils.py", line 
211, in loads
  2014-10-22 18:15:32.184194 20576 TRACE keystone.middleware.core return 
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
  2014-10-22 18:15:32.184201 20576 TRACE keystone.middleware.core   File 
"/usr/lib/python2.7/json/__init__.py", line 338, in loads
  2014-10-22 18:15:32.184207 20576 TRACE keystone.middleware.core return 
_default_decoder.decode(s)
  2014-10-22 18:15:32.184213 20576 TRACE keystone.middleware.core   File 
"/usr/lib/python2.7/json/decoder.py", line 366, in decode
  2014-10-22 18:15:32.184220 20576 TRACE keystone.middleware.core obj, end 
= self.raw_decode(s, idx=_w(s, 0).end())
  2014-10-22 18:15:32.184226 20576 TRACE keystone.middleware.core   File 
"/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
  2014-10-22 18:15:32.184232 20576 TRACE keystone.middleware.core raise 
ValueError("No JSON object could be decoded")
  2014-10-22 18:15:32.184238 20576 TRACE keystone.middleware.core ValueError: 
No JSON object could be decoded
  2014-10-22 18:15:32.184244 20576 TRACE keystone.middleware.core
  2014-10-22 18:15:32.184740 20576 WARNING keystone.common.wsgi [-] 
  2014-10-22 18:15:32.184765 http://www.w3.org/2000/09/xmldsig#"; 
entityID="http://localhost:5000/v3/OS-FEDERATION/saml2/idp";>...rodrigodsrodrigodslocalhostrodrigodsRodrigoDuarterodrigodso...@gmail.com555-55-urn:oasis:names:tc:SAML:2.0:nameid-format:transienthttp://localhost:5000/v3/OS-FEDERATION/saml2/sso"; 
/>

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384382/+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 1400565] Re: ValueError when running Keystone tests

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
Milestone: None => kilo-1

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

Title:
  ValueError when running Keystone tests

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When running the Keystone tests against the latest master branch I get
  the following error:

  ${PYTHON:-python} -m subunit.run discover -t ./ ./keystone/tests  --load-list 
/tmp/user/1000/tmpAaHUxr
  No handlers could be found for logger "keystone.catalog.core"
  Traceback (most recent call last):
File 
"/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/eventlet/hubs/hub.py",
 line 455, in fire_timers
  timer()
File 
"/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/eventlet/hubs/timer.py",
 line 58, in __call__
  cb(*args, **kw)
File 
"/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/eventlet/greenthread.py",
 line 212, in main
  result = function(*args, **kwargs)
File "keystone/common/environment/eventlet_server.py", line 179, in _run
  debug=False)
File 
"/opt/stack/keystone/.tox/py27/local/lib/python2.7/site-packages/eventlet/wsgi.py",
 line 770, in server
  host, port = sock.getsockname()[:2]
  ValueError: need more than 0 values to unpack

  The tests do succeed but the value error is reported during the test
  run. Latest commit is:

  commit 6aaba42f0d3038aa3f26b5f308dd45fcfef2a65a
  Merge: 3a67102 c9acfb8
  Author: Jenkins 
  Date:   Mon Dec 8 23:46:03 2014 +

  Merge "Remove useless field passed into SQLAlchemy "distinct"
  statement"

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1400565/+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 1395688] Re: Memcache distributed lock ruins HA

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  Memcache distributed lock ruins HA

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Current memcache lock's polling interval calculation locks execution for too 
long.
  In concurrent environment when distributed locking is actively used the 
chance of 8 subsequent lock collisions is high enough to begin failing 
authorisation due to timeout.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1395688/+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 1390124] Re: No validation between client's IdP and Keystone IdP

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  No validation between client's IdP and Keystone IdP

Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  With today's configuration there is no strict link between  federated
  assertion issued by a trusted IdP and a IdP configured inside
  Keystone. Hence, user has ability to choose a mapping and possibly get
  unauthorized access.

  Proposed solution: setup a IdP identified included in an assertion
  issued by a IdP and validate whether that both values are equal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1390124/+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 1396763] Re: user id beginning with 0 cannot authenticate through ldap

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  user id beginning with 0 cannot authenticate through ldap

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone icehouse series:
  New
Status in Keystone juno series:
  New
Status in Keystone kilo series:
  Fix Released

Bug description:
  In the case where the [ldap] user_id_attribute = uid

  Lets say a user attempts to authenticate with steve...@example.com,
  and the UID returned is 01234567.

  The following log entries show that the leading 0 is dropped:

  keystone.common.ldap.core [-] LDAP search: base=o=example.com scope=2 
filterstr=(&(emailAddress=steve...@example.com)(objectClass=person)) 
attrs=['emailAddress', 'userPassword', 'enabled', 'uid'] attrsonly=0 search_s 
/opt/stack/keystone/keystone/common/ldap/core.py:926
  keystone.common.ldap.core [-] LDAP unbind unbind_s 
/opt/stack/keystone/keystone/common/ldap/core.py:899
  keystone.identity.core [-] ID Mapping - Domain ID: default, Default Driver: 
True, Domains: False, UUIDs: False, Compatible IDs: True 
_set_domain_id_and_mapping /opt/stack/keystone/keystone/identity/core.py:321
  keystone.identity.core [-] Local ID: 1234567 
_set_domain_id_and_mapping_for_single_ref 
/opt/stack/keystone/keystone/identity/core.py:339
  keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None 
tls_cacertdir=None tls_req_cert=2 tls_avail=1 _common_ldap_initialization 
/opt/stack/keystone/keystone/common/ldap/core.py:575

  ** here is where the leading 0 is dropped **

  keystone.common.ldap.core [-] LDAP search: base=o=example.com scope=2 
filterstr=(&(uid=1234567)(objectClass=person)) attrs=['emailAddress', 
'userPassword', 'enabled', 'uid'] attrsonly=0 search_s 
/opt/stack/keystone/keystone/common/ldap/core.py:926
  keystone.common.ldap.core [-] LDAP unbind unbind_s 
/opt/stack/keystone/keystone/common/ldap/core.py:899
  keystone.common.wsgi [-] Authorization failed. Invalid username or password 
(Disable debug mode to suppress these details.)

  The main code in question is the following in keystone.common.ldap.core.py
  
https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L110-L128

  try:
  return LDAP_VALUES[val]
  except KeyError:
  pass
  try:
  return int(val)
  except ValueError:
  pass
  return utf8_decode(val)

  Where we attempt to convert all fields to int, and if it fails proceed
  to string.

  On a semi-related note: the PyCADF library explicitly expects user_ids
  to be strings, so I had to add str() to user_id in the
  _get_request_audit_info function, in notifications.py:

    initiator = resource.Resource(typeURI=taxonomy.ACCOUNT_USER, name=user_id, 
host=host)
  to
    initiator = resource.Resource(typeURI=taxonomy.ACCOUNT_USER, 
name=str(user_id), host=host)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1396763/+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 1399857] Re: delete endpoint policy returns HTTP 500

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  delete endpoint policy returns HTTP 500

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  When activating the endpoint_policy extension, and then deleting a
  policy file, get the following error:

  keystoneclient.openstack.common.apiclient.exceptions.InternalServerError:
  An unexpected error prevented the server from fulfilling your request:
  'EndpointPolicy' object has no attribute 'delete_association_by_polcy'
  (Disable debug mode to suppress these details.) (HTTP 500)

  
  There is a typo in the controller that can be fixed by this change.

  diff --git a/keystone/contrib/endpoint_policy/controllers.py 
b/keystone/contrib/endpoint_policy/controllers.py
  index c1533f7..569fe9b 100644
  --- a/keystone/contrib/endpoint_policy/controllers.py
  +++ b/keystone/contrib/endpoint_policy/controllers.py
  @@ -46,7 +46,7 @@ class EndpointPolicyV3Controller(controller.V3Controller):
   payload['resource_info'])
   
   def _on_policy_delete(self, service, resource_type, operation, payload):
  -self.endpoint_policy_api.delete_association_by_polcy(
  +self.endpoint_policy_api.delete_association_by_policy(
   payload['resource_info'])

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1399857/+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 1398470] Re: sql migration helpers incorrectly inspect for FKs

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  sql migration helpers incorrectly inspect for FKs

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Our sql migration tests utilise the migration_helpers to execute such
  things as adding and removing constraints. In the case of ForeignKeys,
  the remove helper uses a method  like this:

  def get_constraints_names(table, column_name):
  fkeys = [fk.name for fk in table.constraints
   if (column_name in fk.columns and
isinstance(fk, sqlalchemy.ForeignKeyConstraint)]
  return keys

  The test for column name in fk_colums is unsafe as written, since
  there are more than just ForeignKeyContraints in table.constraints
  (and they don't all have a columns attribute). The check should first
  ensure the item we are looking at IS a ForeignKey, and then check the
  column.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1398470/+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 1390640] Re: /auth/domains incorrectly includes domains with only user inherited roles

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  /auth/domains incorrectly includes domains with only user inherited
  roles

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  The /auth/domains API call is meant to return list of domains for
  which the user could ask for a domain-scoped token - i.e. any domain
  on which they have a role. However, the code manager/driver method it
  calls (list_domain_for_user) does not differentiate between inherited
  and non-inherited user roles - and hence might include domains for
  which the user has no effective role (a domain inherited role ONLY
  applies to the projects within that domain, not to the domain itself).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1390640/+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 1400362] Re: check and delete policy_association_for_region_and_service performs create

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  check and delete  policy_association_for_region_and_service  performs
  create

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_policy/controllers.py#n133

  
  .create_policy_association  should be check_policy_association

  
   @controller.protected()
  def check_policy_association_for_region_and_service(
  self, context, policy_id, service_id, region_id):
  """Check an association between a policy and region+service."""
  self.policy_api.get_policy(policy_id)
  self.catalog_api.get_service(service_id)
  self.catalog_api.get_region(region_id)
  self.endpoint_policy_api.create_policy_association(
  policy_id, service_id=service_id, region_id=region_id)

  
  create_policy_association(  should be delete_policy_association(

  @controller.protected()
  def delete_policy_association_for_region_and_service(
  self, context, policy_id, service_id, region_id):
  """Delete an association between a policy and region+service."""
  self.policy_api.get_policy(policy_id)
  self.catalog_api.get_service(service_id)
  self.catalog_api.get_region(region_id)
  self.endpoint_policy_api.create_policy_association(
  policy_id, service_id=service_id, region_id=region_id)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1400362/+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 1401721] Re: Update role using LDAP backend with same name fails

[Thierry Carrez]

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
Milestone: None => kilo-1

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

Title:
  Update role using LDAP backend with same name fails

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  
  When the keystone server is configured to use the LDAP backend for 
assignments and a role is updated to have the same name the operation fails 
saying that you can't create a role because another role with the same name 
already exists.

  The keystone server should just accept the request and ignore the
  change rather than failing.

  To recreate:

  0. Start with a devstack install using LDAP for assignment backend

  1. Get a token

  $ curl -i \
-H "Content-Type: application/json" \
-d '
  { "auth": {
  "identity": {
"methods": ["password"],
"password": {
  "user": {
"name": "admin",
"domain": { "id": "default" },
"password": "adminpwd"
  }
}
  },
  "scope": {
"project": {
  "name": "demo",
  "domain": { "id": "default" }
}
  }
}
  }' \
http://localhost:35357/v3/auth/tokens ; echo

  $ TOKEN=...

  2. List roles

  $ curl \
  -H "X-Auth-Token: $TOKEN" \
  http://localhost:35357/v3/roles | python -m json.tool

  $ ROLE_ID=36a9eede308d41e8a92effce2e46cc4a

  3. Update a role with the same name.

  $ curl -X PATCH \
  -H "X-Auth-Token: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": {"name": "anotherrole"}}' \
  http://localhost:35357/v3/roles/$ROLE_ID

  {"error": {"message": "Cannot duplicate name {'id':
  u'36a9eede308d41e8a92effce2e46cc4a', 'name': u'anotherrole'}", "code":
  409, "title": "Conflict"}}

  The operation should have worked.

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