[Yahoo-eng-team] [Bug 1480127] Re: Display the primary project name of the user in user table

2018-04-24 Thread Launchpad Bug Tracker 
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

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

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

Title:
  Display the primary project name of the user in user table

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  In the users panel, the table displaying the primary project name of
  the user will make more sense.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1480127/+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 1742064] Re: Quotas updates in Horizon are validated against current user project usage (rather than targetted project's usage)

2018-04-24 Thread Launchpad Bug Tracker 
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

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

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

Title:
  Quotas updates in Horizon are validated against current user project
  usage (rather than targetted project's usage)

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  Admin project has 10 VMs spawned and project "test" has none. When logged in 
as 'admin', attempt to set "test" project quota to any value less than 10 under 
instances section, results in failure because quotas cannot be set to a value 
that is lower than current used resources.
  This issue is producible in Newton, Ocata and Pike.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1742064/+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 1748168] Re: For tenant user private image are not available in dropdown list when tenant user tries to create volume of of that image which is uploaded by tenant user only and t

2018-04-24 Thread Launchpad Bug Tracker 
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

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

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

Title:
  For tenant user private image are not available in dropdown list when
  tenant user tries to create volume of of that image which is uploaded
  by tenant user only and this operation is possible through command
  line

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  For tenant user private image are not available in dropdown list when
  tenant user tries to create volume out of that image which is uploaded
  by tenant user only but this operation is possible through command
  line.

  Find below steps to reproduce this issue:
  1) login using tenant user(should not have admin rights).
  2) upload image to glance.
  3) Create cinder volume
 1) select volume source image
 2) image which you uploaded using tenant user will not be visible in 
dropdown "Use image as a source" 

  But using command line its possible for tenant user to create cinder
  volume using private image. I believe this feature is missing in
  Horizon GUI

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1748168/+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 1731980] Re: Redirect to login after Authentication completed. without explanation

2018-04-24 Thread Launchpad Bug Tracker 
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

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

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

Title:
  Redirect to login after Authentication completed. without explanation

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  Using current master and a Newton Keystone v3 Horizon is stuck on
  login page.

  LOGGING set to debug:

  
  2017-11-13 16:54:01,304 DEBUG openstack_auth.backend backend: Beginning user 
authentication
  2017-11-13 16:54:01,305 DEBUG openstack_auth.plugin.password password: 
Attempting to authenticate for cloud_admin
  2017-11-13 16:54:01,947 DEBUG openstack_auth.backend backend: Authentication 
completed.
  2017-11-13 16:54:01,948 INFO openstack_auth.forms forms: Login successful for 
user "cloud_admin", remote address 127.0.0.1.
  2017-11-13 16:54:01,951 INFO horizon.operation_log operation_log: [127.0.0.1] 
[None] [None] [cloud_admin] [a5fd590f97ed41bebd2250973b12f49a] [cloud_admin] 
[x] [https] [/auth/login/] [/auth/login/] [None] [POST] [302] 
[{"fake_email": "", "username": "cloud_admin", "domain": "cloud_admin", 
"fake_password": "", "region": "http://172.29.236.9:35357/v3;, "next": "/", 
"csrfmiddlewaretoken": "xxxyy", "password": ""}]

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1731980/+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 1760322] Re: Traits not synced if first retrieval fails

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/558068
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=e2924ba2379adc19e7ebd07ead8efd5e9c8e367d
Submitter: Zuul
Branch:master

commit e2924ba2379adc19e7ebd07ead8efd5e9c8e367d
Author: Eric Fried 
Date:   Sat Mar 31 11:42:52 2018 -0500

Use an independent transaction for _trait_sync

Provides a fix for the referenced bug by using an independent
transaction for the _trait_sync method, meaning it gets committed right
away regardless of what happens in the calling scope.

Change-Id: Ie9731d0df8cf52acdc7a442316a35798a4fed4cb
Closes-Bug: 1760322


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

Title:
  Traits not synced if first retrieval fails

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  If the first trait you try to retrieve from placement doesn't exist,
  traits are not synced from os_traits into the database, so it winds up
  empty.

  try:
  rp_obj.Trait.get_by_name(self.ctx, 'CUSTOM_GOLD')
  except exception.TraitNotFound:
  pass
  rp_obj.Trait.get_by_name(self.ctx, os_traits.HW_CPU_X86_AVX2)  # <== 
raises TraitNotFound

  I *think* what's happening is this:

  1@staticmethod
  2@db_api.api_context_manager.writer  # trait sync can cause a write
  3def _get_by_name_from_db(context, name):
  4_ensure_trait_sync(context)
  5result = context.session.query(models.Trait).filter_by(
  6name=name).first()
  7if not result:
  8raise exception.TraitNotFound(names=name)
  9return result

  Line 4 "succeeds" and sets _TRAITS_SYNCED = True.
  But because line 8 raises, the transaction is rolled back.  Database stays 
empty.
  Subsequent retrieval attempts see _TRAITS_SYNCED == True so don't try to 
resync.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1760322/+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 1766711] Re: cloud-init missing dependency on iproute2

2018-04-24 Thread Scott Moser 
** Also affects: cloud-init
   Importance: Undecided
   Status: New

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

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

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

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

Title:
  cloud-init missing dependency on iproute2

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

Bug description:
  cloud-init is not marking a dependency on iproute2.
  It needs iproute2 or nettools to rename devices.

  It was assumed that cloud-init would have dependencies of 'ubuntu-
  minimal', but some official ubuntu-minimal images do not have ubuntu-
  minimal.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: cloud-init 18.2-14-g6d48d265-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  ApportVersion: 2.20.9-0ubuntu6
  Architecture: amd64
  CloudName: LXD
  Date: Tue Apr 24 19:48:48 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)
  user_data.txt:
   #cloud-config
   {}

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1766711/+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 1766705] Re: field.tags not recognized

