[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: keystone
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

** Changed in: swift
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  In Progress
Status in gce-api:
  Confirmed
Status in Karbor:
  New
Status in OpenStack Identity (keystone):
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in OpenStack Object Storage (swift):
  New
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1633323] [NEW] [available-zone]az cachee in process make mistake

[xhzhf]

Public bug reported:

Description
===
when getting in instance's detail info, AZ info is wrong

Steps to reproduce
==
1.
in nova.conf, set memcached_servers = None

2.current az info:
nova aggregate-list
Id name Availability Zone
1 cas1-agg  cas1
modifiy az info:
nova aggregate-update 1 cas1-agg cas2

3.get instance az info:
nova show ID

 
Expected result
===
AZ info is cas2

Actual result
=
AZ info is not stable.sometimes AZ is cas1, sometimes is cas2

Reason
===
nova-api is multi-processing. When setting memcache server to none, nova-api 
will cache az in process memory. But nova-api processes caches are not 
consistent.
So I suggest nova-api does not cache az info in process memory.
Related file is nova/openstack/common/memorycached.py
Related class is Client.

** Affects: nova
 Importance: Undecided
 Assignee: xhzhf (guoyongxhzhf)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => xhzhf (guoyongxhzhf)

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

Title:
  [available-zone]az cachee in process make mistake

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  when getting in instance's detail info, AZ info is wrong

  Steps to reproduce
  ==
  1.
  in nova.conf, set memcached_servers = None

  2.current az info:
  nova aggregate-list
  Id name Availability Zone
  1 cas1-agg  cas1
  modifiy az info:
  nova aggregate-update 1 cas1-agg cas2

  3.get instance az info:
  nova show ID

   
  Expected result
  ===
  AZ info is cas2

  Actual result
  =
  AZ info is not stable.sometimes AZ is cas1, sometimes is cas2

  Reason
  ===
  nova-api is multi-processing. When setting memcache server to none, nova-api 
will cache az in process memory. But nova-api processes caches are not 
consistent.
  So I suggest nova-api does not cache az info in process memory.
  Related file is nova/openstack/common/memorycached.py
  Related class is Client.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633323/+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 1629227] Re: Floating-ip-creation

[Vishal]

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

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

Title:
  Floating-ip-creation

Status in neutron:
  Opinion

Bug description:
  On network node a floating ip is being created by assigning a range of
  floating ip address to external network pool on routers, where gateway
  addresses and dhcp is disabled, but here neutronclient/v2_0/client.py
  returns an empty list to ceilometer which is wrong it should return a
  floating ip status or something meaningful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1629227/+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 1633288] Re: Projects table extra Enabled column

[OpenStack Infra]

Reviewed:  https://review.openstack.org/383885
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=e483dd047b0466abba13371a6730c2b2ad463354
Submitter: Jenkins
Branch:master

commit e483dd047b0466abba13371a6730c2b2ad463354
Author: Cindy Lu 
Date:   Fri Oct 7 13:32:35 2016 -0700

Project table has an extra Enabled column definition

There are two Enabled column definitions, remove
the one attached to v3 enabled (unrelated to v3 too).

Closes-Bug: #1633288
Change-Id: I8ba74eba843b72ba1d55c5237d2972c45057afb7


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

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

Title:
  Projects table extra Enabled column

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  There are two Enabled column definitions, remove
  the one attached to v3 enabled (unrelated to v3 too).

  Remove.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1633288/+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 1633306] [NEW] Partial HA network causing HA router creation failed (race conditon)

[LIU Yulong]

Public bug reported:

ENV: stable/mitaka，VXLAN
Neutron API: two neutron-servers behind a HA proxy VIP.

Exception log:
[1] http://paste.openstack.org/show/585669/
[2] http://paste.openstack.org/show/585670/

Log [1] shows that the subnet of HA network is concurrently deleted
while a new HA router create API comes. Seems the race conditon
described in this bug is till exists :
https://bugs.launchpad.net/neutron/+bug/1533440

Log [2] has a very strange behavior that those 3 API has a same request-
id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e].

Test scenario:
Just create one HA router for a tenant, and then quickly delete it.

For now, our mitaka ENV use VxLAN as tenant network type. So there is a very 
large range of VNI.
So don't save that, and temporarily solution, we add a new config to decide 
whether delete the HA network every time.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ha

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

Title:
  Partial HA network causing HA router creation failed (race conditon)

Status in neutron:
  New

Bug description:
  ENV: stable/mitaka，VXLAN
  Neutron API: two neutron-servers behind a HA proxy VIP.

  Exception log:
  [1] http://paste.openstack.org/show/585669/
  [2] http://paste.openstack.org/show/585670/

  Log [1] shows that the subnet of HA network is concurrently deleted
  while a new HA router create API comes. Seems the race conditon
  described in this bug is till exists :
  https://bugs.launchpad.net/neutron/+bug/1533440

  Log [2] has a very strange behavior that those 3 API has a same
  request-id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e].

  Test scenario:
  Just create one HA router for a tenant, and then quickly delete it.

  For now, our mitaka ENV use VxLAN as tenant network type. So there is a very 
large range of VNI.
  So don't save that, and temporarily solution, we add a new config to decide 
whether delete the HA network every time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633306/+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 1633296] [NEW] Pecan tempest API test jobs timeout

[Brandon Logan]

Public bug reported:

Looks like its because of a ton of dhcp notifications being sent out.
The problem being that pecan tries to grab the plugins dhcp notifier,
but fails, so it instantiates its own.  This happens for every request,
and when the dhcp notifier is instantiated it subscribes to
notifications.  This means, with pecan instantiating a new dhcp notifier
for every request, the subscriptions keep growing and growing.

** Affects: neutron
 Importance: High
 Assignee: Brandon Logan (brandon-logan)
 Status: Confirmed


** Tags: api

** Changed in: neutron
   Status: New => Confirmed

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

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

Title:
  Pecan tempest API test jobs timeout

Status in neutron:
  Confirmed

Bug description:
  Looks like its because of a ton of dhcp notifications being sent out.
  The problem being that pecan tries to grab the plugins dhcp notifier,
  but fails, so it instantiates its own.  This happens for every
  request, and when the dhcp notifier is instantiated it subscribes to
  notifications.  This means, with pecan instantiating a new dhcp
  notifier for every request, the subscriptions keep growing and
  growing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633296/+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 1633293] [NEW] Deprecation warning when service_providers empty

[Jamie Lennox]

Public bug reported:

When fetching the service_providers the code looks like [1]. So if the 
cfg.CONF.service_providers.service_provider field is empty we will always get a 
deprecation warning even if there is nothing actually configured in the 
neutron_*.conf files.
In the event that you have CONF.fatal_deprecations on this halts the program. 

I'm still going through to see what this value should be, but even if
it's an empty list it shouldn't fail with an incorrect deprecation
warning.

[1]
https://github.com/openstack/neutron/blob/1628fb72f8fbac15110713530728a03e8e4bd0f5/neutron/services/provider_configuration.py#L112-L122

** Affects: neutron
 Importance: Undecided
 Assignee: Jamie Lennox (jamielennox)
 Status: In Progress

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

Title:
  Deprecation warning when service_providers empty

Status in neutron:
  In Progress

Bug description:
  When fetching the service_providers the code looks like [1]. So if the 
cfg.CONF.service_providers.service_provider field is empty we will always get a 
deprecation warning even if there is nothing actually configured in the 
neutron_*.conf files.
  In the event that you have CONF.fatal_deprecations on this halts the program. 

  I'm still going through to see what this value should be, but even if
  it's an empty list it shouldn't fail with an incorrect deprecation
  warning.

  [1]
  
https://github.com/openstack/neutron/blob/1628fb72f8fbac15110713530728a03e8e4bd0f5/neutron/services/provider_configuration.py#L112-L122

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633293/+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 1633288] [NEW] Projects table extra Enabled column

[Cindy Lu]

Public bug reported:

There are two Enabled column definitions, remove
the one attached to v3 enabled (unrelated to v3 too).

Remove.

** Affects: horizon
 Importance: Low
 Assignee: Cindy Lu (clu-m)
 Status: In Progress


** Tags: newton-backport-potential

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

Title:
  Projects table extra Enabled column

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  There are two Enabled column definitions, remove
  the one attached to v3 enabled (unrelated to v3 too).

  Remove.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1633288/+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 1632633] Re: fix some word spelling error

[huyupeng]

** Changed in: neutron
   Status: Invalid => Fix Committed

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

Title:
  fix some word spelling error

Status in neutron:
  Fix Committed

Bug description:
  there are some word spelling error in .py file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1632633/+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 1632633] Re: fix some word spelling error

[Darek Smigiel]

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

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

Title:
  fix some word spelling error

Status in neutron:
  Fix Committed

Bug description:
  there are some word spelling error in .py file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1632633/+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 1632633] Re: fix some word spelling error

[OpenStack Infra]

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

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

Title:
  fix some word spelling error

Status in neutron:
  Fix Committed

Bug description:
  there are some word spelling error in .py file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1632633/+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 1633280] [NEW] need a way to disable anti-spoofing rules and yet keep security groups

[Rui Zang]

Public bug reported:

Basically all NFV use-cases would require this split. The current
approach for NFV is to turn things off and have the VNFs protect
themselves rather than the infra-structure supports security.  Even in
simple deployments, like cloud bursting, you'll need to be able to allow
the customer to control his addressing. The customer might want to do so
by having the router (which does the IPSEC tunnel termination) either
use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6) to control addressing
- as opposed to have openstack control the addressing. In this case, the
VNF only deals with addressing but it has to protect itself without
security groups.

