[Yahoo-eng-team] [Bug 1910419] Re: Sphinx 3.4.2 breaks documentation builds with Flask

2022-02-22 Thread Gage Hugo
This appears to have been fixed in upstream Sphinx.

** Changed in: keystone
   Status: New => Won't Fix

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

Title:
  Sphinx 3.4.2 breaks documentation builds with Flask

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  We recently updated openstack/requirements upper constraints for
  Sphinx to 3.4.2 [0]. Sphinx 3.4.2 breaks keystone master development
  (Wallaby) git sha b0b93c03986f3bb40c5a2ec31ee37c83014e197a with the
  following trace:

  building [mo]: targets for 0 po files that are out of date

  
  building [html]: targets for 102 source files that are out of date

  
  updating environment: [new config] 705 added, 0 changed, 0 removed

  
  reading sources... [  0%] admin/auth-totp 

  
  reading sources... [  0%] admin/authentication-mechanisms 

  
  reading sources... [  0%] admin/bootstrap 

  
  reading sources... [  0%] admin/case-insensitive  

  
  reading sources... [  0%] admin/cli-manage-projects-users-and-roles   

  
  reading sources... [  0%] admin/configuration 

  
  reading sources... [  0%] admin/configure_tokenless_x509  

  
  reading sources... [  1%] admin/credential-encryption 

  
  reading sources... [  1%] admin/event_notifications   

  
  reading sources... [  1%] admin/external-authentication   

  
  reading sources... [  1%] admin/federation/configure_federation   

  
  reading sources... [  1%] admin/federation/federated_identity 

  
  reading sources... [  1%] admin/federation/introduction   

  
  reading sources... [  1%] admin/federation/mapping_combinations   

  
  reading sources... [  2%] admin/fernet-token-faq  

  
  reading sources... [  2%] admin/getting-started   

  
  reading sources... [  2%] admin/health-check-middleware   

  
  reading sources... [  2%] admin/identity-concepts 

  
  reading sources... [  2%] admin/identity-sources  

  
  reading sources... [  2%] admin/index 

  
  reading sources... [  2%] admin/jws-key-rotation  
 

[Yahoo-eng-team] [Bug 1877393] Re: train release notes link to explicit_domain_id spec wrong

2021-12-07 Thread Gage Hugo
** Changed in: keystone
   Status: In Progress => Fix Released

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

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

Title:
  train release notes link to explicit_domain_id spec wrong

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Hi,

  the release note belonging to
  https://bugs.launchpad.net/keystone/+bug/1794527 got a not (any more?)
  working link.

  The spec is visible under train, not stein:
  
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/explicit-domains-ids.html

  BR,
  Maurice

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1877393/+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 1901207] Re: Application credentials of other users can be deleted when knowing the ID

2021-12-07 Thread Gage Hugo
** Changed in: keystone
   Status: In Progress => Fix Released

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

Title:
  Application credentials of other users can be deleted when knowing the
  ID

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Intro
  -
  While performing a penetration test on a new OpenStack install of version 
Train, we found a vulnerability that could lead to a Denial of Service 
condition. Using an installation of DevStack we verified that the issue is 
still present.

  Description
  ---
  In the test situation we had two, separate, projects, each with their own 
user. Users were only authorised for their own project, not for the other's 
project.

  After creating an application credential for user A, we were able to
  delete that credential with user B by issuing the OpenStack
  application credential delete command with the credential ID as
  parameter.

  Apparently, there is no authorisation check on the delete (and show)
  action and anyone who knows the credential ID can remove it,
  potentially creating a Denial of Service attack on the affected
  project.

  Precondition
  
  - Logged in user (user B)
  - Knowing the ID of an application credential of another user (user A)

  Discovered on October 8, 2020 by Arjen Zijlstra (a...@warpnet.nl) and
  Arthur Donkers (art...@1secure.nl)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1901207/+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 1936425] Re: Install and configure in keystone: problem when bootstraping the identity service

2021-07-15 Thread Gage Hugo
** Changed in: keystone
   Status: New => Invalid

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

Title:
  Install and configure in keystone: problem when bootstraping the
  identity service

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When bootstraping the identity service, I am getting the following
  error:

  keystone-manage bootstrap --bootstrap-password 'ADMIN_PASS' \
--bootstrap-admin-url http://controller:5000/v3/ \
--bootstrap-internal-url http://controller:5000/v3/ \
--bootstrap-public-url http://controller:5000/v3/ \
--bootstrap-region-id RegionOne

  Config file not found, using default configs.
  /etc/keystone/fernet-keys/ does not exist

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: problem when bootstrapping the 
identity service (config file not found)
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - The mailing list: https://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 19.0.1.dev1 on 2019-09-18 18:54:05
  SHA: f510c806de3e20cdedd55291cd58dafa59398bec
  Source: 
https://opendev.org/openstack/keystone/src/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/wallaby/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1936425/+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 1901902] Re: Authtoken not used when changing password through CLI

2020-10-28 Thread Gage Hugo
This is by design. The change user password API does not require a
token, mostly due to a user requiring an administrator to reset their
password if it expires since they cannot authenticate for a token.

If an attacker gets a username and password, having a token required to
change a password won't really provide any additional security here,
they can already login/authenticate as that user.

That pci-dss bug has a change in flight to no longer expose the
accountlocked exception to users, which should prevent the username
oracle issue.

** Information type changed from Private Security to Public

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

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

Title:
  Authtoken not used when changing password through CLI

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  There is no valid X-Auth-Token needed when changing the password of a
  user. The authentication only depends on ID and original password:

  POST /identity/v3/users//password HTTP/1.1
  Host: xxx.xxx.xxx.xxx
  User-Agent: python-keystoneclient
  Content-Length: 76

  {"user": {"password": "Password1234!", "original_password":
  "Password123!"}}

  The CLI adds an X-Auth-Token, but when removing it, for example using
  a proxy, the request is successfully processed. Even though this
  doesn't pose any direct risk (since the ID and original password still
  have to be known by the attacker), this unnecessarily increases the
  attack surface and doesn't feel like an intended situation.

  Combined with some of the issues reported in:
  https://bugs.launchpad.net/keystone/+bug/1688137 the risk of this
  issue increases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1901902/+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 1866614] Re: CSV Injection in instance edit form in the name field

2020-10-26 Thread Gage Hugo
*** This bug is a duplicate of bug 1842749 ***
https://bugs.launchpad.net/bugs/1842749

Since there hasn't been an update to Jeremy's question, we are going to
mark this as a duplicate of bug 1842749 since this appears to be the
same issue.

** This bug has been marked a duplicate of bug 1842749
   CSV Injection Possible in Compute Usage History

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

