date:20170117

Reviewed:  https://review.openstack.org/420497
Committed: 
https://git.openstack.org/cgit/openstack/neutron-fwaas/commit/?id=2170ab35d0b38054fd1fc263d2378ed1c06998f8
Submitter: Jenkins
Branch:master

commit 2170ab35d0b38054fd1fc263d2378ed1c06998f8
Author: ZhaoBo 
Date:   Mon Jan 16 12:16:16 2017 +0800

Fix update fwr with ipv6 address

Currently, if the Firewall Rule Update's body doesn't contain
'ip_version', then the 'rule_ip_version' is set as None, while it is set
to the IP version '4' if 'ip_version' is not specified in Firewall Rule
Create's body.

This patch add the logic like _validate_fwr_protocol_parameters, and read
the ip_version from db if not specified in update body.

Closes-Bug: #1656739
Change-Id: Idd2aa5213f65d386420b2ee2f0ff5638b56525f5


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

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

Title:
  Update fw_rule with ipv6 address if not specified ip_version

Status in neutron:
  Fix Released

Bug description:
  Get "FirewallIpAddressConflict" error when update exist IPv6
  firewall_rule.

  create body:
  {
  "firewall_rule": {
  "action": "reject",
  "enabled": true,
  "name": "tcp_reject",
  "protocol": "tcp",
  "source_ip_address": "1::23",
  "ip_version": 6
  }
  }

  OK, the firewall_rule will be created successful.

  Then I update it like :
  {
  "firewall_rule": {
  "source_ip_address": "1::22"
  }
  }

  returned "FirewallIpAddressConflict" error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1656739/+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 1657341] [NEW] availability zone is wrong when create volume from image

2017-01-17 Thread atsushi

Public bug reported:

Dear sir,

I have problem about horizon dashboard.

create new volume availability zone is not correct when it is created from
Images -> create volume.
availability zone is displayed about nova, not cinder, so availability zone not
found error happens.

Further information, please check attached image.

Regards,

** Affects: horizon
Importance: Undecided
Status: New

** Attachment added: "WrongAvailabilityZone.docx"

https://bugs.launchpad.net/bugs/1657341/+attachment/4805613/+files/WrongAvailabilityZone.docx

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

Title:
availability zone is wrong when create volume from image

Status in OpenStack Dashboard (Horizon):
New

Bug description:
Dear sir,

I have problem about horizon dashboard.

Further information, please check attached image.

Regards,

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657341/+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 1476213] Re: Adding users from different domain to a group

This should have expired ages ago

** Changed in: keystone
   Status: Incomplete => 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/1476213

Title:
  Adding users from different domain to a group

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  In Horizon, I found that, users from one domain are not allowed to be
  part of the group of another domain..

  Steps followed:
  1. Created 2 domains, domain1 and domain2
  2. Created users, user1 in domain1 and user2 in domain2.
  3. Created groups, group1 in domain1 and group2 in domain2.
  4. In UI, tried to add user1 to group2. While "Add users" is clicked in 
"Group Management" page of group2, it shows only user2.Have attached the 
screenshot of the same.
  5. Same behavior is observed while adding user2 to group1.

  As per the discussion above, users from one domain are allowed to be
  part of the group of another domain.In CLI, same behavior is observed,
  however in UI, the behavior is different as mentioned in the above
  steps.

  Can you please let me know if UI is behaving as designed?

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1476213/+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 1600366] Re: Federated users cannot use heat

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

** This bug is no longer a duplicate of bug 1589993
   Murano cannot deploy with federated user
** This bug has been marked a duplicate of bug 1642687
   Missing domain for federated users

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

Title:
  Federated users cannot use heat

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  Federated users cannot create heat stacks.

  To reproduce:
  Enable heat,
  Sign into horizon using federation
  Create a heat stack (errors out here)

  My guess:
  This is caused because federated users cannot perform trust delegation 
because they do not have any real roles associated with them (Although in other 
cases they somehow get the same roles as the group in the mapping and also the 
local user created after log in is not part of the group).

  Work around:
  1. list the users and find the federated user uuid that was created locally 
on the service provider after signing in
  2. assign the heat_stack_owner role to the federated user uuid
  3. should work now.

  It would be nice if it worked out of the box without having to do the
  work around.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1600366/+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 1546441] Re: db sync command should give user friendly message for invalid 'version' specified

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

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

Title:
  db sync command should give user friendly message for invalid
  'version' specified

Status in Cinder:
  In Progress
Status in Glance:
  In Progress
Status in OpenStack Identity (keystone):
  Opinion
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  db sync command should give user friendly message for invalid
  'version' specified

  The command:

  $ nova-manage db sync
  11

  LOG:

  2016-02-16 01:54:53.908 CRITICAL nova [-] OverflowError: range()
  result has too many items

  2016-02-16 01:54:53.908 TRACE nova Traceback (most recent call last):
  2016-02-16 01:54:53.908 TRACE nova   File "/usr/local/bin/nova-manage", line 
10, in 
  2016-02-16 01:54:53.908 TRACE nova sys.exit(main())
  2016-02-16 01:54:53.908 TRACE nova   File 
"/opt/stack/nova/nova/cmd/manage.py", line 1448, in main
  2016-02-16 01:54:53.908 TRACE nova ret = fn(*fn_args, **fn_kwargs)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/opt/stack/nova/nova/cmd/manage.py", line 932, in sync
  2016-02-16 01:54:53.908 TRACE nova return migration.db_sync(version)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/opt/stack/nova/nova/db/migration.py", line 26, in db_sync
  2016-02-16 01:54:53.908 TRACE nova return IMPL.db_sync(version=version, 
database=database)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/opt/stack/nova/nova/db/sqlalchemy/migration.py", line 57, in db_sync
  2016-02-16 01:54:53.908 TRACE nova version)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 186, 
in upgrade
  2016-02-16 01:54:53.908 TRACE nova return _migrate(url, repository, 
version, upgrade=True, err=err, **opts)
  2016-02-16 01:54:53.908 TRACE nova   File "", line 2, in 
_migrate
  2016-02-16 01:54:53.908 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py", 
line 160, in with_engine
  2016-02-16 01:54:53.908 TRACE nova return f(*a, **kw)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 345, 
in _migrate
  2016-02-16 01:54:53.908 TRACE nova changeset = schema.changeset(version)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 82, 
in changeset
  2016-02-16 01:54:53.908 TRACE nova changeset = 
self.repository.changeset(database, start_ver, version)
  2016-02-16 01:54:53.908 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/repository.py", line 
224, in changeset
  2016-02-16 01:54:53.908 TRACE nova versions = range(int(start) + 
range_mod, int(end) + range_mod, step)
  2016-02-16 01:54:53.908 TRACE nova OverflowError: range() result has too many 
items
  2016-02-16 01:54:53.908 TRACE nova

  
  The command:
  $ nova-manage db sync 2147483

  LOG:
  CRITICAL nova [-] KeyError: 

  2016-02-16 02:06:15.045 TRACE nova Traceback (most recent call last):
  2016-02-16 02:06:15.045 TRACE nova   File "/usr/local/bin/nova-manage", line 
10, in 
  2016-02-16 02:06:15.045 TRACE nova sys.exit(main())
  2016-02-16 02:06:15.045 TRACE nova   File 
"/opt/stack/nova/nova/cmd/manage.py", line 1448, in main
  2016-02-16 02:06:15.045 TRACE nova ret = fn(*fn_args, **fn_kwargs)
  2016-02-16 02:06:15.045 TRACE nova   File 
"/opt/stack/nova/nova/cmd/manage.py", line 932, in sync
  2016-02-16 02:06:15.045 TRACE nova return migration.db_sync(version)
  2016-02-16 02:06:15.045 TRACE nova   File 
"/opt/stack/nova/nova/db/migration.py", line 26, in db_sync
  2016-02-16 02:06:15.045 TRACE nova return IMPL.db_sync(version=version, 
database=database)
  2016-02-16 02:06:15.045 TRACE nova   File 
"/opt/stack/nova/nova/db/sqlalchemy/migration.py", line 57, in db_sync
  2016-02-16 02:06:15.045 TRACE nova version)
  2016-02-16 02:06:15.045 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 186, 
in upgrade
  2016-02-16 02:06:15.045 TRACE nova return _migrate(url, repository, 
version, upgrade=True, err=err, **opts)
  2016-02-16 02:06:15.045 TRACE nova   File "", line 2, in 
_migrate
  2016-02-16 02:06:15.045 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py", 
line 160, in with_engine
  2016-02-16 02:06:15.045 TRACE nova return f(*a, **kw)
  2016-02-16 02:06:15.045 TRACE nova   File 
"/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 345, 
in _migrate
  2016-02-16 02:06:15.045 TRACE nova changeset = schema.changeset(version)
  2016-02-16 02:06:15.045 TRACE nova   File

[Yahoo-eng-team] [Bug 1613901] Re: String "..%c0%af" causes 500 errors in multiple locations

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

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

Title:
  String "..%c0%af" causes 500 errors in multiple locations

Status in Cinder:
  Incomplete
Status in Glance:
  New
Status in OpenStack Identity (keystone):
  Won't Fix
Status in neutron:
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:

  While doing some testing on Keystone using Syntribos
  (https://github.com/openstack/syntribos), our team (myself, Michael
  Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia)
  noticed that we got 500 status codes when the string "..%c0%af" was
  inserted in various places in the URL for different types of requests.

  Here are some examples:

  =

  DELETE /v3/policies/..%c0%af HTTP/1.1
  Host: [REDACTED]:5000
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.0
  X-Auth-Token: [REDACTED]
  Content-Length: 0

  HTTP/1.1 500 Internal Server Error
  Date: Tue, 16 Aug 2016 22:04:27 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  X-Distribution: Ubuntu
  x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3
  Content-Length: 143
  Connection: close
  Content-Type: application/json

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request.", "code": 500, "title": "Internal Server
  Error"}}

  =

  PATCH /v3/policies/..%c0%af HTTP/1.1
  Host: [REDACTED]:5000
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.0
  Content-type: application/json
  X-Auth-Token: [REDACTED]
  Content-Length: 70

  {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"}

  HTTP/1.1 500 Internal Server Error
  Date: Tue, 16 Aug 2016 22:05:36 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  X-Distribution: Ubuntu
  x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2
  Content-Length: 143
  Connection: close
  Content-Type: application/json

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request.", "code": 500, "title": "Internal Server
  Error"}}

  =

  GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles 
HTTP/1.1
  Host: [REDACTED]:5000
  Connection: close
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-requests/2.11.0
  X-Auth-Token: [REDACTED]

  HTTP/1.1 500 Internal Server Error
  Date: Tue, 16 Aug 2016 22:07:09 GMT
  Server: Apache/2.4.7 (Ubuntu)
  Vary: X-Auth-Token
  X-Distribution: Ubuntu
  x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7
  Content-Length: 143
  Connection: close
  Content-Type: application/json

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request.", "code": 500, "title": "Internal Server
  Error"}}

  =

  I've marked this as a security issue as a precaution in case it turns
  out that there is a more serious vulnerability underlying these
  errors. We have no reason to suspect that there is a greater
  vulnerability at this time, but given the many endpoints this seems to
  affect, I figured caution was worthwhile since this may be a
  framework-wide issue. Feel free to make this public if it is
  determined not to be security-impacting.

  Here is a (possibly incomplete) list of affected endpoints. Inserting
  the string "..%c0%af" in any or all of the spots labeled "HERE" should
  yield a 500 error. As you can see, virtually all v3 endpoints exhibit
  this behavior.

  =

  [GET|PATCH|DELETE] /v3/endpoints/[HERE]

  [GET|PATCH]   /v3/domains/[HERE]
  GET   /v3/domains/[HERE]/groups/[HERE]/roles
  [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE]
  GET   /v3/domains/[HERE]/users/[HERE]/roles
  [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE]

  [GET|PATCH|DELETE] /v3/groups/[HERE]
  [HEAD|PUT|DELETE]  /v3/groups[HERE]/users/[HERE]

  [POST|DELETE] /v3/keys/[HERE]

  [GET|PATCH|DELETE] /v3/policies/[HERE]
  [GET|PUT|DELETE]   /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE]
  [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy
  [GET|PUT|DELETE]   /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE]
  [PUT|DELETE]   /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE]
  [GET|PUT|DELETE]   