** Affects: neutron
 Importance: Undecided
 Assignee: Rui Zang (rui-zang)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Rui Zang (rui-zang)

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

Title:
  need a way to disable anti-spoofing rules and yet keep security groups

Status in neutron:
  New

Bug description:
  Basically all NFV use-cases would require this split. The current
  approach for NFV is to turn things off and have the VNFs protect
  themselves rather than the infra-structure supports security.  Even in
  simple deployments, like cloud bursting, you'll need to be able to
  allow the customer to control his addressing. The customer might want
  to do so by having the router (which does the IPSEC tunnel
  termination) either use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6)
  to control addressing - as opposed to have openstack control the
  addressing. In this case, the VNF only deals with addressing but it
  has to protect itself without security groups.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633280/+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 1633218] Re: OS_INTERFACE from openrc breaks keystone

[OpenStack Infra]

Reviewed:  https://review.openstack.org/386238
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=276eaf32e22070cb9ab38dc09b84d5c30ebd9138
Submitter: Jenkins
Branch:master

commit 276eaf32e22070cb9ab38dc09b84d5c30ebd9138
Author: David Medberry 
Date:   Thu Oct 13 15:24:30 2016 -0600

OS_INTERFACE was errantly added to the V2 openrc

Change-Id: Id87af991f4efe78efa955c6b71d5fe19dccdb165
Closes-Bug: #1633218


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

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

Title:
  OS_INTERFACE from openrc breaks keystone

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  When doing a "openstack project list" after sourcing the openrc file
  returned in Horizon, many keystone results break (and or are
  truncated.)

  Unsetting "OS_INTERFACE" restores the proper behavior.

  Tested with latest pip of python-openstackclient and python-
  keystoneclient

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1633218/+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 1633249] [NEW] Boot volume creation leaves secondary volume attached to broken server

[iain MacDonnell]

Public bug reported:

Attempt to boot a server with a block device mapping that includes a
boot volume created from an image, plus an existing data volume. If the
boot-volume creation fails, the data volume is left in state "in-use",
attached to the server which is now in "error" state". The user can't
detach the volume because of the server's error state. They can delete
the server, which then leaves the volume apparently attached to a server
that no longer exists. The only way out of this is to ask an
administrator to reset the state of the data volume (this option is not
available to regular users by default policy).

The easiest way to reproduce this is to attempt to create the boot
volume from qcow2 image where the volume size is less than the image
(virtual) size.

 ~$ cinder list
+--+---+--+--+-+--+-+
| ID   | Status| Name | Size | Volume Type 
| Bootable | Attached to |
+--+---+--+--+-+--+-+
| 2e733722-8b19-4bff-bd8d-bb770554582a | available | data | 1| -   
| false| |
+--+---+--+--+-+--+-+

~$ nova boot --flavor m1.large --availability-zone=imot04-1 --block-device 
'id=9e122d18-d7a4-406d-b8f2-446cfddaa7c7,source=image,dest=volume,device=vda,size=5,bootindex=0'
 --block-device 
'id=2e733722-8b19-4bff-bd8d-bb770554582a,source=volume,dest=volume,device=vdb,size=1,bootindex=1'
 ol4
+--+--+
| Property | Value  
  |
+--+--+
| OS-DCF:diskConfig| MANUAL 
  |
| OS-EXT-AZ:availability_zone  | imot04-1   
  |
| OS-EXT-SRV-ATTR:host | -  
  |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | -  
  |
| OS-EXT-SRV-ATTR:instance_name|
  |
| OS-EXT-STS:power_state   | 0  
  |
| OS-EXT-STS:task_state| scheduling 
  |
| OS-EXT-STS:vm_state  | building   
  |
| OS-SRV-USG:launched_at   | -  
  |
| OS-SRV-USG:terminated_at | -  
  |
| accessIPv4   |
  |
| accessIPv6   |
  |
| adminPass| DNTr8MG3kVmC   
  |
| config_drive |
  |
| created  | 2016-10-13T21:54:08Z   
  |
| flavor   | m1.large (4)   
  |
| hostId   |
  |
| id   | 9541b63c-e003-4bcc-bcb8-5c0461522387   
  |
| image| Attempt to boot from volume - no image 
supplied  |
| key_name | -  
  |
| metadata | {} 
  |
| name | ol4
  |
| os-extended-volumes:volumes_attached | [{"id": 
"2e733722-8b19-4bff-bd8d-bb770554582a"}] |
| progress | 0  
  |
| security_groups  | default
  |
| status   | BUILD  
  |
| tenant_id| 66234fea2ccc42398a1ae5300c594d49   
  |
| updated  | 2016-10-13T21:54:08Z   
  |
| user_id  | b2ae6b7bdac142ddb708a3550f61d998   
  |
+--+--+

~$ cinder list
+--+--+--+--+-+--+--+
| ID   | Status   | Name | Size | Volume Type | 
Bootable | Attached to  |

[Yahoo-eng-team] [Bug 1633236] [NEW] If volume detach fails, it cannot be retried and the instance must be rebooted to detach

[melanie witt]

Public bug reported:

There is a problem where if a volume detach fails at the libvirt driver
level for some reason, the volume detach cannot be retried and the
volume cannot be detached until the instance is rebooted.

Currently, a volume detach at the libvirt driver level happens in two
steps:

 1. Detach from the persistent domain (this will affect the instance upon next 
reboot)
 2. Detach from the transient domain (this will affect the running instance)

A detach from a transient domain is a request from the host to the
guest, to detach the volume. The guest can choose to ignore this
request. For example, if the guest has a file open on the volume by some
process, it might ignore the request to detach that volume because it is
busy.

If this scenario occurs, when a user tries a later request to detach the
volume, it will fail with the error:

 libvirtError: invalid argument: no target device 

because the volume was detached from the persistent domain the first
time. Because of this, the volume can only be detached by rebooting the
instance.

The behavior should be changed to detach from the transient domain
first, retrying if necessary, and detach from the persistent domain only
if the detach from the transient domain has succeeded. This way, if the
guest volume is busy and it ignores the detach request, the detach can
be tried again at a later time by the user.

Suggested steps to reproduce:

 1. Boot an instance and attach a volume
 2. Log in to the guest and open a file on that volume in a text editor
 3. Try to detach the volume using 'nova volume-detach' (it should have failed)
 4. Exit the text editor on the guest
 5. Try to detach the volume using 'nova volume-detach' (should get the 'no 
target device' error)

** Affects: nova
 Importance: Undecided
 Assignee: melanie witt (melwitt)
 Status: In Progress


** Tags: libvirt

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

Title:
  If volume detach fails, it cannot be retried and the instance must be
  rebooted to detach

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  There is a problem where if a volume detach fails at the libvirt
  driver level for some reason, the volume detach cannot be retried and
  the volume cannot be detached until the instance is rebooted.

  Currently, a volume detach at the libvirt driver level happens in two
  steps:

   1. Detach from the persistent domain (this will affect the instance upon 
next reboot)
   2. Detach from the transient domain (this will affect the running instance)

  A detach from a transient domain is a request from the host to the
  guest, to detach the volume. The guest can choose to ignore this
  request. For example, if the guest has a file open on the volume by
  some process, it might ignore the request to detach that volume
  because it is busy.

  If this scenario occurs, when a user tries a later request to detach
  the volume, it will fail with the error:

   libvirtError: invalid argument: no target device 

  because the volume was detached from the persistent domain the first
  time. Because of this, the volume can only be detached by rebooting
  the instance.

  The behavior should be changed to detach from the transient domain
  first, retrying if necessary, and detach from the persistent domain
  only if the detach from the transient domain has succeeded. This way,
  if the guest volume is busy and it ignores the detach request, the
  detach can be tried again at a later time by the user.

  Suggested steps to reproduce:

   1. Boot an instance and attach a volume
   2. Log in to the guest and open a file on that volume in a text editor
   3. Try to detach the volume using 'nova volume-detach' (it should have 
failed)
   4. Exit the text editor on the guest
   5. Try to detach the volume using 'nova volume-detach' (should get the 'no 
target device' error)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633236/+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 1619423] Re: snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys

[Ryan Harper]

** Also 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/1619423

Title:
  snappy does not include ssh-import-id preventing cloud-init user-data
  from importing ssh-keys

Status in cloud-init:
  New
Status in Snappy:
  Confirmed

Bug description:
  cloud-init user-data can specify adding users with

  users:
- name: linda
  ssh-import-keys: linda.user

  and after user account creation, cloud-init invokes:

  sudo -Hu linda ssh-import-id linda-user

  This fails as ssh-import-id isn't part of the Ubuntu-Core image

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1619423/+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 1633218] [NEW] OS_INTERFACE from openrc breaks keystone

[David Medberry]

Public bug reported:

When doing a "openstack project list" after sourcing the openrc file
returned in Horizon, many keystone results break (and or are truncated.)

Unsetting "OS_INTERFACE" restores the proper behavior.

Tested with latest pip of python-openstackclient and python-
keystoneclient

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  OS_INTERFACE from openrc breaks keystone

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When doing a "openstack project list" after sourcing the openrc file
  returned in Horizon, many keystone results break (and or are
  truncated.)

  Unsetting "OS_INTERFACE" restores the proper behavior.

  Tested with latest pip of python-openstackclient and python-
  keystoneclient

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1633218/+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 1633200] Re: Unable to create server with image that has hw_watchdog_action='disabled'

[Matt Riedemann]

** No longer affects: nova/newton

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

