[Yahoo-eng-team] [Bug 1319581] Re: NSX: missing fk constraint between network gateway and devices

[Armando Migliaccio]

** Also affects: vmware-nsx
   Importance: Undecided
   Status: New

** No longer affects: neutron

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

Title:
  NSX: missing fk constraint between network gateway and devices

Status in vmware-nsx:
  New

Bug description:
  
https://github.com/openstack/neutron/blob/master/neutron/plugins/vmware/dbexts/networkgw_db.py#L120

  class NetworkGatewayDeviceReference(model_base.BASEV2):
  id = sa.Column(sa.String(36), primary_key=True)
  network_gateway_id = sa.Column(sa.String(36),
 sa.ForeignKey('networkgateways.id',
   ondelete='CASCADE'),
 primary_key=True)
  interface_name = sa.Column(sa.String(64), primary_key=True)

  The field 'id' refers to a gateway device. As there is no foreign key
  constraint the database layer will allow for creating gateway for non-
  existing devices - the error will then be detected in the backend
  anyway, but it should be caught at the DB layer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/vmware-nsx/+bug/1319581/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[sonu]

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

** Changed in: python-designateclient
 Assignee: (unassigned) => sonu (sonu-bhumca11)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in congress:
  New
Status in Designate:
  New
Status in Glance:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in Mistral:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in python-designateclient:
  New
Status in python-mistralclient:
  New
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[Anusha]

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

** Changed in: congress
 Assignee: (unassigned) => Anusha (anusha-iiitm)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in congress:
  New
Status in Designate:
  New
Status in Glance:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in Mistral:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in python-mistralclient:
  New
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[sonu]

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

** Changed in: designate
 Assignee: (unassigned) => sonu (sonu-bhumca11)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in Designate:
  New
Status in Glance:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in Mistral:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in python-mistralclient:
  New
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1500590] [NEW] On VPN Service Detials page, the "VPN Connections" label should display "None" when no connections are found

[Lucas Palm]

Public bug reported:

Currently, on the VPN Service Details page, the "VPN Connections" label
is showing a blank value when no connections are found.  I propose that
"None" should be displayed instead to provide the user with a clearer
understanding that no connection was found and also be consistent with
the "Description" label above on that same page.

** Affects: horizon
 Importance: Undecided
 Assignee: Lucas Palm (lapalm)
 Status: New

** Attachment added: "VPN Service Details Bug 2.png"
   
https://bugs.launchpad.net/bugs/1500590/+attachment/4477868/+files/VPN%20Service%20Details%20Bug%202.png

** Changed in: horizon
 Assignee: (unassigned) => Lucas Palm (lapalm)

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

Title:
  On VPN Service Detials page, the "VPN Connections" label should
  display "None" when no connections are found

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Currently, on the VPN Service Details page, the "VPN Connections"
  label is showing a blank value when no connections are found.  I
  propose that "None" should be displayed instead to provide the user
  with a clearer understanding that no connection was found and also be
  consistent with the "Description" label above on that same page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1500590/+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 1500526] Re: Deprecate config option 'use_helper_for_ns_read'

[John Kasperski]

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

Launchpad messed up and opened 3 bugs for a single bug report.

** This bug is no longer a duplicate of bug 1500527
   Deprecate config option 'use_helper_for_ns_read'  
** This bug has been marked a duplicate of bug 1500528
   Deprecate config option 'use_helper_for_ns_read'

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

Title:
  Deprecate config option 'use_helper_for_ns_read'

Status in neutron:
  New

Bug description:
  The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
  "True" as seen here:

  cfg.BoolOpt('use_helper_for_ns_read',
  default=True,
  help=_('Use the root helper to read the namespaces from '
 'the operating system.')),

  There are two places in neutron.agent.linux.ip_lib where the list of
  namespaces are retrieved:

 class IPWrapper(SubProcessBase):
  def get_namespaces(cls):
  output = cls._execute([], 'netns', ('list',))
  return [l.strip() for l in output.split('\n')]

  and

 class IpNetnsCommand(IpCommandBase):
  def exists(self, name):
  output = self._parent._execute(
  ['o'], 'netns', ['list'],
  run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
  for line in output.split('\n'):
  if name == line.strip():
  return True
  return False

  Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
  Both of these methods are called through out the code.

  The configuration option is not necessary in the first case therefore
  it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500526/+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 1496953] Re: Instance status values in CSV summary are not translated

[Doug Fish]

This got prematurely changed to fixed committed/fixed released. This was
not addressed by https://review.openstack.org/#/c/223773/

The difference is that https://review.openstack.org/#/c/223773/ is about
making *any* text in *.csv files is translatable. This bug is about a
couple of extra strings that remain untransalatable even after resources
are extracted out of csv files in general.

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

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

Title:
  Instance status values in CSV summary are not translated

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  I prepared my environment using the pseudo translation tool to use
  German.

  When I navigate to the Admin->System->Overview and click on the
  "Download CSV Summary" button, the instance status/state values
  ("Active", "Stopped") in the generated csv file are not translated
  into the locale I'm using.  However when I navigate to the instance
  the Status values are translated.

  You can see in the attached screen shot the translated values from the
  instance page and the non-translated values from the csv file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1496953/+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 1500586] [NEW] VPN Service Details page has confusing/useless labels

[Lucas Palm]

Public bug reported:

On the VPN Service Details Page, there are a few labeling issues that
are confusing and useless to the user.

I propose the following fixes to improve the user-experience on this
page:

- The "Router ID"  label is showing the Router name, not the ID.  This
label should be changed to "Router Name".

- "Project ID" and "Subnet ID" labels should also be changed to "Project
Name" and "Subnet Name".  The corresponding names should then be
displayed instead of the ID's.  To the everyday Horizon user, an ID is
not as useful as a name.

- For the new "Project Name" and Subnet Name" labels mentioned above,
the name should be a link to the corresponding details page for that
item, much like the current router name implementation.  If the user
really wants to see the ID, they should just click that link to visit
the details page for that item.

** Affects: horizon
 Importance: Undecided
 Assignee: Lucas Palm (lapalm)
 Status: New

** Attachment added: "VPN Service Details Bug 1.png"
   
https://bugs.launchpad.net/bugs/1500586/+attachment/4477857/+files/VPN%20Service%20Details%20Bug%201.png