2018-04-24 Thread Brian Rosmaita 
** Project changed: glance => openstack-doc-tools

** Changed in: openstack-doc-tools
 Assignee: (unassigned) => Brian Rosmaita (brian-rosmaita)

** Summary changed:

- field.tags not recognized
+ openstackdocstheme: field.tags not recognized

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

Title:
  openstackdocstheme: field.tags not recognized

Status in openstack-doc-tools:
  New

Bug description:
  This is a test from the api-ref generated on patch 547714.  The URL is
  below, you can see that it has a field.tags specification, but that
  field does not appear to be populated when a bug is filed.

  
https://bugs.launchpad.net/glance/+filebug?field.title=Image%20Service%20API%20v2%20(CURRENT)%20in%20glance=%0A%0A%0AThis%20bug%20tracker%20is%20for%20errors%20with%20the%20documentation,%20use%20the%20following%20as%20a%20template%20and%20remove%20or%20add%20fields%20as%20you%20see%20fit.%20Convert%20[%20]%20into%20[x]%20to%20check%20boxes:%0A%0A-%20[%20]%20This%20doc%20is%20inaccurate%20in%20this%20way:%20__%0A-%20[%20]%20This%20is%20a%20doc%20addition%20request.%0A-%20[%20]%20I%20have%20a%20fix%20to%20the%20document%20that%20I%20can%20paste%20below%20including%20example:%20input%20and%20output.%20%0A%0AIf%20you%20have%20a%20troubleshooting%20or%20support%20issue,%20use%20the%20following%20%20resources:%0A%0A%20-%20Ask%20OpenStack:%20http://ask.openstack.org%0A%20-%20The%20mailing%20list:%20http://lists.openstack.org%0A%20-%20IRC:%20%27openstack%27%20channel%20on%20Freenode%0A%0A---%0ARelease:%20%20on%202018-04-23%2012:43%0ASHA:%205e2df55f04af52af5d7f49f8d04e2b939ed9a57f%0ASource:%20https://git.openstack.org/cgit/openstack/glance/tree
  /api-
  ref/source/v2/index.rst%0AURL:%20http://logs.openstack.org/14/547714/4/check
  /build-openstack-api-ref/b963253/html/v2/index.html#images
  =api-ref

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-doc-tools/+bug/1766705/+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 1766701] [NEW] Trunk Tests are failing often in dvr-multinode scenario job

2018-04-24 Thread Slawek Kaplonski 
Public bug reported:

In about 40% of test runs tests like:
neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_trunk_subport_lifecycle,
 example runs:
* 
http://logs.openstack.org/03/560703/7/check/neutron-tempest-plugin-dvr-multinode-scenario/1f67afd/logs/testr_results.html.gz
* 
http://logs.openstack.org/17/553617/19/check/neutron-tempest-plugin-dvr-multinode-scenario/a13a6fd/logs/testr_results.html.gz
* 
http://logs.openstack.org/84/533284/5/check/neutron-tempest-plugin-dvr-multinode-scenario/1c09aa6/logs/testr_results.html.gz

neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_subport_connectivity, 
example run:
* 
http://logs.openstack.org/90/545490/9/check/neutron-tempest-plugin-dvr-multinode-scenario/c1ed535/logs/testr_results.html.gz


are failing.

** Affects: neutron
 Importance: High
 Status: Confirmed


** Tags: gate-failure l3-dvr-backlog trunk

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

Title:
  Trunk Tests are failing often in dvr-multinode scenario job

Status in neutron:
  Confirmed

Bug description:
  In about 40% of test runs tests like:
  
neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_trunk_subport_lifecycle,
 example runs:
  * 
http://logs.openstack.org/03/560703/7/check/neutron-tempest-plugin-dvr-multinode-scenario/1f67afd/logs/testr_results.html.gz
  * 
http://logs.openstack.org/17/553617/19/check/neutron-tempest-plugin-dvr-multinode-scenario/a13a6fd/logs/testr_results.html.gz
  * 
http://logs.openstack.org/84/533284/5/check/neutron-tempest-plugin-dvr-multinode-scenario/1c09aa6/logs/testr_results.html.gz

  
neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_subport_connectivity, 
example run:
  * 
http://logs.openstack.org/90/545490/9/check/neutron-tempest-plugin-dvr-multinode-scenario/c1ed535/logs/testr_results.html.gz

  
  are failing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1766701/+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 1763741] Re: Policy docs for os_compute_api:os-flavor-extra-specs:index don't include 2.47 and 2.61 usage

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/561404
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=d435f2f03ffe6cb473c516b4d21027c706467d59
Submitter: Zuul
Branch:master

commit d435f2f03ffe6cb473c516b4d21027c706467d59
Author: Matt Riedemann 
Date:   Sat Apr 14 08:42:58 2018 -0400

Update os_compute_api:os-flavor-extra-specs:index docs for 2.61

The 2.61 microversion relies on this policy rule to determine
if extra specs should be included directly in responses for
the flavor resource directly, specifically showing flavor details,
updating the description of a flavor, and creating a new flavor.

Change-Id: I8d8bc5c74f9eb9a4c36418d36990cf6db78af061
Closes-Bug: #1763741


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

Title:
  Policy docs for os_compute_api:os-flavor-extra-specs:index don't
  include 2.47 and 2.61 usage

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Confirmed
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  Looking at:

  https://docs.openstack.org/nova/latest/configuration/policy.html

  It doesn't mention that os_compute_api:os-flavor-extra-specs:index is
  used by other APIs for 2.47 and 2.61. Specifically:

  2.47:

  GET /servers/{server_id}
  GET /servers/detail
  PUT /servers/{server_id}
  POST /servers/{server_id} (rebuild)

  2.61:

  GET /flavors/{flavor_id}
  GET /flavors/detail
  PUT /flavors/{flavor_id}
  POST /flavors

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1763741/+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 1766703] [NEW] Rally tests job is reaching job timeout often