Title:
  Unable to create server with image that has
  hw_watchdog_action='disabled'

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  This is from ocata devstack. Set the hw_watchdog_action image property
  with value 'disabled':

  stack@osc:~$ openstack image set --property
  hw_watchdog_action=disabled cirros-0.3.4-x86_64-uec

  stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec
  
+++
  | Field  | Value  
|
  
+++
  | properties | hw_watchdog_action='disabled', 
kernel_id='08463073-3460-4b5f-92cc-ade974936e96', 
ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' |
  
+++

  Then try to boot the server and it will fail:

  stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c 
--flavor 42 test-watchdog-disabled
  ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is 
invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48)

  
  stack@osc:/opt/stack/nova$ git log -1
  commit 7a9eb10d0d15e5327aa73c72418d89afce11abef
  Merge: b796673 951dee3
  Author: Jenkins 
  Date:   Wed Oct 5 18:27:22 2016 +

  Merge "Fix periodic-nova-py{27,35}-with-oslo-master"

  
  The problem is the ImageMetaProps object in nova is using enums for the 
hw_watchdog_action field:

  
https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/objects/fields.py#L383

  And that doesn't have 'disabled' as a value.

  However, if you look at the glance metadef it's an option, so someone
  using Horizon could set this:

  
https://github.com/openstack/glance/blob/d3e820724e1d578003b13e72e753d9b1d75173e1/etc/metadefs
  /compute-watchdog.json#L25

  And the libvirt driver actually defaults to 'disabled':

  
https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/virt/libvirt/driver.py#L4536

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633200/+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 1631517] Re: No formal statement of project name restrictions

[OpenStack Infra]

Reviewed:  https://review.openstack.org/385241
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=1974f2d5dc1e24d1c67258c48f2a5da0dd846cd1
Submitter: Jenkins
Branch:master

commit 1974f2d5dc1e24d1c67258c48f2a5da0dd846cd1
Author: Steve Martinelli 
Date:   Tue Oct 11 22:46:10 2016 -0400

[api] add a note about project name restrictions

Mention that project names are limited to domain, 64 characters,
and utf8 support depends on the given backend.

Change-Id: Idc266d693c9e81d2bc9b51f20ad5f1282bda5721
Closes-Bug: 1631517


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

Title:
  No formal statement of project name restrictions

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  I am unable to find any official documentation on project name
  restrictions. The only two that can be found are 1. It must be uniqe
  within the domain and 2. No more than 64 characters.

  
http://developer.openstack.org/api-ref/identity/v3/?expanded=create-project-detail
 only states:
  "name: The name of the project, which must be unique within the owning 
domain. A project can have the same name as its domain."

  
https://github.com/openstack/tempest/blob/master/tempest/api/identity/admin/v3/test_projects_negative.py#L60-L64
  shows there is a 64 character limit.

  The name must be sent in a valid json which could be any utf-8 character, but 
does that always work within limits of all backends that use MySQL. MySQL's 
restrictions state utf-8, but "can contain only characters in the Basic 
Multilingual Plane (BMP). Supplementary characters are not permitted in 
identifiers."
  https://dev.mysql.com/doc/refman/5.5/en/charset-restrictions.html

  Please add documentation for restrictions on project names beyond
  uniqueness and character count.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1631517/+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 1633200] [NEW] Unable to create server with image that has hw_watchdog_action='disabled'

[Matt Riedemann]

Public bug reported:

This is from ocata devstack. Set the hw_watchdog_action image property
with value 'disabled':

stack@osc:~$ openstack image set --property hw_watchdog_action=disabled
cirros-0.3.4-x86_64-uec

stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec
+++
| Field  | Value
  |
+++
| properties | hw_watchdog_action='disabled', 
kernel_id='08463073-3460-4b5f-92cc-ade974936e96', 
ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' |
+++

Then try to boot the server and it will fail:

stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c 
--flavor 42 test-watchdog-disabled
ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is 
invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48)


stack@osc:/opt/stack/nova$ git log -1
commit 7a9eb10d0d15e5327aa73c72418d89afce11abef
Merge: b796673 951dee3
Author: Jenkins 
Date:   Wed Oct 5 18:27:22 2016 +

Merge "Fix periodic-nova-py{27,35}-with-oslo-master"


The problem is the ImageMetaProps object in nova is using enums for the 
hw_watchdog_action field:

https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/objects/fields.py#L383

And that doesn't have 'disabled' as a value.

However, if you look at the glance metadef it's an option, so someone
using Horizon could set this:

https://github.com/openstack/glance/blob/d3e820724e1d578003b13e72e753d9b1d75173e1/etc/metadefs
/compute-watchdog.json#L25

And the libvirt driver actually defaults to 'disabled':

https://github.com/openstack/nova/blob/7a9eb10d0d15e5327aa73c72418d89afce11abef/nova/virt/libvirt/driver.py#L4536

** Affects: nova
 Importance: Medium
 Assignee: Matt Riedemann (mriedem)
 Status: In Progress

** Affects: nova/newton
 Importance: Medium
 Status: Triaged

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

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

** Changed in: nova
 Assignee: (unassigned) => Matt Riedemann (mriedem)

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

** Changed in: nova/newton
   Status: New => Confirmed

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

** Changed in: nova/newton
   Status: Confirmed => Triaged

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

Title:
  Unable to create server with image that has
  hw_watchdog_action='disabled'

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) newton series:
  Triaged

Bug description:
  This is from ocata devstack. Set the hw_watchdog_action image property
  with value 'disabled':

  stack@osc:~$ openstack image set --property
  hw_watchdog_action=disabled cirros-0.3.4-x86_64-uec

  stack@osc:~$ openstack image show -c properties cirros-0.3.4-x86_64-uec
  
+++
  | Field  | Value  
|
  
+++
  | properties | hw_watchdog_action='disabled', 
kernel_id='08463073-3460-4b5f-92cc-ade974936e96', 
ramdisk_id='ff195fc4-c039-43b5-acca-501aba68aba2' |
  
+++

  Then try to boot the server and it will fail:

  stack@osc:~$ nova boot --poll --image c8af19ff-cebc-4112-a237-78dcd19e588c 
--flavor 42 test-watchdog-disabled
  ERROR (BadRequest): Invalid image metadata. Error: Field value disabled is 
invalid (HTTP 400) (Request-ID: req-488be9ab-ebcb-473b-b238-968f91ed0f48)

  
  stack@osc:/opt/stack/nova$ git log -1
  commit 7a9eb10d0d15e5327aa73c72418d89afce11abef
  Merge: b796673 951dee3
  Author: Jenkins 
  Date:   Wed Oct 5 18:27:22 2016 +

  Merge "Fix periodic-nova-py{27,35}-with-oslo-master"

  
  The problem is the ImageMetaProps object in nova is using enums for the 
hw_watchdog_action field:

  

[Yahoo-eng-team] [Bug 1627615] Re: Cannot override IDL class in OVSDB connection class

[OpenStack Infra]

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

commit 070ee35b9c580904829c6c205163485edd0f4a43
Author: Omer Anson 
Date:   Wed Sep 28 11:17:55 2016 +0300

Allow to override Idl class in OVSDB Connection

Add an option to neutron.agent.ovsdb.native.connection.Connection to
override the Idl class that is created to communicate with OVSDB.

This is a feature that would help in Dragonflow[1], where the notify
method should be overriden before start() is called, in order to receive
all events in real-time, and not retroactively.

[1] 
https://github.com/openstack/dragonflow/blob/d17ae9705a4f585fe3e87a398823dc983cf985c1/dragonflow/ovsdb/impl_idl.py#L135

Change-Id: I49da05f02a00352b1b1db863d244e97f9c148804
Closes-Bug: 1627615


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

Title:
  Cannot override IDL class in OVSDB connection class

Status in neutron:
  Fix Released

Bug description:
  The current ovsdb connection class
  (neutron.agent.ovsdb.native.connection.Connection) creates an instance
  of idl.Idl, but does not allow the client of the library to select a
  different library (e.g. a class overriding idl.Idl). Clients wanting
  to do this have to re-implement the entire start method, which
  contains a lot of unrelated logic.

  This is a feature that would assist us in Dragonflow[1], where we want
  to override the notify method and get OVSDB events, and have this
  method overriden at the moment of connection (and not in retrospect).

  
[1]https://github.com/openstack/dragonflow/blob/master/dragonflow/db/drivers/ovsdb_vswitch_impl.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1627615/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[OpenStack Infra]

Reviewed:  https://review.openstack.org/385918
Committed: 
https://git.openstack.org/cgit/openstack/octavia/commit/?id=9fe5317e004e723d5ad9141cf1e5e90c5f8fe2e5
Submitter: Jenkins
Branch:master

commit 9fe5317e004e723d5ad9141cf1e5e90c5f8fe2e5
Author: Deepak 
Date:   Thu Oct 13 16:57:37 2016 +0530

Drop MANIFEST.in - it's not needed by pbr

octavia already uses PBR:-
setuptools.setup(
setup_requires=['pbr>=1.8'],
pbr=True)

This patch removes `MANIFEST.in` file as pbr generates a
sensible manifest from git files and some standard files
and it removes the need for an explicit `MANIFEST.in` file.

Change-Id: I0b6a7a6eb3be8c1982a4fd7576dea1db9890f69c
Closes-Bug: #1608980


** Changed in: octavia
   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/1608980

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  Confirmed
Status in gce-api:
  Confirmed
Status in Karbor:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[Andrey Pavlov]

** Also affects: gce-api
   Importance: Undecided
   Status: New

** Changed in: gce-api
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

** Changed in: ec2-api
   Importance: Undecided => Low