** Changed in: horizon
 Assignee: (unassigned) => Lucas Palm (lapalm)

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

Title:
  VPN Service Details page has confusing/useless labels

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  On the VPN Service Details Page, there are a few labeling issues that
  are confusing and useless to the user.

  I propose the following fixes to improve the user-experience on this
  page:

  - The "Router ID"  label is showing the Router name, not the ID.  This
  label should be changed to "Router Name".

  - "Project ID" and "Subnet ID" labels should also be changed to
  "Project Name" and "Subnet Name".  The corresponding names should then
  be displayed instead of the ID's.  To the everyday Horizon user, an ID
  is not as useful as a name.

  - For the new "Project Name" and Subnet Name" labels mentioned above,
  the name should be a link to the corresponding details page for that
  item, much like the current router name implementation.  If the user
  really wants to see the ID, they should just click that link to visit
  the details page for that item.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1500586/+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 1500037] Re: CLI glance client return non-informative error message when we trying download null-size image

[dshakhray]

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

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

Title:
  CLI glance client return non-informative error message when we trying
  download null-size image

Status in Glance:
  Invalid

Bug description:
  CLI (shell) glance client return a non-informative responce if we
  trying download a image with null size.

  Affected v1 and v2 API.

  Steps to reproduce:

  1. Create a new zero size image:

  agalkin@rinner:~$ glance image-create
  +--+--+
  | Property | Value|
  +--+--+
  | checksum | None |
  | container_format | None |
  | created_at   | 2015-09-26T14:29:50Z |
  | disk_format  | None |
  | id   | ad655133-2165-48d7-9134-d24dfe0773ba |
  | min_disk | 0|
  | min_ram  | 0|
  | name | None |
  | owner| d127c7f11f68427092ef009f0782bac2 |
  | protected| False|
  | size | None |
  | status   | queued   |
  | tags | []   |
  | updated_at   | 2015-09-26T14:29:50Z |
  | virtual_size | None |
  | visibility   | private  |
  +--+--+

  2. Trying to download this image.

  ---
  by API v1:
  ---

  agalkin@rinner:~$ glance --os-image-api-version 1 image-download 
ad655133-2165-48d7-9134-d24dfe0773ba  >> image.tmp
  404 Not Found: The resource could not be found.: Image 
ad655133-2165-48d7-9134-d24dfe0773ba is not active (HTTP 404)

  
  --
  by API v2:
  --

  agalkin@rinner:~$ glance --os-image-api-version 2 image-download 
ad655133-2165-48d7-9134-d24dfe0773ba >> image.tmp
  'NoneType' object has no attribute 'close'

  or:

  agalkin@rinner:~$ glance --os-image-api-version 2 image-download 
ad655133-2165-48d7-9134-d24dfe0773ba --progress  >> image.tmp
  NoneType object is not an iterator

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1500037/+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 1500509] [NEW] Define paste entrypoints

[Brant Knudson]

Public bug reported:

oslo.middleware middlewares should define the entry points for the
factories.

In setup.cfg:

[entry_points]
paste.filter_factory =
request_id = oslo_middleware:RequestId.factory

(Or whatever you want to call the entrypoint)

Then we can use it in keystone instead of defining our own.

Here's how it's used in keystone:

[filter:request_id]
use = egg:keystone#request_id

So we'd change to "use = egg:oslo.incubator#request_id".

And then eventually we can remove the line from keystone-paste.ini.

** Affects: keystone
 Importance: Wishlist
 Status: New

** Affects: oslo.middleware
 Importance: Undecided
 Status: New

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

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

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

Title:
  Define paste entrypoints

Status in Keystone:
  New
Status in oslo.middleware:
  New

Bug description:
  oslo.middleware middlewares should define the entry points for the
  factories.

  In setup.cfg:

  [entry_points]
  paste.filter_factory =
  request_id = oslo_middleware:RequestId.factory

  (Or whatever you want to call the entrypoint)

  Then we can use it in keystone instead of defining our own.

  Here's how it's used in keystone:

  [filter:request_id]
  use = egg:keystone#request_id

  So we'd change to "use = egg:oslo.incubator#request_id".

  And then eventually we can remove the line from keystone-paste.ini.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500509/+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 1500527] [NEW] Deprecate config option 'use_helper_for_ns_read'

[John Kasperski]

Public bug reported:

The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:

cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
   'the operating system.')),

There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:

   class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]

and

   class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False

Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
Both of these methods are called through out the code.

The configuration option is not necessary in the first case therefore it
should be removed.

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  Deprecate config option 'use_helper_for_ns_read'

Status in neutron:
  New

Bug description:
  The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
  "True" as seen here:

  cfg.BoolOpt('use_helper_for_ns_read',
  default=True,
  help=_('Use the root helper to read the namespaces from '
 'the operating system.')),

  There are two places in neutron.agent.linux.ip_lib where the list of
  namespaces are retrieved:

 class IPWrapper(SubProcessBase):
  def get_namespaces(cls):
  output = cls._execute([], 'netns', ('list',))
  return [l.strip() for l in output.split('\n')]

  and

 class IpNetnsCommand(IpCommandBase):
  def exists(self, name):
  output = self._parent._execute(
  ['o'], 'netns', ['list'],
  run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
  for line in output.split('\n'):
  if name == line.strip():
  return True
  return False

  Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
  Both of these methods are called through out the code.

  The configuration option is not necessary in the first case therefore
  it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500527/+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 1500526] [NEW] Deprecate config option 'use_helper_for_ns_read'

[John Kasperski]

Public bug reported:

The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:

cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
   'the operating system.')),

There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:

   class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]

and

   class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False

Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
Both of these methods are called through out the code.

The configuration option is not necessary in the first case therefore it
should be removed.

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  Deprecate config option 'use_helper_for_ns_read'

Status in neutron:
  New