/v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE]

  [GET|PATCH|DELETE] /v3/projects/[HERE]
  [DELETE|PATCH] /v3/projects/[HERE]/cascade
  GET/v3/projects/[HERE]/groups/[HERE]/roles
  GET/v3/projects/[HERE]/users/[HERE]/roles
  [HEAD|PUT|DELETE]  /v3/projects/[HERE]/groups/[HERE]/roles/[HERE]

  [GET|PATCH|DELETE] /v3/regions/[HERE]

  [PATCH|DELETE]

[Yahoo-eng-team] [Bug 1653316] Re: ldap doesn't work

** Changed in: keystone
   Status: Incomplete => 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/1653316

Title:
  ldap doesn't work

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  fail to auth.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1653316/+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 1629446] Re: federated login fails after user is removed from group

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

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

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

** Changed in: keystone/mitaka
   Importance: Undecided => Medium

** Changed in: keystone/newton
   Importance: Undecided => Medium

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

Title:
  federated login fails after user is removed from group

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) mitaka series:
  New
Status in OpenStack Identity (keystone) newton series:
  New

Bug description:
  A user part of a group in auth0 tries to login in using the mapping
  below just fine

  [
  {
  "local": [
  {
  "user": {
  "name": "{1}::{0}"
  }
  },
  {
  "domain": {
  "id": "default"
  },
  "groups": "{1}"
  }
  ],
  "remote": [
  {
  "type": "HTTP_OIDC_CLAIM_EMAIL"
  },
  {
  "type": "HTTP_OIDC_CLAIM_GROUPS"
  }
  ]
  }
  ]

  
  Once the user is removed from the group in auth0 and tries to login :

  Expected Result:
  Failed to log on to horizon as federation user using OpenID Connect protocol 
and got 401 code:

  {"error": {"message": "The request you have made requires
  authentication.", "code": 401, "title": "Unauthorized"}}

  Actual Result:
  Got 500 instead of 401

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request.", "code": 500, "title": "Internal Server
  Error"}}

  error in keystone-all.logs:

  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
[req-f5f27f59-788b-494b-9719-bcdbb6b628c0 - - - - -] unexpected EOF while 
parsing (, line 0)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/common/wsgi.py",
 line 249, in __call__
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi result = 
method(context, **params)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
 line 329, in federated_idp_specific_sso_auth
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi res = 
self.federated_authentication(context, idp_id, protocol_id)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
 line 302, in federated_authentication
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi return 
self.authenticate_for_token(context, auth=auth)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
 line 396, in authenticate_for_token
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
self.authenticate(context, auth_info, auth_context)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
 line 520, in authenticate
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi auth_context)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 65, in authenticate
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
self.identity_api)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 141, in handle_unscoped_token
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi federation_api, 
identity_api)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 194, in apply_mapping_filter
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
identity_provider, protocol, assertion)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/common/manager.py",
 line 124, in wrapped
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi __ret_val = 
__f(*args, **kwargs)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File

[Yahoo-eng-team] [Bug 1644175] Re: create project command mentioned in Installation guide for Newton throwing error

We do that here: http://docs.openstack.org/developer/python-
openstackclient/command-objects/project.html#project-create

--

--domain 
Domain owning the project (name or ID)

*New in version 3.*


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

** Changed in: ubuntu
   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/1644175

Title:
  create project command mentioned in Installation guide for Newton
  throwing error

Status in OpenStack Identity (keystone):
  Invalid
Status in Ubuntu:
  Invalid

Bug description:
  While doing manual installation of Newton release by the following URL:
  http://docs.openstack.org/newton/install-guide-rdo/keystone-users.html

  The project create command throws error. 
  [root@controller ~(keystone_admin)]# openstack project create --domain 
default --description "Service Project" service
  usage: openstack project create [-h] [-f {json,shell,table,value,yaml}]
  [-c COLUMN] [--max-width ]
  [--noindent] [--prefix PREFIX]
  [--description ]
  [--enable | --disable]
  [--property

[Yahoo-eng-team] [Bug 1580053] Re: Configure Apache HTTPD for mod_shibboleth(WSGIScriptAliasMatch): steps for creating hard links are missing

The federation docs were improved greatly over here:
https://github.com/openstack/keystone/commit/38f79a8edf624a12c06558d97602f54f8e4bd83a

** Changed in: keystone
   Status: Triaged => 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/1580053

Title:
  Configure Apache HTTPD for mod_shibboleth(WSGIScriptAliasMatch): steps
  for creating hard links are missing

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  In the section "Configure Apache HTTPD for mod_shibboleth":

  http://docs.openstack.org/developer/keystone/extensions/shibboleth.html
  #configure-apache-httpd-for-mod-shibboleth

  it is given that:

  Add WSGIScriptAlias directive to your vhost configuration:
  --

  WSGIScriptAliasMatch ^(/v3/OS-
  FEDERATION/identity_providers/.*?/protocols/.*?/auth)$
  /var/www/keystone/main/$1

  While the users try to configure, they actually see that the directory
  /var/www/keystone does not exist.

  It would be better to mention that create a directory
  /var/www/keystone if it does not exist and create the following hard
  links:

  For example:
  ln /opt/stack/keystone/httpd/keystone.py main
  ln /opt/stack/keystone/httpd/keystone.py admin

  It took me a while to understand the above steps while I was
  configuring the Keystone for federations.

  I would also recommend that we should call it WSGIScriptAliasMatch
  directive instead of WSGIScriptAlias directive since we are actually
  adding WSGIScriptAliasMatch directive. So the above underlined text
  should be read as follows:

  Add WSGIScriptAliasMatch directive to your vhost configuration:

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1580053/+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 1651813] Fix merged to neutron (master)

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

commit dcd4c8b8de4972b8e5aff55e041df54f66ac81b3
Author: Quan Tian 
Date:   Wed Dec 21 20:40:08 2016 +0800

DVR: delete stale devices after router update

After the external network change of router gateway, the l3 agent
deletes stale external devices in the qrouter namespace only. This
doesn't apply to distributed router.

This patch extract a method named _delete_stale_external_devices from
RouterInfo and override it in DvrEdgeRouter.

Change-Id: I2602efd5be92ec57410e54cf9c26641330a52ee6
Partial-Bug: #1651813


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

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

Title:
  Csnat port missing after update router gateway to another network

Status in neutron:
  Fix Released

Bug description:
  When updating router gateway to another external network, original csnat 
ports are deleted in db, but no new ports are created. 
  Besides, stale devices belong to the original network remains in the snat 
namespace.

  How to reproduce:

  - create two external network, one internal network, one distributed router
  - add the internal network interface to the router, set the router's gateway 
to the first external network 
  - set the router's gateway to another external network, csnat ports will be 
deleted in db, stale devices "qg-XXX" will be found in snat namespace.

  $ neutron router-port-list test -c id -c mac_address -c fixed_ips -c 
device_owner
  
+--+---+--+--+
  | id   | mac_address   | fixed_ips
| 
device_owner |
  
+--+---+--+--+
  | 233f23b2-7cda-415b-80f3-27d1a014518f | fa:16:3e:b3:8d:4b | {"subnet_id": 
"c1918178-4697-4de7-9c92-ff618ae8a6ee", "ip_address": "172.16.1.252"}  | 
network:router_gateway   |
  | 91e2e5f2-30d7-4c1d-9fe8-b42bfab2b67e | fa:16:3e:3e:dc:60 | {"subnet_id": 
"0537a1e9-a30c-433e-b034-023b74916821", "ip_address": "192.168.100.1"} | 
network:router_interface_distributed |
  
+--+---+--+--+

  $ sudo ip netns exec snat-c618e83d-0ab9-48fc-8efa-a25b7b947978 ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
  42: sg-49fc22d0-cd:  mtu 1450 qdisc noqueue state 
UNKNOWN group default
  link/ether fa:16:3e:ad:29:1d brd ff:ff:ff:ff:ff:ff
  inet 192.168.100.9/24 brd 192.168.100.255 scope global sg-49fc22d0-cd
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:fead:291d/64 scope link
 valid_lft forever preferred_lft forever
  46: qg-d4ce7b19-cb:  mtu 1450 qdisc noqueue state 
UNKNOWN group default
  link/ether fa:16:3e:c2:bc:45 brd ff:ff:ff:ff:ff:ff
  inet 192.168.200.8/24 brd 192.168.200.255 scope global qg-d4ce7b19-cb
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:fec2:bc45/64 scope link
 valid_lft forever preferred_lft forever
  47: qg-233f23b2-7c:  mtu 1500 qdisc noqueue state 
UNKNOWN group default
  link/ether fa:16:3e:b3:8d:4b brd ff:ff:ff:ff:ff:ff
  inet 172.16.1.252/24 brd 172.16.1.255 scope global qg-233f23b2-7c
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:feb3:8d4b/64 scope link
 valid_lft forever preferred_lft forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1651813/+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 1564110] Re: OpenStack should support MySQL Cluster (NDB)

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

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

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

Title:
  OpenStack should support MySQL Cluster (NDB)

Status in Ceilometer:
  Won't Fix
Status in Cinder:
  Opinion
Status in Glance:
  New
Status in heat:
  New
Status in Ironic:
  Confirmed
Status in OpenStack Identity (keystone):
  Opinion
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Confirmed
Status in oslo.db:
  New

Bug description:
  oslo.db assumes that a MySQL database can only have a storage engine
  of InnoDB. This causes complications for OpenStack to support other
  MySQL storage engines, such as MySQL Cluster (NDB). Oslo.db should
  have a configuration string (i.e. mysql_storage_engine) in the oslo_db
  database group that can be used by SQLalchemy, Alembic, and OpenStack
  to implement the desired support and behavior for alternative MySQL
  storage engines.

  I do have a change-set patch for options.py in oslo_db that will add
  this functionality. I'll post once I'm added to the CLA for OpenStack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1564110/+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 1656482] Re: GET /resource_providers?member_of does not validate the value is a uuid

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

commit c17772e1f202c9ffb651adc3299a1990c35766f3
Author: Matt Riedemann 
Date:   Fri Jan 13 21:42:07 2017 -0500

placement: validate member_of values are uuids

The 1.3 microversion adds the member_of query parameter
for listing resource providers which are members of
one or more aggregates based on the aggregate uuids. However
the REST API handler code is simply parsing and passing the
member_of values through to the object code which is doing a
SQL IN statement which will result in no resource providers if
an invalidate aggregate uuid is provided, i.e. not actually a
uuid.

This patch adds simple uuid validation to the handler code
that's parsing the member_of query parameter.

Change-Id: I912f731e0d75979aea0a0f22c15e6cfb84a95050
Closes-Bug: #1656482


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

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