Title:
  CSV Injection in instance edit form in the name field

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  This is arguably more a problem with Excel or Libre Office or other
  software that indiscriminately executes code in a document it is
  opening, but since we can fix it easily on our side, I think it would
  make sense to do so.

  The gist of it is that it's possible to name an instance in such a
  way, that it results in a spreadsheet formula that will be executed
  when the exported CSV file with the list of instances is imported in a
  spreadsheet program. In case of Microsoft Excel that formula could
  potentially do anything, which is a Bad Thing™, but I don't think they
  will fix it ever, so it's on us to escape such data, so that it won't
  be interpreted as formulas.

  This escaping is apparently done by appending a single apostrophe to
  the field's data whenever that data begins with +, -, = or @
  characters. I'm attaching a patch that I think should do it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1866614/+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 1895723] Re: Keystone is restarting due to stale primary key

2020-09-15 Thread Gage Hugo
** Also affects: kolla-ansible
   Importance: Undecided
   Status: New

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

Title:
  Keystone is restarting due to stale primary key

Status in OpenStack Identity (keystone):
  New
Status in kolla-ansible:
  New

Bug description:
  After restart of keystone's container, it keeps restarting. I found only this 
error in docker logs keystone:
  Running command: '/usr/bin/keystone-startup.sh -DFOREGROUND'
  + exec /usr/bin/keystone-startup.sh -DFOREGROUND
  + set -o errexit
  + set -o pipefail
  + TOKEN_DIR=/etc/keystone/fernet-keys
  + n=0
  + '[' '!' -f /etc/keystone/fernet-keys/0 ']'
  ++ ls -1 /etc/keystone/fernet-keys
  ++ sort -hr
  ++ head -n 1
  + TOKEN_PRIMARY=5
  ++ date +%s
  ++ date +%s -r /etc/keystone/fernet-keys/5
  + TOKEN_AGE=589164
  + '[' 589164 -gt 86400 ']'
  + echo 'ERROR: Primary token 5 is stale.'
  + exit 1

  Workaround is change expiration from 86400 to 864000 in
  /etc/kolla/keystone/keystone-startup.sh:

  # Compare if it's older than fernet_token_expiry and run key rotation if 
needed
  if [ "${TOKEN_AGE}" -gt "864000" ]; then
  echo "ERROR: Primary token ${TOKEN_PRIMARY} is stale."
  exit 1
  fi

  Regarding the comment in code, It should also run rotation of primary
  key. But this part is missing, it only throws an exception as
  mentioned. Or I would like to ask, why the primary key wasn't rotated
  automatically when it was needed.

  I am using 2 weeks old deployment of Ussuri, deployd by kolla-ansible
  on CentOS8.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1895723/+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 1883659] Re: keystonemiddleware connections to memcached from neutron-server grow beyond configured values

2020-06-16 Thread Gage Hugo
Added oslo.cache, not 100% sure which is affected yet.

** Also affects: oslo.cache
   Importance: Undecided
   Status: New

** No longer affects: keystone

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

Title:
  keystonemiddleware connections to memcached from neutron-server grow
  beyond configured values

Status in keystonemiddleware:
  New
Status in oslo.cache:
  New

Bug description:
  Using: keystone-17.0.0, Ussuri
   
  I've noticed a very odd behaviour of keystone_authtoken with memcached and 
neutron-server. The connection count to memcached grows over time, ignoring the 
settings of memcache_pool_maxsize and memcache_pool_unused_timeout. The 
keystone_authtoken middleware configuration is as follows:

  [keystone_authtoken]
  www_authenticate_uri = http://keystone_vip:5000
  auth_url = http://keystone_vip:35357
  auth_type = password
  project_domain_id = default
  user_domain_id = default
  project_name = service
  username = neutron
  password = neutron_password_here
  cafile =
  memcache_security_strategy = ENCRYPT
  memcache_secret_key = secret_key_here
  memcached_servers = 
memcached_server_1:11211,memcached_server_2:11211,memcached_server_3:11211
  memcache_pool_maxsize = 100
  memcache_pool_unused_timeout = 600
  token_cache_time = 3600

  Commenting out memcached settings under [keystone_authtoken] and
  restarting neutron-server drops the connection count in memcached to
  normal levels, i.e. hundreds, rather than thousands when neutron-
  server is using memcached. Neutron team (slaweq) suggested this is a
  Keystone issue because quote: "Neutron is just using
  keystonemiddleware as one of the middlewares in the pipeline".

  Grafana memcached connection graphs: https://ibb.co/p3TCJqC AND
  https://ibb.co/nmmvvH4

  The drops in the graphs indicate the restart of the neutron-server, so
  not sure if this is something to be expected, or there is an issue
  with the configuration, or it's a bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1883659/+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 1883659] Re: keystonemiddleware connections to memcached from neutron-server grow beyond configured values

2020-06-16 Thread Gage Hugo
Added keystonemiddleware

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

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

Title:
  keystonemiddleware connections to memcached from neutron-server grow
  beyond configured values

Status in keystonemiddleware:
  New
Status in oslo.cache:
  New

Bug description:
  Using: keystone-17.0.0, Ussuri
   
  I've noticed a very odd behaviour of keystone_authtoken with memcached and 
neutron-server. The connection count to memcached grows over time, ignoring the 
settings of memcache_pool_maxsize and memcache_pool_unused_timeout. The 
keystone_authtoken middleware configuration is as follows:

  [keystone_authtoken]
  www_authenticate_uri = http://keystone_vip:5000
  auth_url = http://keystone_vip:35357
  auth_type = password
  project_domain_id = default
  user_domain_id = default
  project_name = service
  username = neutron
  password = neutron_password_here
  cafile =
  memcache_security_strategy = ENCRYPT
  memcache_secret_key = secret_key_here
  memcached_servers = 
memcached_server_1:11211,memcached_server_2:11211,memcached_server_3:11211
  memcache_pool_maxsize = 100
  memcache_pool_unused_timeout = 600
  token_cache_time = 3600

  Commenting out memcached settings under [keystone_authtoken] and
  restarting neutron-server drops the connection count in memcached to
  normal levels, i.e. hundreds, rather than thousands when neutron-
  server is using memcached. Neutron team (slaweq) suggested this is a
  Keystone issue because quote: "Neutron is just using
  keystonemiddleware as one of the middlewares in the pipeline".

  Grafana memcached connection graphs: https://ibb.co/p3TCJqC AND
  https://ibb.co/nmmvvH4

  The drops in the graphs indicate the restart of the neutron-server, so
  not sure if this is something to be expected, or there is an issue
  with the configuration, or it's a bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1883659/+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 1855080] Re: Credentials API allows listing and retrieving of all users credentials

2020-01-02 Thread Gage Hugo
OSSA Report: https://review.opendev.org/#/c/698045/

** Changed in: ossa
   Status: Confirmed => Fix Released

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

Title:
  Credentials API allows listing and retrieving of all users credentials

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Fix Released
Status in keystone package in Ubuntu:
  New

Bug description:
  Tested against Stein and Train.

  # User creating a credential, i.e totp or similar
  $ OS_CLOUD=1 openstack token issue
  | project_id | c3caf1b55bb84b78a795fd81838e5160
  | user_id| 9971b0f13d2d4a578212d028a53c3209
  $ OS_CLOUD=1 openstack credential create --type test 