Bug description:
  The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
  "True" as seen here:

  cfg.BoolOpt('use_helper_for_ns_read',
  default=True,
  help=_('Use the root helper to read the namespaces from '
 'the operating system.')),

  There are two places in neutron.agent.linux.ip_lib where the list of
  namespaces are retrieved:

 class IPWrapper(SubProcessBase):
  def get_namespaces(cls):
  output = cls._execute([], 'netns', ('list',))
  return [l.strip() for l in output.split('\n')]

  and

 class IpNetnsCommand(IpCommandBase):
  def exists(self, name):
  output = self._parent._execute(
  ['o'], 'netns', ['list'],
  run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
  for line in output.split('\n'):
  if name == line.strip():
  return True
  return False

  Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
  Both of these methods are called through out the code.

  The configuration option is not necessary in the first case therefore
  it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500526/+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 1500528] [NEW] Deprecate config option 'use_helper_for_ns_read'

[John Kasperski]

Public bug reported:

The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:

cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
   'the operating system.')),

There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:

   class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]

and

   class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False

Both methods are calling "ip netns list", but only one is actually using
the configuration option. Both of these methods are called through out
the code.

The configuration option is not necessary in the first case therefore it
should be removed.

** Affects: neutron
 Importance: Undecided
 Assignee: John Kasperski (jckasper)
 Status: New

** Description changed:

  The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
  "True" as seen here:
  
- cfg.BoolOpt('use_helper_for_ns_read',
- default=True,
- help=_('Use the root helper to read the namespaces from '
-'the operating system.')),
+ cfg.BoolOpt('use_helper_for_ns_read',
+ default=True,
+ help=_('Use the root helper to read the namespaces from '
+    'the operating system.')),
  
  There are two places in neutron.agent.linux.ip_lib where the list of
  namespaces are retrieved:
  
-class IPWrapper(SubProcessBase):
- def get_namespaces(cls):
- output = cls._execute([], 'netns', ('list',))
- return [l.strip() for l in output.split('\n')]
+    class IPWrapper(SubProcessBase):
+ def get_namespaces(cls):
+ output = cls._execute([], 'netns', ('list',))
+ return [l.strip() for l in output.split('\n')]
  
  and
  
-class IpNetnsCommand(IpCommandBase):
- def exists(self, name):
- output = self._parent._execute(
- ['o'], 'netns', ['list'],
- run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
- for line in output.split('\n'):
- if name == line.strip():
- return True
- return False
+    class IpNetnsCommand(IpCommandBase):
+ def exists(self, name):
+ output = self._parent._execute(
+ ['o'], 'netns', ['list'],
+ run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
+ for line in output.split('\n'):
+ if name == line.strip():
+ return True
+ return False
  
- Both methods are calling "ip netns list", but only one is actually using the 
configuration option. 
- Both of these methods are called through out the code.
+ Both methods are calling "ip netns list", but only one is actually using
+ the configuration option. Both of these methods are called through out
+ the code.
  
  The configuration option is not necessary in the first case therefore it
  should be removed.

** Changed in: neutron
 Assignee: (unassigned) => John Kasperski (jckasper)

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

Title:
  Deprecate config option 'use_helper_for_ns_read'

Status in neutron:
  New

Bug description:
  The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
  "True" as seen here:

  cfg.BoolOpt('use_helper_for_ns_read',
  default=True,
  help=_('Use the root helper to read the namespaces from '
     'the operating system.')),

  There are two places in neutron.agent.linux.ip_lib where the list of
  namespaces are retrieved:

     class IPWrapper(SubProcessBase):
  def get_namespaces(cls):
  output = cls._execute([], 'netns', ('list',))
  return [l.strip() for l in output.split('\n')]

  and

     class IpNetnsCommand(IpCommandBase):
  def exists(self, name):
  output = self._parent._execute(
  ['o'], 'netns', ['list'],
  run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
  for line in output.split('\n'):
  if name == line.strip():
  return True
  return False

  Both methods are calling "ip netns list", but only one is actually
  using the configuration option. Both of these methods are called
  through out the code.

  The configuration option is not necessary in the first case therefore
  it should be removed.

To manage notifications 

[Yahoo-eng-team] [Bug 1500607] [NEW] Load Balancer's Status Tree API is not documented

[Michael Johnson]

Public bug reported:

The LBaaSv2 API to query the status tree is not documented in the
OpenStack API documentation here: http://developer.openstack.org/api-
ref-networking-v2-ext.html#lbaas-v2.0

I would expect to see a section for:
/lbaas/loadbalancers/loadbalancer_id/statuses

The Kosmos (GSLB) team is interested in using this API.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: lbaas

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

Title:
  Load Balancer's Status Tree API is not documented

Status in neutron:
  New

Bug description:
  The LBaaSv2 API to query the status tree is not documented in the
  OpenStack API documentation here: http://developer.openstack.org/api-
  ref-networking-v2-ext.html#lbaas-v2.0

  I would expect to see a section for:
  /lbaas/loadbalancers/loadbalancer_id/statuses

  The Kosmos (GSLB) team is interested in using this API.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500607/+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 1500615] Re: Large Ops scenario is taking too long

[Matt Riedemann]

The test itself is creating 100 instances at once:

http://logs.openstack.org/23/226923/5/gate/gate-tempest-dsvm-large-
ops/826845d/logs/tempest_conf.txt.gz

large_ops_number = 100

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

** Changed in: nova
   Importance: Critical => High

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

Title:
  Large Ops scenario is taking too long

Status in devstack:
  New
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  gate-tempest-dsvm-large-ops error rate is spiking since the last 24
  hours (http://goo.gl/G9Zazy) with the following stacktrace :

  2015-09-28 15:02:50.954 | Traceback (most recent call last):
  2015-09-28 15:02:50.954 |   File "tempest/test.py", line 127, in wrapper
  2015-09-28 15:02:50.954 | return f(self, *func_args, **func_kwargs)
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
138, in test_large_ops_scenario_3
  2015-09-28 15:02:50.954 | self._large_ops_scenario()
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
123, in _large_ops_scenario
  2015-09-28 15:02:50.954 | self.nova_boot()
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
119, in nova_boot
  2015-09-28 15:02:50.954 | self._wait_for_server_status('ACTIVE')
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
81, in _wait_for_server_status
  2015-09-28 15:02:50.955 | server['id'], status)
  2015-09-28 15:02:50.955 |   File "tempest/common/waiters.py", line 95, in 
wait_for_server_status
  2015-09-28 15:02:50.955 | raise exceptions.TimeoutException(message)
  2015-09-28 15:02:50.955 | tempest.exceptions.TimeoutException: Request timed 
out

  http://logs.openstack.org/23/226923/5/gate/gate-tempest-dsvm-large-
  ops/826845d/console.html#_2015-09-28_15_02_50_955

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1500615/+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 1500459] [NEW] Validating federated fernet token loses user domain info

[Brant Knudson]

Public bug reported:


When using UUID tokens, after token validation the user's domain info is filled 
in. For federated ephemeral users the domain ID and name are both the set to 
the [federation].federated_domain_name config value.[1].

When using fernet tokens, the user domain info isn't filled in.

We've got code in keystone that assumes that all users are going to have
the domain info filled in, for example TokenModel raises UnexpectedError
if the user info in the token doesn't have a domain name or ID, and
doesn't provide a way to check if the user has a domain name or ID
first.[2] (Why does keystone have multiple ways to represent a token??)

The domain info should be filled in when using fernet tokens so that it
works like the other providers.

[1]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n589

[2]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/token_model.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n112

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

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

Title:
  Validating federated fernet token loses user domain info

Status in Keystone:
  In Progress

Bug description:
  
  When using UUID tokens, after token validation the user's domain info is 
filled in. For federated ephemeral users the domain ID and name are both the 
set to the [federation].federated_domain_name config value.[1].

  When using fernet tokens, the user domain info isn't filled in.

  We've got code in keystone that assumes that all users are going to
  have the domain info filled in, for example TokenModel raises
  UnexpectedError if the user info in the token doesn't have a domain
  name or ID, and doesn't provide a way to check if the user has a
  domain name or ID first.[2] (Why does keystone have multiple ways to
  represent a token??)

  The domain info should be filled in when using fernet tokens so that
  it works like the other providers.

  [1]
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n589

  [2]
  
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/models/token_model.py?id=3d989e8815c5fe932bb6e7a3e0541e8c75046225#n112

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500459/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[hardik]

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

** Changed in: python-mistralclient
 Assignee: (unassigned) => hardik (hardik-parekh047)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in Mistral:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in python-mistralclient:
  New
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1493453] Re: [SRU] vendor_data isn't parsed properly when using the nocloud datasource

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu9