** Changed in: ec2-api
   Status: New => Confirmed

** Changed in: gce-api
   Importance: Undecided => Low

** Changed in: gce-api
   Status: New => 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/1608980

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  Confirmed
Status in gce-api:
  Confirmed
Status in Karbor:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

** Also affects: ec2-api
   Importance: Undecided
   Status: New

** Changed in: ec2-api
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  New
Status in Karbor:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints

[OpenStack Infra]

Reviewed:  https://review.openstack.org/384259
Committed: 
https://git.openstack.org/cgit/openstack/freezer/commit/?id=ab47e90f217bd9caed7cb35ceabb5a62528bad15
Submitter: Jenkins
Branch:master

commit ab47e90f217bd9caed7cb35ceabb5a62528bad15
Author: Jeremy Liu 
Date:   Mon Oct 10 10:16:22 2016 +0800

Support upper-constraints in tox.ini

Openstack infra now supports upper constraints for all jobs.
Update tox.ini to use upper constraints for all jobs.

Change-Id: I524b0a31ecf2253bedee52b56109f5ff79b428cb
Closes-bug: #1614361


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

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

Title:
  tox.ini needs to be updated as openstack infra now supports upper
  constraints

Status in castellan:
  In Progress
Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in Designate:
  Fix Released
Status in Freezer:
  Fix Released
Status in Glance:
  In Progress
Status in heat:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in Mistral:
  Fix Released
Status in networking-ovn:
  Invalid
Status in octavia:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-mistralclient:
  In Progress
Status in python-muranoclient:
  Fix Released
Status in OpenStack Search (Searchlight):
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in tacker:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Invalid
Status in vmware-nsx:
  Fix Released
Status in zaqar:
  Fix Released
Status in Zaqar-ui:
  Fix Released

Bug description:
  Openstack infra now supports upper constraints for releasenotes, cover, venv 
targets.
  tox.ini uses install_command for these targets, which can now be safely 
removed.
  Reference for mail that details this support: 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/castellan/+bug/1614361/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: karbor
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  New
Status in Karbor:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: searchlight
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in ec2-api:
  New
Status in Karbor:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1632080] Re: Adding routes to router does not increment its revision number

[OpenStack Infra]

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

commit 29e15f9278e8d81fa4d8722deadd8739af60eb51
Author: Omer Anson 
Date:   Mon Oct 10 22:46:32 2016 +0300

Have RouterRoute object increment Router revision

When modifying RouterRoute objects on a Router (e.g. adding a route to a
router via the ExtraRoute extension), have the modification update the
Router's revision number.

Change-Id: If9bb56442375efac3043b9de0a03972552ac34bf
Closes-Bug: 1632080


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

Title:
  Adding routes to router does not increment its revision number

Status in neutron:
  Fix Released

Bug description:
  Adding routes to router does not increment its revision number:

  As per the following output, note that revision_number is 3 after the call to 
openstack router set (which succeeded):
  [stack@l1 ~]$ openstack router show r1

  
  +---+---+
  | Field | Value |
  +---+---+
  | admin_state_up| UP|
  | created_at| 2016-10-10T17:18:45Z  |
  | description   |   |
  | external_gateway_info | null  |
  | id| d7400cc1-1ad4-47b4-9a58-f86f0baf7f06  |
  | name  | r1|
  | project_id| b370e3cd05504661967a04cb119d50ec  |
  | project_id| b370e3cd05504661967a04cb119d50ec  |
  | revision_number   | 3 |
  | routes| destination='10.0.3.0/24', gateway='10.0.1.4' |
  | status| ACTIVE|
  | updated_at| 2016-10-10T18:48:31Z  |
  +---+---+
  [stack@l1 ~]$ openstack router set --route 
destination=10.0.4.0/24,gateway=10.0.1.4  r1
 
  [stack@l1 ~]$ openstack router show r1
  +---+---+
  | Field | Value |
  +---+---+
  | admin_state_up| UP|
  | created_at| 2016-10-10T17:18:45Z  |
  | description   |   |
  | external_gateway_info | null  |
  | id| d7400cc1-1ad4-47b4-9a58-f86f0baf7f06  |
  | name  | r1|
  | project_id| b370e3cd05504661967a04cb119d50ec  |
  | project_id| b370e3cd05504661967a04cb119d50ec  |
  | revision_number   | 3 |
  | routes| destination='10.0.4.0/24', gateway='10.0.1.4' |
  |   | destination='10.0.3.0/24', gateway='10.0.1.4' |
  | status| ACTIVE|
  | updated_at| 2016-10-10T18:48:31Z  |
  +---+---+

  
  Expected output: revision_number is 4 (or more) on the second call to 
openstack router show r1.

  Found on commit 355c145 Merge "Cleanup Newton Release Notes"

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1632080/+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 1632742] Re: /v2 route doesn't exist

[Brian Rosmaita]

I must've had this sitting open for a while and completely missed Sean's
update.

We discussed this at the glance meeting today and decided to agree with
Sean's position, namely that a 404 is appropriate.

It could make sense to have the versions returned, or it could make
sense to have a JSON-home type document returned.  So we don't want to
be precipitate in deciding what (if anything) to return.

** Changed in: glance
   Status: Triaged => Won't Fix

** Changed in: glance
 Assignee: Brian Rosmaita (brian-rosmaita) => (unassigned)

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

Title:
  /v2 route doesn't exist

Status in Glance:
  Won't Fix

Bug description:
  Looking at the api-ref docs, I'm able to list versions of the image
  API available in a cloud (I'm using a devstack created from master as
  of last week):

  http://developer.openstack.org/api-
  ref/image/versions/index.html?expanded=id1-detail#id1

  stack@osc:/opt/stack/glance$ git log -1
  commit 9bd264cd034f996852372ae0ca988bd67b98cf9a
  Merge: 2de3caf ce6cb2d
  Author: Jenkins 
  Date:   Tue Oct 4 02:28:10 2016 +

  Merge "[api-ref] configure LogABug feature"
  stack@osc:/opt/stack/glance$

  
  I'm able to list versions for the image endpoint:

  stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" 
http://9.5.127.82:9292 | json_pp
  {
 "versions" : [
{
   "id" : "v2.4",
   "status" : "CURRENT",
   "links" : [
  {
 "rel" : "self",
 "href" : "http://9.5.127.82:9292/v2/;
  }
   ]
},
{
   "links" : [
  {
 "rel" : "self",
 "href" : "http://9.5.127.82:9292/v2/;
  }
   ],
   "id" : "v2.3",
   "status" : "SUPPORTED"
},
{
   "links" : [
  {
 "rel" : "self",
 "href" : "http://9.5.127.82:9292/v2/;
  }
   ],
   "status" : "SUPPORTED",
   "id" : "v2.2"
},
{
   "id" : "v2.1",
   "status" : "SUPPORTED",
   "links" : [
  {
 "rel" : "self",
 "href" : "http://9.5.127.82:9292/v2/;
  }
   ]
},
{
   "status" : "SUPPORTED",
   "id" : "v2.0",
   "links" : [
  {
 "href" : "http://9.5.127.82:9292/v2/;,
 "rel" : "self"
  }
   ]
},
{
   "links" : [
  {
 "href" : "http://9.5.127.82:9292/v1/;,
 "rel" : "self"
  }
   ],
   "status" : "DEPRECATED",
   "id" : "v1.1"
},
{
   "links" : [
  {
 "rel" : "self",
 "href" : "http://9.5.127.82:9292/v1/;
  }
   ],
   "id" : "v1.0",
   "status" : "DEPRECATED"
}
 ]
  }
  stack@osc:/opt/stack/glance$

  
  I'm able to list the v1 route which is just a list of images:

  stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" 
http://9.5.127.82:9292/v1/ | json_pp
   {
 "images" : [
{
   "size" : 25165824,
   "name" : "cirros-0.3.4-x86_64-uec",
   "id" : "c8af19ff-cebc-4112-a237-78dcd19e588c",
   "disk_format" : "ami",
   "checksum" : "eb9139e4942121f22bbc2afc0400b2a4",
   "container_format" : "ami"
},
{
   "disk_format" : "ari",
   "container_format" : "ari",
   "checksum" : "be575a2b939972276ef675752936977f",
   "size" : 3740163,
   "name" : "cirros-0.3.4-x86_64-uec-ramdisk",
   "id" : "ff195fc4-c039-43b5-acca-501aba68aba2"
},
{
   "size" : 4979632,
   "name" : "cirros-0.3.4-x86_64-uec-kernel",
   "id" : "08463073-3460-4b5f-92cc-ade974936e96",
   "disk_format" : "aki",
   "container_format" : "aki",
   "checksum" : "8a40c862b5735975d82605c1dd395796"
}
 ]
  }

  
  But I'm not able to list the v2 route:

  stack@osc:/opt/stack/glance$ curl -s -H "X-Auth-Token: $OS_TOKEN" 
http://9.5.127.82:9292/v2/
  404 Not Found

  The resource could not be found.

 stack@osc:/opt/stack/glance$

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1632742/+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 1633120] [NEW] Nova scheduler tries to assign an already-in-use SRIOV QAT VF to a new instance (openstack-mitaka)

[Chinmaya Dwibedy]

Public bug reported:

Upon trying to create VM instance (Say A) with one QAT VF, it fails with the 
following error i.e., “Requested operation is not valid: PCI device 
:88:04.7 is in use by driver QEMU, domain instance-0081”. Please note 
that, PCI device :88:04.7 is already being assigned to another VM (Say B) . 
 We have installed openstack-mitaka release on CentO7 system. It has two Intel 