2018-04-24 Thread Slawek Kaplonski 
Public bug reported:

In about 20-30% of runs neutron-rally-neutron job fails because global job's 
timeout is reached.
Example failed runs: 
* 
http://logs.openstack.org/24/558724/11/check/neutron-rally-neutron/d891678/job-output.txt.gz
* 
http://logs.openstack.org/90/545490/9/check/neutron-rally-neutron/9de921a/job-output.txt.gz

** Affects: neutron
 Importance: High
 Status: Confirmed


** Tags: gate-failure

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

Title:
  Rally tests job is reaching job timeout often

Status in neutron:
  Confirmed

Bug description:
  In about 20-30% of runs neutron-rally-neutron job fails because global job's 
timeout is reached.
  Example failed runs: 
  * 
http://logs.openstack.org/24/558724/11/check/neutron-rally-neutron/d891678/job-output.txt.gz
  * 
http://logs.openstack.org/90/545490/9/check/neutron-rally-neutron/9de921a/job-output.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1766703/+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 1766702] [NEW] Periodic job * neutron-dynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4 fails

2018-04-24 Thread Slawek Kaplonski 
Public bug reported:

Periodic job neutron-dynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4 
is failing all the time since about 21.04.2018.
Example log from failed run: 
http://logs.openstack.org/periodic/git.openstack.org/openstack/neutron-dynamic-routing/master/neutron-dynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4/708499c/job-output.txt.gz
 

Possible culprit: https://review.openstack.org/#/c/560465/ but I didn’t
check it deeply so it might be only trigger for some other failure in
fact.

** Affects: neutron
 Importance: High
 Status: Confirmed


** Tags: gate-failure

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

Title:
  Periodic job * neutron-dynamic-routing-dsvm-tempest-with-ryu-master-
  scenario-ipv4 fails

Status in neutron:
  Confirmed

Bug description:
  Periodic job 
neutron-dynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4 is failing 
all the time since about 21.04.2018.
  Example log from failed run: 
http://logs.openstack.org/periodic/git.openstack.org/openstack/neutron-dynamic-routing/master/neutron-dynamic-routing-dsvm-tempest-with-ryu-master-scenario-ipv4/708499c/job-output.txt.gz
 

  Possible culprit: https://review.openstack.org/#/c/560465/ but I
  didn’t check it deeply so it might be only trigger for some other
  failure in fact.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1766702/+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 1766705] [NEW] field.tags not recognized

2018-04-24 Thread Brian Rosmaita 
Public bug reported:

This is a test from the api-ref generated on patch 547714.  The URL is
below, you can see that it has a field.tags specification, but that
field does not appear to be populated when a bug is filed.

https://bugs.launchpad.net/glance/+filebug?field.title=Image%20Service%20API%20v2%20(CURRENT)%20in%20glance=%0A%0A%0AThis%20bug%20tracker%20is%20for%20errors%20with%20the%20documentation,%20use%20the%20following%20as%20a%20template%20and%20remove%20or%20add%20fields%20as%20you%20see%20fit.%20Convert%20[%20]%20into%20[x]%20to%20check%20boxes:%0A%0A-%20[%20]%20This%20doc%20is%20inaccurate%20in%20this%20way:%20__%0A-%20[%20]%20This%20is%20a%20doc%20addition%20request.%0A-%20[%20]%20I%20have%20a%20fix%20to%20the%20document%20that%20I%20can%20paste%20below%20including%20example:%20input%20and%20output.%20%0A%0AIf%20you%20have%20a%20troubleshooting%20or%20support%20issue,%20use%20the%20following%20%20resources:%0A%0A%20-%20Ask%20OpenStack:%20http://ask.openstack.org%0A%20-%20The%20mailing%20list:%20http://lists.openstack.org%0A%20-%20IRC:%20%27openstack%27%20channel%20on%20Freenode%0A%0A---%0ARelease:%20%20on%202018-04-23%2012:43%0ASHA:%205e2df55f04af52af5d7f49f8d04e2b939ed9a57f%0ASource:%20https://git.openstack.org/cgit/openstack/glance/tree
/api-
ref/source/v2/index.rst%0AURL:%20http://logs.openstack.org/14/547714/4/check
/build-openstack-api-ref/b963253/html/v2/index.html#images
=api-ref

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  field.tags not recognized

Status in Glance:
  New

Bug description:
  This is a test from the api-ref generated on patch 547714.  The URL is
  below, you can see that it has a field.tags specification, but that
  field does not appear to be populated when a bug is filed.

  
https://bugs.launchpad.net/glance/+filebug?field.title=Image%20Service%20API%20v2%20(CURRENT)%20in%20glance=%0A%0A%0AThis%20bug%20tracker%20is%20for%20errors%20with%20the%20documentation,%20use%20the%20following%20as%20a%20template%20and%20remove%20or%20add%20fields%20as%20you%20see%20fit.%20Convert%20[%20]%20into%20[x]%20to%20check%20boxes:%0A%0A-%20[%20]%20This%20doc%20is%20inaccurate%20in%20this%20way:%20__%0A-%20[%20]%20This%20is%20a%20doc%20addition%20request.%0A-%20[%20]%20I%20have%20a%20fix%20to%20the%20document%20that%20I%20can%20paste%20below%20including%20example:%20input%20and%20output.%20%0A%0AIf%20you%20have%20a%20troubleshooting%20or%20support%20issue,%20use%20the%20following%20%20resources:%0A%0A%20-%20Ask%20OpenStack:%20http://ask.openstack.org%0A%20-%20The%20mailing%20list:%20http://lists.openstack.org%0A%20-%20IRC:%20%27openstack%27%20channel%20on%20Freenode%0A%0A---%0ARelease:%20%20on%202018-04-23%2012:43%0ASHA:%205e2df55f04af52af5d7f49f8d04e2b939ed9a57f%0ASource:%20https://git.openstack.org/cgit/openstack/glance/tree
  /api-
  ref/source/v2/index.rst%0AURL:%20http://logs.openstack.org/14/547714/4/check
  /build-openstack-api-ref/b963253/html/v2/index.html#images
  =api-ref

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1766705/+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 1733377] Re: l3_ext_ha_mode extension is not documented in api-ref

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/563570
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=6b0a599b98df4912ac0fcbc34f4fe43ba236e4bf
Submitter: Zuul
Branch:master