---
cloud-init (0.7.7~bzr1091-0ubuntu9) vivid; urgency=medium

  * d/patches/lp-1493453-nocloudds-vendor_data.patch:
- fix vendor_data variable assignment for the NoCloud Datasource
  (LP: #1493453).

  * d/patches/lp-1461242-generate-ed25519-host-keys.patch:
- ssh: generate ed25519 host keys if supported (LP: #1461242).

 -- Ben Howard   Tue, 22 Sep 2015 15:02:06 -0600

** Changed in: cloud-init (Ubuntu Vivid)
   Status: Fix Committed => Fix Released

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

Title:
  [SRU] vendor_data isn't parsed properly when using the nocloud
  datasource

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Committed
Status in cloud-init source package in Vivid:
  Fix Released
Status in cloud-init source package in Wily:
  Fix Released

Bug description:
  SRU Justification:

  [IMPACT] The NoCloud Datasource assigns vendor_data to the wrong
  cloud-init internal variable. This causes the vendor_data to be
  improperly parsed, and prevents it from being consummed.

  [FIX] See original report below

  [TESTING]
  1. Start in-cloud instance
  2. Update cloud-init to version in proposed
  3. Populate /var/lib/cloud/seed/nocloud/{user,meta,vendor}-data:

    meta-data:
   instance-id: testing

    user-data:
   #cloud-config
   packages:
   - pastebinit

    vendor-data:
   #cloud-config
   runcmd:
   - [ "touch", "/tmp/vd-worked" ]

  3. Configure instance for NoCloud DS:

  $ cat > /etc/cloud/cloud.cfg.d/999-sru.cfg 

[Yahoo-eng-team] [Bug 1461242] Re: cloud-init does not generate ed25519 keys

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu9

---
cloud-init (0.7.7~bzr1091-0ubuntu9) vivid; urgency=medium

  * d/patches/lp-1493453-nocloudds-vendor_data.patch:
- fix vendor_data variable assignment for the NoCloud Datasource
  (LP: #1493453).

  * d/patches/lp-1461242-generate-ed25519-host-keys.patch:
- ssh: generate ed25519 host keys if supported (LP: #1461242).

 -- Ben Howard   Tue, 22 Sep 2015 15:02:06 -0600

** Changed in: cloud-init (Ubuntu Vivid)
   Status: Fix Committed => Fix Released

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

Title:
  cloud-init does not generate ed25519 keys

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Released
Status in cloud-init source package in Utopic:
  Invalid
Status in cloud-init source package in Vivid:
  Fix Released
Status in cloud-init source package in Wily:
  Fix Released

Bug description:
  Cloud-init does not generate ed25519 hosts keys as expected. Ubuntu
  14.04 and later have SSH configurations expecting ed25519 keys by
  default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1461242/+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 1493453] Re: [SRU] vendor_data isn't parsed properly when using the nocloud datasource

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.12

---
cloud-init (0.7.5-0ubuntu1.12) trusty; urgency=medium

  * d/patches/lp-1493453-nocloudds-vendor_data.patch:
- fix vendor_data variable assignment for the NoCloud Datasource
  (LP: #1493453).

 -- Ben Howard   Mon, 21 Sep 2015 15:24:17 -0600

** Changed in: cloud-init (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

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

Title:
  [SRU] vendor_data isn't parsed properly when using the nocloud
  datasource

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Released
Status in cloud-init source package in Vivid:
  Fix Released
Status in cloud-init source package in Wily:
  Fix Released

Bug description:
  SRU Justification:

  [IMPACT] The NoCloud Datasource assigns vendor_data to the wrong
  cloud-init internal variable. This causes the vendor_data to be
  improperly parsed, and prevents it from being consummed.

  [FIX] See original report below

  [TESTING]
  1. Start in-cloud instance
  2. Update cloud-init to version in proposed
  3. Populate /var/lib/cloud/seed/nocloud/{user,meta,vendor}-data:

    meta-data:
   instance-id: testing

    user-data:
   #cloud-config
   packages:
   - pastebinit

    vendor-data:
   #cloud-config
   runcmd:
   - [ "touch", "/tmp/vd-worked" ]

  3. Configure instance for NoCloud DS:

  $ cat > /etc/cloud/cloud.cfg.d/999-sru.cfg 

[Yahoo-eng-team] [Bug 1500468] [NEW] [Sahara] Cluster Node Process list display is unsightly

[Chad Roberts]

Public bug reported:

** Low Priority **

Under Data Processing -> Clusters ->  to see the
details page, then click on the Node Groups tab.

The alignment of the list of node processes is rather ugly.  The dots
for the list appear to the left of everything else in the node group
details.  It seems like the list should be indented with respect to the
Node Processes label.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: sahara

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

Title:
  [Sahara] Cluster Node Process list display is unsightly

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  ** Low Priority **

  Under Data Processing -> Clusters ->  to see the
  details page, then click on the Node Groups tab.

  The alignment of the list of node processes is rather ugly.  The dots
  for the list appear to the left of everything else in the node group
  details.  It seems like the list should be indented with respect to
  the Node Processes label.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1500468/+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 1500365] Re: neutron port API does not support atomicity

[Eugene Nikanorov]

>From API perspective, there is no restriction on port ownership within one 
>tenant. 
If tenant wants to change the ownership - it can do that. Also, there is no 
problems with atomicity, because API calls act quite atomically. 
What you are looking for is transactional semantics where such client problem 
could be resolved, but I don't think neutron is going to provide such ability 
any time soon, and also I don't think it is on the map.

** Changed in: neutron
   Status: New => 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/1500365

Title:
  neutron port API does not support atomicity

Status in neutron:
  Opinion

Bug description:
  Neutron port API offers an update method where the user of the API can say "I 
use this port" by setting the device_owner and device_id fields of the port. 
However the neutron API does not prevent port allocation race conditions.
  The API semantic is that a port is used if the device_id and the device_owner 
fields are set, and not used if they aren't.  Now lets have two clients that 
both want to set the ownership of the port. Both clients first have to check if 
the port is free or not by checking the value of the device_owner and device_id 
fields of the port, then they have to set the those fields to express 
ownership. 
  If the two clients act parallel it is pretty much possible that both clients 
see that the fields are empty and both issue the port update command. This can 
leads to race conditions between clients.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500365/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[MD NADEEM]

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

** Changed in: zaqar
 Assignee: (unassigned) => MD NADEEM (mail2nadeem92)

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

** Changed in: python-zaqarclient
 Assignee: (unassigned) => MD NADEEM (mail2nadeem92)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in Python client library for Zaqar:
  New
Status in Sahara:
  Fix Released
Status in zaqar:
  New

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1500337] [NEW] Rollback of live-migration fails in the case of cinder with the NFS driver

[Hiroyuki Eguchi]

Public bug reported:

This error occurs under the following situations.

- cinder is using the NFS driver.
- cinder volume is attached to the instance.
- fail to live migrate before destination host attach to the NFS server

We should consider whether destination host has mounted to NFS server or
not when executing rollback of live-migration .



ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf umount 
/var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b
Exit code: 32
Stdout: u''
Stderr: u'umount: /var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b: not 
mounted\n'

** Affects: nova
 Importance: Undecided
 Assignee: Hiroyuki Eguchi (h-eguchi)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Hiroyuki Eguchi (h-eguchi)

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

Title:
  Rollback of live-migration fails in the case of cinder with the NFS
  driver

Status in OpenStack Compute (nova):
  New

Bug description:
  This error occurs under the following situations.

  - cinder is using the NFS driver.
  - cinder volume is attached to the instance.
  - fail to live migrate before destination host attach to the NFS server

  We should consider whether destination host has mounted to NFS server
  or not when executing rollback of live-migration .

  

  ProcessExecutionError: Unexpected error while running command.
  Command: sudo nova-rootwrap /etc/nova/rootwrap.conf umount 
/var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b
  Exit code: 32
  Stdout: u''
  Stderr: u'umount: /var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b: not 
mounted\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1500337/+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 1500400] [NEW] Functional tests do not work with Python 3

[Cyril Roelandt]

Public bug reported:

Running the functional tests (tox -efunctional) with python 3 is not
possible yet.

** Affects: neutron
 Importance: Undecided
 Assignee: Cyril Roelandt (cyril-roelandt)
 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/1500400

Title:
  Functional tests do not work with Python 3

Status in neutron:
  In Progress

Bug description:
  Running the functional tests (tox -efunctional) with python 3 is not
  possible yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500400/+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 1487086] Re: Pagination doesn't work with v2 API image-list

[Kairat Kushaev]

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

** Project changed: glance => python-glanceclient

** Changed in: python-glanceclient
   Status: New => In Progress

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

Title:
  Pagination doesn't work with v2 API image-list

Status in python-glanceclient:
  In Progress

Bug description:
  It would useful to allow users to output list of images by pages.
  But right now it is not possible because glance client v2 doesn't have marker 
parameter defined.

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-glanceclient/+bug/1487086/+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 1497066] Re: If IP version is not specified while creating Firewall Rule, then it should populate it based on the Source and Destination IP