QAT devices. There are 32 VF devices available per QAT Device/DH895xCC device 
Out of 64 VFs, only 8 VFs are allocated (to VM instances) and rest should be 
available.
But the nova scheduler tries to assign an already-in-use SRIOV VF to a new 
instance and instance fails. It appears that the nova database is not tracking 
which VF's have already been taken. But if I shut down VM B instance, then 
other instance VM A boots up and vice-versa. Note that, both the VM instances 
cannot run simultaneously because of the aforesaid issue. 

We should always be able to create as many instances with the requested
PCI devices as there are available VFs.

Please feel free to let me know if additional information is needed. Can
anyone please suggest why it tries to assign same PCI device which has
been assigned already? Is there any way to resolve this issue? Thank you
in advance for your support and help.

[root@localhost ~(keystone_admin)]# lspci -d:435
83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT
88:00.0 Co-processor: Intel Corporation DH895XCC Series QAT
[root@localhost ~(keystone_admin)]#


[root@localhost ~(keystone_admin)]# lspci -d:443 | grep "QAT Virtual Function" 
| wc -l
64
[root@localhost ~(keystone_admin)]#
 
 
[root@localhost ~(keystone_admin)]# mysql -u root nova -e "SELECT 
hypervisor_hostname, address, instance_uuid, status FROM pci_devices JOIN 
compute_nodes oncompute_nodes.id=compute_node_id" | grep :88:04.7
localhost  :88:04.7e10a76f3-e58e-4071-a4dd-7a545e8000deallocated
localhost  :88:04.7c3dbac90-198d-4150-ba0f-a80b912d8021allocated
localhost  :88:04.7c7f6adad-83f0-4881-b68f-6d154d565ce3allocated
localhost.nfv.benunets.com :88:04.70c3c11a5-f9a4-4f0d-b120-40e4dde843d4 
   allocated
[root@localhost ~(keystone_admin)]#
 
[root@localhost ~(keystone_admin)]# grep -r 
e10a76f3-e58e-4071-a4dd-7a545e8000de /etc/libvirt/qemu
/etc/libvirt/qemu/instance-0081.xml:  
e10a76f3-e58e-4071-a4dd-7a545e8000de
/etc/libvirt/qemu/instance-0081.xml:  e10a76f3-e58e-4071-a4dd-7a545e8000de
/etc/libvirt/qemu/instance-0081.xml:  
/etc/libvirt/qemu/instance-0081.xml:  
/etc/libvirt/qemu/instance-0081.xml:  
[root@localhost ~(keystone_admin)]#
[root@localhost ~(keystone_admin)]# grep -r 
0c3c11a5-f9a4-4f0d-b120-40e4dde843d4 /etc/libvirt/qemu
/etc/libvirt/qemu/instance-00ab.xml:  
0c3c11a5-f9a4-4f0d-b120-40e4dde843d4
/etc/libvirt/qemu/instance-00ab.xml:  0c3c11a5-f9a4-4f0d-b120-40e4dde843d4
/etc/libvirt/qemu/instance-00ab.xml:  
/etc/libvirt/qemu/instance-00ab.xml:  
/etc/libvirt/qemu/instance-00ab.xml:  
[root@localhost ~(keystone_admin)]#
 
On the controller, , it appears there are duplicate PCI device entries in the 
Database:
 
MariaDB [nova]> select hypervisor_hostname,address,count(*) from pci_devices 
JOIN compute_nodes on compute_nodes.id=compute_node_id group by 
hypervisor_hostname,address having count(*) > 1;
+-+--+--+
| hypervisor_hostname | address  | count(*) |
+-+--+--+
| localhost  | :05:00.0 |3 |
| localhost  | :05:00.1 |3 |
| localhost  | :83:01.0 |3 |
| localhost  | :83:01.1 |3 |
| localhost  | :83:01.2 |3 |
| localhost  | :83:01.3 |3 |
| localhost  | :83:01.4 |3 |
| localhost  | :83:01.5 |3 |
| localhost  | :83:01.6 |3 |
| localhost  | :83:01.7 |3 |
| localhost  | :83:02.0 |3 |
| localhost  | :83:02.1 |3 |
| localhost  | :83:02.2 |3 |
| localhost  | :83:02.3 |3 |
| localhost  | :83:02.4 |3 |
| localhost  | :83:02.5 |3 |
| localhost  | :83:02.6 |3 |
| localhost  | :83:02.7 |3 |
| localhost  | :83:03.0 |3 |
| localhost  | :83:03.1 |3 |
| localhost  | :83:03.2 |3 |
| localhost  | :83:03.3 |3 |
| localhost  | :83:03.4 |3 |
| localhost  | :83:03.5 |3 |
| localhost  | :83:03.6 |3 |
| localhost  | :83:03.7 |3 |
| localhost  | :83:04.0 |3 |
| localhost

[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[OpenStack Infra]

Reviewed:  https://review.openstack.org/385968
Committed: 
https://git.openstack.org/cgit/openstack/zun/commit/?id=9b805918882abcf36145ddd9ef6e69889273c5ec
Submitter: Jenkins
Branch:master

commit 9b805918882abcf36145ddd9ef6e69889273c5ec
Author: Iswarya_Vakati 
Date:   Thu Oct 13 18:21:37 2016 +0530

Drop MANIFEST.in - it's not needed by pbr

Zun already uses PBR:-
setuptools.setup(
setup_requires=['pbr>=1.8'],
pbr=True)

This patch removes `MANIFEST.in` file as pbr generates a
sensible manifest from git files and some standard files
and it removes the need for an explicit `MANIFEST.in` file.

Change-Id: I30830509234c2e37759b97502bb9fd5a9e7036dd
Closes-Bug:#1608980


** Changed in: zun
   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/1608980

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1631133] Re: nova's osapi_compute_workers is not valid (must be greater than 1)

[OpenStack Infra]

Reviewed:  https://review.openstack.org/385078
Committed: 
https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=38f98383d396d89b8f6047e57e5e606615ee5a16
Submitter: Jenkins
Branch:master

commit 38f98383d396d89b8f6047e57e5e606615ee5a16
Author: Dan Prince 
Date:   Tue Oct 11 12:09:43 2016 -0400

Only set NovaWorkers in the non-default case

This patch updates the t-h-t templates for
nova services so that we only set the value of workers in
the non-default case. TripleO has always defaulted the
workers count to 0 and there was recently a regression in
nova where they treat the default of 0 as invalid (a bug
that may get fixed in nova but we don't want to wait on it)

This patch avoids the issue by allowing the default value
to be unset if the TripleO default of 0 is configured.

Change-Id: I175977b88129d87caeb32332d47eb14816a6d5d4
Closes-bug: #1631133


** Changed in: tripleo
   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/1631133

Title:
  nova's osapi_compute_workers is not valid (must be greater than 1)

Status in OpenStack Compute (nova):
  In Progress
Status in tripleo:
  Fix Released

Bug description:
  As of Nova e8436283e45b6716fb61d6f6590fadb5fb4ba45c commit TripleO now
  fails to deploy nova-api correctly. This is because our default value
  set osapi_compute_workers=0 and metadata_workers=0 and this is no
  longer valid. Nova now requires an integer greater than 0, or an empty
  string.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1631133/+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 1551504] Re: I/O (PCIe) Based NUMA Scheduling can't really achieve pci numa binding in some cases.

[Stephen Finucane]

Having discussed this since, it's clear that this isn't a bug but a
design decision. nova allows scheduling PCI devices on hosts without an
exposed NUMA topology as this satisfies the majority of use cases. It
would be possible to make this behavior configurable, but this is a
feature request - not a bug - and would require a spec [1].

[1] https://review.openstack.org/#/c/361140/

** Changed in: nova
   Status: In Progress => 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/1551504

Title:
  I/O (PCIe) Based NUMA Scheduling  can't really achieve pci numa
  binding in some cases.

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  1. version
  kilo 2015.1.0, liberty

  this bug is base on BP:
  https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling

  In the current implementation scheme:

  /nova/pci/stats.py
  

   def _filter_pools_for_numa_cells(pools, numa_cells):
  # Some systems don't report numa node info for pci devices, in
  # that case None is reported in pci_device.numa_node, by adding None
  # to numa_cells we allow assigning those devices to instances with
  # numa topology
  numa_cells = [None] + [cell.id for cell in numa_cells]
  
#

  If some compute nodes don't report numa node info for pci devices.
  Then these pci devices will be regarded as "belong to all numa node" to deal 
with by default.

  This can lead to a problem:
  Pci devices is not on the numa node which CPU\MEM on.
  In this way, the real purpose of I/O (PCIe) Based NUMA Scheduling is not 
reached.
  More serious is that the user will be wrong thought pci devices is on the 
numa node that CPU\MEM on.

  The truth is, there are still many systems don't report numa node info for 
pci devices.
  So, i think this bug need fixed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1551504/+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 1618513] Re: nova quota policy with details seems broken

[OpenStack Infra]

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

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

** Changed in: nova
 Assignee: stgleb (gstepanov) => Andrey Volkov (avolkov)

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

Title:
  nova quota policy with details seems broken

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  The default policy for this call:

  novaclient(request).quotas.get(tenant_id, detail=True)

  fails unless I am an admin type user.   This doesn't seem to make
  sense, as an _member_ type user, I can still find all the details just
  the same.   This just makes user do many more calls and calculations
  to work around this.

  The default policy file should be that if you are the member of the
  project, you can see the details if you want.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1618513/+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 1633084] Re: Secondary IPv6 subnet never gets configured in router