commit 6b0a599b98df4912ac0fcbc34f4fe43ba236e4bf
Author: Michal Kelner Mishali 
Date:   Mon Apr 23 13:55:26 2018 +0300

Document L3 HA extension

Adding description of l3-ext-ha-mode in routers docs

Closes-Bug: #1733377

Change-Id: I7adb2c5ddd65aeb20a6a911c6965edcf0ebf38fd
Signed-off-by: Michal Kelner Mishali 


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

Title:
  l3_ext_ha_mode extension is not documented in api-ref

Status in neutron:
  Fix Released

Bug description:
  The l3_ext_ha_mode extension is not documented in our api-ref:
  - The routers api-ref needs a subsection atop it describing the extension.
  - Any params added by the extension also need to be doc'd therein.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1733377/+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 1766692] [NEW] instance.uuid no longer being a str breaks powervm scsi disconnect

2018-04-24 Thread Eric Fried 
Public bug reported:

Long-standing code in pypowervm [1] used isinstance(..., str) to help
identify whether an input was a UUID or an integer short ID.  This is
used with to find SCSI mappings [2] with Instance.uuid [3] when
disconnecting a disk during destroy [4].

Then this change in oslo.versionedobjects happened [5], resulting in
instance.uuid no longer being a str.  So the check at [1] fails, and we
try to int() a UUID string, resulting in [6], pasted here in case that
link expires:

PowerVM error destroying instance.: ValueError: invalid literal for int() with 
base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA'
 Traceback (most recent call last):
   File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 
672, in _destroy
 _setup_flow_and_run()
   File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 
668, in _setup_flow_and_run
 tf_base.run(flow, instance=instance)
   File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/base.py", line 
40, in run
 return eng.run()
   File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py",
 line 247, in run
 for _state in self.run_iter(timeout=timeout):
   File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/engine.py",
 line 340, in run_iter
 failure.Failure.reraise_if_any(er_failures)
   File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", 
line 336, in reraise_if_any
 failures[0].reraise()
   File "/usr/local/lib/python2.7/dist-packages/taskflow/types/failure.py", 
line 343, in reraise
 six.reraise(*self._exc_info)
   File 
"/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py",
 line 53, in _execute_task
 result = task.execute(**arguments)
   File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/tasks/storage.py", 
line 452, in execute
 self.instance, stg_ftsk=self.stg_ftsk, disk_type=self.disk_type)
   File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/disk/ssp.py", line 
174, in disconnect_disk
 match_func=match_func)
   File 
"/usr/local/lib/python2.7/dist-packages/pypowervm/tasks/scsi_mapper.py", line 
503, in find_maps
 is_uuid, client_id = uuid.id_or_uuid(client_lpar_id)
   File "/usr/local/lib/python2.7/dist-packages/pypowervm/utils/uuid.py", line 
55, in id_or_uuid
 ret_id = int(an_id)
 ValueError: invalid literal for int() with base 10: 
'4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA'

(Okay, our bad for using str at all - though to be fair, it's possible
that code predates the very existence of py3.)

The right fix is for [1] to use is_uuid_like from oslo.utils.  This
shall be done.  However, since [5] was backported to queens and pike,
unless we can get away with backporting requirements changes, we may
have to do something backportable in nova-powervm and nova as well.

[1] 
https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/utils/uuid.py#L50
[2] 
https://github.com/powervm/pypowervm/blob/release/1.1.14/pypowervm/tasks/scsi_mapper.py#L503
[3] 
https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/disk/ssp.py#L128
[4] 
https://github.com/openstack/nova/blob/1605391084d6a1f57384ef48bad8ca2185cf6fa7/nova/virt/powervm/driver.py#L272
[5] https://review.openstack.org/#/q/Ic6b6308fb1960ec40407e6efde30137b64543e72
[6] 
http://184.172.12.213/58/557958/10/check/nova-out-of-tree-pvm/c1d7e99/logs/n-cpu.txt.gz?#_Apr_20_08_51_16_452651

** Affects: nova
 Importance: Undecided
 Status: New

** Affects: nova-powervm
 Importance: Undecided
 Status: New

** Affects: pypowervm
 Importance: Undecided
 Status: New

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

** Also affects: pypowervm
   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/1766692

Title:
  instance.uuid no longer being a str breaks powervm scsi disconnect

Status in OpenStack Compute (nova):
  New
Status in nova-powervm:
  New
Status in pypowervm:
  New

Bug description:
  Long-standing code in pypowervm [1] used isinstance(..., str) to help
  identify whether an input was a UUID or an integer short ID.  This is
  used with to find SCSI mappings [2] with Instance.uuid [3] when
  disconnecting a disk during destroy [4].

  Then this change in oslo.versionedobjects happened [5], resulting in
  instance.uuid no longer being a str.  So the check at [1] fails, and
  we try to int() a UUID string, resulting in [6], pasted here in case
  that link expires:

  PowerVM error destroying instance.: ValueError: invalid literal for int() 
with base 10: '4E27E1E6-6A24-4F0A-8E7B-2BBE7B4A28BA'
   Traceback (most recent call last):
 File "/opt/stack/nova-powervm/nova_powervm/virt/powervm/driver.py", line 
672, in _destroy

[Yahoo-eng-team] [Bug 1766676] [NEW] command: [openstack compute service list --service nova-compute] failed on ubuntu

2018-04-24 Thread Leo Liu 
Public bug reported:

In https://docs.openstack.org/keystone/queens/install/index-ubuntu.html
use port 5000 not use the port 35357