Title:
  GET /resource_providers?member_of does not validate the value is a
  uuid

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The 1.3 microversion of the placement API adds a member_of query
  string parameter to the /resource_providers handler and the values are
  meant to be aggregate uuids, but the REST API handler code simply
  parses the query string and passes the filter through to the DB API
  query code, which is doing a simple aggregate.uuid IN [values] query.
  For something that's not a uuid it's just going to result in no
  results and return an empty list, but the REST API should be stricter
  about the actual member_of values being uuids.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1656482/+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 1631960] Re: An unexpected API error when booting a server with resonable parameters.

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

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

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

Title:
  An unexpected API error when booting a server with resonable
  parameters.

Status in OpenStack Compute (nova):
  Expired

Bug description:
  I get an unexpected API error when I boot a server with nova boot.
  Before this, I list flavors and images. I think my parameters are
  resonaable. As follows：

  wh@ubuntu:~/devstack$ nova list
  ++--+++-+--+
  | ID | Name | Status | Task State | Power State | Networks |
  ++--+++-+--+
  ++--+++-+--+
  wh@ubuntu:~/devstack$ nova flavor-list
  
++---+---+--+---+--+---+-+---+
  | ID | Name  | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor 
| Is_Public |
  
++---+---+--+---+--+---+-+---+
  | 1  | m1.tiny   | 512   | 1| 0 |  | 1 | 1.0 
| True  |
  | 2  | m1.small  | 2048  | 20   | 0 |  | 1 | 1.0 
| True  |
  | 3  | m1.medium | 4096  | 40   | 0 |  | 2 | 1.0 
| True  |
  | 4  | m1.large  | 8192  | 80   | 0 |  | 4 | 1.0 
| True  |
  | 42 | m1.nano   | 64| 0| 0 |  | 1 | 1.0 
| True  |
  | 5  | m1.xlarge | 16384 | 160  | 0 |  | 8 | 1.0 
| True  |
  | 84 | m1.micro  | 128   | 0| 0 |  | 1 | 1.0 
| True  |
  | c1 | cirros256 | 256   | 0| 0 |  | 1 | 1.0 
| True  |
  | d1 | ds512M| 512   | 5| 0 |  | 1 | 1.0 
| True  |
  | d2 | ds1G  | 1024  | 10   | 0 |  | 1 | 1.0 
| True  |
  | d3 | ds2G  | 2048  | 10   | 0 |  | 2 | 1.0 
| True  |
  | d4 | ds4G  | 4096  | 20   | 0 |  | 4 | 1.0 
| True  |
  
++---+---+--+---+--+---+-+---+
  wh@ubuntu:~/devstack$ glance image-list
  +--+-+
  | ID   | Name|
  +--+-+
  | dff7ce82-5453-427c-98b1-88422bf53e3c | cirros-0.3.4-x86_64-uec |
  | 38fab68d-e787-45de-b022-10d70a24b2b9 | cirros-0.3.4-x86_64-uec-kernel  |
  | cb2a8ab4-a18c-48cc-817d-08d3caaf6659 | cirros-0.3.4-x86_64-uec-ramdisk |
  +--+-+
  wh@ubuntu:~/devstack$ nova boot --flavor m1.tiny --image 
cirros-0.3.4-x86_64-uec virtual_machine1
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-7ed777bb-c9e9-4ed8-bd7d-55470efaa8b5)

  And I feel strange about nova list command. Because it can list 
virtual_machine1 even an unexpected API error occurred. 
  Supplementary explanation:
  nova version:6.0.0
  My code is the latest master branch.
  Think for your help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1631960/+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 1642579] Re: use neutron for nova-compute but compute use nova-network rpc api

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

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

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

Title:
  use neutron for nova-compute but compute use nova-network rpc api

Status in OpenStack Compute (nova):
  Expired

Bug description:
  my nova.conf like this:
  network_api_class=nova.network.neutronv2.api.API
  use_neutron=True

  when I create a vm because nova-compute not found the glance image then a 
exceptin occure:
  2016-11-14 11:32:48.729 37828  Traceback (most recent call last):
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 358, in 
_cleanup_allocated_networks
  2016-11-14 11:32:48.729 37828  context, instance, 
requested_networks=requested_networks)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped
  2016-11-14 11:32:48.729 37828  return func(self, context, *args, **kwargs)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/nova/network/api.py", line 299, in 
deallocate_for_instance
  2016-11-14 11:32:48.729 37828  requested_networks=requested_networks)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 183, in 
deallocate_for_instance
  2016-11-14 11:32:48.729 37828  return cctxt.call(ctxt, 
'deallocate_for_instance', **kwargs)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 413, in 
call
  2016-11-14 11:32:48.729 37828  return self.prepare().call(ctxt, method, 
**kwargs)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 158, in 
call
  2016-11-14 11:32:48.729 37828  retry=self.retry)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 91, in 
_send
  2016-11-14 11:32:48.729 37828  timeout=timeout, retry=retry)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
512, in send
  2016-11-14 11:32:48.729 37828  retry=retry)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
501, in _send
  2016-11-14 11:32:48.729 37828  result = self._waiter.wait(msg_id, timeout)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
379, in wait
  2016-11-14 11:32:48.729 37828  message = self.waiters.get(msg_id, 
timeout=timeout)
  2016-11-14 11:32:48.729 37828File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
277, in get
  2016-11-14 11:32:48.729 37828  'to message ID %s' % msg_id)
  2016-11-14 11:32:48.729 37828  MessagingTimeout: Timed out waiting for a 
reply to message ID e3b4c7fb434b48908ac4f0ef49fb77f1

  I use the neutron for netowrk but the error log show that nova-conductor use 
nova-network rpc api
  for example the code:File 
"/usr/lib/python2.7/site-packages/nova/network/api.py", line 299, in 
deallocate_for_instance 
  in fact it should use 
/usr/lib/python2.7/site-packages/nova/network/neutronv2.api.py

  why? I guess maybe I create a error instance then the bug occure
  if I create a active instance the bug will not be occure

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1642579/+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 1640705] Re: Unexpected nova API Error in launching a intance

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

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

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

Title:
  Unexpected nova API Error in launching a intance

Status in OpenStack Compute (nova):
  Expired

Bug description:
  when i excute the command:penstack server create --flavor m1.nano --image 
cirros   --nic net-id=xxx --security-group default   --key-name mykey 
provider-instance
  a error occured as the following:
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-7f5ecbf3-61e3-436b-b064-c003b70df4c7)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1640705/+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 1642303] Re: neutron multiple external flat networks fails

[Expired for kolla because there has been no activity for 60 days.]

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

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

Title:
  neutron multiple external flat networks fails

Status in kolla:
  Expired
Status in neutron:
  Expired

Bug description:
  Setting up one external flat network works fine. However when trying
  to setup more than one external flat network, neutron-openvswitch-
  agent disconnects ovs continously. This bug will be opened in both
  kolla and neutron since it is not determined what is causing this.

  ENV: kolla stable/newton; containers are centos source.

  - relevant kolla config settings 
  /etc/kolla/globals.yml
  neutron_bridge_name: "br-vlan802,br-vlan805" 
  neutron_external_interface: "bond0.802,bond0.805"

  #no dvr, lbaas, qos, etc
  -

  config files and logs can be found here
  http://paste.openstack.org/show/589464/
  http://paste.openstack.org/show/589286/
  http://paste.openstack.org/show/589276/

  snipplet from ovs log. 805 and 802 are the external bridges. They get 
disconnected as soon as they connect. br-tun and br-int does not show this 
behavior.
  => openvswitch/ovs-vswitchd.log <==
  2016-11-15T12:15:51.586Z|01155|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:52.585Z|01156|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:52.586Z|01157|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:52.587Z|01158|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:53.584Z|01159|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:53.585Z|01160|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:53.586Z|01161|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:54.585Z|01162|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:54.586Z|01163|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:54.587Z|01164|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:55.584Z|01165|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:55.586Z|01166|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:55.587Z|01167|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:56.584Z|01168|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:56.586Z|01169|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:56.587Z|01170|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:57.585Z|01171|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:57.586Z|01172|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:57.586Z|01173|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:58.585Z|01174|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:58.586Z|01175|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:58.587Z|01176|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:59.585Z|01177|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:59.586Z|01178|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:59.587Z|01179|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:00.585Z|01180|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:16:00.587Z|01181|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:16:00.587Z|01182|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:01.584Z|01183|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:16:01.585Z|01184|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:16:01.586Z|01185|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:02.585Z|01186|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...

To manage notifications about this bug go to:
https://bugs.launchpad.net/kolla/+bug/1642303/+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 1642303] Re: neutron multiple external flat networks fails

[Expired for neutron because there has been no activity for 60 days.]

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

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

Title:
  neutron multiple external flat networks fails

Status in kolla:
  Expired
Status in neutron:
  Expired

Bug description:
  Setting up one external flat network works fine. However when trying
  to setup more than one external flat network, neutron-openvswitch-
  agent disconnects ovs continously. This bug will be opened in both
  kolla and neutron since it is not determined what is causing this.

  ENV: kolla stable/newton; containers are centos source.

  - relevant kolla config settings 
  /etc/kolla/globals.yml
  neutron_bridge_name: "br-vlan802,br-vlan805" 
  neutron_external_interface: "bond0.802,bond0.805"

  #no dvr, lbaas, qos, etc
  -

  config files and logs can be found here
  http://paste.openstack.org/show/589464/
  http://paste.openstack.org/show/589286/
  http://paste.openstack.org/show/589276/

  snipplet from ovs log. 805 and 802 are the external bridges. They get 
disconnected as soon as they connect. br-tun and br-int does not show this 
behavior.
  => openvswitch/ovs-vswitchd.log <==
  2016-11-15T12:15:51.586Z|01155|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:52.585Z|01156|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:52.586Z|01157|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:52.587Z|01158|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:53.584Z|01159|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:53.585Z|01160|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:53.586Z|01161|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:54.585Z|01162|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:54.586Z|01163|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:54.587Z|01164|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:55.584Z|01165|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:55.586Z|01166|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:55.587Z|01167|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:56.584Z|01168|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:56.586Z|01169|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:56.587Z|01170|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:57.585Z|01171|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:57.586Z|01172|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:57.586Z|01173|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:58.585Z|01174|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:58.586Z|01175|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:58.587Z|01176|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:15:59.585Z|01177|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:15:59.586Z|01178|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:15:59.587Z|01179|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:00.585Z|01180|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:16:00.587Z|01181|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:16:00.587Z|01182|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:01.584Z|01183|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connecting...
  2016-11-15T12:16:01.585Z|01184|rconn|INFO|br-vlan802<->tcp:127.0.0.1:6633: 
connected
  2016-11-15T12:16:01.586Z|01185|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connection closed by peer
  2016-11-15T12:16:02.585Z|01186|rconn|INFO|br-vlan805<->tcp:127.0.0.1:6633: 
connecting...

To manage notifications about this bug go to:
https://bugs.launchpad.net/kolla/+bug/1642303/+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 1582099] Re: Need to create the sample file for Add Floating IP request action.

2017-01-17 Thread Anusha Unnam

For TODO's I don't think we need to report a bug, we can directly submit
a patch for that change to Gerrit. Anyhow this TODO has been addressed
already in the current master. So marking this bug as Invalid.

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

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

Title:
  Need to create the sample file for Add Floating IP request action.

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Currently, the floating-ips-create-resp.json is used as the request
  sample for Add (Associate) Floating Ip (Addfloatingip Action) in the
  servers-actions.inc file. According to TODO, a new request sample file
  must be created for this action.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1582099/+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 1543169] Re: Nova os-volume-types endpoint doesn't exist

2017-01-17 Thread Anusha Unnam