[Brian Haley]

Doh, I'm an idiot, john-davidge pointed out I forgot to add the router
interface to this subnet, I should know better :)

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

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

Title:
  Secondary IPv6 subnet never gets configured in router

Status in neutron:
  Invalid

Bug description:
  I brought up a devstack recently, which creates both internal IPv4 and
  IPv6 subnets on a single network.  To test a bug fix I wanted to add a
  secondary IPv6 subnet on the network, so using Horizon I did that
  (since a subnetpool was already configured), such that:

  $ neutron net-list --field name --field subnets
  +-+---+
  | name| subnets   |
  +-+---+
  | public  | 32df3f47-2cc0-491f-a9dc-6a9b06287444  |
  | | ca7291e9-0470-49fe-80a7-63eddd73b338  |
  | private | ecaa0a78-646a-46fe-9846-996eddf70cf1 2001:db8:8000:1::/64 |
  | | afa2f586-4f8c-4951-800f-8f82bb37bc8c 2001:db8:8000::/64   |
  | | dd467ff5-5c9a-4cfe-91c9-fb788fc7ff40 10.0.0.0/24  |
  +-+---+

  The 2001:db8:8000:1::/64 never got configured in my router, although
  it does show up in the DB.

  It's not in the namespace or radvd.conf file, so VMs don't
  autoconfigure it.

  $ sudo ip netns exec qrouter-f76baa3f-5881-4c49-8e72-cef86fa03166 ip a
  1: lo:  mtu 65536
  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
  46: qr-7f0792c8-39:  mtu 1450
  link/ether fa:16:3e:73:90:28 brd ff:ff:ff:ff:ff:ff
  inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-7f0792c8-39
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:fe73:9028/64 scope link 
 valid_lft forever preferred_lft forever
  49: qr-936fd0dc-71:  mtu 1450
  link/ether fa:16:3e:ed:78:be brd ff:ff:ff:ff:ff:ff
  inet6 2001:db8:8000::1/64 scope global 
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:feed:78be/64 scope link 
 valid_lft forever preferred_lft forever

  And here's the two subnet's info, which seems pretty identical except
  for the prefix:

  $ neutron subnet-show ipv6-private-subnet
  
+---+-+
  | Field | Value   
|
  
+---+-+
  | allocation_pools  | {"start": "2001:db8:8000::2", "end": 
"2001:db8:8000:0::::"} |
  | cidr  | 2001:db8:8000::/64  
|
  | created_at| 2016-10-05T20:50:32Z
|
  | description   | 
|
  | dns_nameservers   | 
|
  | enable_dhcp   | True
|
  | gateway_ip| 2001:db8:8000::1
|
  | host_routes   | 
|
  | id| afa2f586-4f8c-4951-800f-8f82bb37bc8c
|
  | ip_version| 6   
|
  | ipv6_address_mode | slaac   
|
  | ipv6_ra_mode  | slaac   
|
  | name  | ipv6-private-subnet 
|
  | network_id| f6b05fa1-29e4-4e2f-96ae-d9f4cdededea
|
  | project_id| df427083b46c400e956f66ba952b3b55
|
  | revision_number   | 2   
|
  | service_types | 
|
  | subnetpool_id | 79e46698-bc5a-4458-bed9-6d2a47d7876c
|
  | tenant_id | df427083b46c400e956f66ba952b3b55   

[Yahoo-eng-team] [Bug 1633084] [NEW] Secondary IPv6 subnet never gets configured in router

[Brian Haley]

Public bug reported:

I brought up a devstack recently, which creates both internal IPv4 and
IPv6 subnets on a single network.  To test a bug fix I wanted to add a
secondary IPv6 subnet on the network, so using Horizon I did that (since
a subnetpool was already configured), such that:

$ neutron net-list --field name --field subnets
+-+---+
| name| subnets   |
+-+---+
| public  | 32df3f47-2cc0-491f-a9dc-6a9b06287444  |
| | ca7291e9-0470-49fe-80a7-63eddd73b338  |
| private | ecaa0a78-646a-46fe-9846-996eddf70cf1 2001:db8:8000:1::/64 |
| | afa2f586-4f8c-4951-800f-8f82bb37bc8c 2001:db8:8000::/64   |
| | dd467ff5-5c9a-4cfe-91c9-fb788fc7ff40 10.0.0.0/24  |
+-+---+

The 2001:db8:8000:1::/64 never got configured in my router, although it
does show up in the DB.

It's not in the namespace or radvd.conf file, so VMs don't autoconfigure
it.

$ sudo ip netns exec qrouter-f76baa3f-5881-4c49-8e72-cef86fa03166 ip a
1: lo:  mtu 65536
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
46: qr-7f0792c8-39:  mtu 1450
link/ether fa:16:3e:73:90:28 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global qr-7f0792c8-39
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe73:9028/64 scope link 
   valid_lft forever preferred_lft forever
49: qr-936fd0dc-71:  mtu 1450
link/ether fa:16:3e:ed:78:be brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:8000::1/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feed:78be/64 scope link 
   valid_lft forever preferred_lft forever

And here's the two subnet's info, which seems pretty identical except
for the prefix:

$ neutron subnet-show ipv6-private-subnet
+---+-+
| Field | Value 
  |
+---+-+
| allocation_pools  | {"start": "2001:db8:8000::2", "end": 
"2001:db8:8000:0::::"} |
| cidr  | 2001:db8:8000::/64
  |
| created_at| 2016-10-05T20:50:32Z  
  |
| description   |   
  |
| dns_nameservers   |   
  |
| enable_dhcp   | True  
  |
| gateway_ip| 2001:db8:8000::1  
  |
| host_routes   |   
  |
| id| afa2f586-4f8c-4951-800f-8f82bb37bc8c  
  |
| ip_version| 6 
  |
| ipv6_address_mode | slaac 
  |
| ipv6_ra_mode  | slaac 
  |
| name  | ipv6-private-subnet   
  |
| network_id| f6b05fa1-29e4-4e2f-96ae-d9f4cdededea  
  |
| project_id| df427083b46c400e956f66ba952b3b55  
  |
| revision_number   | 2 
  |
| service_types |   
  |
| subnetpool_id | 79e46698-bc5a-4458-bed9-6d2a47d7876c  
  |
| tenant_id | df427083b46c400e956f66ba952b3b55  
  |
| updated_at| 2016-10-05T20:50:32Z  
  |
+---+-+

$ neutron subnet-show ipv6-subnet-2
+---+---+
| Field | Value 
|

[Yahoo-eng-team] [Bug 1632981] Re: keystone delete role gives no output when operation is successful

[Steve Martinelli]

this is as-designed. no delete operations give feedback. just as in
linux if something does not give you an error, you can assume it
occurred just fine.

https://www.quora.com/What-is-the-appropriate-HTTP-response-code-to-a
-successful-DELETE-request

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

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

Title:
  keystone delete role gives no output when operation is successful

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When a role is deleted, no output is displayed on screen. This is
  vague. A confirmation should be generated for the user to avoid
  ambiguity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1632981/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: zun
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

** Changed in: watcher
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in watcher:
  In Progress
Status in Zun:
  New

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1633066] [NEW] Input int value into service_type list hit internal error

[zhaobo]

Public bug reported:

I use REST api to create/update subnet with serive_types. I use some int
type values in the list.

The creation body is:
{
"subnet": {
"network_id": "0d04102a-ba15-4d6c-94ee-8ac480cbb1ba",
"name": "hellowor",
"cidr": "99.99.99.99/24",
"service_types" : ["network:1",2,3],
"ip_version": 4
}
}

neutron server hit internal error.
2016-10-13 17:44:27.842 ERROR neutron.api.v2.resource 
[req-b9846c07-3574-4094-b6fe-ca978c1d31ce admin 
488da3aab0ff45df9e85e17e7f89fedd] create failed: No details.
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 430, in create
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return 
self._create(request, body, **kwargs)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 88, in wrapped
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise()
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 84, in wrapped
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*args, 
**kwargs)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource ectxt.value = 
e.inner_exc
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise()
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*args, 
**kwargs)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 124, in wrapped
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
traceback.format_exc())
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource self.force_reraise()
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 119, in wrapped
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource return f(*dup_args, 
**dup_kwargs)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 439, in _create
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 719, in prepare_request_body
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource 
attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest)
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/attributes.py", line 431, in convert_value
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource res = 
validator(res_dict[attr], attr_vals['validate'][rule])
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/subnet_service_types.py", line 47, in 
_validate_subnet_service_types
2016-10-13 17:44:27.842 TRACE neutron.api.v2.resource not 
service_type.startswith(tuple(prefixes))):
2016-10-13 17:44:27.842 TRACE 

[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: solum
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in Solum:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[iswarya vakati]

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

** Changed in: trove
 Assignee: (unassigned) => iswarya vakati (v-iswarya)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  In Progress
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  In Progress
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  New

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1633047] [NEW] Nova - boot from volume - Min Disk Size - Liberty

[Ross Martyn]

Public bug reported:

Description
===
Seemingly incorrect validation of image requirements for instance when using 
boot from volume functionality.

Steps to reproduce
==
* Create an image with a minimum disk size (Eg 2GB)
* Create a bootable volume from image (Eg 2GB)
* Launch an flavor with 1GB RAM (root disk set to 40Gb in our case, but not 
expected to be used during boot from volume).

Expected result
===
In this case the instance should be created, as the image minimum requirements 
are met.

Actual result
=
Volume is smaller than the minimum size specified in image metadata. Volume 
size is 1073741824 bytes, minimum size is 2147483648 bytes