9971b0f13d2d4a578212d028a53c3209 test-data
  $ OS_CLOUD=1 openstack credential list
  
+--+--+--+---++
  | ID   | Type | User ID  
| Data  | Project ID |
  
+--+--+--+---++
  | 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 
| test-data | None   |
  
+--+--+--+---++

  # Different User but same Project
  $ OS_CLOUD=2 openstack token issue
  | project_id | c3caf1b55bb84b78a795fd81838e5160
  | user_id| 6b28a0b073fc4ac7843f33190ebc5c3c
  $ OS_CLOUD=2 openstack credential list
  
+--+--+--+---++
  | ID   | Type | User ID  
| Data  | Project ID |
  
+--+--+--+---++
  | 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 
| test-data | None   |
  
+--+--+--+---++

  # Different User and Different Project
  $ OS_CLOUD=3 openstack token issue
  | project_id | d43f20ae5a7e4f36b701710277384401
  | user_id| 2e48f1a7d1474391a826a2b9700e5949
  $ OS_CLOUD=3 openstack credential list
  
+--+--+--+---++
  | ID   | Type | User ID  
| Data  | Project ID |
  
+--+--+--+---++
  | 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 
| test-data | None   |
  
+--+--+--+---++

  As shown anyone who's authenticated can retrieve any credentials
  including their 'secret'.

  This is a rather severe information disclosure vulnerability and
  completely defies the purpose of TOTP or MFA as these credentials are
  not kept secure or private whatsoever.

  If Auth-rules are configured allow login with only 'topt' it would be
  extremely easy to assume a different user's identity.

  A CVE should be issued for this. I can take care of that paperwork.

  Versions affected and tested:

  Train/ubuntu:
  $ dpkg -l | grep keystone
  ii  keystone 2:16.0.0-0ubuntu1~cloud0 
   all  OpenStack identity service - Daemons
  ii  keystone-common  2:16.0.0-0ubuntu1~cloud0 
   all  OpenStack identity service - Common files
  ii  python-keystoneauth1 3.13.1-0ubuntu1~cloud0   
   all  authentication library for OpenStack 
Identity - Python 2.7
  ii  python-keystoneclient1:3.19.0-0ubuntu1~cloud0 
   all  client library for the OpenStack Keystone 
API - Python 2.x
  ii  python-keystonemiddleware6.0.0-0ubuntu1~cloud0
   all  Middleware for OpenStack Identity 
(Keystone) - Python 2.x
  ii  python3-keystone 2:16.0.0-0ubuntu1~cloud0 
   all  OpenStack identity service - Python 3 
library
  ii  python3-keystoneauth13.17.1-0ubuntu1~cloud0   
   all  authentication library for OpenStack 
Identity - Python 3.x
  ii  python3-keystoneclient   1:3.21.0-0ubuntu1~cloud0 
   all  client library for the OpenStack Keystone 
API - Python 3.x
  ii  python3-keystonemiddleware   7.0.1-0ubuntu1~cloud0
   all  

[Yahoo-eng-team] [Bug 1856904] [NEW] CADF Notifications are missing user name in initiator object

2019-12-18 Thread Gage Hugo
Public bug reported:

When enabling CADF notifications, each event notification contains an
initiator object, this object contains an id, typeuri, project_id, etc.
This notification is useful for auditors to determine who has
authenticated and/or what action a user has performed.

The various examples in the OpenStack CADF standard[0] show a user name
as part of the initiator, however most notifications only contain the
user_id. For deployments that contain non-local users, this only
provides a UUID as the user_id, and it is not immediately clear which
user performed an action. Additional work has to be done, either
manually or via an alerting process to query each user_id against
keystone to determine which user performed what action.

To better conform to the standard[0], keystone should be including
usernames as part of the initiator object.

[0]
https://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.1.0.pdf#page=12

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: notifications

** Summary changed:

- CADF Notifications are missing user name in initiator
+ CADF Notifications are missing user name in initiator object

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

Title:
  CADF Notifications are missing user name in initiator object

Status in OpenStack Identity (keystone):
  New

Bug description:
  When enabling CADF notifications, each event notification contains an
  initiator object, this object contains an id, typeuri, project_id,
  etc. This notification is useful for auditors to determine who has
  authenticated and/or what action a user has performed.

  The various examples in the OpenStack CADF standard[0] show a user
  name as part of the initiator, however most notifications only contain
  the user_id. For deployments that contain non-local users, this only
  provides a UUID as the user_id, and it is not immediately clear which
  user performed an action. Additional work has to be done, either
  manually or via an alerting process to query each user_id against
  keystone to determine which user performed what action.

  To better conform to the standard[0], keystone should be including
  usernames as part of the initiator object.

  [0]
  
https://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.1.0.pdf#page=12

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1856904/+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 1840288] Re: Trusts GET API leaks existence information to unauthorized users

2019-08-15 Thread Gage Hugo
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.

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

** Changed in: ossa
   Status: New => Incomplete

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

Title:
  Trusts GET API leaks existence information to unauthorized users

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id}
  API leaks information about the existence of a trust to unauthorized
  users.

  If an authenticated user requests a trust that either does not exist
  or has no remaining uses, the returned response is a 404 regardless of
  whether the user is an admin or a trustor/trustee of the hypothetical
  (e.g. soft-deleted or used-up) trust. If the trust does exist but the
  user has no access to it, the returned response is a 403. If an
  attacker had some reasonable way of guessing or brute-forcing the UUID
  of a trust, they could use this leak to confirm its existence. A valid
  trust ID can then be used as part of a token request in combination
  with the trustee's credentials.

  The issue is here:

  
https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150

  The current "identity:get_trust" default policy rule is "" which is
  all-permissive, and authorization is hardcoded in the trust controller
  code. To enforce the "only the trustor or trustee can GET this" rule,
  it does a lookup of the trust and doesn't catch a NotFound, thereby
  leaking it directly back to the requester.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1840288/+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 1781536] Re: Wrong port number in Queens install guide

2018-11-27 Thread Gage Hugo
Fixed here:

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

** Changed in: keystone
 Assignee: (unassigned) => Gage Hugo (gagehugo)

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

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1781536

Title:
  Wrong port number in Queens install guide

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  I noticed that on page
  https://docs.openstack.org/keystone/queens/install/keystone-install-
  rdo.html#install-and-configure-components, which is for installing and
  configuring keystone, under Finalize the installation section, step 2,
  this value export OS_AUTH_URL=http://controller:35357/v3 seems wrong.
  Here port number should be 5000 as now keystone runs on same port for
  all interfaces

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [x] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [X] I have a fix to the document that I can paste below including example: 
input and output. 

  Input - export OS_AUTH_URL=http://controller:35357/v3
  Output - export OS_AUTH_URL=http://controller:5000/v3

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 13.0.1.dev9 on 2018-05-08 06:44
  SHA: 4ca0172fcdb1ce28a1f00d5a0e1bb3d646141803
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-rdo.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1781536/+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 1796077] Re: policy.json doesn't allow user to change password