[OpenStack Infra]

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

** Changed in: neutron
   Status: Opinion => 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/1497066

Title:
  If IP version is not specified while creating Firewall Rule, then it
  should populate it based on the Source and Destination IP

Status in neutron:
  In Progress

Bug description:
  Example:
  reedip@reedip-VirtualBox:/opt/stack/python-neutronclient/neutronclient$ 
neutron firewall-rule-create --protocol tcp --action deny --source-ip-address 
1::1
  Created a new firewall_rule:
  ++--+
  | Field  | Value|
  ++--+
  | action | deny |
  | description|  |
  | destination_ip_address |  |
  | destination_port   |  |
  | enabled| True |
  | firewall_policy_id |  |
  | id | dca8cb81-f65b-4eef-afbe-60d0abb5eecf |
  | ip_version | 4|
  | name   |  |
  | position   |  |
  | protocol   | tcp  |
  | shared | False|
  | source_ip_address  | 1::1 |
  | source_port|  |
  | tenant_id  | 83bb2407a0fb484581bde56dc1fae293 |
  ++--+
  reedip@reedip-VirtualBox:/opt/stack/python-neutronclient/neutronclient$

  On specifying IPv6 source address, the ip_version is populated as IPv4 which 
is not right.
  If IP Version is not specified, then in that case IP version should retrieve 
the data from Source/Destination IP.

  
  Need to confirm additional test case:
  - If IP version is specified and it does not match the IP version of 