This is incorrect volume size is LARGER than nova api is reporting, we
thought this may be reporting the RAM size, rather than the disk size,
however we disproved this by doubling the minimum disk size, and using a
2GB RAM instance. This succeeded.

Stumpt! For now, we have removed minimum disk sizes.

Environment
===
1. OpenStack Liberty on Ubuntu14.04 w/ Ceph Jewel.

dpkg -l |grep nova
ii  nova-api  2:12.0.3-0ubuntu1~cloud0

2. Libvirt+KVM (Unrelated, fails/refused(400) during API Call.

3. CEPH backed volumes/images and ephemeral disks

4. Neutron in use, but i expect also unrelated.

Logs & Configs
==
The main log is the following.

2016-10-13 10:21:01.471 24901 DEBUG nova.api.openstack.wsgi  Returning 400 
to user: Volume is smaller than the minimum size specified in image metadata. 
Volume size is 1073741824 bytes, minimum size is 2147
483648 bytes. __call__ 
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:1175

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

Title:
  Nova - boot from volume - Min Disk Size - Liberty

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  Seemingly incorrect validation of image requirements for instance when using 
boot from volume functionality.

  Steps to reproduce
  ==
  * Create an image with a minimum disk size (Eg 2GB)
  * Create a bootable volume from image (Eg 2GB)
  * Launch an flavor with 1GB RAM (root disk set to 40Gb in our case, but not 
expected to be used during boot from volume).

  Expected result
  ===
  In this case the instance should be created, as the image minimum 
requirements are met.

  Actual result
  =
  Volume is smaller than the minimum size specified in image metadata. Volume 
size is 1073741824 bytes, minimum size is 2147483648 bytes

  This is incorrect volume size is LARGER than nova api is reporting, we
  thought this may be reporting the RAM size, rather than the disk size,
  however we disproved this by doubling the minimum disk size, and using
  a 2GB RAM instance. This succeeded.

  Stumpt! For now, we have removed minimum disk sizes.

  Environment
  ===
  1. OpenStack Liberty on Ubuntu14.04 w/ Ceph Jewel.

  dpkg -l |grep nova
  ii  nova-api  2:12.0.3-0ubuntu1~cloud0

  2. Libvirt+KVM (Unrelated, fails/refused(400) during API Call.

  3. CEPH backed volumes/images and ephemeral disks

  4. Neutron in use, but i expect also unrelated.

  Logs & Configs
  ==
  The main log is the following.

  2016-10-13 10:21:01.471 24901 DEBUG nova.api.openstack.wsgi  Returning 
400 to user: Volume is smaller than the minimum size specified in image 
metadata. Volume size is 1073741824 bytes, minimum size is 2147
  483648 bytes. __call__ 
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:1175

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633047/+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 1633042] [NEW] L3 scheduler: make RouterL3AgentBinding always concurrently safe

[John Schwarz]

Public bug reported:

Changeset I3447ea5bcb7c57365c6f50efe12a1671e86588b3 added a
binding_index column to the RouterL3AgentBinding table, which is unique
with the router_id. However, the current logic isn't concurrent safe as
some concurrent cases can raise a DBDuplicateEntry (if the same
binding_index is being used by 2 different workers).

** Affects: neutron
 Importance: Medium
 Assignee: John Schwarz (jschwarz)
 Status: In Progress


** Tags: l3-dvr-backlog l3-ha

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

Title:
  L3 scheduler: make RouterL3AgentBinding always concurrently safe

Status in neutron:
  In Progress

Bug description:
  Changeset I3447ea5bcb7c57365c6f50efe12a1671e86588b3 added a
  binding_index column to the RouterL3AgentBinding table, which is
  unique with the router_id. However, the current logic isn't concurrent
  safe as some concurrent cases can raise a DBDuplicateEntry (if the
  same binding_index is being used by 2 different workers).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633042/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

[Shashi]

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

** Changed in: neutron
 Assignee: (unassigned) => Shashi (shashi-kant)

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  New
Status in Kosmos:
  New
Status in Magnum:
  Fix Released
Status in masakari:
  New
Status in neutron:
  In Progress
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  New
Status in Tricircle:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1633033] [NEW] live migration with encrypted volume fails

[Paul Carlton]

Public bug reported:

When live migrating an instance with an encrypted volume it fails to
detach the encrypted volume from the source and attaches at the target
as an unencrypted volume.

I do see the encrypted volume connector on the source but not on the
target

ls -l /dev/disk/by-path
total 0
lrwxrwxrwx 1 root root 121 Oct 13 10:26 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
 -> 
/dev/mapper/crypt-ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
lrwxrwxrwx 1 root root   9 Oct 13 10:36 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1
 -> ../../sdd

Target

ls -l /dev/disk/by-path
total 0
lrwxrwxrwx 1 root root  9 Oct 13 10:48 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
 -> ../../sdb
lrwxrwxrwx 1 root root  9 Oct 13 10:48 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1
 -> ../../sdc

The instance can still access encrypted volume, but the data disappears
when you umount/mount the device so I guess it looked ok at first due to
filesystem caching

The live migration fails in post migrate on the source due to an error
trying to detach the encrypted volume (see bug
https://bugs.launchpad.net/os-brick/+bug/1631318, which I'll close now)

Subsequent attempts to detach the volume from the instance (after
manually updating it to say it is on the target and active, see
https://bugs.launchpad.net/nova/+bug/1628606.

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

Title:
  live migration with encrypted volume fails

Status in OpenStack Compute (nova):
  New

Bug description:
  When live migrating an instance with an encrypted volume it fails to
  detach the encrypted volume from the source and attaches at the target
  as an unencrypted volume.

  I do see the encrypted volume connector on the source but not on the
  target

  ls -l /dev/disk/by-path
  total 0
  lrwxrwxrwx 1 root root 121 Oct 13 10:26 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
 -> 
/dev/mapper/crypt-ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
  lrwxrwxrwx 1 root root   9 Oct 13 10:36 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1
 -> ../../sdd

  Target

  ls -l /dev/disk/by-path
  total 0
  lrwxrwxrwx 1 root root  9 Oct 13 10:48 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-1a17d61f-7f44-450e-b040-a0baebdb0466-lun-1
 -> ../../sdb
  lrwxrwxrwx 1 root root  9 Oct 13 10:48 
ip-192.168.16.20:3260-iscsi-iqn.2010-10.org.openstack:volume-76909639-61bc-4abd-9a1e-fd5624bb8fc1-lun-1
 -> ../../sdc

  The instance can still access encrypted volume, but the data
  disappears when you umount/mount the device so I guess it looked ok at
  first due to filesystem caching

  The live migration fails in post migrate on the source due to an error
  trying to detach the encrypted volume (see bug
  https://bugs.launchpad.net/os-brick/+bug/1631318, which I'll close
  now)

  Subsequent attempts to detach the volume from the instance (after
  manually updating it to say it is on the target and active, see
  https://bugs.launchpad.net/nova/+bug/1628606.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1633033/+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 1618766] Re: Add new configuration test in sanity check: vf_extended_management

[OpenStack Infra]

Reviewed:  https://review.openstack.org/369811
Committed: 
https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=c9bdbf3c321b949e01a58d9397febabb067fbb5d
Submitter: Jenkins
Branch:master

commit c9bdbf3c321b949e01a58d9397febabb067fbb5d
Author: chenxing 
Date:   Wed Sep 14 04:37:40 2016 +

[cli-reference] add a new sanity check parameter

Change-Id: I88b666522b8e21297657605b83d10174847e64fa
Closes-Bug: #1618766


** Changed in: openstack-manuals
   Status: In Progress => Fix Released

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

Title:
  Add new configuration test in sanity check: vf_extended_management

Status in neutron:
  Invalid
Status in openstack-manuals:
  Fix Released

Bug description:
  https://review.openstack.org/351833
  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 a2dc3c35e3d35c6a5f2099fee819e87b4fa216e9
  Author: Rodolfo Alonso Hernandez 
  Date:   Mon Jul 18 11:52:12 2016 +0100

  Add new configuration test in sanity check: vf_extended_management
  
  This test will check if 'ip link' version installed in this server
  supports extended VF management parameter 'min_tx_rate'. This
  parameter set the minimum egress rate for an interface.
  
  This test is executed when SR-IOV back-end and QoS extension
  are enabled.
  
  DocImpact
  Partial-Bug: #1560963
  
  Change-Id: Ie9334f4ad2f6b047bf56689edfa8a612364a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618766/+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 1633006] [NEW] Post metering-label-rules API returns 500 when the body has wrong metering_label_id

[Hirofumi Ichihara]

Public bug reported:

When we calls metering-label-rules POST API with wrong
metering_label_id, we catch 500 from Neutron server.


$ curl -g -i -X POST 
http://127.0.0.1:9696/v2.0/metering/metering-label-rules.json -H "User-Agent: 
python-neutronclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: $TOKEN" -d '{"metering_label_rule": 
{"remote_ip_prefix": "10.0.0.0/24", "direction": "ingress", 
"metering_label_id": "43e7dfd6-0deb-427b-9abc-5eaf5ada5040"}}'
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 150
X-Openstack-Request-Id: req-7242ca76-283a-4589-ae69-7214622b804b
Date: Thu, 13 Oct 2016 09:22:43 GMT

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

Error log:

2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource self._affected_rows = 
self._read_query_result(unbuffered=unbuffered)
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1019, in 
_read_query_result
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource result.read()
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1302, in 
read
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource first_packet = 
self.connection._read_packet()
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 981, in 
_read_packet
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource packet.check_error()
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 393, in 
check_error
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource 
err.raise_mysql_exception(self._data)
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 107, in 
raise_mysql_exception
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource raise 
errorclass(errno, errval)
2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource DBReferenceError: 
(pymysql.err.IntegrityError) (1452, u'Cannot add or update a child row: a 
foreign key constraint fails (`neutron`.`meteringlabelrules`, CONSTRAINT 
`meteringlabelrules_ibfk_1` FOREIGN KEY (`metering_label_id`) REFERENCES 
`meteringlabels` (`id`) ON DELETE CASCADE)') [SQL: u'INSERT INTO 
meteringlabelrules (id, direction, remote_ip_prefix, metering_label_id, 
excluded) VALUES (%(id)s, %(direction)s, %(remote_ip_prefix)s, 
%(metering_label_id)s, %(excluded)s)'] [parameters: {'remote_ip_prefix': 
u'10.0.0.0/24', 'direction': u'ingress', 'metering_label_id': 
u'43e7dfd6-0deb-427b-9abc-5eaf5ada5040', 'id': 
'ee5358b7-7326-42d2-be37-829b97f945af', 'excluded': 0}]

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