2018-10-04 Thread Gage Hugo
Users have their own self-service API[0] they can call to change their
own password.  This is separate from the update_user one, and is
currently not covered by any policy.  There are ways to enforce security
regulations (PCI-DSS) on users, which is more defined here[1].

[0] 
https://developer.openstack.org/api-ref/identity/v3/#change-password-for-user
[1] 
https://docs.openstack.org/keystone/pike/admin/identity-security-compliance.html

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

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

Title:
  policy.json doesn't allow user to change password

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Currently in Keystone the default policy.v3cloudsample.json doesn't
  allow user to change its password.

  It's defined in:
  "identity:update_user": "rule:cloud_admin or 
rule:admin_and_matching_target_user_domain_id"
  which make user (which is owner in policy.json) unable to change it own 
password.

  Not sure if this change is intended or not, but as a operator, I would
  like to allow users to change its password by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1796077/+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 1795415] Re: Verify operation in keystone

2018-10-01 Thread Gage Hugo
*** This bug is a duplicate of bug 1790148 ***
https://bugs.launchpad.net/bugs/1790148

** This bug has been marked a duplicate of bug 1790148
   Verify operation in keystone (Documentation fault)

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

Title:
  Verify operation in keystone

Status in OpenStack Identity (keystone):
  New

Bug description:
  - [X] This doc is inaccurate in this way:

  In point 2, it is suggested to run

openstack --os-auth-url http://controller:35357/v3 \
--os-project-domain-name Default --os-user-domain-name Default \
--os-project-name admin --os-username admin token issue

  However, the endpoint has been configured on port 5000 previously.
  This is a sort of garbage inherited from previous OpenStack versions where 
"keystone needed to be run on two separate ports to accomodate the Identity v2 
API which ran a separate admin-only service commonly on port 35357."

  - [X] I have a fix to the document that I can paste below including
  example:

  Replace the previous command with

openstack --os-auth-url http://controller:5000/v3 \
--os-project-domain-name Default --os-user-domain-name Default \
--os-project-name admin --os-username admin token issue

  Take care!
  Francesco

  ---
  Release:  on 2018-09-10 22:19
  SHA: c5930abc5aa06881f28baa697d8d43a1f25157b8
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-rdo.rst
  URL: 
https://docs.openstack.org/keystone/rocky/install/keystone-verify-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1795415/+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 1794112] Re: Install and configure in keystone connection mysql

2018-09-25 Thread Gage Hugo
Closing out then.

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

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

Title:
  Install and configure in keystone connection mysql

Status in OpenStack Identity (keystone):
  Invalid

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [ ] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [x] I have a fix to the document that I can paste below including example: 
input and output. 

  
  [database]
  # ...
  connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone

  should be :

  [database]
  # ...
  connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@localhost/keystone

  because mysql daemon listens on 127.0.0.1:3306

  With @controller, Identitiy service population silently fails.

  Thank you.

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 13.0.2.dev1 on 2018-09-10 23:21
  SHA: 7693b84c0692f9b9ec756c73df7456d87f54f0cb
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1794112/+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 1793816] Re: Verify operation in keystone

2018-09-21 Thread Gage Hugo
*** This bug is a duplicate of bug 1790148 ***
https://bugs.launchpad.net/bugs/1790148

** This bug has been marked a duplicate of bug 1790148
   Verify operation in keystone (Documentation fault)

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

Title:
  Verify operation in keystone

Status in OpenStack Identity (keystone):
  New

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: Reference URL containing port 
35357, instead of 5000
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release:  on 2018-09-10 22:19
  SHA: c5930abc5aa06881f28baa697d8d43a1f25157b8
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-rdo.rst
  URL: 
https://docs.openstack.org/keystone/rocky/install/keystone-verify-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1793816/+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 1780503] [NEW] identity.authenticate CADF initiator id is random

2018-07-06 Thread Gage Hugo
mestamp\": \"2018-07-06
22:56:45.534129\", \"publisher_id\": \"identity.keystone-api-
7d5c6cff4-g9dvd\", \"payload\": {\"typeURI\":
\"http://schemas.dmtf.org/cloud/audit/1.0/event\;, \"initiator\":
{\"typeURI\": \"service/security/account/user\", \"host\": {\"agent\":
\"osc-lib/1.10.0 keystoneauth1/3.7.0 python-requests/2.18.4
CPython/2.7.12\", \"address\": \"[redacted]\"}, \"id\":
\"129bfaf0-a8e3-579b-9030-0a5917547b46\"}, \"target\": {\"typeURI\":
\"service/security/account/user\", \"id\": \"f67acddd-78df-
58f1-be93-dcb196e44a9e\"}, \"observer\": {\"typeURI\":
\"service/security\", \"id\": \"9e53891b98b84bb898c0419e16426eca\"},
\"eventType\": \"activity\", \"eventTime\":
\"2018-07-06T22:56:45.533872+\", \"action\": \"authenticate\",
\"outcome\": \"success\", \"id\":
\"50468200-4b87-5a8a-b855-d25e8721ccea\"}, \"message_id\":
\"cd9fe069-c0f6-4d3e-af65-f288cbb90f41\"}", "oslo.version": "2.0"} |
1054  | string   | False   |

ubuntu@zbook:~$ python rabbitmqadmin --host=[redacted] --port=15672
--vhost="keystone" --username=superuser --password=123456 get
queue=notifications.info ackmode=ack_requeue_false | tail -n +4 | head
-n +1