But in 
https://docs.openstack.org/nova/queens/install/controller-install-ubuntu.html
and https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html
config the 35357 in /etc/nova/nova.conf

So in https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html
when execute command [openstack compute service list --service nova-compute] 
failed.

Error In /var/log/nova/nova-api.log is below:
Failed to discover available identity versions when contacting 
http://controller:35357.



---
Release: 17.0.3.dev27 on 2018-04-20 00:22
SHA: bf0a0697734b204e9c64df834895d46382a2cc3c
Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/compute-install-ubuntu.rst
URL: https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  command: [openstack compute service list --service nova-compute]
  failed on ubuntu

Status in OpenStack Compute (nova):
  New

Bug description:
  In https://docs.openstack.org/keystone/queens/install/index-
  ubuntu.html use port 5000 not use the port 35357

  But in 
https://docs.openstack.org/nova/queens/install/controller-install-ubuntu.html
  and https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html
  config the 35357 in /etc/nova/nova.conf

  So in 
https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html
  when execute command [openstack compute service list --service nova-compute] 
failed.

  Error In /var/log/nova/nova-api.log is below:
  Failed to discover available identity versions when contacting 
http://controller:35357.




  ---
  Release: 17.0.3.dev27 on 2018-04-20 00:22
  SHA: bf0a0697734b204e9c64df834895d46382a2cc3c
  Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/compute-install-ubuntu.rst
  URL: 
https://docs.openstack.org/nova/queens/install/compute-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1766676/+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 1739646] Re: Instance type with disk set to 0 can cause DoS

2018-04-24 Thread Jeremy Stanley 
Sounds like we've got consensus on class B1, so I'll mark the OSSA task
won't fix, add a new OSSN task, switch the bug type to just public
rather than public security and add the security bugtag instead.

** Information type changed from Public Security to Public

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

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

** Tags added: security

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

Title:
  Instance type with disk set to 0 can cause DoS

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  In Progress
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  In OpenStack at the moment, there is the ability to create instance
  types with disk size 0.  The API documentation states the following:

  "The size of the root disk that will be created in GiB. If 0 the root
  disk will be set to exactly the size of the image used to deploy the
  instance. However, in this case filter scheduler cannot select the
  compute host based on the virtual image size. Therefore, 0 should only
  be used for volume booted instances or for testing purposes."

  In a cloud environment where a deployer wants to offer boot-from-
  volume instances, those instance types will be there.  However, this
  means that a user can upload an image of 4TB and boot small instances
  where each one will have 4TB of storage, potentially exhausting the
  disks local storage (or Ceph cluster if using Ceph for ephemeral
  storage).

  I'm not sure if this is a security issue or it should be published as
  an advisory, but I believe there should be an option to disable the
  feature of booting an instance with the exact size of the image used
  so deployers have the ability/choice to provide boot-from-volume
  instance types.

  I can confirm this in our environment that if a customer creates an
  instance with 200GB of ephemeral disk space, they can take an image of
  it, then create an instance with that image on an instance type that
  has no ephemeral disk space and get 200GB of disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1739646/+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 1766668] [NEW] 'image_source' should not be required for Ironic boot from volume

2018-04-24 Thread Guang Yee 
Public bug reported:

Description
===
When configure Ironic to boot from volume, 'openstack baremetal node validate 
$NODE_UUID' still fails with something like "Cannot validate image information 
for node 6977c516-976d-456b-9d71-daa56f589302 because one or more parameters 
are missing from its instance_info. Missing are: ['ramdisk', 'kernel', 
'image_source']".

'image_source' should not be required.

Steps to reproduce
==

1. Install devstack with Ironic BFV enabled according to 
https://docs.openstack.org/ironic/pike/contributor/ironic-boot-from-volume.html.
2. source devstack/openrc admin admin
3. export OS_BAREMETAL_API_VERSION=1.34
4. get the baremetal node ID ($NODE_UUID) with 'openstack baremetal node list'
5. run 'openstack baremetal node validate $NODE_UUID'

Expected result
===
Both 'boot' and 'deploy' interfaces to validate, and yield 'True' value.

Actual result
=

| boot   | False  | Cannot validate image information for node 
6977c516-976d-456b-9d71-daa56f589302 because one or more parameters are missing 
from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] |
| console| False  | Missing 'ipmi_terminal_port' parameter in node's 
driver_info.
 |
| deploy | False  | Cannot validate image information for node 
6977c516-976d-456b-9d71-daa56f589302 because one or more parameters are missing 
from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] |


Environment
===
Devstack with Ironic BFV enabled. Ubuntu VM.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: ironic

** Tags added: ironic

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

Title:
  'image_source' should not be required for Ironic boot from volume

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  When configure Ironic to boot from volume, 'openstack baremetal node validate 
$NODE_UUID' still fails with something like "Cannot validate image information 
for node 6977c516-976d-456b-9d71-daa56f589302 because one or more parameters 
are missing from its instance_info. Missing are: ['ramdisk', 'kernel', 
'image_source']".

  'image_source' should not be required.

  Steps to reproduce
  ==

  1. Install devstack with Ironic BFV enabled according to 
https://docs.openstack.org/ironic/pike/contributor/ironic-boot-from-volume.html.
  2. source devstack/openrc admin admin
  3. export OS_BAREMETAL_API_VERSION=1.34
  4. get the baremetal node ID ($NODE_UUID) with 'openstack baremetal node list'
  5. run 'openstack baremetal node validate $NODE_UUID'

  Expected result
  ===
  Both 'boot' and 'deploy' interfaces to validate, and yield 'True' value.

  Actual result
  =

  | boot   | False  | Cannot validate image information for node 
6977c516-976d-456b-9d71-daa56f589302 because one or more parameters are missing 
from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] |
  | console| False  | Missing 'ipmi_terminal_port' parameter in node's 