Changing the status from new to Invalid, as this bug is marked as invalid by 
sean dague before it was changed to confirmed by sharat sharma.
Carolyn, Please feel free to mark it as new if you still feel this bug is valid.

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

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

Title:
  Nova os-volume-types endpoint doesn't exist

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

Bug description:
  The Nova v2.1 documentation shows an endpoint "os-volume-types" which
  lists the available volume types. http://developer.openstack.org/api-
  ref-compute-v2.1.html#listVolumeTypes

  I am using OpenStack Liberty and that endpoint doesn't appear to exist
  anymore. GET requests sent to /v2.1/{tenant_id}/os-volume-types
  return 404 not found. When I searched the Nova codebase on GitHub, I
  could only find a reference to volume types in the policy.json but not
  implemented anywhere.

  Does this endpoint still exist, and if so what is the appropriate
  documentation?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1543169/+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 1557166] Re: V2 Endpoint creation with missing region returns 500

Reviewed:  https://review.openstack.org/304489
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=3039e6c4bc9b1d721ecd2dc95d949072866ec8f1
Submitter: Jenkins
Branch:master

commit 3039e6c4bc9b1d721ecd2dc95d949072866ec8f1
Author: Kanika Singh 
Date:   Tue Apr 12 15:18:30 2016 +0530

Handling of 'region' parameter as None

In V2 Endpoint creation it returns 500 error due to missing
'region'. So, changed the way of fetching the same parameter to handle
None case.

Change-Id: I5c9ef206193072da73d3990d5f77003124db8265
Closes-Bug: #1557166


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

Title:
  V2 Endpoint creation with missing region returns 500

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Keystone returns a 500 if optional attribute region is not passed in
  on endpoint creation.

  Curl:
  export SERVICE_ID=1234
  export PUBLIC_URL='https://publicurl/v1'
  export ADMIN_URL='https://adminurl/v1'
  export INTERNAL_URL='https://internalurl/v1'

  #Create endpoint
  curl -X POST $ENDPOINT/v2.0/endpoints -d '{ "endpoint": {"service_id": 
"'$SERVICE_ID'", "publicurl": "'$PUBLIC_URL'", "adminurl": "'$ADMIN_URL'", 
"internalurl": "'$INTERNAL_URL'"}}' -H "Content-Type: application/json" -H 
"Accept: application/json" -H "X-Auth-Token: $ADMIN_TOKEN" -k -v | json

  Response:
  < HTTP/1.1 500 Internal Server Error  

[264/1952]
  < Vary: X-Auth-Token
  < Content-Type: application/json
  < Content-Length: 143
  < X-Openstack-Request-Id: req-f0006f4e-25b5-47ae-acb8-5072967b0778
  < Date: Mon, 14 Mar 2016 21:24:48 GMT
  <
  { [data not shown]
  100   348  100   143  100   205   2097   3007 --:--:-- --:--:-- --:--:--  3059
  * Connection #0 to host 127.0.0.1 left intact
  {
  "error": {
  "code": 500,
  "message": "An unexpected error prevented the server from fulfilling 
your request.",
  "title": "Internal Server Error"
  }
  }

  Attempting to pop attribute that does not exist.
  
https://github.com/openstack/keystone/blob/a2a06d05310ab9bd8d0360a59f769563a1393e03/keystone/catalog/controllers.py#L180

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1557166/+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 1657299] [NEW] Intermittent failures in neutron-fwaas v2 tempest tests

2017-01-17 Thread Nate Johnston

Public bug reported:

Occasionally the neutron-fwaas v2 tempest tests (gate-neutron-fwaas-v2
-dsvm-tempest, gate-neutron-fwaas-v2-dsvm-tempest-multinode-nv, or both)
will fail with the following error on the test
neutron_fwaas.tests.tempest_plugin.tests.api.test_fwaasv2_extensions.FWaaSv2ExtensionTestJSON.test_create_show_delete_firewall_group.

  Captured traceback:
  ~~~
 Traceback (most recent call last):
   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/test_fwaasv2_extensions.py",
 line 127, in _try_delete_firewall_group
 self.firewall_groups_client.delete_firewall_group(fwg_id)
   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/services/v2_client.py",
 line 38, in delete_firewall_group
 return self.delete_resource(uri)
   File "tempest/lib/services/network/base.py", line 41, in delete_resource
 resp, body = self.delete(req_uri)
   File "tempest/lib/common/rest_client.py", line 306, in delete
 return self.request('DELETE', url, extra_headers, headers, body)
   File "tempest/lib/common/rest_client.py", line 663, in request
 self._error_checker(resp, resp_body)
   File "tempest/lib/common/rest_client.py", line 826, in _error_checker
 message=message)
 tempest.lib.exceptions.ServerFault: Got server fault
 Details: Request Failed: internal server error while processing your 
request. 

Example: http://logs.openstack.org/08/421408/1/check/gate-neutron-
fwaas-v2-dsvm-tempest/b55ddb2/console.html#_2017-01-17_18_24_59_724184

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

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

Title:
  Intermittent failures in neutron-fwaas v2 tempest tests

Status in neutron:
  New

Bug description:
  Occasionally the neutron-fwaas v2 tempest tests (gate-neutron-fwaas-v2
  -dsvm-tempest, gate-neutron-fwaas-v2-dsvm-tempest-multinode-nv, or
  both) will fail with the following error on the test
  
neutron_fwaas.tests.tempest_plugin.tests.api.test_fwaasv2_extensions.FWaaSv2ExtensionTestJSON.test_create_show_delete_firewall_group.

Captured traceback:
~~~
   Traceback (most recent call last):
 File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/test_fwaasv2_extensions.py",
 line 127, in _try_delete_firewall_group
   self.firewall_groups_client.delete_firewall_group(fwg_id)
 File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/services/v2_client.py",
 line 38, in delete_firewall_group
   return self.delete_resource(uri)
 File "tempest/lib/services/network/base.py", line 41, in 
delete_resource
   resp, body = self.delete(req_uri)
 File "tempest/lib/common/rest_client.py", line 306, in delete
   return self.request('DELETE', url, extra_headers, headers, body)
 File "tempest/lib/common/rest_client.py", line 663, in request
   self._error_checker(resp, resp_body)
 File "tempest/lib/common/rest_client.py", line 826, in _error_checker
   message=message)
   tempest.lib.exceptions.ServerFault: Got server fault
   Details: Request Failed: internal server error while processing your 
request. 

  Example: http://logs.openstack.org/08/421408/1/check/gate-neutron-
  fwaas-v2-dsvm-tempest/b55ddb2/console.html#_2017-01-17_18_24_59_724184

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657299/+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 1657260] [NEW] Established connection don't stops when rule is removed

2017-01-17 Thread Slawek Kaplonski

Public bug reported:

If iptables driver is used for Security groups (e.g. in Linuxbridge L2 agent) 
there is an issue with update rules. When You have rule which allows some kind 
of traffic (like ssh for example from some src IP address) and You have 
established, active connection which match this rule, connection will be still 
active even if rule will be removed/changed.
It is because in iptables in chain for each SG as first there is rule to accept 
packets with "state RELATED,ESTABLISHED".
I'm not sure if it is in fact bug or maybe it's just design decision to have 
better performance of iptables.

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

Title:
  Established connection don't stops when rule is removed

Status in neutron:
  New

Bug description:
  If iptables driver is used for Security groups (e.g. in Linuxbridge L2 agent) 
there is an issue with update rules. When You have rule which allows some kind 
of traffic (like ssh for example from some src IP address) and You have 
established, active connection which match this rule, connection will be still 
active even if rule will be removed/changed.
  It is because in iptables in chain for each SG as first there is rule to 
accept packets with "state RELATED,ESTABLISHED".
  I'm not sure if it is in fact bug or maybe it's just design decision to have 
better performance of iptables.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657260/+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 1599057] Re: live-migration Interrupt when get network info failed

2017-01-17 Thread Timofey Durakov

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

this is actually the duplicate for 1647451

** This bug has been marked a duplicate of bug 1647451
   Post live migration step could fail due to auth errors

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

Title:
  live-migration Interrupt when get network info failed

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Description
  ===
  When an exception raised by neutron，live migrate will be interrupt and vm 
task_state keep in migrating.

  Steps to reproduce
  ==
  1.Set the Token timeout after 5 minutes.

  2.Login dashboard, and live-migrate an CentOS instance after 4
  minutes(the token will timeout after 1min)

  3.bug reproduced,because of neutronclient  Authentication required
  (token timeout)

  Expected result
  ===
  Instance rollback or directly in error state.

  Actual result
  =
  Live migrate operation stoped，but instance task_state keeping in "migrating"

  Environment
  ===
  version: Mitaka

  hypervisor : Libvirt + KVM

  storage: LVM

  networking type: Neutron with OpenVSwitch

  
  Logs & Configs
  ==
  In source node,nova-compute log as follow:

  2016-07-02 16:14:17.809 10162 INFO nova.compute.manager 
[req-d322c8ac-2d6d-4960-8275-ac6e3f26f7ac ebe821cc991f4657aa3002054739933c 
71acb857b6e34df6bfa2da07b0ce7902 - - -] [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] _post_live_migration() is started..
  2016-07-02 16:14:18.072 10162 WARNING nova.virt.libvirt.driver 
[req-d322c8ac-2d6d-4960-8275-ac6e3f26f7ac ebe821cc991f4657aa3002054739933c 
71acb857b6e34df6bfa2da07b0ce7902 - - -] [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] Error monitoring migration: 
Authentication required
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] Traceback (most recent call last):
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6504, in 
_live_migration
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] dom, finish_event)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 6434, in 
_live_migration_monitor
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] migrate_data)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 88, in wrapped
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] payload)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] six.reraise(self.type_, self.value, 
self.tb)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 71, in wrapped
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] return f(self, context, *args, **kw)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 405, in 
decorated_function
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] kwargs['instance'], e, sys.exc_info())
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] six.reraise(self.type_, self.value, 
self.tb)
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 393, in 
decorated_function
  2016-07-02 16:14:18.072 10162 TRACE nova.virt.libvirt.driver [instance: 
37d55e32-751a-415a-b707-4f54bc06b6b8] return function(self, context, *args, 
**kwargs)
  2016-07-02 16:14:18.072 10162 TRACE

[Yahoo-eng-team] [Bug 1491926] Re: Remove padding from Fernet tokens

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

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

Title:
  Remove padding from Fernet tokens

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

Bug description:
  In bug 1433372, we determined that we should percent encode Fernet
  tokens, because the padding characters (=) aren't considered URL safe
  by some RFCs.

  We also fail some tempest tests because clients sometimes decode or
  encode responses [0]. We should just remove the padding, that way
  clients don't have to worry about it. When we go to validate a token,
  we can determine what the padding is based on the length of the token:

  missing_padding = 4 - len(token) % 4
  if missing_padding:
  token += b'=' * missing_padding

  
  A patch can be proposed to master, stable/liberty, and stable/kilo to ensure 
that Fernet tokens can be validated regardless of padding. This is important to 
consider when upgrading from Kilo to Liberty or Kilo to Mitaka.

  [0] http://cdn.pasteraw.com/es3j52dpfgem4nom62e7vktk7g5u2j1

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1491926/+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 1488208] Re: Revoking a role assignment revokes unscoped tokens too

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

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

Title:
  Revoking a role assignment revokes unscoped tokens too

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

Bug description:
  When you delete a role assignment using a user+role+project pairing,
  unscoped tokens between the user+project are unnecessarily revoked as
  well. In fact, two events are created for each role assignment
  deletion (one that is scoped correctly and one that is scoped too
  broadly).

  The test failure in https://review.openstack.org/#/c/216236/
  illustrates this issue:

http://logs.openstack.org/36/216236/1/check/gate-keystone-
  python27/3f44af1/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1488208/+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 1490804] Re: [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546)

** Changed in: keystone/kilo
   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/1490804

Title:
  [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546)

Status in django-openstack-auth:
  Invalid
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in keystonemiddleware:
  Fix Released
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released
Status in python-keystoneclient:
  Won't Fix

Bug description:
  A keystone token which has been revoked can still be used by manipulating 
particular byte fields within the token.
  When a Keystone token is revoked it is added to the revoked list which stores 
the exact token value. Any API will look at the token to see whether or not it 
should accept a token. By changing a single byte within the token, the 
revocation can be bypassed.  see the testing script [1].

  It is suggested that the revocation should be changed to only check
  the token's inner ID.

  [1] http://paste.openstack.org/show/436516/

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1484237] Re: token revocations not always respected when using fernet tokens

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

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

Title:
  token revocations not always respected when using fernet tokens

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

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1484237/+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 1541621] Re: Invalid fernet X-Subject-Token token should result in 404 instead of 401

** Changed in: keystone/liberty
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/1541621

Title:
Invalid fernet X-Subject-Token token should result in 404 instead of
401

Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) liberty series:
Fix Released

Bug description:
When a scoped fernet token is no longer valid (i.e. all the roles had
been removed from the scope), token validation should result in 404
instead of 401. According to Keystone V3 API spec, 401 is returned
only if X-Auth-Token is invalid [0]. Invalid X-Subject-Token should
yield 404. Furthermore, auth_token middleware only treat 404 as
invalid subject token and cache it accordingly [1]. Improper 401 will
cause unnecessary churn as middleware will repeatedly attempt to re-
authenticate the service user.

To reproduce the problem:

1. get a project scoped token
2. remove all the roles assigned to the user for that project
3. attempt to validate that project-scoped token will result in 401

[0]
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#401-unauthorized
[1]
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_identity.py#L215

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1541621/+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 1527759] Re: Default domain no longer lets keystone tenant-list work

** Changed in: keystone/liberty
   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/1527759

Title:
  Default domain no longer lets keystone tenant-list work

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Won't Fix
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  We recently upgraded from kilo.0 to kilo.2 in our dev environment and
  noticed that keystone tenant-list is always failing for the admin
  user.

  Our config is as follows default domain is tied to read-only ldap
  (AD), a heat domain is created to use for trusts to handle the created
  heatstack users/passwords. Under kilo.0 everything was happy. Under
  kilo0.2 we get the following error:

  keystone tenant-list
  The request you have made requires authentication. (HTTP 401) (Request-ID: 
req-d30289f0-778d-4577-8150-7ddd5438ad9c)

  The main error message is:
  2015-12-16 17:07:36.493 20386 WARNING keystone.common.wsgi [-] Authorization 
failed. Non-default domain is not supported (Disable debug mode to suppress 
these details.) (Disable debug mode to suppress these details.) from 
10.224.48.132

  Looking at the differences between kilo.0 and kilo.2  it seems like:
  
https://github.com/openstack/keystone/commit/9dfad21201251364c6d205e8e79813bfe78e6107
  is the most likely culprit for this regression. However, I have not
  yet been able to test if reverting that change fixes the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1527759/+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 1526976] Re: Any operation without token fails with internal server error for fernet token

** Changed in: keystone/liberty
   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/1526976

Title:
  Any operation without token fails with internal server error for
  fernet token

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  This bug is only for fernet token.  Configure keystone to use fernet
  token. Call any operation without passing a X-Auth-Token. It reports
  500 error. It should throw 401

  e.g curl -X DELEETE $OS_AUTH_URL/v3/projects/https://bugs.launchpad.net/keystone/+bug/1526976/+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 1497461] Re: Fernet tokens fail for some users with LDAP identity backend

** Changed in: keystone/liberty
   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/1497461

Title:
  Fernet tokens fail for some users with LDAP identity backend

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  The following bug fixed most situations where when using Fernet + LDAP 
identify backend.
  https://bugs.launchpad.net/keystone/+bug/1459382

  However, some users have trouble, resulting in a UserNotFound exception in 
the logs with a UUID.  Here's the error:
  2015-09-18 20:04:47.313 12979 WARNING keystone.common.wsgi [-] Could not find 
user: 457269632042726f776e203732363230

  So the issue is this.  The user DN query + filter will return my user as:
 CN=Eric Brown 
72620,OU=PAO_Users,OU=PaloAlto_California_USA,OU=NALA,OU=SITES,OU=Engineering,DC=vmware,DC=com

  Therefore, I have to use CN as the user id attribute.  My user id
  would therefore be "Eric Brown 72620".  The fernet token_formatters.py
  attempts to convert this user id into a UUID.  And in my case that is
  successful.  It results in UUID of 457269632042726f776e203732363230.
  Of course, a user id of 457269632042726f776e203732363230 doesn't exist
  in LDAP, so as a result I get a UserNotFound.  So I don't understand
  why the convert_uuid_bytes_to_hex is ever used in the case of LDAP
  backend.

  For other users, the token_formatters.convert_uuid_bytes_to_hex()
  raises a ValueError and everything works.  Here's an example that
  illustrates the behavior

  >>> import uuid
  >>> uuid_obj = uuid.UUID(bytes='Eric Brown 72620')
  >>> uuid_obj.hex
  '457269632042726f776e203732363230'

  >>> import uuid
  >>> uuid_obj = uuid.UUID(bytes='Your Mama')
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python2.7/uuid.py", line 144, in __init__
  raise ValueError('bytes is not a 16-char string')
  ValueError: bytes is not a 16-char string



  Here's the complete traceback (after adding some additional debug):

  2015-09-18 20:04:47.312 12979 WARNING keystone.common.wsgi [-] EWB Traceback 
(most recent call last):
File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 449, 
in __call__
  response = self.process_request(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 
238, in process_request
  auth_context = self._build_auth_context(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 
218, in _build_auth_context
  token_data=self.token_provider_api.validate_token(token_id))
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 
198, in validate_token
  token = self._validate_token(unique_id)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, 
in decorate
  should_cache_fn)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, 
in get_or_create
  async_creator) as value:
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, 
in __enter__
  return self._enter()
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, 
in _enter
  generated = self._enter_create(createdtime)
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149, 
in _enter_create
  created = self.creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 612, 
in gen_value
  created_value = creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1009, 
in creator
  return fn(*arg, **kw)
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 
261, in _validate_token
  return self.driver.validate_v3_token(token_id)
File 
"/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py", 
line 258, in validate_v3_token
  audit_info=audit_ids)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", 
line 441, in get_token_data
  self._populate_user(token_data, user_id, trust)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", 
line 275, in _populate_user
  user_ref = self.identity_api.get_user(user_id)
File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 
342, in wrapper
  return f(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 
353, in wrapper
  return f(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, 
in decorate
  should_cache_fn)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, 
in get_or_create

[Yahoo-eng-team] [Bug 1555187] Re: keystone fails to start in kilo due to pysaml2 4.0.4 release

** Changed in: keystone/kilo
   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/1555187

Title:
  keystone fails to start in kilo due to pysaml2 4.0.4 release

Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Identity (keystone) kilo series:
  Fix Released

Bug description:
  http://logs.openstack.org/66/278466/8/check/gate-heat-dsvm-functional-
  orig-mysql-
  lbaasv1/26b4f7d/logs/apache/keystone.txt.gz#_2016-03-09_14_12_14_814037

  2016-03-09 14:12:14.807391 mod_wsgi (pid=27348): Exception occurred 
processing WSGI script '/var/www/keystone/main'.
  2016-03-09 14:12:14.807440 Traceback (most recent call last):
  2016-03-09 14:12:14.807474   File "/var/www/keystone/main", line 25, in 

  2016-03-09 14:12:14.807536 application = 
wsgi_server.initialize_application(name)
  2016-03-09 14:12:14.807552   File 
"/opt/stack/new/keystone/keystone/server/wsgi.py", line 51, in 
initialize_application
  2016-03-09 14:12:14.807574 startup_application_fn=loadapp)
  2016-03-09 14:12:14.807586   File 
"/opt/stack/new/keystone/keystone/server/common.py", line 43, in setup_backends
  2016-03-09 14:12:14.807603 res = startup_application_fn()
  2016-03-09 14:12:14.807615   File 
"/opt/stack/new/keystone/keystone/server/wsgi.py", line 48, in loadapp
  2016-03-09 14:12:14.807632 'config:%s' % config.find_paste_config(), name)
  2016-03-09 14:12:14.807643   File 
"/opt/stack/new/keystone/keystone/service.py", line 45, in loadapp
  2016-03-09 14:12:14.807740 controllers.latest_app = deploy.loadapp(conf, 
name=name)
  2016-03-09 14:12:14.807757   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
  2016-03-09 14:12:14.808057 return loadobj(APP, uri, name=name, **kw)
  2016-03-09 14:12:14.808096   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
  2016-03-09 14:12:14.808122 return context.create()
  2016-03-09 14:12:14.808135   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in 
create
  2016-03-09 14:12:14.808152 return self.object_type.invoke(self)
  2016-03-09 14:12:14.808162   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in 
invoke
  2016-03-09 14:12:14.808176 **context.local_conf)
  2016-03-09 14:12:14.808187   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in 
fix_call
  2016-03-09 14:12:14.808277 val = callable(*args, **kw)
  2016-03-09 14:12:14.808300   File 
"/usr/local/lib/python2.7/dist-packages/paste/urlmap.py", line 31, in 
urlmap_factory
  2016-03-09 14:12:14.808447 app = loader.get_app(app_name, 
global_conf=global_conf)
  2016-03-09 14:12:14.808465   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
  2016-03-09 14:12:14.808485 name=name, global_conf=global_conf).create()
  2016-03-09 14:12:14.808494   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
  2016-03-09 14:12:14.808508 APP, name=name, global_conf=global_conf)
  2016-03-09 14:12:14.808516   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
  2016-03-09 14:12:14.808529 global_additions=global_additions)
  2016-03-09 14:12:14.808538   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 562, in 
_pipeline_app_context
  2016-03-09 14:12:14.808552 for name in pipeline[:-1]]
  2016-03-09 14:12:14.808560   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
  2016-03-09 14:12:14.808573 section)
  2016-03-09 14:12:14.808582   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
  2016-03-09 14:12:14.808595 value = import_string(found_expr)
  2016-03-09 14:12:14.808606   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 22, in 
import_string
  2016-03-09 14:12:14.808621 return pkg_resources.EntryPoint.parse("x=" + 
s).load(False)
  2016-03-09 14:12:14.808640   File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2202, 
in load
  2016-03-09 14:12:14.810590 return self.resolve()
  2016-03-09 14:12:14.810636   File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2208, 
in resolve
  2016-03-09 14:12:14.810691 module = __import__(self.module_name, 
fromlist=['__name__'], level=0)
  2016-03-09 14:12:14.810711   File 
"/opt/stack/new/keystone/keystone/contrib/federation/routers.py", line 17, in 

  2016-03-09 14:12:14.810904 from keystone.contrib.federation import 
controllers
  2016-03-09 14:12:14.810929   File

[Yahoo-eng-team] [Bug 1639030] Re: Configure networking based on EC2 metadata source

2017-01-17 Thread Scott Moser

** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

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

Title:
  Configure networking based on EC2 metadata source

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  New