| notifications.info | keystone | 0 | {"oslo.message":
"{\"priority\": \"INFO\", \"_unique_id\":
\"e13c4eb09440496cb80b2297a61c12b8\", \"event_type\":
\"identity.authenticate\", \"timestamp\": \"2018-07-06
22:56:45.572963\", \"publisher_id\": \"identity.keystone-api-
7d5c6cff4-g9dvd\", \"payload\": {\"typeURI\":
\"http://schemas.dmtf.org/cloud/audit/1.0/event\;, \"initiator\":
{\"typeURI\": \"service/security/account/user\", \"host\": {\"agent\":
\"osc-lib/1.10.0 keystoneauth1/3.7.0 python-requests/2.18.4
CPython/2.7.12\", \"address\": \"[redacted]\"}, \"id\":
\"38cee0b3-9b7f-5905-95f1-fa6cf61a637d\"}, \"target\": {\"typeURI\":
\"service/security/account/user\", \"id\":
\"3c9cdad0-a0f4-5151-ab44-da09add4be49\"}, \"observer\": {\"typeURI\":
\"service/security\", \"id\": \"9e53891b98b84bb898c0419e16426eca\"},
\"eventType\": \"activity\", \"eventTime\":
\"2018-07-06T22:56:45.572690+\", \"action\": \"authenticate\",
\"outcome\": \"success\", \"id\": \"1b0d8ade-f94a-517c-
a9f6-fb3df0a2c8c1\"}, \"message_id\": \"c8a55a89-908c-
49c0-a0b2-9002fccecb03\"}", "oslo.version": "2.0"} | 1054  |
string   | False   |


[0] 
https://github.com/openstack/keystone/blob/master/keystone/conf/default.py#L221

** Affects: keystone
 Importance: Undecided
 Assignee: Gage Hugo (gagehugo)
 Status: New

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

Title:
  identity.authenticate CADF initiator id is random

Status in OpenStack Identity (keystone):
  New

Bug description:
  When enabling CADF notifications and clearing the notification_opt_out
  setting[0] (which cause keystone to be more chatty with notifications)
  in order to audit identity.authenticate events, keystone (sometimes)
  emits a notification for the identity.authentication event where the
  initiator's ID is a random UUID that doesn't match up to a user.

  An example of this is shown below, where keystone only has one user
  (admin). The config values for enabling CADF notifications were set
  here:

  DEFAULT:
notification_format: cadf
notification_opt_out: ""
  oslo_messaging_notifications:
driver: messagingv2
   

  ubuntu@zbook:~$ openstack --os-cloud openstack_helm token issue
  
++-+
  | Field  | Value  

 |
  
++--

[Yahoo-eng-team] [Bug 1775295] Re: Queen keystone installation instructions outdated, keystone-managed credential_setup invalid choice

2018-06-06 Thread Gage Hugo
Seems like ubuntu 16.04 ships with Mitaka, and I think
"credential_setup" was added in Newton so that would explain why the
command is missing.

The docs seem to be correct though in terms of setting up the queens
repo.

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

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

Title:
  Queen keystone installation instructions outdated, keystone-managed
  credential_setup invalid choice

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  - [x] This doc is inaccurate in this way:
  This command
  "apt install keystone  apache2 libapache2-mod-wsgi"
  installs keystone with keystone-manage version 9.3.0 which doesn't support 
subsequent command:
  "keystone-manage credential_setup --keystone-user keystone --keystone-group 
keystone"

  I'm new to openstack so not sure whether this issue is unique to my 
environment.
  If this is an actual issue, how do i get around this. 

  P.s: I'm installing keystone on a clean installation of Ubuntu 16.04

  Thanks so much in advance!
  ---
  Release: 13.0.1.dev9 on 2018-05-08 06:44
  SHA: 4ca0172fcdb1ce28a1f00d5a0e1bb3d646141803
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1775295/+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 1761538] Re: Cookie hash value displayed in rabbitmq logs

2018-04-05 Thread Gage Hugo
This likely is more related to RabbitMQ (and as fungi pointed out,
should probably be noted in OSSN) if it has a security impact on
OpenStack as a whole, rather than specifically keystone.

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

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

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

Title:
  Cookie hash value displayed in rabbitmq logs

Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Security Notes:
  New

Bug description:
  ENabled rabbitmq debug and restarted the process. Found sensitive data
  displayed in logs.

  rabbitmq uses Erlang cookie concept where a cluster of nodes
  communicates to each other. Any node that posses this secret cookie
  can communicate with other nodes in the cluster.

  
  =INFO REPORT 31-Mar-2018::03:28:46 ===
  stopped SSL Listener on [::]:5671

  =INFO REPORT 31-Mar-2018::03:28:46 ===
  Stopped RabbitMQ application

  =INFO REPORT 31-Mar-2018::03:28:46 ===
  Halting Erlang VM

  =INFO REPORT 31-Mar-2018::03:29:54 ===
  Starting RabbitMQ 3.6.6 on Erlang 19.1.1
  Copyright (C) 2007-2016 Pivotal Software, Inc.
  Licensed under the MPL.  See http://www.rabbitmq.com/

  =INFO REPORT 31-Mar-2018::03:29:54 ===
  node   : rabbit@ip9-114-192-221
  home dir   : /var/lib/rabbitmq
  config file(s) : /etc/rabbitmq/rabbitmq.config
  cookie hash: RVLZk6qSkQ471Dqtfk14wA==
  log: /var/log/rabbitmq/rab...@ip9-114-192-221.log
  sasl log   : /var/log/rabbitmq/rab...@ip9-114-192-221-sasl.log
  database dir   : /var/lib/rabbitmq/mnesia/rabbit@ip9-114-192-221

  =INFO REPORT 31-Mar-2018::03:29:57 ===
  Memory limit set to 3876MB of 9690MB total.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1761538/+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 1756190] Re: Project tags is too restrictive

2018-03-20 Thread Gage Hugo
This may affect KSC as well, see [0].

[0]
https://review.openstack.org/#/c/553108/3/keystone/resource/backends/sql.py@182

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

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

Title:
  Project tags is too restrictive

Status in OpenStack Identity (keystone):
  In Progress
Status in python-keystoneclient:
  New

Bug description:
  Currently, when querying project tags it only matches projects that
  have exactly the parameters given and no additional parameters. This
  is out of alignment with both the project tags spec and nova.

  This is best explained by example:

  Consider two projects: p1 and p2
  p1 has tags [blue, green, red]
  p2 has tag [blue]

  tags=blue is only returning p1. It should return both p1 and p2.
  tags=blue,green is returning no projects. This should return p1.
  tags-any=blue is returning p1 and p2. This should continue to return both p1 
and p2.
  tags-any=blue,yellow is returning both p1 and p2. This should continue to 
return both.

  This also applies to not-tags and not-tags-any.

  not-tags=blue is returning p1 and it should not.
  not-tags=blue,green currently returning both p1 and p2. It should not return 
p1.
  not-tags-any=blue should continue to not return both p1 and p2.
  not-tags-any=blue,yellow should continue not to return either p1 or p2.

  In other words, tags is currently returning projects that have an
  exact set of it's parameters. It should return projects that have a
  superset of it's parameters -- or all the parameters and maybe some
  other stuff.

  tags should logically AND it's parameters
  tags-any should logically OR it's parameters

  This will bring us into alignment with the tags spec (although perhaps
  the tags spec could be updated to be clearer?) and also with Nova's
  server tags implementation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1756190/+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 1738372] Re: Install and configure in keystone

2018-03-16 Thread Gage Hugo
I was able to duplicate this, it seems like there may be an issue with
the heat devstack plugin, when running devstack (stable/ocata) it
originally checks out stable/ocata heat, but once it hits the devstack
plugin it will checkout master heat, and then hit:

2018-02-04 15:56:12.694 | from heat.policies import actions
2018-02-04 15:56:12.694 | File "/home/stack/heat/heat/policies/actions.py", 
line 20, in 
2018-02-04 15:56:12.694 | policy.DocumentedRuleDefault(
2018-02-04 15:56:12.694 | AttributeError: 'module' object has no attribute 
'DocumentedRuleDefault'

https://github.com/openstack/heat/blob/master/heat/policies/actions.py#L20

Looks like the policies modules were added after ocata:

https://github.com/openstack/heat/tree/stable/ocata/heat/policies/actions.py

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

** Changed in: keystone
   Status: Confirmed => Invalid

** Summary changed:

- Install and configure in keystone
+ ocata devstack checking out Heat master

** Summary changed:

- ocata devstack checking out Heat master
+ ocata heat devstack plugin checking out heat master

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

Title:
  ocata heat devstack plugin checking out heat master

Status in OpenStack Heat:
  New
Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When I run the following command:
  su -s /bin/sh -c "keystone-manage db_sync" keystone

  One exception raised:
  AttributeError: 'module' object has no attribute 'DocumentedRuleDefault'

  I don't know what is? But I have searched on the internet, and this
  may be caused by the python Env. I want to know the exactly version
  python packages and version. Thanks a lot.

  
  This bug tracker is for errors with the documentation, use the following as a 
template and remove or add fields as you see fit. Convert [ ] into [x] to check 
boxes:

  - [ ] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 12.0.1.dev6 on 2017-11-16 21:02
  SHA: d0721d7cf4dc808946a7016b0ca2830c8850d5d9
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/pike/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1738372/+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 1756140] [NEW] Project Tags Documentation Wrong - Create Tag

2018-03-15 Thread Gage Hugo
Public bug reported:

The API ref for Adding a single tag[0] to a project has the wrong
response parameters. Currently it states that the response will be an
array of tags when adding a single tag to a project. However this does
not match the current implementation in keystone as well as the API-WG
spec for tags[1].

Fix will be to remove the parameters from the response since it returns
no body and a 201.

[0] 
https://developer.openstack.org/api-ref/identity/v3/#add-single-tag-to-a-project
[1] 
https://specs.openstack.org/openstack/api-wg/guidelines/tags.html#addressing-individual-tags

** Affects: keystone
 Importance: Low
 Assignee: Gage Hugo (gagehugo)
 Status: In Progress

** Changed in: keystone
   Status: New => Triaged

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

Title:
  Project Tags Documentation Wrong - Create Tag

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  The API ref for Adding a single tag[0] to a project has the wrong
  response parameters. Currently it states that the response will be an
  array of tags when adding a single tag to a project. However this does
  not match the current implementation in keystone as well as the API-WG
  spec for tags[1].

  Fix will be to remove the parameters from the response since it
  returns no body and a 201.

  [0] 
https://developer.openstack.org/api-ref/identity/v3/#add-single-tag-to-a-project
  [1] 
https://specs.openstack.org/openstack/api-wg/guidelines/tags.html#addressing-individual-tags

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1756140/+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 1755511] Re: Install and configure in keystone

2018-03-13 Thread Gage Hugo
With Queens most of the v2 API was removed (minus ec2 related) and port
35357 is a leftover relic from v2 when the admin APIs relied on using
it, vs 5000 for public.  With V3 the separation of ports is not
necessary, admin is fine on 5000.

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

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

Title:
  Install and configure in keystone

Status in OpenStack Identity (keystone):
  Invalid

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  This Bug in on following Page:
  
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

  Step 5: Bootstrap the Identity Service:
Current content with BUG in port no for admin URL:
# keystone-manage bootstrap --bootstrap-password ADMIN_PASS \
--bootstrap-admin-url http://controller:5000/v3/ \
--bootstrap-internal-url http://controller:5000/v3/ \
--bootstrap-public-url http://controller:5000/v3/ \
--bootstrap-region-id RegionOne

Recommended Correction:
# keystone-manage bootstrap --bootstrap-password ADMIN_PASS \
--bootstrap-admin-url http://controller:35357/v3/ \
--bootstrap-internal-url http://controller:5000/v3/ \
--bootstrap-public-url http://controller:5000/v3/ \
--bootstrap-region-id RegionOne

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 13.0.1.dev2 on 2018-03-13 06:53
  SHA: 8625f602ed7f755e881b768737a9a3184d5b0e4c
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1755511/+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 1752301] [NEW] Project tags treats entire collection as a single tag

2018-02-28 Thread Gage Hugo
Public bug reported:

When backporting Debian stable/queens from release Sid to Stretch, an
issue where 3 unit tests were failing due to the entire project tags
collection being treated as a single tag was encountered[0].

It was later determined that the hybrid_property.expression
implementation was causing this issue[1]. When a quick change was pushed
up and tested, the issue appeared to be fixed[2].

The fix for this issue is to drop @hybrid_property usage for @property,
which removes the use of tags.expression. Project should always have
tags instantiated, so there is not a behavior difference, which is a
better fit for @property.


[0] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-02-27.log.html#t2018-02-27T11:23:30

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
/%23openstack-keystone.2018-02-27.log.html#t2018-02-27T19:32:42