driver_info.
 |
  | deploy | False  | Cannot validate image information for node 
6977c516-976d-456b-9d71-daa56f589302 because one or more parameters are missing 
from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] |

  
  Environment
  ===
  Devstack with Ironic BFV enabled. Ubuntu VM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/178/+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 1766661] [NEW] 'host' property is missing for Cinder volume connector when boot from volume

2018-04-24 Thread Guang Yee 
Public bug reported:

Description
===
Not sure if this is a bug or by design. But in any case, we need to clarify how 
to the volume connectors are created when boot from volume. According the doc 
(https://docs.openstack.org/ironic/pike/admin/boot-from-volume.html), we need 
to create an iSCSI Qualifying Name (IQN) connector that is unique to the SAN. 
It didn't mention anything else so its gives reader the impression that nothing 
else is required. But the problem is, depending on the Cinder backend driver, 
we also need the 'host' property in the connector. Otherwise, BFV will fail and 
you'll see something similar to this appearing in the Cinder Volume logs.

cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 
hostname = common._safe_hostname(connector['host'])
cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 
KeyError: 'host'
cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 

Looking at the code where the volume connector is created, seems like
the only workaround would be to also create another volume connection of
type 'ip'. See

https://github.com/openstack/nova/blob/stable/pike/nova/virt/ironic/driver.py#L1773

So we ended up creating two connectors, iqn and ip, in order to make the
error go away.

Steps to reproduce
==
1. Configure Ironic to Boot From Volume according to the doc 
(https://docs.openstack.org/ironic/pike/admin/boot-from-volume.html)
2. Configure a Cinder backend (i.e. 3par_iscsi) which requires the 'host' 
property.
3. Attempt to BFV and it will fail. Check the Cinder Volume logs for the 
"KeyError: 'host'" entry.


Expected result
===
BFV should work.

Actual result
=
BFV failed with the "KeyError: 'host'" entry in Cinder Volume log.

Environment
===
1. Install DevStack with Ironic BFV enabled. See 
https://docs.openstack.org/ironic/pike/contributor/ironic-boot-from-volume.html

2. Configure Cinder to use VSA or some backend which request a 'host'.

3. Do BFV

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  'host' property is missing for Cinder volume connector when boot from
  volume

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  Not sure if this is a bug or by design. But in any case, we need to clarify 
how to the volume connectors are created when boot from volume. According the 
doc (https://docs.openstack.org/ironic/pike/admin/boot-from-volume.html), we 
need to create an iSCSI Qualifying Name (IQN) connector that is unique to the 
SAN. It didn't mention anything else so its gives reader the impression that 
nothing else is required. But the problem is, depending on the Cinder backend 
driver, we also need the 'host' property in the connector. Otherwise, BFV will 
fail and you'll see something similar to this appearing in the Cinder Volume 
logs.

  cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 
hostname = common._safe_hostname(connector['host'])
  cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 
KeyError: 'host'
  cinder-volume.log:2018-04-20 21:20:28.543 20455 ERROR cinder.volume.manager 

  Looking at the code where the volume connector is created, seems like
  the only workaround would be to also create another volume connection
  of type 'ip'. See

  
https://github.com/openstack/nova/blob/stable/pike/nova/virt/ironic/driver.py#L1773

  So we ended up creating two connectors, iqn and ip, in order to make
  the error go away.

  Steps to reproduce
  ==
  1. Configure Ironic to Boot From Volume according to the doc 
(https://docs.openstack.org/ironic/pike/admin/boot-from-volume.html)
  2. Configure a Cinder backend (i.e. 3par_iscsi) which requires the 'host' 
property.
  3. Attempt to BFV and it will fail. Check the Cinder Volume logs for the 
"KeyError: 'host'" entry.

  
  Expected result
  ===
  BFV should work.

  Actual result
  =
  BFV failed with the "KeyError: 'host'" entry in Cinder Volume log.

  Environment
  ===
  1. Install DevStack with Ironic BFV enabled. See 
https://docs.openstack.org/ironic/pike/contributor/ironic-boot-from-volume.html

  2. Configure Cinder to use VSA or some backend which request a 'host'.

  3. Do BFV

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/171/+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 1761536] Re: Nova compute manager failed to create virtual interface

2018-04-24 Thread Jason Hobbs 
It seems unlikely that any of those options are to blame, given this
happens 100% of the time on queens and never happens on pike.

** Also affects: charm-neutron-openvswitch
   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/1761536

Title:
  Nova compute manager failed to create virtual interface

Status in OpenStack neutron-gateway charm:
  Invalid
Status in OpenStack neutron-openvswitch charm:
  New
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Rally test scenario: 
NovaServers.boot_server_associate_and_dissociate_floating_ip fails.
  All 5 nova-compute-kvm instances timeout:

  

  Task 2ccf3cf6-c252-4e0f-8fdd-ca58ad819aff has 5 error(s)
  


  TimeoutException: Rally tired waiting 300.00 seconds for Server
  s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to
  become ('ACTIVE') current status BUILD

  Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/rally/task/runner.py", line 
71, in _run_scenario_once
  getattr(scenario_inst, method_name)(**scenario_kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/servers.py",
 line 1116, in run
  server = self._boot_server(image, flavor, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/rally/task/atomic.py", line 
91, in func_atomic_actions
  f = func(self, *args, **kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/utils.py",
 line 86, in _boot_server
  check_interval=CONF.openstack.nova_server_boot_poll_interval
File "/usr/local/lib/python2.7/dist-packages/rally/task/utils.py", line 
252, in wait_for_status
  timeout=timeout)
  TimeoutException: Rally tired waiting 300.00 seconds for Server 
s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to become 
('ACTIVE') current status BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-gateway/+bug/1761536/+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 1766623] [NEW] Neutron port not updated with customised security group

2018-04-24 Thread Janki Chhatbar 
Public bug reported:

I am creating a port and then spawning a VM attached to this port with
customised security group. Security group should also be updated on the
port during VM creation.

$ openstack server create --flavor 1 --image 
341b5f08-43be-4a23-9b8b-277b072c8832 --security-group 
b96e1775-a71c-4289-a29a-78a1e446321e --nic 
port-id=d1c5b4f4-9ed9-42fb-ae25-c497292e46b6 myvm
+-+-+
| Field   | Value   
|
+-+-+
| OS-DCF:diskConfig   | MANUAL  
|
| OS-EXT-AZ:availability_zone | 
|
| OS-EXT-SRV-ATTR:host| None
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | None
|
| OS-EXT-SRV-ATTR:instance_name   | 
|
| OS-EXT-STS:power_state  | NOSTATE 
|
| OS-EXT-STS:task_state   | scheduling  
|
| OS-EXT-STS:vm_state | building
|
| OS-SRV-USG:launched_at  | None
|
| OS-SRV-USG:terminated_at| None
|
| accessIPv4  | 
|
| accessIPv6  | 
|
| addresses   | 
|
| adminPass   | xjyYP7viwHMk
|
| config_drive| 
|
| created | 2018-04-24T11:49:51Z
|
| flavor  | m1.tiny (1) 
|
| hostId  | 
|
| id  | c219edd4-abde-4cb5-87a5-b6c14aac80bd
|
| image   | cirros-0.3.5-x86_64-disk 
(341b5f08-43be-4a23-9b8b-277b072c8832) |
| key_name| None
|
| name| myvm
|
| progress| 0   
|
| project_id  | 00c278d1bc154eb7b42bde6a5c83742c
|
| properties  | 
|
| security_groups | 
name='b96e1775-a71c-4289-a29a-78a1e446321e' |
| status  | BUILD   
|
| updated | 2018-04-24T11:49:52Z
|
| user_id | 034125b1cf114bf1a9f66f6e120abc8c
|
| volumes_attached| 
|
+-+-+

$ openstack port show d1c5b4f4-9ed9-42fb-ae25-c497292e46b6
+---+-+
| Field | Value 
  |
+---+-+
| admin_state_up| UP
  |
| allowed_address_pairs |   
  |
| binding_host_id   |   
  |
| binding_profile   |   
  |
|

[Yahoo-eng-team] [Bug 1765008] Re: Tempest API tests failing for stable/queens branch

2018-04-24 Thread YAMAMOTO Takashi 
i think i misunderstood.
it seems the sim extension "standard-attr-segment" was added to ml2 plugin.
i suspect it should be in the segment service plugin instead.


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

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

Title:
  Tempest API tests failing for stable/queens branch

Status in neutron:
  Confirmed
Status in tripleo:
  In Progress

Bug description:
  neutron-tempest-plugin repo is branchless so same tests are running for 
master and stable/queens neutron code.
  Recently there was new test merged: https://review.openstack.org/#/c/558609/
  and this cause problem like: 
http://logs.openstack.org/47/562147/1/check/neutron-tempest-plugin-api/5596592/logs/testr_results.html.gz
 for stable branches

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1765008/+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 1765008] Re: Tempest API tests failing for stable/queens branch

2018-04-24 Thread YAMAMOTO Takashi 
neutron part of the issue has been fixed

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

** Changed in: neutron
Milestone: None => rocky-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/1765008

Title:
  Tempest API tests failing for stable/queens branch

Status in neutron:
  Confirmed
Status in tripleo:
  In Progress

Bug description:
  neutron-tempest-plugin repo is branchless so same tests are running for 
master and stable/queens neutron code.
  Recently there was new test merged: https://review.openstack.org/#/c/558609/
  and this cause problem like: 
http://logs.openstack.org/47/562147/1/check/neutron-tempest-plugin-api/5596592/logs/testr_results.html.gz
 for stable branches

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1765008/+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 1764685] Re: The performance of list instances with IP filter can be improved

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/539469
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=a3a94cf4ec3c0e41ab2a8a66dfc0e7adca2d2a8e
Submitter: Zuul
Branch:master

commit a3a94cf4ec3c0e41ab2a8a66dfc0e7adca2d2a8e
Author: Kevin_Zheng 
Date:   Wed Jan 31 16:52:53 2018 +0800

Improve performance when list instances with IP filter

When list instances with IP filter, there is no need
to try to get instances from BuildRequest, as building
instances will not have IP address. Skip this db call
can slightly improve performance.

Closes-Bug: #1764685

Change-Id: Ic02206e887e3fea7752d615bbed680510c482097


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

Title:
  The performance of list instances with IP filter can be improved

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  When list instances with IP filter, there is no need
  to try to get instances from BuildRequest, as building
  instances will not have IP address. Skip this db call
  can slightly improve performance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1764685/+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 1759959] Re: api-ref: documentation of address scope extension is missing

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/558863
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=492e5cc6789a3b475cb3a47b13bf5a24b94dee84
Submitter: Zuul
Branch:master

commit 492e5cc6789a3b475cb3a47b13bf5a24b94dee84
Author: Hongbin Lu 
Date:   Wed Apr 4 16:08:30 2018 +

api-ref: document the address scope extension

Change-Id: Ifd8233ae118059aeae28504bc34d2cb8efb1e4e9
Closes-Bug: #1759959


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

Title:
  api-ref: documentation of address scope extension is missing

Status in neutron:
  Fix Released

Bug description:
  There is an address scope API extension defined in neutron-lib
  https://github.com/openstack/neutron-
  lib/blob/master/neutron_lib/api/definitions/address_scope.py , but its
  documentation seems to be missing in API reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1759959/+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 1764390] Re: Replace passing system_metadata to notification functions with instance.system_metadata usage