Source/Destination Address then failure should be reported
  ( if --ip-version is given as 6 and source address is given as 192.168.101.1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1497066/+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 1500385] [NEW] Change region selector requires 2 ciicks to open

[Timur Sufiev]

Public bug reported:

This behavior is true only for stable/kilo branch and is not seen in
liberty release due to a different codebase.

** Affects: horizon
 Importance: Undecided
 Assignee: Timur Sufiev (tsufiev-x)
 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/1500385

Title:
  Change region selector requires 2 ciicks to open

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  This behavior is true only for stable/kilo branch and is not seen in
  liberty release due to a different codebase.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1500385/+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 1500361] [NEW] Generated config files are completely wrong

[Thomas Goirand]

Public bug reported:

The files generated using oslo-config-generator are completely wrong.
For example, it is missing [keystone_authtoken] and many more. This
shows on the example config in git (ie: etc/glance-api.conf in Glance's
git repo).

I believe the generator's config files is missing --namespace
keystonemiddleware.auth_token (maybe instead of
keystoneclient.middleware.auth_token).

IMO, this is a critical issue, which should be addressed with highest
priority. This blocks me from testing Liberty rc1 in Debian.

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  Generated config files are completely wrong

Status in Glance:
  New

Bug description:
  The files generated using oslo-config-generator are completely wrong.
  For example, it is missing [keystone_authtoken] and many more. This
  shows on the example config in git (ie: etc/glance-api.conf in
  Glance's git repo).

  I believe the generator's config files is missing --namespace
  keystonemiddleware.auth_token (maybe instead of
  keystoneclient.middleware.auth_token).

  IMO, this is a critical issue, which should be addressed with highest
  priority. This blocks me from testing Liberty rc1 in Debian.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1500361/+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 1500365] [NEW] neutron port API does not support atomicity

[Balazs Gibizer]

Public bug reported:

Neutron port API offers an update method where the user of the API can say "I 
use this port" by setting the device_owner and device_id fields of the port. 
However the neutron API does not prevent port allocation race conditions.
The API semantic is that a port is used if the device_id and the device_owner 
fields are set, and not used if they aren't.  Now lets have two clients that 
both want to set the ownership of the port. Both clients first have to check if 
the port is free or not by checking the value of the device_owner and device_id 
fields of the port, then they have to set the those fields to express 
ownership. 
If the two clients act parallel it is pretty much possible that both clients 
see that the fields are empty and both issue the port update command. This can 
leads to race conditions between clients.

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  neutron port API does not support atomicity

Status in neutron:
  New

Bug description:
  Neutron port API offers an update method where the user of the API can say "I 
use this port" by setting the device_owner and device_id fields of the port. 
However the neutron API does not prevent port allocation race conditions.
  The API semantic is that a port is used if the device_id and the device_owner 
fields are set, and not used if they aren't.  Now lets have two clients that 
both want to set the ownership of the port. Both clients first have to check if 
the port is free or not by checking the value of the device_owner and device_id 
fields of the port, then they have to set the those fields to express 
ownership. 
  If the two clients act parallel it is pretty much possible that both clients 
see that the fields are empty and both issue the port update command. This can 
leads to race conditions between clients.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500365/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

[hardik]

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

** Changed in: mistral
 Assignee: (unassigned) => hardik (hardik-parekh047)

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Keystone:
  In Progress
Status in Manila:
  In Progress
Status in Mistral:
  In Progress
Status in murano:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in Python client library for Zaqar:
  New
Status in Sahara:
  Fix Released
Status in zaqar:
  New

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1500631] [NEW] ldap url option actually supports multiple URIs

[Eric Brown]

Public bug reported:

The help text for the ldap.url config option states: "URL for connecting
to the LDAP server."  This implies only one URL can be specified.  But
actually, multiple may be specified due to the python-ldap module being
used.

The python-ldap module is basically a wrapper for the openldap client
library.  And if you look into the source, ldap.initialize() calls
ldap_initialize() which supports multiple URIs in the URI string.  And
is easily found in the man page for ldap_initialize:

ldap_initialize()  acts like ldap_init(), but it returns an integer indicating 
either suc‐
 cess or the failure reason, and it allows to specify details for  the  
connection  in  the
 schema portion of the URI.  The uri parameter may be a comma- or 
whitespace-separated list
 of URIs containing only the schema, the host, and the port fields. .

So I did try comma separated ldap URLs in keystone, which worked as I
would expect.  It attempts connections with the first host and tries the
next if it fails to bind.  My simple example using python-ldap where
there is no ldap server at localhost, but there is at ldaps.company.com

l = ldap.initialize('ldap://localhost:389,ldaps://ldaps.company.com:636')
 l.simple_bind_s()
(97, [], 1, [])

The same works in keystone, so the keystone config help should be
updated to show this is actually a supported option.  Its very useful
for deployers using AD where there is commonly redundancy using many
domain controllers behind that one domain.

Note: the whitespace-separated list did not work for me, only comma.

** Affects: keystone
 Importance: Low
 Assignee: Eric Brown (ericwb)
 Status: In Progress


** Tags: ldap

** Tags added: ldap

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

Title:
  ldap url option actually supports multiple URIs

Status in Keystone:
  In Progress

Bug description:
  The help text for the ldap.url config option states: "URL for
  connecting to the LDAP server."  This implies only one URL can be
  specified.  But actually, multiple may be specified due to the python-
  ldap module being used.

  The python-ldap module is basically a wrapper for the openldap client
  library.  And if you look into the source, ldap.initialize() calls
  ldap_initialize() which supports multiple URIs in the URI string.  And
  is easily found in the man page for ldap_initialize:

  ldap_initialize()  acts like ldap_init(), but it returns an integer 
indicating either suc‐
   cess or the failure reason, and it allows to specify details for  the  
connection  in  the
   schema portion of the URI.  The uri parameter may be a comma- or 