[2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
/%23openstack-keystone.2018-02-27.log.html#t2018-02-27T21:24:34

** Affects: keystone
 Importance: High
 Assignee: Gage Hugo (gagehugo)
 Status: In Progress

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

Title:
  Project tags treats entire collection as a single tag

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  When backporting Debian stable/queens from release Sid to Stretch, an
  issue where 3 unit tests were failing due to the entire project tags
  collection being treated as a single tag was encountered[0].

  It was later determined that the hybrid_property.expression
  implementation was causing this issue[1]. When a quick change was
  pushed up and tested, the issue appeared to be fixed[2].

  The fix for this issue is to drop @hybrid_property usage for
  @property, which removes the use of tags.expression. Project should
  always have tags instantiated, so there is not a behavior difference,
  which is a better fit for @property.

  
  [0] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-02-27.log.html#t2018-02-27T11:23:30

  [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
  /%23openstack-keystone.2018-02-27.log.html#t2018-02-27T19:32:42

  [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
  /%23openstack-keystone.2018-02-27.log.html#t2018-02-27T21:24:34

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1752301/+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 1749397] Re: In Verify operation of the Identity service 1st step is not required as the file /etc/keystone/keystone-paste.ini doesn't contain admin_auth_token

2018-02-21 Thread Gage Hugo
*** This bug is a duplicate of bug 1716797 ***
https://bugs.launchpad.net/bugs/1716797

Looks like this was reported right after
https://bugs.launchpad.net/keystone/+bug/1716797 was committed.

** This bug has been marked a duplicate of bug 1716797
   Verify operation in keystone: step 1 has already been done

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

Title:
  In Verify operation of the Identity service 1st step is not required
  as the file /etc/keystone/keystone-paste.ini doesn't contain
  admin_auth_token

Status in OpenStack Identity (keystone):
  New

Bug description:
  In Verify operation of the Identity service 1st step is not required
  as the file /etc/keystone/keystone-paste.ini doesn't contain
  admin_auth_token in the sections [pipeline:public_api],
  [pipeline:admin_api], and [pipeline:api_v3].

  https://docs.openstack.org/keystone/pike/install/keystone-verify-
  ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1749397/+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 1742648] Re: Doc build(both html and man) failing with sphinx 1.6.6

2018-01-17 Thread Gage Hugo
This is probably more of an issue with sphinx then, as the current
solution is to block it on upper constraints[0].

[0] https://review.openstack.org/#/c/534779/

** Changed in: keystone
   Status: Confirmed => Invalid

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

Title:
  Doc build(both html and man) failing with sphinx 1.6.6

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  There seems to be some issue when building docs with sphinx 1.6.6. Current 
u-c for sphinx is 1.6.5.
  Filing bug so that it can be fixed in keystone(if it's a keystone issue) or 
sphinx==1.6.6 can be blacklisted if issue is confirmed in sphinx.

  Reproduction steps:-
  git clone https://github.com/openstack/keystone
  cd keystone
  tox -edocs   #SUCCESS

  .tox/docs/bin/pip install sphinx==1.6.6
  tox -edocs#FAILS with below Error

  Expected result: Doc build should pass

  Actual result: Doc build fails
  ERROR log:-
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... 
  Warning, treated as error:
  
/home/ykarel/work/keystone/doc/source/api/keystone.assignment.backends.rst:document
 isn't included in any toctree
  ERROR: InvocationError: '/home/ykarel/work/keystone/.tox/docs/bin/python 
setup.py build_sphinx'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1742648/+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 1738946] Re: so many Relationship links in api-ref documentation are userless

2017-12-19 Thread Gage Hugo
The links aren't useless, but it has come up multiple times where users
are confused what their purpose is for.  The best explanation we have
for them is here[0].

[0] https://bugs.launchpad.net/keystone/+bug/1674676/comments/3

** Changed in: keystone
   Status: New => Opinion

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

Title:
  so many Relationship links in api-ref documentation are userless

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  so many Relationship links in api-ref doc are userless.

  for example, in api-ref/v3/users.inc file, the Relationship link of
  list users is 'https://docs.openstack.org/api/openstack-
  identity/3/rel/users', however, when I type in my chrome browser, it
  links to 'https://docs.openstack.org/pike/api/'.

  the same issue happens in roles.inc、projects.inc etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1738946/+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 1719492] Re: admin_token_auth not found

2017-11-01 Thread Gage Hugo
Yeah this looks like it's a duplicate of the bug that Craig posted.

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

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

Title:
  admin_token_auth not found

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  in the /etc/keystone/keystone-paste.ini ,the admin_token_auth is not
  found.rmemove it plaese.

  
  This bug tracker is for errors with the documentation, use the following as a 
template and remove or add fields as you see fit. Convert [ ] into [x] to check 
boxes:

  - [ ] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 12.0.0.0rc3.dev2 on 2017-08-26 22:01
  SHA: 5a9aeefff06678d790d167b6dac752677f02edf9
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/pike/install/keystone-verify-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1719492/+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 1717312] Re: Keystone Installation Tutorial for Ubuntu in keystone

2017-09-14 Thread Gage Hugo
This is a duplicate of https://bugs.launchpad.net/keystone/+bug/1716899
and already has a fix in review.

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

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

Title:
  Keystone Installation Tutorial for Ubuntu in keystone

Status in OpenStack Identity (keystone):
  Invalid

Bug description:

  - [x] This doc is inaccurate in this way: After "Verify Operation" page of 
"Finalize the installation" for keystone in Pike release the next page must be 
"Create a domain, projects, users, and roles" where as the next button is 
linked to "Getting started" page which should come after "Using the scripts" 
page.
  Because of this user can miss the "Create a domain, projects, users, and 
roles" page which results in missing project and user creation further leading 
to glance and other services configuration failure.


  ---
  Release: 12.0.0.0rc3.dev2 on 2017-08-26 22:01
  SHA: 5a9aeefff06678d790d167b6dac752677f02edf9
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/index-ubuntu.rst
  URL: https://docs.openstack.org/keystone/pike/install/index-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1717312/+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 1714179] Re: keystone project can not update or search extra filed

2017-09-07 Thread Gage Hugo
I think the idea for extras was to add custom fields, but not allow the
entire "extras" json blob to be searchable so that resources in keystone
wouldn't become data stores. You can already update these fields by
their attribute name (I know "email" is a popular one for Users), but
searching would require some discussion and I think the current
consensus is to avoid doing that. If you are needing to search projects
by some field, there is a current spec that is WIP for Queens to add
"tags" to projects. [0]

[0] https://specs.openstack.org/openstack/keystone-
specs/specs/keystone/queens/project-tags.html

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

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

Title:
  keystone project can not update or search extra field

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  keystone project can not update or search extra field

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1714179/+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 1689468] Re: odd keystone behavior when X-Auth-Token ends with carriage return

2017-07-12 Thread Gage Hugo
** Also affects: keystonemiddleware
   Importance: Undecided
   Status: New

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

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

Title:
  odd keystone behavior when X-Auth-Token ends with carriage return

Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  In Progress

Bug description:
  I had to root cause a very odd problem today, where a user complained
  that they had a token that worked with neutron but didn't work with
  keystone. E.g. they could list networks, but couldn't list projects. I
  thought there must be some mistake, but I was finally able to
  reproduce it and they were correct. Here's a script that shows the
  problem:

  OPENSTACK=
  AUTH_FILE=/root/auth.json

  TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
  -H "Accept:application/json" -H "Content-Type: application/json" -d
  @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'`

  echo 'neutron:'; curl -1 -k -X GET
  https://$OPENSTACK:9696/v2.0/networks -H "X-Auth-Token: $TOKEN" -H
  "Content-Type: application/json"; echo; echo

  echo 'keystone:'; curl -1 -k -X GET
  https://$OPENSTACK:5000/v3/projects -H "X-Auth-Token: $TOKEN" -H
  "Accept: application/json"; echo; echo

  
  With debug=True and insecure_debug=True and 
default_log_levels=keystonemiddleware=True, this yields something like:

  neutron:
  {"networks": []}

  keystone:
  {"error": {"message": "auth_context did not decode anything useful (Disable 
insecure_debug mode to suppress these details.)", "code": 401, "title": 
"Unauthorized"}}


  I was finally able to figure out why... the awk command used to parse
  the token out of the X-Subject-Token header was leaving a \r on the
  end of the $TOKEN value, and apparently that's handled fine when you
  make the request to neutron (and presumably any non-keystone service),
  but not when you are talking to keystone directly. That makes some
  sense, since keystone has to do its own token validation differently.

  Changing the following line in the script above (adding the gsub to
  trim the \r) fixed the issue:

  TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
  -H "Accept:application/json" -H "Content-Type: application/json" -d
  @${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":";
  gsub(/\r$/,"",$2); print $2}'`

  
  We should fix this to be consistent with non-keystone token validation, to 