** Tags: metering

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

** Tags added: metering

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

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

Title:
  Post metering-label-rules API returns 500 when the body has wrong
  metering_label_id

Status in neutron:
  In Progress

Bug description:
  When we calls metering-label-rules POST API with wrong
  metering_label_id, we catch 500 from Neutron server.

  
  $ curl -g -i -X POST 
http://127.0.0.1:9696/v2.0/metering/metering-label-rules.json -H "User-Agent: 
python-neutronclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: $TOKEN" -d '{"metering_label_rule": 
{"remote_ip_prefix": "10.0.0.0/24", "direction": "ingress", 
"metering_label_id": "43e7dfd6-0deb-427b-9abc-5eaf5ada5040"}}'
  HTTP/1.1 500 Internal Server Error
  Content-Type: application/json
  Content-Length: 150
  X-Openstack-Request-Id: req-7242ca76-283a-4589-ae69-7214622b804b
  Date: Thu, 13 Oct 2016 09:22:43 GMT

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

  Error log:

  2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource self._affected_rows 
= self._read_query_result(unbuffered=unbuffered)
  2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1019, in 
_read_query_result
  2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource result.read()
  2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1302, in 
read
  2016-10-13 09:22:43.156 TRACE neutron.api.v2.resource 

[Yahoo-eng-team] [Bug 1632987] [NEW] _nova_to_osvif_vif_bridge: 'module' object has no attribute 'vif'

[Markus Zoeller (markus_z)]

Public bug reported:

Description
===
The unit-test 
"nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password"
 fails. I could narrow it down to this commit: 
https://github.com/openstack/nova/commit/735f710

 move os_vif.initialize() to nova-compute start

os_vif.initialize() was previously executed during module load. This
means it was entirely possible that it was run before things like
logging were actually set up in the expected way. Move this back into
execution time instead of load time to ensure that logging is actually
setup.

Changes need to be made to tests which make assumptions about os_vif
objects to manually initialize os_vif when it will be used. os_vif
objects can't be created until it is initialized, so some delayed
object creation is also done in test_vif.py.

Closes-Bug: #1615676

Change-Id: I89fe5c5b3d762f3a3238b587685df85d15ee56c4


Steps to reproduce
==
A chronological list of steps which will bring off the
issue you noticed:
* Clone/pull nova
* tox -e py27 
nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password
 -r


Expected result
===
Test should succeed


Actual result
=

==
Failed 1 tests - output below:
==


nova.tests.unit.virt.test_virt_drivers.LibvirtConnTestCase.test_set_admin_password

--

Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/virt/test_virt_drivers.py", line 58, in 
wrapped_func
return f(self, *args, **kwargs)
  File 
"/home/markus/git/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py", 
line 1305, in patched
return func(*args, **keywargs)
  File "nova/tests/unit/virt/test_virt_drivers.py", line 980, in 
test_set_admin_password
instance, network_info = self._get_running_instance(obj=True)
  File "nova/tests/unit/virt/test_virt_drivers.py", line 261, in 
_get_running_instance
[], 'herp', network_info=network_info)
  File "nova/virt/libvirt/driver.py", line 2602, in spawn
write_to_disk=True)
  File "nova/virt/libvirt/driver.py", line 4651, in _get_guest_xml
context)
  File "nova/virt/libvirt/driver.py", line 4483, in _get_guest_config
flavor, virt_type, self._host)
  File "nova/virt/libvirt/vif.py", line 507, in get_config
vif_obj = os_vif_util.nova_to_osvif_vif(vif)
  File "nova/network/os_vif_util.py", line 369, in nova_to_osvif_vif
vifobj = func(vif)
  File "nova/network/os_vif_util.py", line 248, in 
_nova_to_osvif_vif_bridge
objects.vif.VIFBridge,
AttributeError: 'module' object has no attribute 'vif'


Captured pythonlogging:
~~~
2016-10-13 10:12:16,176 INFO [248_add_expire_reservations_index] 
Skipped adding reservations_deleted_expire_idx because an equivalent index 
already exists.
2016-10-13 10:12:18,153 INFO [os_brick.initiator.connectors.disco] Init 
DISCO connector
2016-10-13 10:12:18,153 WARNING 
[os_brick.initiator.connectors.remotefs] Connection details not present. 
RemoteFsClient may not initialize properly.
2016-10-13 10:12:18,209 INFO [nova.virt.osinfo] Cannot load Libosinfo: 
(No module named gi.repository.Libosinfo)
2016-10-13 10:12:18,209 INFO [nova.virt.libvirt.driver] Creating image
2016-10-13 10:12:18,258 INFO [nova.virt.libvirt.driver] Connection 
event '1' reason 'None'
2016-10-13 10:12:18,260 INFO [nova.virt.libvirt.host] Libvirt host 
capabilities 
  
cef19ce0-0ca2-11df-855d-b19fbce37686

  x86_64
  Penryn
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
tcp
  



  apparmor
  0

  

  
hvm

  32
  /usr/bin/qemu
  pc-0.14
  pc
  pc-0.13
  pc-0.12
  pc-0.11
  pc-0.10
  isapc
  
  
  
/usr/bin/kvm
pc-0.14
pc
pc-0.13
pc-0.12
pc-0.11
pc-0.10
isapc
  


  
  
  
  
  
   

[Yahoo-eng-team] [Bug 1632981] [NEW] keystone delete role gives no output when operation is successful

[the-bling]

Public bug reported:

When a role is deleted, no output is displayed on screen. This is vague.
A confirmation should be generated for the user to avoid ambiguity.

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: keystone role

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

Title:
  keystone delete role gives no output when operation is successful

Status in OpenStack Identity (keystone):
  New

Bug description:
  When a role is deleted, no output is displayed on screen. This is
  vague. A confirmation should be generated for the user to avoid
  ambiguity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1632981/+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 1632768] Re: rootwrap daemon with libvirt/xen not working

[Thomas Bechtold]

Looks like this is a oslo.rootwrap bug and executing an unknown command
is not tested in the testsuite.

** Also affects: oslo.rootwrap
   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/1632768

Title:
  rootwrap daemon with libvirt/xen not working

Status in OpenStack Compute (nova):
  Incomplete
Status in oslo.rootwrap:
  In Progress

Bug description:
  Using:
  - SLE12SP1
  - xen 4.7
  - nova 13.1.2.dev68 (stable-mitaka tarball)

  
  When configuring nova-compute to use the rootwrap daemon and using Xen with 
libvirt as hypervisor I get the following error when booting a VM:

  2016-10-12 15:54:34.216 17936 INFO nova.compute.claims 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] Claim successful
  2016-10-12 15:54:34.458 17936 INFO nova.virt.osinfo 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] Cannot load Libosinfo: (No module named 
Libosinfo)
  2016-10-12 15:54:34.479 17936 WARNING oslo_config.cfg 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] Option "username" from group "neutron" 
is deprecated. Use option "user-name" from group "neutron".
  2016-10-12 15:54:34.751 17936 INFO nova.virt.libvirt.driver 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] Creating image
  2016-10-12 15:54:34.758 17936 INFO nova.utils 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] Executing RootwrapDaemonHelper.execute 
cmd=[u'touch -c 
/var/lib/nova/instances/_base/309100c6d00d13edba007a0dde00e9889ce0410a'] 
kwargs=[{'run_as_root': True}]
  2016-10-12 15:54:34.795 17936 INFO oslo_rootwrap.client 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] Spawned new rootwrap daemon process 
with pid=17984
  2016-10-12 15:54:36.060 17936 INFO nova.utils 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] Executing RootwrapDaemonHelper.execute 
cmd=[u'xend status'] kwargs=[{'run_as_root': True}]
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager 
[req-5f1c8974-b449-41fa-806b-73f705ed1634 47640c082746419f87ae498f7bdab44e 
08f3d1224d1845cda767a2193594c3d7 - - -] [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] Instance failed to spawn
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] Traceback (most recent call last):
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2218, in 
_build_resources
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] yield resources
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2064, in 
_build_and_run_instance
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] block_device_info=block_device_info)
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2790, in 
spawn
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] write_to_disk=True)
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4746, in 
_get_guest_xml
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] context)
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4605, in 
_get_guest_config
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5] flavor, guest.os_type)
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3640, in 
_get_guest_storage_config
  2016-10-12 15:54:36.062 17936 ERROR nova.compute.manager [instance: 
98dbdd8b-ae17-4861-bffe-cc48042f93e5]