whitespace-separated list
   of URIs containing only the schema, the host, and the port fields. .

  So I did try comma separated ldap URLs in keystone, which worked as I
  would expect.  It attempts connections with the first host and tries
  the next if it fails to bind.  My simple example using python-ldap
  where there is no ldap server at localhost, but there is at
  ldaps.company.com

  l = ldap.initialize('ldap://localhost:389,ldaps://ldaps.company.com:636')
   l.simple_bind_s()
  (97, [], 1, [])

  The same works in keystone, so the keystone config help should be
  updated to show this is actually a supported option.  Its very useful
  for deployers using AD where there is commonly redundancy using many
  domain controllers behind that one domain.

  Note: the whitespace-separated list did not work for me, only comma.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500631/+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 1500567] [NEW] port binding host_id does not update when removing openvswitch agent

[Charlie Ott]

Public bug reported:

SPECS:
Openstack Juno
neutron version 2.3.9
nova version 2.20.0
OS: CentOS 6.5 Final
kernel: 2.6.32-504.1.3.el6.mos61.x86_64 (Mirantis Fuel 6.1 installed 
compute+ceph node)


SCENARIO:
I had a compute node that was also running an neutron-openvswitch-agent.  This 
was 'node-12'.
Before node-12's primary disk died, there was an instance being hosted on the 
node, which was in the state 'SHUTDOWN'.
I have created a node-15, which also runs the neutron-openvswitch-agent with 
nova-compute.  I did not migrate the instance before perfroming a neutron 
agent-delete on node-12, so now there is metadata that looks like this:

[root@node-14 ~]# neutron port-show c209538b-ecc1-4414-9f97-e0f6a5d08ecc
+---+--+
| Field | Value 
   |
+---+--+
| admin_state_up| True  
   |
| allowed_address_pairs |   
   |
| binding:host_id   | node-12


ACTION:
Node-12 neutron agent is deleted, using the command, `neutron agent-delete 
6bcadbe2-7631-41f5-9124-6fe75016217a`

EXPECTED:
all neturon ports bound with that agent should be updated and modified to use 
an alternative binding host_id, preferably the host currently running the VM. 
In my scenario, this would be node-15. NOT node-12.

ACTUAL:
The neutron ports maintained the same binding:host_id, which was node-12.


ADDITIONAL INFORMATION:

I was able to update the value using the following request:

curl -X PUT -d '{"port":{"binding:host_id": "node-15.domain.com"}}' -H
"X-Auth_token:f3f1c03239b246a8a7ffa9ca0eb323bf" -H "Content-type:
application/json"
http://10.10.30.2:9696/v2.0/ports/f98fe798-d522-4b6c-b084-45094fdc5052.json

However, I'm not sure if there are modifications to the openvswitch
agent on node-15 that also need to be performed.

Also, since my node-12 died before I could migrate the instances, and I
attempted to power them on before i realized they needed migration, I
was forced to update the instances table in the database, and specify
node-15 as the new host.

> update instances set task_state = NULL where task_state = 'powering-on';
> update instances set host = 'node-15.domain.com' where host = 
> 'node-12.domain.com';
> update instances set node = 'node-15.domain.com' where node = 
> 'node-12.domain.com';
> update instances set launched_on = 'node-15.domain.com' where launched_on = 
> 'node-12.domain.com';

In my case, the work around is to kick off a 'migrate', in which case
the binding:host_id is updated.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: network neutron-core

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

Title:
  port binding host_id does not update when removing openvswitch agent

Status in neutron:
  New

Bug description:
  SPECS:
  Openstack Juno
  neutron version 2.3.9
  nova version 2.20.0
  OS: CentOS 6.5 Final
  kernel: 2.6.32-504.1.3.el6.mos61.x86_64 (Mirantis Fuel 6.1 installed 
compute+ceph node)

  
  SCENARIO:
  I had a compute node that was also running an neutron-openvswitch-agent.  
This was 'node-12'.
  Before node-12's primary disk died, there was an instance being hosted on the 
node, which was in the state 'SHUTDOWN'.
  I have created a node-15, which also runs the neutron-openvswitch-agent with 
nova-compute.  I did not migrate the instance before perfroming a neutron 
agent-delete on node-12, so now there is metadata that looks like this:

  [root@node-14 ~]# neutron port-show c209538b-ecc1-4414-9f97-e0f6a5d08ecc
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | admin_state_up| True
 |
  | allowed_address_pairs | 
 |
  | binding:host_id   | node-12

  
  ACTION:
  Node-12 neutron agent is deleted, using the command, `neutron agent-delete 
6bcadbe2-7631-41f5-9124-6fe75016217a`

  EXPECTED:
  all neturon ports bound with that agent should be updated and modified to use 
an alternative binding host_id, preferably the host currently running the VM. 
In my scenario, this would be node-15. NOT node-12.

  ACTUAL:
  The neutron 

[Yahoo-eng-team] [Bug 1500658] [NEW] Unhandled 404 when neutron doesn't support floating IPs

[Sam Morrison]

Public bug reported:

Getting the following error in nova-api logs when neutron doesn't
support floating IPs