Bug description:
  EC2 metadata[1] presents information regarding network devices (mac,
  name, etc) that would be useful to consume.  Chiefly we could match
  the network device names surfaced in the EC2 UIs (eth0, eth2...)
  rather than using our own enumeration at boot.

  A method to detemermine if we are on an instance in EC2 as been
  published[2] as part of their documentation so we can now do this in
  the EC2 datasource without impacting clouds that have copied that
  datasource.

  The work done for DO datasource[3] would be applicable here as a
  model.

  [1] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
  [2] 
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html
  [3] 
https://git.launchpad.net/cloud-init/commit/?id=9f83bb8e80806d3dd79ba426474dc3c696e19a41

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1639030/+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 1645908] Re: Domain id reference for federated users fails in keystone middleware

Moved to keystonemiddleware project.

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

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

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

Title:
  Domain id reference for federated users fails in keystone middleware

Status in keystonemiddleware:
  New

Bug description:
  Version: Keystone Mitaka

  Keystone middleware expects the domain id field to be set for a user.
  For federated users, the domain id is set to be None and hence causes
  an error during autoscaling of a Heat stack created by SSO user.

  Had to modify _populate_user() function in
  keystone/token/providers/common.py to set a dummy domain id for
  federated users as below to fix this issue:

  # Fix: domain id for federated users is None, so send dummy value.
  # Added is_local user attribute to distinguish local and federated 
users.
  if user_ref.get('is_local'):
  domain = self._get_filtered_domain(user_ref['domain_id'])
  else:
  domain = {
'id': CONF.federation.federated_domain_name,
'name': CONF.federation.federated_domain_name
   }
  # end

  Wondering if this is the right way to resolve the domain reference
  issue for SSO.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1645908/+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 1627749] Re: qos driver api can have better error handling

2017-01-17 Thread Manjeet Singh Bhatia

For networking-odl we have change documentation to configure driver
properly,

** Also affects: networking-odl
   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/1627749

Title:
  qos driver api can have better error handling

Status in networking-odl:
  New
Status in neutron:
  Confirmed

Bug description:
  the current qos (notification) driver api assumes driver methods are async 
and always success.
  however, it might not be the case for some of possible backends.  eg. a 
controller based implementation, where a driver would make a rest api call to 
the backend.

  - currently one of drivers raises an exception, the rest of drivers are 
simply skipped.
it might not be what an api user would expect.

  - whan driver calls end up with an error, the db changes should be reverted, 
or
the resource should be marked "possibly not sync".

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-odl/+bug/1627749/+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 1657210] [NEW] Remove deprecated min_l3_agents_per_router

Public bug reported:

https://review.openstack.org/385604
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

commit dd5aca38f90e1b387837c555e110d825062bfb5a
Author: Assaf Muller 
Date:   Wed Oct 12 15:32:45 2016 -0400

Remove deprecated min_l3_agents_per_router

The option was deprecated [1] for removal in Newton
and is being removed in Ocata.

[1] Deprecated in patch with Gerrit Change-Id of:
I8a5fc74a96c784d474aefe2d9b27eeb66521ca82

DocImpact remove all references to the option.

Change-Id: I3a9195ff6fd18fad9f85cec03a632e7e52d954e7
Closes-Bug: #1555042

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc neutron

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

Title:
  Remove deprecated min_l3_agents_per_router

Status in neutron:
  New

Bug description:
  https://review.openstack.org/385604
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit dd5aca38f90e1b387837c555e110d825062bfb5a
  Author: Assaf Muller 
  Date:   Wed Oct 12 15:32:45 2016 -0400

  Remove deprecated min_l3_agents_per_router
  
  The option was deprecated [1] for removal in Newton
  and is being removed in Ocata.
  
  [1] Deprecated in patch with Gerrit Change-Id of:
  I8a5fc74a96c784d474aefe2d9b27eeb66521ca82
  
  DocImpact remove all references to the option.
  
  Change-Id: I3a9195ff6fd18fad9f85cec03a632e7e52d954e7
  Closes-Bug: #1555042

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657210/+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 1656686] Re: Invalid 'nova-manage image' subcommand in man pages

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

commit e88c0bbb7944bc75d554d7851df282f4de760b91
Author: Matt Riedemann 
Date:   Sun Jan 15 14:17:10 2017 -0500

Remove nova-manage image from man pages

There is no 'nova-manage image' subcommand so this removes
it's reference from the man pages.

Change-Id: Ia918006d58c8d7536c37187c37b8004c6f7d3aac
Closes-Bug: #1656686


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

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

Title:
  Invalid 'nova-manage image' subcommand in man pages

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The man pages for the nova-manage CLI call out an 'image' subcommand
  which doesn't actually exist:

  http://docs.openstack.org/developer/nova/man/nova-manage.html#nova-
  images

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1656686/+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 1657190] [NEW] FWaaS - 'public'(shared) resource is not visible from other projects

2017-01-17 Thread Yushiro FURUKAWA

Public bug reported:

In FWaaS v2, 'public'(equal to shared) resource cannot visible from
other project privilege.

[How to reproduce]
source devstack/openrc admin admin
openstack firewall group create --name public1 --public
source devstack/openrc demo demo
openstack firewall group list

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

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

Title:
  FWaaS - 'public'(shared) resource is not visible from other projects

Status in neutron:
  New

Bug description:
  In FWaaS v2, 'public'(equal to shared) resource cannot visible from
  other project privilege.

  [How to reproduce]
  source devstack/openrc admin admin
  openstack firewall group create --name public1 --public
  source devstack/openrc demo demo
  openstack firewall group list

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657190/+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 1657182] [NEW] FWaaS - default parameter of 'protocol' is wrong

2017-01-17 Thread Yushiro FURUKAWA

Public bug reported:

When creating firewall_rule with no '--protocol' option, 'ICMP' is
selected.  This is actually 'tcp'.


[How to reproduce]

source devstack/openrc admin admin
openstack firewall group rule create --source-port 100:100

Source, destination port are not allowed when protocol is set to ICMP.
Neutron server returns request_ids: ['req-35f28579-aa5d-4744-86d8-cbb2a451cd49']

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


** Tags: fwaas low-hanging-fruit

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

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

Title:
  FWaaS - default parameter of 'protocol' is wrong

Status in neutron:
  New

Bug description:
  When creating firewall_rule with no '--protocol' option, 'ICMP' is
  selected.  This is actually 'tcp'.

  
  [How to reproduce]

  source devstack/openrc admin admin
  openstack firewall group rule create --source-port 100:100

  Source, destination port are not allowed when protocol is set to ICMP.
  Neutron server returns request_ids: 
['req-35f28579-aa5d-4744-86d8-cbb2a451cd49']

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657182/+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 1623488] Re: Documentation needed to clarify how to configure auth_endpoint for image signing

2017-01-17 Thread Alexandra Settle

The documentation for Barbican resides within their own repo.

This does not currently affect the OpenStack manuals project.

I recommend the documentation is updated here: http://docs.openstack.org
/project-install-guide/key-manager/draft/

** Changed in: openstack-manuals
   Status: Confirmed => Opinion

** Also affects: barbican
   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/1623488

Title:
  Documentation needed to clarify how to configure auth_endpoint for
  image signing

Status in Barbican:
  New
Status in OpenStack Compute (nova):
  Confirmed
Status in openstack-manuals:
  Opinion

Bug description:
  Description
  ===
  By default Barbican uses http://localhost:5000/v3 for the auth_endpoint 
(where keystone is). Users should know that this can be changed in nova.conf. 
This will solve the issue of Barbican being unable to connect to Keystone.

  Steps to reproduce
  ==
  If keystone is not on localhost then Barbican will not being able to connect 
to Keystone. Also, using this documentation to create a signed image:

  https://github.com/openstack/glance/blob/master/doc/source/signature.rst

  Then booting the image using 'nova boot'.

  Note: verify_glance_signatures must be set to true in nova.conf

  Expected result
  ===
  Barbican should connect to Keystone to authorize credentials when booting a 
signed image.

  Actual result
  =
  Barbican cannot connect to Keystone and booting a signed image fails.

  Environment
  ===
  This is using the mitaka branch.


  This also happens in Glance:
  https://bugs.launchpad.net/glance/+bug/1620539

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1623488/+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 1657174] [NEW] The filesizeformat() method does not consider the situation like `float('inf')` or EB, ZB and YB.

2017-01-17 Thread liao...@hotmail.com

Public bug reported:

Sometimes the `bytes` may get float('inf'), then it will display
"inf0PB" which will be a misleading for the user. Besides, with the
hardware like storage and mem getting larger, we should consider size
larger than PB like EB, ZB and YB.

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

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

Title:
  The filesizeformat() method does not consider the situation like
  `float('inf')` or EB, ZB and YB.

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Sometimes the `bytes` may get float('inf'), then it will display
  "inf0PB" which will be a misleading for the user. Besides, with the
  hardware like storage and mem getting larger, we should consider size
  larger than PB like EB, ZB and YB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657174/+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 1657153] [NEW] Scheduling of Firewalls

2017-01-17 Thread Reedip

Public bug reported:


Currently Openstack firewalls lack scheduling. Openstack firewalls 
allow a particular rule to be active through-out its lifespan, 
till it is a part of a Firewall.Most firewalls now a days support  
the facility to schedule a policy/rule, so that more variations 
and extended usablitiy can be provided to the user.

Problem Description
===

While efficient in its working, Openstack firewalls do not support Scheduling 
mechanism.When a firewall is created and associated with a router, the rules 
governing the firewall are active the whole time.
However, in order to extend the user support, and to provide a more detailed 
firewall experience, scheduling of the firewall rules is possible. Scheduling 
allows a firewall to be 'Active' for the duration specified, and for the rest 
of the duration, remain 'Passive'.

Use Cases:
a) User creates a firewall rule with no duration specified.
- Scenario : Regression
- User Impact: No change from previous releases. The firewall will operate 
based like it used to earlier, as no duration is defined.

b) User creates a firewall rule with Action in Deny/Accept/Reject for a 
specific time-period.
- Scenario : New
- User Impact: The enforced rules would be active and Deny/Accept/Reject all
the specific packets for the duration specified. After that, the rule would
expire. Packets will not be filtered after the specific duration.For the 
remaining duration,User can create a new rule with a separate action,if 
required.

Limitation
---
Currently Firewall rules can only be scheduled on a daily basis. That is 
because although 'time' module may come pre-packed with iptables, the 'date'
module does not, and therefore day/date wise filtering is currently not 
available in this release.
However, it can be easily added if the date module is released for iptables.

IP Tables allow filteration of Packets based on time, using a 'time' module ,
which is proposed to be used in this patch.

** Affects: neutron
 Importance: Undecided
 Assignee: Reedip (reedip-banerjee)
 Status: New


** Tags: fwaas

** Changed in: neutron
 Assignee: (unassigned) => Reedip (reedip-banerjee)

** Tags added: fwaas

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

Title:
  Scheduling of Firewalls

Status in neutron:
  New