2018-04-24 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/561724
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=1c36654ad8eadfa4e0fca785b1a8a717de118b50
Submitter: Zuul
Branch:master

commit 1c36654ad8eadfa4e0fca785b1a8a717de118b50
Author: Matt Riedemann 
Date:   Mon Apr 16 16:58:07 2018 -0400

Remove vestigial system_metadata param from info_from_instance()

The system_metadata argument to info_from_instance() was not used
so it's removed in this change, along with all callers of that
method, which goes quite a ways.

Also, the docstring for the system_metadata argument to
notify_usage_exists() is updated since it is passed in one
specific place: rebuild with a new image. In that case, nova-api
saves off the original instance system_metadata before resetting
the system_metadata based on the new image to rebuild, which is
then passed down through nova-conductor and nova-compute where
it eventually gets used to override "image_meta" in the payload
created in info_from_instance(). It's weird, yes, and essentially
means that for legacy versioned notifications, the instance payload
will always contain the image_meta for the instance before it's
rebuilt with the new image, which is something we don't do for
versioned notifications.

Test test_local_delete_without_info_cache is removed since it's
(1) weird in that it is doing mox-like stuff in a mock-based
test and (2) the code it was meant to test from change
Ie0bba032615d3da06cdd95b221beb37a9b8a377d no longer exists.