2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/__init__.py", line 125, in 
__call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return 
req.get_response(self.application)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1320, in send
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack application, 
catch_exc_info=False)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack app_iter = 
application(self.environ, start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return resp(environ, 
start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", 
line 634, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return 
self._call_app(env, start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py", 
line 554, in _call_app
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return self._app(env, 
_fake_start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return resp(environ, 
start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return resp(environ, 
start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/routes/middleware.py", line 131, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack response = 
self.app(environ, start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return resp(environ, 
start_response)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack resp = 
self.call_func(req, *args, **self.kwargs)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return self.func(req, 
*args, **kwargs)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 756, in 
__call__
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack content_type, body, 
accept)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 821, in 
_process_stack
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack action_result = 
self.dispatch(meth, request, action_args)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 911, in 
dispatch
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack return 
method(req=request, **action_args)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/contrib/floating_ips.py",
 line 108, in index
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack floating_ips = 
self.network_api.get_floating_ips_by_project(context)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/nova/network/neutronv2/api.py", line 1262, in 
get_floating_ips_by_project
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack fips = 
client.list_floatingips(tenant_id=project_id)['floatingips']
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 102, in 
with_params
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack ret = 
self.function(instance, *args, **kwargs)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 691, in 
list_floatingips
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack **_params)
2015-09-29 10:04:50.551 6376 TRACE nova.api.openstack   File 
"/usr/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 307, in 
list

[Yahoo-eng-team] [Bug 1499658] Re: Consume wsgi module from oslo.service

[Elena Ezhova]

I agree with you, Matt, that such refactoring is not really a bug. I
filed it to track the progress for various OpenStack projects just like
it was done a cycle or two ago when we had "Move to oslo.*" bugs.
Perhaps now each project should deal with such things in a way that is
most appropriate to it.

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

** Changed in: neutron
 Assignee: Elena Ezhova (eezhova) => (unassigned)

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

Title:
  Consume wsgi module from oslo.service

Status in Cinder:
  New
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Basic WSGI functionality has been moved to oslo.service [1] and now
  OpenStack projects can adopt it.

  [1]
  https://github.com/openstack/oslo.service/blob/master/oslo_service/wsgi.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1499658/+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 1500430] [NEW] Access to floating IP can take 30+ seconds during boot_runcommand_delete test on scale.

[Eugene Nikanorov]

Public bug reported:

For some reason simple GET access to a floating IP on a 200-node cluster
during boot_runcommand_delete test takes too much time, ranging from 0
to 35 seconds with median ~15 seconds.

That leads to timeouts on nova side.
Also, some traces in RPC workers appear: http://paste.openstack.org/show/474339/
That may indicate that the table is a contention point.
Slowdown may be caused by constant retries.

** Affects: neutron
 Importance: High
 Assignee: Eugene Nikanorov (enikanorov)
 Status: Confirmed


** Tags: scale

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

Title:
  Access to floating IP can take 30+ seconds during
  boot_runcommand_delete test on scale.

Status in neutron:
  Confirmed

Bug description:
  For some reason simple GET access to a floating IP on a 200-node
  cluster during boot_runcommand_delete test takes too much time,
  ranging from 0 to 35 seconds with median ~15 seconds.

  That leads to timeouts on nova side.
  Also, some traces in RPC workers appear: 
http://paste.openstack.org/show/474339/
  That may indicate that the table is a contention point.
  Slowdown may be caused by constant retries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500430/+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 1500615] [NEW] Large Ops scenario is taking too long

[Sylvain Bauza]

Public bug reported:

gate-tempest-dsvm-large-ops error rate is spiking since the last 24
hours (http://goo.gl/G9Zazy) with the following stacktrace :

2015-09-28 15:02:50.954 | Traceback (most recent call last):
2015-09-28 15:02:50.954 |   File "tempest/test.py", line 127, in wrapper
2015-09-28 15:02:50.954 | return f(self, *func_args, **func_kwargs)
2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
138, in test_large_ops_scenario_3
2015-09-28 15:02:50.954 | self._large_ops_scenario()
2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
123, in _large_ops_scenario
2015-09-28 15:02:50.954 | self.nova_boot()
2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
119, in nova_boot
2015-09-28 15:02:50.954 | self._wait_for_server_status('ACTIVE')
2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 81, 
in _wait_for_server_status
2015-09-28 15:02:50.955 | server['id'], status)
2015-09-28 15:02:50.955 |   File "tempest/common/waiters.py", line 95, in 
wait_for_server_status
2015-09-28 15:02:50.955 | raise exceptions.TimeoutException(message)
2015-09-28 15:02:50.955 | tempest.exceptions.TimeoutException: Request timed out

http://logs.openstack.org/23/226923/5/gate/gate-tempest-dsvm-large-
ops/826845d/console.html#_2015-09-28_15_02_50_955

** Affects: nova
 Importance: Critical
 Status: Confirmed


** Tags: testing

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

Title:
  Large Ops scenario is taking too long

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  gate-tempest-dsvm-large-ops error rate is spiking since the last 24
  hours (http://goo.gl/G9Zazy) with the following stacktrace :

  2015-09-28 15:02:50.954 | Traceback (most recent call last):
  2015-09-28 15:02:50.954 |   File "tempest/test.py", line 127, in wrapper
  2015-09-28 15:02:50.954 | return f(self, *func_args, **func_kwargs)
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
138, in test_large_ops_scenario_3
  2015-09-28 15:02:50.954 | self._large_ops_scenario()
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
123, in _large_ops_scenario
  2015-09-28 15:02:50.954 | self.nova_boot()
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
119, in nova_boot
  2015-09-28 15:02:50.954 | self._wait_for_server_status('ACTIVE')
  2015-09-28 15:02:50.954 |   File "tempest/scenario/test_large_ops.py", line 
81, in _wait_for_server_status
  2015-09-28 15:02:50.955 | server['id'], status)
  2015-09-28 15:02:50.955 |   File "tempest/common/waiters.py", line 95, in 
wait_for_server_status
  2015-09-28 15:02:50.955 | raise exceptions.TimeoutException(message)
  2015-09-28 15:02:50.955 | tempest.exceptions.TimeoutException: Request timed 
out

  http://logs.openstack.org/23/226923/5/gate/gate-tempest-dsvm-large-
  ops/826845d/console.html#_2015-09-28_15_02_50_955

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1500615/+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 1500689] [NEW] Use IPOpt to validate IP addresses

[Masaki Matsushita]

Public bug reported:

We can use cfg.IPOpt to validate IP addresses.
I think it would be helpful in common/config.py.

** Affects: keystone
 Importance: Undecided
 Assignee: Masaki Matsushita (mmasaki)
 Status: In Progress

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

Title:
  Use IPOpt to validate IP addresses

Status in Keystone:
  In Progress

Bug description:
  We can use cfg.IPOpt to validate IP addresses.
  I think it would be helpful in common/config.py.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1500689/+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 1500430] Re: Access to floating IP can take 30+ seconds during boot_runcommand_delete test on scale.

[Eugene Nikanorov]

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

** No longer affects: neutron

** Changed in: mos
 Assignee: (unassigned) => Eugene Nikanorov (enikanorov)

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

** Changed in: mos
   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/1500430

Title:
  Access to floating IP can take 30+ seconds during
  boot_runcommand_delete test on scale.

Status in Mirantis OpenStack:
  Confirmed

Bug description:
  For some reason simple GET access to a floating IP on a 200-node
  cluster during boot_runcommand_delete test takes too much time,
  ranging from 0 to 35 seconds with median ~15 seconds.

  That leads to timeouts on nova side.
  Also, some traces in RPC workers appear: 
http://paste.openstack.org/show/474339/
  That may indicate that the table is a contention point.
  Slowdown may be caused by constant retries.

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