Bug description:
  
  Currently Openstack firewalls lack scheduling. Openstack firewalls 
  allow a particular rule to be active through-out its lifespan, 
  till it is a part of a Firewall.Most firewalls now a days support  
  the facility to schedule a policy/rule, so that more variations 
  and extended usablitiy can be provided to the user.

  Problem Description
  ===

  While efficient in its working, Openstack firewalls do not support Scheduling 
  mechanism.When a firewall is created and associated with a router, the rules 
  governing the firewall are active the whole time.
  However, in order to extend the user support, and to provide a more detailed 
  firewall experience, scheduling of the firewall rules is possible. Scheduling 
  allows a firewall to be 'Active' for the duration specified, and for the rest 
  of the duration, remain 'Passive'.

  Use Cases:
  a) User creates a firewall rule with no duration specified.
  - Scenario : Regression
  - User Impact: No change from previous releases. The firewall will operate 
  based like it used to earlier, as no duration is defined.

  b) User creates a firewall rule with Action in Deny/Accept/Reject for a 
  specific time-period.
  - Scenario : New
  - User Impact: The enforced rules would be active and Deny/Accept/Reject all
  the specific packets for the duration specified. After that, the rule would
  expire. Packets will not be filtered after the specific duration.For the 
  remaining duration,User can create a new rule with a separate action,if 
  required.

  Limitation
  ---
  Currently Firewall rules can only be scheduled on a daily basis. That is 
  because although 'time' module may come pre-packed with iptables, the 'date'
  module does not, and therefore day/date wise filtering is currently not 
  available in this release.
  However, it can be easily added if the date module is released for iptables.

  IP Tables allow filteration of Packets based on time, using a 'time' module ,
  which is proposed to be used in this patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657153/+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 1657137] [NEW] network-ip-availabilities API returns 500 when non-existence network-id is passed

2017-01-17 Thread Hirofumi Ichihara

Public bug reported:

The network-ip-availabilities API returns 500 when non-existence
network-id is passed.

$ curl -g -i -X GET 
http://127.0.0.1:9696/v2.0/network-ip-availabilities/090db2f5-3d0f-41f2-b932-a50d33960bca
 -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
"X-Auth-Token: $TOKEN"
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 150
X-Openstack-Request-Id: req-80ec0a12-d6ee-4cab-8649-070e0a986b2e
Date: Tue, 17 Jan 2017 14:16:59 GMT

{"NeutronError": {"message": "Request Failed: internal server error
while processing your request.", "type": "HTTPInternalServerError",
"detail": ""}}

** Affects: neutron
 Importance: Low
 Assignee: Hirofumi Ichihara (ichihara-hirofumi)
 Status: New


** Tags: api

** Changed in: neutron
 Assignee: (unassigned) => Hirofumi Ichihara (ichihara-hirofumi)

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

** Tags added: api

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

Title:
  network-ip-availabilities API returns 500 when non-existence network-
  id is passed

Status in neutron:
  New

Bug description:
  The network-ip-availabilities API returns 500 when non-existence
  network-id is passed.

  $ curl -g -i -X GET 
http://127.0.0.1:9696/v2.0/network-ip-availabilities/090db2f5-3d0f-41f2-b932-a50d33960bca
 -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
"X-Auth-Token: $TOKEN"
  HTTP/1.1 500 Internal Server Error
  Content-Type: application/json
  Content-Length: 150
  X-Openstack-Request-Id: req-80ec0a12-d6ee-4cab-8649-070e0a986b2e
  Date: Tue, 17 Jan 2017 14:16:59 GMT

  {"NeutronError": {"message": "Request Failed: internal server error
  while processing your request.", "type": "HTTPInternalServerError",
  "detail": ""}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657137/+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 1651126] Re: Update MTU on existing devices

The MTU Considerations page of the Networking Guide[1] will need to be
updated.

[1] http://docs.openstack.org/newton/networking-guide/config-mtu.html

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

** Changed in: openstack-manuals
   Status: New => Confirmed

** Changed in: openstack-manuals
   Importance: Undecided => Medium

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

Title:
  Update MTU on existing devices

Status in neutron:
  New
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/405532
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 5c8dffa7fb6c95a04a7b50c7d6e63c9a2729231b
  Author: Ihar Hrachyshka 
  Date:   Tue Nov 29 22:24:29 2016 +

  Update MTU on existing devices
  
  This patch makes OVS and Linuxbridge interface drivers to set MTU on
  plug() attempt if the device already exists. This helps when network MTU
  changes (which happens after some configuration file changes).
  
  This will allow to update MTU values on agent restart, without the need
  to bind all ports to new nodes, that would involve migrating agents. It
  will also help in case when you have no other nodes to migrate to (in
  single node mode).
  
  Both OVS and Linuxbridge interface drivers are updated.
  
  Other drivers (in-tree IVS as well as 3party drivers) will use the
  default set_mtu implementation, that only warns about the missing
  feature (once per process startup).
  
  DocImpact suggest to restart agents after MTU config changes instead of
rewiring router/DHCP ports.
  
  Related: If438e4816b425e6c5021a55567dcaaa77d1f
  Related: If09eda334cddc74910dda7a4fb498b7987714be3
  Closes-Bug: #1649845
  Change-Id: I3c6d6cb55c5808facec38f87114c2ddf548f05f1

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1651126/+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 1655471] Re: Update MTU on existing devices

Previous versions of the networking guide are not maintained. A bug
already exists[1] to track the change in master.

[1] https://bugs.launchpad.net/openstack-manuals/+bug/1651126

** Changed in: openstack-manuals
   Status: Confirmed => Won't Fix

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

Title:
  Update MTU on existing devices

Status in neutron:
  Invalid
Status in openstack-manuals:
  Won't Fix

Bug description:
  https://review.openstack.org/412462
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 52f31b0ddbb978402f65850bf41ceb409c560d4f
  Author: Ihar Hrachyshka 
  Date:   Tue Nov 29 22:24:29 2016 +

  Update MTU on existing devices
  
  This patch makes OVS and Linuxbridge interface drivers to set MTU on
  plug() attempt if the device already exists. This helps when network MTU
  changes (which happens after some configuration file changes).
  
  This will allow to update MTU values on agent restart, without the need
  to bind all ports to new nodes, that would involve migrating agents. It
  will also help in case when you have no other nodes to migrate to (in
  single node mode).
  
  Both OVS and Linuxbridge interface drivers are updated.
  
  Other drivers (in-tree IVS as well as 3party drivers) will use the
  default set_mtu implementation, that only warns about the missing
  feature (once per process startup).
  
  DocImpact suggest to restart agents after MTU config changes instead of
rewiring router/DHCP ports.
  
  Related: If438e4816b425e6c5021a55567dcaaa77d1f
  Related: If09eda334cddc74910dda7a4fb498b7987714be3
  Closes-Bug: #1649845
  Change-Id: I3c6d6cb55c5808facec38f87114c2ddf548f05f1
  (cherry picked from commit 5c8dffa7fb6c95a04a7b50c7d6e63c9a2729231b)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655471/+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 1657130] [NEW] get_data in DataSourceOpenStack.py can time out if metadata service is slow

2017-01-17 Thread Lars Kellogg-Stedman

Public bug reported:

cloud-init sometimes times out and fails to fetch metadata in the
OpenStack environment when the Controller node is under high workload.

The default timeout value is 5 seconds and it may be too small in some
cases where the Controller node is too busy to respond to the metadata
request  from the instance in time.

There is a 'timeout' configuration setting, as in...

  datasource:
OpenStack:
  timeout: 30

...but this value is not used by the get_data method in
cloudinit/sources/DataSourceOpenStack.py, because get_data is called
from cloudinit/sources/__init__.py with no keyword arguments:

LOG.debug("Seeing if we can get any data from %s", cls)
s = cls(sys_cfg, distro, paths)
if s.get_data():
myrep.message = "found %s data from %s" % (mode, name)
return (s, type_utils.obj_name(cls))

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

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

Title:
  get_data in DataSourceOpenStack.py can time out if metadata service is
  slow

Status in cloud-init:
  New

Bug description:
  cloud-init sometimes times out and fails to fetch metadata in the
  OpenStack environment when the Controller node is under high workload.

  The default timeout value is 5 seconds and it may be too small in some
  cases where the Controller node is too busy to respond to the metadata
  request  from the instance in time.

  There is a 'timeout' configuration setting, as in...

datasource:
  OpenStack:
timeout: 30

  ...but this value is not used by the get_data method in
  cloudinit/sources/DataSourceOpenStack.py, because get_data is called
  from cloudinit/sources/__init__.py with no keyword arguments:

  LOG.debug("Seeing if we can get any data from %s", cls)
  s = cls(sys_cfg, distro, paths)
  if s.get_data():
  myrep.message = "found %s data from %s" % (mode, name)
  return (s, type_utils.obj_name(cls))

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1657130/+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 1657095] [NEW] Failed to upload image to Vmware vcenter backend

2017-01-17 Thread Tzach Shefi

Public bug reported:

Failing to upload images to vmware vcenter backend on Glance Liberty.

Glance Liberty 
python-glance-11.0.1-6.el7ost.noarch
python-glance-store-0.9.1-3.el7ost.noarch
python-glanceclient-1.1.1-2.el7ost.noarch
openstack-glance-11.0.1-6.el7ost.noarch
Vmware vcenter 5.5u3  (VCSA)

Glance config
stores=file,http,vmware (unsure if need to add vmware yes/no?) 
default_store = vsphere

vmware_server_host=x.y.z.w
vmware_server_username=root
vmware_server_password=x
vmware_datastores=dc1:datastore1
vmware_api_insecure=true
vmware_task_poll_interval=5
vmware_store_image_dir=/openstack_glance


Error I get: 
# glance --debug image-create --name test.vmdk --container-format bare 
--disk-format vmdk --file /root/cirros-0.3.4-x86_64-disk.vmdk
Request returned failure status 500.
+--+--+
| Property | Value|
+--+--+
| checksum | None |
| container_format | bare |
| created_at   | 2017-01-17T10:50:40Z |
| disk_format  | vmdk |
| id   | 169ae026-3222-4956-8a14-69309cfa3988 |
| min_disk | 0|
| min_ram  | 0|
| name | test.vmdk|
| owner| f0f5b951090d497daa62c7bf0cc28dd2 |
| protected| False|
| size | None |
| status   | queued   |
| tags | []   |
| updated_at   | 2017-01-17T10:50:40Z |
| virtual_size | None |
| visibility   | private  |
+--+--+
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/glanceclient/shell.py", line 688, in 
main
args.func(client, args)
  File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", line 
98, in func_wrapper
return func(gc, args)
  File "/usr/lib/python2.7/site-packages/glanceclient/v2/shell.py", line 85, in 
do_image_create
do_image_upload(gc, args)
  File "/usr/lib/python2.7/site-packages/glanceclient/v2/shell.py", line 318, 
in do_image_upload
gc.images.upload(args.id, image_data, args.size)
  File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 221, 
in upload
self.http_client.put(url, headers=hdrs, data=body)
  File "/usr/lib/python2.7/site-packages/keystoneclient/adapter.py", line 179, 
in put
return self.request(url, 'PUT', **kwargs)
  File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 
333, in request
return self._handle_response(resp)
  File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 89, 
in _handle_response
raise exc.from_response(resp, resp.content)
HTTPInternalServerError: 500 Internal Server Error: The server has either erred 
or is incapable of performing the requested operation. (HTTP 500)
500 Internal Server Error: The server has either erred or is incapable of 
performing the requested operation. (HTTP 500)

Api.log

2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi   File 
"/usr/lib/python2.7/site-packages/glance_store/backend.py", line 340, in 
store_add_to_backend
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi context=context)
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi   File 
"/usr/lib/python2.7/site-packages/glance_store/capabilities.py", line 226, in 
op_checker
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi return 
store_op_fun(store, *args, **kwargs)
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi   File 
"/usr/lib/python2.7/site-packages/glance_store/_drivers/vmware_datastore.py", 
line 536, in add
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi raise 
exceptions.BackendException(msg)
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi BackendException: Failed 
to upload content of image 169ae026-3222-4956-8a14-69309cfa3988. The request 
returned an unexpected status: 3
01.
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi The response body:
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi None
2017-01-17 12:50:40.754 12199 ERROR glance.common.wsgi 

 
Under vcenter I have a folder called "openstack_glance". 