save someone else the trouble debugging this if nothing else. Keystone was 
doing weird things, where the debug logs would show that the context knew the 
user and roles, but had no token... leaving one to wonder how it figured out 
the user and roles if it didn't have a token?!? Not a good user experience for 
someone trying to write a script to our APIs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1689468/+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 1436957] Re: assertRaisesRegexp has been deprecated for assertRaisesRegex

2017-06-02 Thread Gage Hugo
Keystone has custom test tools [0] for this (which are named the same
and slightly confusing). The one assertRaisesRegexp test tool was added
[1] as a fix for py26 and is not the same as the function from python 2.
It might be useful to change the name of [0] to avoid any future
confusion, but for the purpose of this bug, keystone shouldn't need any
changes.

[0] 
https://github.com/openstack/keystone/blob/7754f170aa0eb42bea356e7f912bc241832eb1f3/keystone/tests/unit/core.py#L800
[1] https://review.openstack.org/#/c/39064/

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

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

Title:
  assertRaisesRegexp has been deprecated for assertRaisesRegex

Status in OpenStack Identity (keystone):
  Invalid
Status in python-keystoneclient:
  Fix Released
Status in python-magnumclient:
  Fix Released
Status in tacker:
  Fix Released
Status in watcher:
  Fix Released

Bug description:
  I am trying to enable tests using tap format for keystone, once I ran
  nosetests --with-tap, a warning message was shown for
  keystoneclient/tests/unit/test_session.py:238: Pending
  DeprecationWarning: Please use assertRegex instead

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1436957/+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 1668173] Re: Update release notes bp link

2017-05-19 Thread Gage Hugo
This was fixed and merged, the commit message had "Clouse-Bug:#1668173"
which probably caused the bot to miss it.

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

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

Title:
  Update release notes bp link

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  In Ocata Series Release Notes
  , the bp
   link is incorrect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1668173/+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 1659053] Re: use uuids with pycadf

2017-02-02 Thread Gage Hugo
** Also affects: pycadf
   Importance: Undecided
   Status: New

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

** Changed in: pycadf
 Assignee: (unassigned) => Gage Hugo (gagehugo)

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

Title:
  use uuids with pycadf

Status in OpenStack Identity (keystone):
  In Progress
Status in pycadf:
  In Progress

Bug description:
  pycadf warnings are plentiful in keystone tests: UserWarning: Invalid uuid. 
To ensure interoperability, identifiersshould be a valid uuid.
warnings.warn('Invalid uuid. To ensure interoperability, identifiers'

  
  Be sure keystone is providing uuids appropriately.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1659053/+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 1608653] [NEW] Installing reqs from test-requirements.txt using pip fails due to missing lib package for psycopg2

2016-08-01 Thread Gage Hugo
Public bug reported:

When setting up a development environment following the instructions
here:

http://docs.openstack.org/developer/keystone/devref/development.environment.html

On Ubuntu 16.04.1 when installing dependencies from test-
requirements.txt using pip, the installation fails when it tries to
install psycopg2:

Collecting psycopg2>=2.5; extra == "postgresql" (from 
oslo.db[fixtures,mysql,postgresql]>=4.1.0->-r test-requirements.txt (line 13))
  Downloading psycopg2-2.6.2.tar.gz (376kB)
100% || 378kB 769kB/s
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/psycopg2.egg-info
writing pip-egg-info/psycopg2.egg-info/PKG-INFO
writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
writing dependency_links to 
pip-egg-info/psycopg2.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found

Error: pg_config executable not found.

Please add the directory containing pg_config to the PATH
or specify the full executable path with the option:

python setup.py build_ext --pg-config /path/to/pg_config build
...

or with the pg_config option in 'setup.cfg'.


Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-j460mO/psycopg2/


Googling this error brings you to this fix from stackoverflow:

http://stackoverflow.com/questions/11618898/pg-config-executable-not-
found

Which simply involves installing the libpq-dev package.  This fixes the
problem and the rest of test-requirements.txt are installed fine.

Recommend adding libpg-dev (Ubuntu/Debian) along with other package
managers to the list of dependencies to install before using pip:

http://docs.openstack.org/developer/keystone/devref/development.environment.html
#installing-dependencies

** Affects: keystone
 Importance: Undecided
 Assignee: Gage Hugo (gagehugo)
 Status: New


** Tags: documentation

** Changed in: keystone
     Assignee: (unassigned) => Gage Hugo (gagehugo)

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

Title:
  Installing reqs from test-requirements.txt using pip fails due to
  missing lib package for psycopg2

Status in OpenStack Identity (keystone):
  New

Bug description:
  When setting up a development environment following the instructions
  here:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html

  On Ubuntu 16.04.1 when installing dependencies from test-
  requirements.txt using pip, the installation fails when it tries to
  install psycopg2:

  Collecting psycopg2>=2.5; extra == "postgresql" (from 
oslo.db[fixtures,mysql,postgresql]>=4.1.0->-r test-requirements.txt (line 13))
Downloading psycopg2-2.6.2.tar.gz (376kB)
  100% || 378kB 769kB/s
  Complete output from command python setup.py egg_info:
  running egg_info
  creating pip-egg-info/psycopg2.egg-info
  writing pip-egg-info/psycopg2.egg-info/PKG-INFO
  writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
  writing dependency_links to 
pip-egg-info/psycopg2.egg-info/dependency_links.txt
  writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
  warning: manifest_maker: standard file '-c' not found

  Error: pg_config executable not found.

  Please add the directory containing pg_config to the PATH
  or specify the full executable path with the option:

  python setup.py build_ext --pg-config /path/to/pg_config build
  ...

  or with the pg_config option in 'setup.cfg'.

  
  Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-j460mO/psycopg2/

  
  Googling this error brings you to this fix from stackoverflow:

  http://stackoverflow.com/questions/11618898/pg-config-executable-not-
  found

  Which simply involves installing the libpq-dev package.  This fixes
  the problem and the rest of test-requirements.txt are installed fine.

  Recommend adding libpg-dev (Ubuntu/Debian) along with other package
  managers to the list of dependencies to install before using pip:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html
  #installing-dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1608653/+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 1533322] Re: "extra_resources" is hidden in ComputeNode

2016-04-13 Thread Gage Hugo
Marked as invalid due to the response from Jay Pipes:

The extra_resources attribute was removed because the extensible
resource tracker functionality was deprecated and removed from Nova.  If
there is some functionality you need to include in the scheduler, please
propose it as a nova-specs blueprint and come on to IRC Freenode
#openstack-nova channel to discuss how to implement this functionality.

Going to abandon the change for now.

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

** Changed in: nova
 Assignee: Gage Hugo (gh159m) => (unassigned)

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

Title:
  "extra_resources" is hidden in ComputeNode

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  "extra_resources" is a text field defined in ComputeNode model:
  
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L165

  But it's not defined in objects.compute_node.ComputeNode:
  https://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L52

  True that it's not used anywhere in projects, but it's critical for
  some customized schedulers.

  No clue shows this field is about to deprecate, can we expose this
  field in objects.compute_node.ComputeNode?

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