Change-Id: Ia1820334dcaceca9d7fa874dd7c553fa1c5befec
Closes-Bug: #1764390


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

Title:
  Replace passing system_metadata to notification functions with
  instance.system_metadata usage

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  
  Both notify_usage_exists() [1] and info_from_instance() [2] functions used in 
the notification code path get the system_metadata passed in. Instead we should 
use the instance.system_metadata directly  whenever it is possible.

  [1] 
https://github.com/openstack/nova/blob/57d3b7093259b625672a98b0ff41643175f6cb82/nova/compute/utils.py#L278
  
[2]https://github.com/openstack/nova/blob/57d3b7093259b625672a98b0ff41643175f6cb82/nova/notifications/base.py#L382

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1764390/+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 1761536] Re: Nova compute manager failed to create virtual interface

2018-04-24 Thread Frode Nordahl 
The crashdump shows multiple occurrences of RPC Timeouts in 
neutron-openvswitch-agent.log:
Timeout in RPC method tunnel_sync. Waiting for 54 seconds before next attempt. 
If the server is not down, consider increasing the rpc_response_timeout option 
as Neutron server(s) may be overloaded and unable to respond quickly enough.: 
MessagingTimeout: Timed out waiting for a reply to message ID 
6ecd4578ba6942769d00f39be63017a7

Right before the server build failure this message is logged:
2018-04-05 11:19:04.188 232295 ERROR 
neutron.agent.linux.openvswitch_firewall.firewall 
[req-8b07034a-1536-4fb0-a356-5df4be8a2c8c - - - - -] Initializing unfiltered 
port e84c9f3c-d412-45de-80fc-acf2af4ab56b that does not exist in ovsdb: Port 
e84c9f3c-d412-45de-80fc-acf2af4ab56b is not managed by this agent..: 
OVSFWPortNotFound: Port e84c9f3c-d412-45de-80fc-acf2af4ab56b is not managed by 
this agent.

It seems to me that the Neutron OpenvSwitch Agent on compute node nova-
compute-kvm_4 is out of sync and that the worker-multiplier and/or rpc-
response-timeout config options of the deployment need adjusting.

** Changed in: charm-neutron-gateway
   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/1761536

Title:
  Nova compute manager failed to create virtual interface

Status in OpenStack neutron-gateway charm:
  Invalid
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Rally test scenario: 
NovaServers.boot_server_associate_and_dissociate_floating_ip fails.
  All 5 nova-compute-kvm instances timeout:

  

  Task 2ccf3cf6-c252-4e0f-8fdd-ca58ad819aff has 5 error(s)
  


  TimeoutException: Rally tired waiting 300.00 seconds for Server
  s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to
  become ('ACTIVE') current status BUILD

  Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/rally/task/runner.py", line 
71, in _run_scenario_once
  getattr(scenario_inst, method_name)(**scenario_kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/servers.py",
 line 1116, in run
  server = self._boot_server(image, flavor, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/rally/task/atomic.py", line 
91, in func_atomic_actions
  f = func(self, *args, **kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/utils.py",
 line 86, in _boot_server
  check_interval=CONF.openstack.nova_server_boot_poll_interval
File "/usr/local/lib/python2.7/dist-packages/rally/task/utils.py", line 
252, in wait_for_status
  timeout=timeout)
  TimeoutException: Rally tired waiting 300.00 seconds for Server 
s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to become 
('ACTIVE') current status BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-gateway/+bug/1761536/+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 1766485] [NEW] Support locking user password

2018-04-24 Thread Pavlo Shchelokovskyy 
Public bug reported:

Change https://review.openstack.org/#/c/559438/ (related bug 1755874)
introduced concept of locking user password from changing via self
service in Keystone V3 API.

Horizon should implement support for changing this user option too.

Sibling story for python-openstackclient
https://storyboard.openstack.org/#!/story/2001906

** Affects: horizon
 Importance: Undecided
 Status: New

** Description changed:

  Change https://review.openstack.org/#/c/559438/ (related bug 1755874)
  introduced concept of locking user password from changing via self
  service in Keystone V3 API.
  
- Client interfaces such as Horizon and OpenStack client should implement
- support for changing this user option too.
+ Horizon should implement support for changing this user option too.

** Description changed:

  Change https://review.openstack.org/#/c/559438/ (related bug 1755874)
  introduced concept of locking user password from changing via self
  service in Keystone V3 API.
  
  Horizon should implement support for changing this user option too.
+ 
+ Sibling story for python-openstackclient
+ https://storyboard.openstack.org/#!/story/2001906

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

Title:
  Support locking user password

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Change https://review.openstack.org/#/c/559438/ (related bug 1755874)
  introduced concept of locking user password from changing via self
  service in Keystone V3 API.

  Horizon should implement support for changing this user option too.

  Sibling story for python-openstackclient
  https://storyboard.openstack.org/#!/story/2001906

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