In the recent releases I noticed when I configure Nova/Cinder with vcenter they 
create a folder under vcenter root called Openstack under which a sub folder 
called: Project (f0f5b951090d497daa62c7bf0cc28dd2) -> Admin tenant's ID. 
Having nothing to lose I also created a sub folder here called 
openstack_glance. 
Tested below two versions as well, same error on image upload.

[Yahoo-eng-team] [Bug 1657090] Re: [RFE]Add bandwidth_limit to vip

** Project changed: neutron => octavia

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

Title:
  [RFE]Add bandwidth_limit to vip

Status in octavia:
  New

Bug description:
  Currently, neutron lbaas and octavia just support connection_limit, but not 
bandwidth_limit. We need support it to make LB more powerful.
  If no bandwidth_limit, the upstream bottleneck of vip will issue the low 
speed in the public cloud, eventhough the backend server is powerful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/octavia/+bug/1657090/+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 1657091] Re: [RFE]Support l4 udp protocol loadbalance

** Project changed: neutron => octavia

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

Title:
  [RFE]Support l4 udp protocol loadbalance

Status in octavia:
  New

Bug description:
  Currently, neutron-lbaas or octavia implemented the haproxy just support 
TCP,HTTP,HTTPS,TERMINATED_HTTPS.
  We need support udp if we want the data flow lb towards this kind protocol or 
requirements.

To manage notifications about this bug go to:
https://bugs.launchpad.net/octavia/+bug/1657091/+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 1657090] [NEW] [RFE]Add bandwidth_limit to vip

Public bug reported:

Currently, neutron lbaas and octavia just support connection_limit, but not 
bandwidth_limit. We need support it to make LB more powerful.
If no bandwidth_limit, the upstream bottleneck of vip will issue the low speed 
in the public cloud, eventhough the backend server is powerful.

** Affects: neutron
 Importance: Undecided
 Assignee: zhaobo (zhaobo6)
 Status: New


** Tags: lbaas

** Changed in: neutron
 Assignee: (unassigned) => zhaobo (zhaobo6)

** Tags added: lbaas

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

Title:
  [RFE]Add bandwidth_limit to vip

Status in neutron:
  New

Bug description:
  Currently, neutron lbaas and octavia just support connection_limit, but not 
bandwidth_limit. We need support it to make LB more powerful.
  If no bandwidth_limit, the upstream bottleneck of vip will issue the low 
speed in the public cloud, eventhough the backend server is powerful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657090/+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 1657089] [NEW] [RFE]Add bandwidth_limit to vip

Public bug reported:

Currently, neutron lbaas and octavia just support connection_limit, but not 
bandwidth_limit. We need support it to make LB more powerful.
If no bandwidth_limit, the upstream bottleneck of vip will issue the low speed 
in the public cloud, eventhough the backend server is powerful.

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

Title:
  [RFE]Add bandwidth_limit to vip

Status in neutron:
  New

Bug description:
  Currently, neutron lbaas and octavia just support connection_limit, but not 
bandwidth_limit. We need support it to make LB more powerful.
  If no bandwidth_limit, the upstream bottleneck of vip will issue the low 
speed in the public cloud, eventhough the backend server is powerful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657089/+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 1657091] [NEW] [RFE]Support l4 udp protocol loadbalance

Public bug reported:

Currently, neutron-lbaas or octavia implemented the haproxy just support 
TCP,HTTP,HTTPS,TERMINATED_HTTPS.
We need support udp if we want the data flow lb towards this kind protocol or 
requirements.

** Affects: neutron
 Importance: Undecided
 Assignee: zhaobo (zhaobo6)
 Status: New


** Tags: lbaas

** Changed in: neutron
 Assignee: (unassigned) => zhaobo (zhaobo6)

** Tags added: lbaas

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

Title:
  [RFE]Support l4 udp protocol loadbalance

Status in neutron:
  New

Bug description:
  Currently, neutron-lbaas or octavia implemented the haproxy just support 
TCP,HTTP,HTTPS,TERMINATED_HTTPS.
  We need support udp if we want the data flow lb towards this kind protocol or 
requirements.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657091/+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 1657087] [NEW] Functional versioned notification test test_create_delete_server_with_instance_update randomly fails

2017-01-17 Thread Matt Riedemann

Public bug reported:

We have some non-deterministic failures in this functional test for
versioned notifications:

http://logs.openstack.org/32/420132/3/check/gate-nova-tox-db-functional-
ubuntu-xenial/0ecd455/console.html#_2017-01-17_03_22_08_097927

2017-01-17 03:22:08.097927 | 
nova.tests.functional.notification_sample_tests.test_instance.TestInstanceNotificationSample.test_create_delete_server_with_instance_update
2017-01-17 03:22:08.097978 | 
---
2017-01-17 03:22:08.097991 | 
2017-01-17 03:22:08.098008 | Captured traceback:
2017-01-17 03:22:08.098026 | ~~~
2017-01-17 03:22:08.098048 | Traceback (most recent call last):
2017-01-17 03:22:08.098098 |   File 
"nova/tests/functional/notification_sample_tests/test_instance.py", line 166, 
in test_create_delete_server_with_instance_update
2017-01-17 03:22:08.098124 | self.assertEqual(7, len(instance_updates))
2017-01-17 03:22:08.098183 |   File 
"/home/jenkins/workspace/gate-nova-tox-db-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 411, in assertEqual
2017-01-17 03:22:08.098223 | self.assertThat(observed, matcher, message)
2017-01-17 03:22:08.098283 |   File 
"/home/jenkins/workspace/gate-nova-tox-db-functional-ubuntu-xenial/.tox/functional/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 498, in assertThat
2017-01-17 03:22:08.098302 | raise mismatch_error
2017-01-17 03:22:08.098328 | testtools.matchers._impl.MismatchError: 7 != 6
2017-01-17 03:22:08.098341 | 
2017-01-17 03:22:08.098353 | 
2017-01-17 03:22:08.098371 | Captured pythonlogging:
2017-01-17 03:22:08.098388 | ~~~
2017-01-17 03:22:08.098838 | 2017-01-17 03:20:02,061 INFO 
[nova.api.openstack] Loaded extensions: ['extensions', 'flavors', 
'image-metadata', 'image-size', 'images', 'ips', 'limits', 'os-admin-actions', 
'os-admin-password', 'os-agents', 'os-aggregates', 
'os-assisted-volume-snapshots', 'os-attach-interfaces', 'os-availability-zone', 
'os-baremetal-nodes', 'os-block-device-mapping', 'os-cells', 'os-certificates', 
'os-cloudpipe', 'os-config-drive', 'os-console-auth-tokens', 
'os-console-output', 'os-consoles', 'os-create-backup', 'os-deferred-delete', 
'os-evacuate', 'os-extended-availability-zone', 
'os-extended-server-attributes', 'os-extended-status', 'os-extended-volumes', 
'os-fixed-ips', 'os-flavor-access', 'os-flavor-extra-specs', 
'os-flavor-manage', 'os-flavor-rxtx', 'os-floating-ip-dns', 
'os-floating-ip-pools', 'os-floating-ips', 'os-floating-ips-bulk', 'os-fping', 
'os-hide-server-addresses', 'os-hosts', 'os-hypervisors', 
'os-instance-actions', 'os-instance-usage-audit-log', 'os
 -keypairs', 'os-lock-server', 'os-migrate-server', 'os-migrations', 
'os-multinic', 'os-multiple-create', 'os-networks', 'os-networks-associate', 
'os-pause-server', 'os-quota-class-sets', 'os-quota-sets', 
'os-remote-consoles', 'os-rescue', 'os-scheduler-hints', 
'os-security-group-default-rules', 'os-security-groups', 
'os-server-diagnostics', 'os-server-external-events', 'os-server-groups', 
'os-server-password', 'os-server-tags', 'os-server-usage', 'os-services', 
'os-shelve', 'os-simple-tenant-usage', 'os-suspend-server', 
'os-tenant-networks', 'os-used-limits', 'os-user-data', 
'os-virtual-interfaces', 'os-volumes', 'server-metadata', 'server-migrations', 
'servers', 'versions']
2017-01-17 03:22:08.099353 | 2017-01-17 03:20:02,598 INFO 
[nova.api.openstack] Loaded extensions: ['extensions', 'flavors', 
'image-metadata', 'image-size', 'images', 'ips', 'limits', 'os-admin-actions', 
'os-admin-password', 'os-agents', 'os-aggregates', 
'os-assisted-volume-snapshots', 'os-attach-interfaces', 'os-availability-zone', 
'os-baremetal-nodes', 'os-block-device-mapping', 'os-cells', 'os-certificates', 
'os-cloudpipe', 'os-config-drive', 'os-console-auth-tokens', 
'os-console-output', 'os-consoles', 'os-create-backup', 'os-deferred-delete', 
'os-evacuate', 'os-extended-availability-zone', 
'os-extended-server-attributes', 'os-extended-status', 'os-extended-volumes', 
'os-fixed-ips', 'os-flavor-access', 'os-flavor-extra-specs', 
'os-flavor-manage', 'os-flavor-rxtx', 'os-floating-ip-dns', 
'os-floating-ip-pools', 'os-floating-ips', 'os-floating-ips-bulk', 'os-fping', 
'os-hide-server-addresses', 'os-hosts', 'os-hypervisors', 
'os-instance-actions', 'os-instance-usage-audit-log', 'os
 -keypairs', 'os-lock-server', 'os-migrate-server', 'os-migrations', 
'os-multinic', 'os-multiple-create', 'os-networks', 'os-networks-associate', 
'os-pause-server', 'os-quota-class-sets', 'os-quota-sets', 
'os-remote-consoles', 'os-rescue', 'os-scheduler-hints', 
'os-security-group-default-rules', 'os-security-groups', 
'os-server-diagnostics', 'os-server-external-events', 'os-server-groups', 
'os-server-password',

[Yahoo-eng-team] [Bug 1657084] [NEW] [RFE]Add time period attribute to firewall_rule

Public bug reported:

The firewall should be configured more navigate or time sensitive. For
many company, in the day time, they may not allow their employers to
access internet or use some "bad" softwares, but in the night, they may
not set the limitation. This is very useful for manager to control data
flowes all day.

For this goal, we need a attribute in firewall_rule, it called
"time/period".

It may like:

name  type   CRUD   default
time/period uuid-str  CR  N/A


This may need a period process to do this work. And need an new API to query 
the time of the rule work, set the period.

** Affects: neutron
 Importance: Undecided
 Assignee: zhaobo (zhaobo6)
 Status: New


** Tags: fwaas

** Changed in: neutron
 Assignee: (unassigned) => zhaobo (zhaobo6)

** Tags added: fwaas

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

Title:
  [RFE]Add time period attribute to firewall_rule

Status in neutron:
  New

Bug description:
  The firewall should be configured more navigate or time sensitive. For
  many company, in the day time, they may not allow their employers to
  access internet or use some "bad" softwares, but in the night, they
  may not set the limitation. This is very useful for manager to control
  data flowes all day.

  For this goal, we need a attribute in firewall_rule, it called
  "time/period".

  It may like:

  name  type   CRUD   default
  time/period uuid-str  CR  N/A

  
  This may need a period process to do this work. And need an new API to query 
the time of the rule work, set the period.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657084/+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 1657071] [NEW] [RFE]Add "log" attribute to firewall_policy