[Yahoo-eng-team] [Bug 1427391] [NEW] Serial console cannot find instance

[Randy Bertram]

Public bug reported:

In some configurations, Serial Console says that instance cannot be
found for the giving id, even though the instance is available. It seems
to work fine in development environment, but not on system z server.

** Affects: horizon
 Importance: Undecided
 Assignee: Randy Bertram (rbertram)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) = Randy Bertram (rbertram)

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

Title:
  Serial console cannot find instance

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  In some configurations, Serial Console says that instance cannot be
  found for the giving id, even though the instance is available. It
  seems to work fine in development environment, but not on system z
  server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427391/+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 1427396] [NEW] lbaasv2 pool list not returning all data

[Phillip Toohill]

Public bug reported:

Each pool returned by the API on a request to list pools should include
all relevant data, such as, session persistence and listeners.

** Affects: neutron
 Importance: Undecided
 Assignee: Phillip Toohill (phillip-toohill)
 Status: New


** Tags: lbaas

** Changed in: neutron
 Assignee: (unassigned) = Phillip Toohill (phillip-toohill)

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

Title:
  lbaasv2 pool list not returning all data

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Each pool returned by the API on a request to list pools should
  include all relevant data, such as, session persistence and listeners.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427396/+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 1420942] Re: noVNC insecure cookie allows session hijacking

[Nathan Kinder]

This should be marked as public now.  As Tritan mentioned in comment#8,
it's already been disclosed (not to mention that we already wrote and
published an OSSN).

** Information type changed from Private Security to Public Security

** Also affects: ossn
   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/1420942

Title:
  noVNC insecure cookie allows session hijacking

Status in OpenStack Compute (Nova):
  Invalid
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459,
  where it was decided that the issues raised there were best practice
  hardening, but not practically exploitable.

  The noVNC websocket token cookie is not set as secure-only. This is
  practically exploitable by an attacker who can read user traffic.

  The setup is as follows:

  Nova and horizon configured to serve from https. Nova is patched to
  resolve #1409142.

  User is accessing the cloud through a man in the middle who controls
  all traffic to and from the user. [1]

  user - attacker - cloud(https)

  Here's what happens:
  1) User logs into cloud securely via https://yourcloud.com/
  2) User securely accesses a server via websocket VNC and logs in. User 
(optionally) closes this window.
  3) User opens a new browser tab to an insecure site (it can be any insecure 
site at all)
  4) On receiving the request for the insecure site, the attacker fetches it 
from the source, and rewrites it to include an invisible attack iframe before 
serving it to the user. [2]
  5) The attack iframe directs the user's browser to open 
http://yourcloud.com:6080 inside the hidden iframe (even if you don't serve 
that site insecurely)
  6) When the user's browser requests http://yourcloud.com:6080, the attacker 
logs the request including the cookies, and responds with a blank page.
  7) The attacker now has access to the auth token used to open the VNC socket 
(since the most recent one is sent in a cookie), and can stay connected to that 
socket indefinitely in any browser.

  A clever attacker will cycle the iframe contents repeatedly, and steal
  every VNC socket a user opens as the token cookies change, rather than
  just the most recent one. As long as the attacker stays connected to
  the socket, the connection stays open indefinitely.

  Note that the above attack does not involve the user clicking through
  any TLS warnings, and does not involve them actively clicking phishing
  links or anything similar.

  Fixing this is going to involve letting noVNC know when it is supposed to be 
behind TLS, and modifying cookie setting behavior accordingly. Django's 
documentation on this is a good starting place for a fairly standard approach 
to telling an application it is receiving HTTPS traffic:
  https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header

  -Paul

  [1] As a practical aside, it is easy to become this mitm on most local 
network segments, so users who connect to any network with any untrusted users 
are vulnerable. An attacker who can only read user traffic (without the ability 
to block or modify it) can usually become a full mitm by spoofing DNS responses.
  [2] the attacker can actually do this step at any point in the process, even 
before step 1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1420942/+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 1420942] Re: noVNC insecure cookie allows session hijacking

[Nathan Kinder]

This has been published as OSSN-0044:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0044

** Changed in: ossn
   Status: New = Fix Released

** Changed in: ossn
 Assignee: (unassigned) = Paul McMillan (paul-mcmillan)

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

Title:
  noVNC insecure cookie allows session hijacking

Status in OpenStack Compute (Nova):
  Invalid
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459,
  where it was decided that the issues raised there were best practice
  hardening, but not practically exploitable.

  The noVNC websocket token cookie is not set as secure-only. This is
  practically exploitable by an attacker who can read user traffic.

  The setup is as follows:

  Nova and horizon configured to serve from https. Nova is patched to
  resolve #1409142.

  User is accessing the cloud through a man in the middle who controls
  all traffic to and from the user. [1]

  user - attacker - cloud(https)

  Here's what happens:
  1) User logs into cloud securely via https://yourcloud.com/
  2) User securely accesses a server via websocket VNC and logs in. User 
(optionally) closes this window.
  3) User opens a new browser tab to an insecure site (it can be any insecure 
site at all)
  4) On receiving the request for the insecure site, the attacker fetches it 
from the source, and rewrites it to include an invisible attack iframe before 
serving it to the user. [2]
  5) The attack iframe directs the user's browser to open 
http://yourcloud.com:6080 inside the hidden iframe (even if you don't serve 
that site insecurely)
  6) When the user's browser requests http://yourcloud.com:6080, the attacker 
logs the request including the cookies, and responds with a blank page.
  7) The attacker now has access to the auth token used to open the VNC socket 
(since the most recent one is sent in a cookie), and can stay connected to that 
socket indefinitely in any browser.

  A clever attacker will cycle the iframe contents repeatedly, and steal
  every VNC socket a user opens as the token cookies change, rather than
  just the most recent one. As long as the attacker stays connected to
  the socket, the connection stays open indefinitely.

  Note that the above attack does not involve the user clicking through
  any TLS warnings, and does not involve them actively clicking phishing
  links or anything similar.

  Fixing this is going to involve letting noVNC know when it is supposed to be 
behind TLS, and modifying cookie setting behavior accordingly. Django's 
documentation on this is a good starting place for a fairly standard approach 
to telling an application it is receiving HTTPS traffic:
  https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header

  -Paul

  [1] As a practical aside, it is easy to become this mitm on most local 
network segments, so users who connect to any network with any untrusted users 
are vulnerable. An attacker who can only read user traffic (without the ability 
to block or modify it) can usually become a full mitm by spoofing DNS responses.
  [2] the attacker can actually do this step at any point in the process, even 
before step 1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1420942/+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 1043886] Re: Firewall rules are not updated if you restart nova-compute

[Brian Shang]

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

Title:
  Firewall rules are not updated if you restart nova-compute

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  IptablesFirewallDriver from nova/virt/firewall.py keeps a list of
  instances in self.instances.

  When nova-compute starts this is empty. It is not loaded at start in some 
way, instead
  it is filled using the prepare_instance_filter method.

  This method is called from the virt drivers in a few scenarios that are 
different on 
  libvirt and xenapi (these are the ones I checked).

  On xenapi it only happens during spawn, on libvirt it also happens
  during hard reboot.

  This means that if you have some running instances using some security group, 
and then for
  some reason restart the nova-compute service - updates to the security group 
(i.e.
  adding/removing some rule) will not be propagated to iptables correctly. On 
libvirt
  you can fix this by rebooting an instance hard. On xenapi you can't fix it.

  I added an ugly hack to make xenapi work like I want it to (but I can see 
that it is
  not fit for inclusion).  I would be happy to fix this in some less ugly way 
if someone 
  gave me a helpful hint of what the core devs would consider be a good way to 
solve it.

  To me perhaps the reasonable thing would be for IptablesFirewallDriver to 
treat
  self.instances as a cache and if some instance is not there, then check if it 
is running
  and if so - fetch the network_info + do prepare_instance_filter.

  Anyway, here is my ugly hack patch, perhaps it helps someone or gives more 
insight into 
  what I mean :-):

  --- /home/atomia/jma_backup/nova/virt/xenapi/vmops.py   2012-06-12 
15:04:56.0 +0200
  +++ /usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py  2012-08-30 
16:37:58.226715150 +0200
  @@ -32,6 +32,7 @@

   from nova.compute import api as compute
   from nova.compute import power_state
  +from nova.compute import utils as compute_utils
   from nova import context as nova_context
   from nova import db
   from nova import exception
  @@ -1749,6 +1750,16 @@

   def refresh_security_group_rules(self, security_group_id):
recreates security group rules for every instance 
  +LOG.debug(JMA: refresh_security_group_rules for  + 
str(security_group_id) + , the firewall driver is of type  + 
self.firewall_driver.__class__.__name__)
  +
  +import nova.network
  +nw_api = nova.network.API()
  +context = nova_context.get_admin_context()
  +security_group = db.security_group_get(context, security_group_id)
  +for instance in security_group['instances']:
  +nw_info = 
compute_utils.legacy_network_info(nw_api.get_instance_nw_info(context, 
instance))
  +self.firewall_driver.prepare_instance_filter(instance, nw_info)
  +
   self.firewall_driver.refresh_security_group_rules(security_group_id)

   def refresh_security_group_members(self, security_group_id):

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1043886/+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 1427432] [NEW] lbaas related(?) check-grenade-dsvm-neutron failure

[YAMAMOTO Takashi]

Public bug reported:

https://review.openstack.org/#/c/160523/  (purely doc-only change)
http://logs.openstack.org/23/160523/2/check/check-grenade-dsvm-neutron/6f82325/logs/new/screen-q-svc.txt.gz#_2015-03-02_23_28_04_319

2015-03-02 23:28:04.319 15268 TRACE neutron.common.config cls._instance = 
cls()
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 128, in __init__
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
self._load_service_plugins()
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 175, in _load_service_plugins
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config provider)
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 133, in _get_plugin_instance
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config mgr = 
driver.DriverManager(namespace, plugin_provider)
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/driver.py, line 45, in 
__init__
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
verify_requirements=verify_requirements,
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/named.py, line 55, in 
__init__
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
verify_requirements)
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/extension.py, line 170, in 
_load_plugins
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
self._on_load_failure_callback(self, ep, err)
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/driver.py, line 50, in 
_default_on_load_failure
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config raise err
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config ImportError: No 
module named neutron_lbaas.services.loadbalancer.plugin
2015-03-02 23:28:04.319 15268 TRACE neutron.common.config

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

Title:
  lbaas related(?) check-grenade-dsvm-neutron failure

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  https://review.openstack.org/#/c/160523/  (purely doc-only change)
  
http://logs.openstack.org/23/160523/2/check/check-grenade-dsvm-neutron/6f82325/logs/new/screen-q-svc.txt.gz#_2015-03-02_23_28_04_319

  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config cls._instance = 
cls()
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 128, in __init__
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
self._load_service_plugins()
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 175, in _load_service_plugins
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config provider)
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/opt/stack/new/neutron/neutron/manager.py, line 133, in _get_plugin_instance
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config mgr = 
driver.DriverManager(namespace, plugin_provider)
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/driver.py, line 45, in 
__init__
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
verify_requirements=verify_requirements,
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/named.py, line 55, in 
__init__
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
verify_requirements)
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/extension.py, line 170, in 
_load_plugins
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config 
self._on_load_failure_callback(self, ep, err)
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config   File 
/usr/local/lib/python2.7/dist-packages/stevedore/driver.py, line 50, in 
_default_on_load_failure
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config raise err
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config ImportError: No 
module named neutron_lbaas.services.loadbalancer.plugin
  2015-03-02 23:28:04.319 15268 TRACE neutron.common.config

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427432/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : 

[Yahoo-eng-team] [Bug 1427440] [NEW] V2 only keystone wont start - revoke not in loaded backends

[Jamie Lennox]

Public bug reported:

2015-03-03 00:22:25.674809 mod_wsgi (pid=10468): Target WSGI script 
'/var/www/keystone/main' cannot be loaded as Python module.
2015-03-03 00:22:25.674835 mod_wsgi (pid=10468): Exception occurred processing 
WSGI script '/var/www/keystone/main'.
2015-03-03 00:22:25.674856 Traceback (most recent call last):
2015-03-03 00:22:25.674872   File /var/www/keystone/main, line 25, in module
2015-03-03 00:22:25.674947 application = 
wsgi_server.initialize_application(name)
2015-03-03 00:22:25.674970   File 
/opt/stack/keystone/keystone/server/wsgi.py, line 51, in 
initialize_application
2015-03-03 00:22:25.675021 startup_application_fn=loadapp)
2015-03-03 00:22:25.675041   File 
/opt/stack/keystone/keystone/server/common.py, line 44, in setup_backends
2015-03-03 00:22:25.675086 
drivers.update(dependency.resolve_future_dependencies())
2015-03-03 00:22:25.675098   File 
/opt/stack/keystone/keystone/common/dependency.py, line 287, in 
resolve_future_dependencies
2015-03-03 00:22:25.675177 raise 
UnresolvableDependencyException(dependency, targets)
2015-03-03 00:22:25.675466 UnresolvableDependencyException: Unregistered 
dependency: revoke_api for [keystone.identity.core.Manager object at 
0x7f68e6b1ad10, keystone.assignment.core.Manager object at 0x7f68e6888910, 
keystone.resource.core.Manager object at 0x7f68e690, 
keystone.token.provider.Manager object at 0x7f68e6888e90]


The revoke api should be added to the load_backends in keystone/backends.py

** Affects: keystone
 Importance: Undecided
 Assignee: Steve Martinelli (stevemar)
 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/1427440

Title:
  V2 only keystone wont start - revoke not in loaded backends

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  2015-03-03 00:22:25.674809 mod_wsgi (pid=10468): Target WSGI script 
'/var/www/keystone/main' cannot be loaded as Python module.
  2015-03-03 00:22:25.674835 mod_wsgi (pid=10468): Exception occurred 
processing WSGI script '/var/www/keystone/main'.
  2015-03-03 00:22:25.674856 Traceback (most recent call last):
  2015-03-03 00:22:25.674872   File /var/www/keystone/main, line 25, in 
module
  2015-03-03 00:22:25.674947 application = 
wsgi_server.initialize_application(name)
  2015-03-03 00:22:25.674970   File 
/opt/stack/keystone/keystone/server/wsgi.py, line 51, in 
initialize_application
  2015-03-03 00:22:25.675021 startup_application_fn=loadapp)
  2015-03-03 00:22:25.675041   File 
/opt/stack/keystone/keystone/server/common.py, line 44, in setup_backends
  2015-03-03 00:22:25.675086 
drivers.update(dependency.resolve_future_dependencies())
  2015-03-03 00:22:25.675098   File 
/opt/stack/keystone/keystone/common/dependency.py, line 287, in 
resolve_future_dependencies
  2015-03-03 00:22:25.675177 raise 
UnresolvableDependencyException(dependency, targets)
  2015-03-03 00:22:25.675466 UnresolvableDependencyException: Unregistered 
dependency: revoke_api for [keystone.identity.core.Manager object at 
0x7f68e6b1ad10, keystone.assignment.core.Manager object at 0x7f68e6888910, 
keystone.resource.core.Manager object at 0x7f68e690, 
keystone.token.provider.Manager object at 0x7f68e6888e90]

  
  The revoke api should be added to the load_backends in keystone/backends.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427440/+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 1427459] [NEW] Pools are retrieved for monitors detail even there are no pool association

[Liyingjun]

Public bug reported:

$ neutron lb-healthmonitor-show e1dbcea5-0028-4d78-a378-339b70e0d315
++--+
| Field  | Value|
++--+
| admin_state_up | True |
| delay  | 5|
| id | e1dbcea5-0028-4d78-a378-339b70e0d315 |
| max_retries| 2|
| pools  |  |
| tenant_id  | b82b3fa05d8041e183d93aec15527f23 |
| timeout| 3|
| type   | PING |
++--+

see detachments.

** Affects: horizon
 Importance: Undecided
 Assignee: Liyingjun (liyingjun)
 Status: In Progress

** Attachment added: Screen Shot 2015-03-03 at 9.38.36 AM.png
   
https://bugs.launchpad.net/bugs/1427459/+attachment/4332803/+files/Screen%20Shot%202015-03-03%20at%209.38.36%20AM.png

** Changed in: horizon
 Assignee: (unassigned) = Liyingjun (liyingjun)

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

Title:
  Pools are retrieved for monitors detail even there are no pool
  association

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  $ neutron lb-healthmonitor-show e1dbcea5-0028-4d78-a378-339b70e0d315
  ++--+
  | Field  | Value|
  ++--+
  | admin_state_up | True |
  | delay  | 5|
  | id | e1dbcea5-0028-4d78-a378-339b70e0d315 |
  | max_retries| 2|
  | pools  |  |
  | tenant_id  | b82b3fa05d8041e183d93aec15527f23 |
  | timeout| 3|
  | type   | PING |
  ++--+

  see detachments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427459/+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 1427465] [NEW] vArmour fwaas agent broken, unit tests skipped, CI not running

[Assaf Muller]

Public bug reported:

https://github.com/openstack/neutron-
fwaas/blob/master/neutron_fwaas/services/firewall/agents/varmour/varmour_router.py#L64

vArmour L3 agent _router_added is calling
neutron.agent.l3.router_info.RouterInfo__init__ and its not passing
mandatory parameters (interface_driver, agent_conf). These parameters
were introduced in change IDs:

I33a23eb37678d94cea3ace8afe090935b1e70685
I0ec75d731d816955c1915e283a137abcb51ac232

The unit tests that would catch this error:

https://github.com/openstack/neutron-
fwaas/blob/master/neutron_fwaas/tests/unit/services/firewall/drivers/varmour/test_varmour_fwaas.py#L153

Are being skipped at the gate (Which is essentially another bug, why do these 
unit tests require a REST call to succeed, and are failing to complete the REST 
call with the default configuration?)
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/tests/unit/services/firewall/drivers/varmour/test_varmour_fwaas.py#L182

Finally, 3rd party vArmour CI is not being run.

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

Title:
  vArmour fwaas agent broken, unit tests skipped, CI not running

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  https://github.com/openstack/neutron-
  
fwaas/blob/master/neutron_fwaas/services/firewall/agents/varmour/varmour_router.py#L64

  vArmour L3 agent _router_added is calling
  neutron.agent.l3.router_info.RouterInfo__init__ and its not passing
  mandatory parameters (interface_driver, agent_conf). These parameters
  were introduced in change IDs:

  I33a23eb37678d94cea3ace8afe090935b1e70685
  I0ec75d731d816955c1915e283a137abcb51ac232

  The unit tests that would catch this error:

  https://github.com/openstack/neutron-
  
fwaas/blob/master/neutron_fwaas/tests/unit/services/firewall/drivers/varmour/test_varmour_fwaas.py#L153

  Are being skipped at the gate (Which is essentially another bug, why do these 
unit tests require a REST call to succeed, and are failing to complete the REST 
call with the default configuration?)
  
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/tests/unit/services/firewall/drivers/varmour/test_varmour_fwaas.py#L182

  Finally, 3rd party vArmour CI is not being run.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427465/+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 1427485] [NEW] Fernet tokens contain a version identifier that is not integrity verified

[Dolph Mathews]

Public bug reported:

Fernet tokens all start with a plaintext string of either F00 or F01
indicating either version 0 (normal unscoped and scoped tokens) or
version 1 (trust-based tokens). That versioning lies outside of the
integrity-verified portion of the token, and is thus susceptible to
manipulation by end users.

With only two token versions, this doesn't present any issues that I'm
aware of, but to harden ourselves against the future, we should move
that versioning information into the integrity-verified portion of the
message. Otherwise, we carry of risk of future implementations
inadvertently introducing privilege escalation vulnerabilities, a means
for end users to disable authorization checks by supplying older
versions, etc, etc.

In addition, the format prefix was originally intended to make it easier
for remote clients (keystonemiddleware.auth_token) to parse apart and
validate tokens without going back to talk to Keystone. Since that's not
the plan here (Fernet tokens must be validated with Keystone, since
that's the only place where the encryption keys are accessible), the
entire format prefix (F00 / F01) can be dropped, as long as Keystone
can still validate the tokens it's issuing.

** Affects: keystone
 Importance: Medium
 Assignee: Dolph Mathews (dolph)
 Status: New


** Tags: fernet

** Tags added: fernet

** Summary changed:

- Fernet tokens contain non-integrity verified version identifier
+ Fernet tokens contain a version identifier that is not integrity verified

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

Title:
  Fernet tokens contain a version identifier that is not integrity
  verified

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Fernet tokens all start with a plaintext string of either F00 or
  F01 indicating either version 0 (normal unscoped and scoped
  tokens) or version 1 (trust-based tokens). That versioning lies
  outside of the integrity-verified portion of the token, and is thus
  susceptible to manipulation by end users.

  With only two token versions, this doesn't present any issues that I'm
  aware of, but to harden ourselves against the future, we should move
  that versioning information into the integrity-verified portion of the
  message. Otherwise, we carry of risk of future implementations
  inadvertently introducing privilege escalation vulnerabilities, a
  means for end users to disable authorization checks by supplying older
  versions, etc, etc.

  In addition, the format prefix was originally intended to make it
  easier for remote clients (keystonemiddleware.auth_token) to parse
  apart and validate tokens without going back to talk to Keystone.
  Since that's not the plan here (Fernet tokens must be validated with
  Keystone, since that's the only place where the encryption keys are
  accessible), the entire format prefix (F00 / F01) can be dropped,
  as long as Keystone can still validate the tokens it's issuing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427485/+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 1427437] [NEW] LDAP debug logging during unit tests brings us close to causing jenkins to fail our tests

[Henry Nash]

Public bug reported:

The Jenkins runs of our unit tests have a cap of 50Mb of log output..if
we generate more than that, then it will fail out tests on the
assumption that something is wrong.  Our full run of our tests brings us
perilously close already to this limit - primarily due to LDAP debug
logging.  We should switch off ldap debug logging for our unit tests.

** Affects: keystone
 Importance: Critical
 Assignee: Henry Nash (henry-nash)
 Status: New

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

Title:
  LDAP debug logging during unit tests brings us close to causing
  jenkins to fail our tests

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The Jenkins runs of our unit tests have a cap of 50Mb of log
  output..if we generate more than that, then it will fail out tests on
  the assumption that something is wrong.  Our full run of our tests
  brings us perilously close already to this limit - primarily due to
  LDAP debug logging.  We should switch off ldap debug logging for our
  unit tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427437/+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 1427474] [NEW] IPv6 SLAAC subnet create should update ports on net

[Dane LeBlanc]

Public bug reported:

If ports are first created on a network, and then an IPv6 SLAAC
or DHCPv6-stateless subnet is created on that network, then the
ports created prior to the subnet create are not getting
automatically updated (associated) with addresses for the
SLAAC/DHCPv6-stateless subnet, as required.

Note that this problem was discussed in the Neutron
multiple-ipv6-prefixes blueprint, but is being addressed
with a separate  Neutron bug since this is a bug that can
potentially be backported to Juno.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

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

Title:
  IPv6 SLAAC subnet create should update ports on net

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If ports are first created on a network, and then an IPv6 SLAAC
  or DHCPv6-stateless subnet is created on that network, then the
  ports created prior to the subnet create are not getting
  automatically updated (associated) with addresses for the
  SLAAC/DHCPv6-stateless subnet, as required.

  Note that this problem was discussed in the Neutron
  multiple-ipv6-prefixes blueprint, but is being addressed
  with a separate  Neutron bug since this is a bug that can
  potentially be backported to Juno.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427474/+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 1427467] [NEW] Oversight when copying configdrive during live migration on Hyperv

[Adelina Tuvenie]

Public bug reported:

When fixing bug https://launchpad.net/bugs/1322096 there was an
oversight.  When copying the iso we check if the instance requires a
config drive and if that config drive is a iso, by checking the value
config_drive_cdrom from the conf. This value can change and thus, even
if the instance has a iso configdrive attached it will be ommitted  in
the way the fix was implemented.

A better idea would be to check if the instance has a attached iso.

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

Title:
  Oversight when copying configdrive during live migration on Hyperv

Status in OpenStack Compute (Nova):
  New

Bug description:
  When fixing bug https://launchpad.net/bugs/1322096 there was an
  oversight.  When copying the iso we check if the instance requires a
  config drive and if that config drive is a iso, by checking the value
  config_drive_cdrom from the conf. This value can change and thus,
  even if the instance has a iso configdrive attached it will be
  ommitted  in the way the fix was implemented.

  A better idea would be to check if the instance has a attached iso.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427467/+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 1427521] [NEW] client side filter is missing in vpn tables

[Masco Kaliyamoorthy]

Public bug reported:

client side filter option is missing in vpn tables

** Affects: horizon
 Importance: Undecided
 Assignee: Masco Kaliyamoorthy (masco)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) = Masco Kaliyamoorthy (masco)

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

Title:
  client side filter is missing in vpn tables

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  client side filter option is missing in vpn tables

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427521/+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 1427509] [NEW] add oauth and federation authentication to config file

[Steve Martinelli]

Public bug reported:

Recently federation and oauth support are no longer optional features.
In the [auth] section of the keystone config file, they should be
indicated as valid options for authentication. But perhaps now included
in the default 'methods' option.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  add oauth and federation authentication to config file

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Recently federation and oauth support are no longer optional features.
  In the [auth] section of the keystone config file, they should be
  indicated as valid options for authentication. But perhaps now
  included in the default 'methods' option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427509/+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 1427520] [NEW] Language change option is not working new panels

[Sudheer Kalla]

Public bug reported:

In horizon i have added a new panel My Panel ,which consists of table
and table action to upload a file , After this i navigated to settings
and changed the preferred language(to Hindhi)  , I noticed that all the
panel are affected with new language(Hindhi)  but My Panel is
uneffected and still is in English language

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

Title:
  Language change option is not working new panels

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  In horizon i have added a new panel My Panel ,which consists of
  table and table action to upload a file , After this i navigated to
  settings and changed the preferred language(to Hindhi)  , I noticed
  that all the panel are affected with new language(Hindhi)  but My
  Panel is uneffected and still is in English language

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427520/+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 1427517] [NEW] client side filter is missing in firewall tables

[Masco Kaliyamoorthy]

Public bug reported:

client side filter option is missing in all the firewall tables

** Affects: horizon
 Importance: Undecided
 Assignee: Masco Kaliyamoorthy (masco)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) = Masco Kaliyamoorthy (masco)

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

Title:
  client side filter is missing in firewall tables

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  client side filter option is missing in all the firewall tables

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427517/+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 1427365] [NEW] openvswitch-agent init script does not source /etc/sysconfig/neutron

[Tom Helander]

Public bug reported:

The init script '/etc/init.d/openstack-neutron-openvswitch-agent' does
not source /etc/sysconfig/neutron, causing the ml2 plugin configuration
to not be read as the default value for NEUTRON_PLUGIN_CONF in the init
script is '/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini'.

I resolved this problem by adding the source just after
NEUTRON_PLUGIN_ARGS= (see attached).

I'm running on openSUSE-13.1 using the SUSE open build service RPM
repository
(https://build.opensuse.org/project/show/Cloud:OpenStack:Juno).

# rpm -qi openstack-neutron-openvswitch-agent
Name: openstack-neutron-openvswitch-agent
Version : 2014.2.3.dev28
Release : 1.1
Architecture: noarch
Install Date: Mon Mar  2 11:55:57 2015
Group   : Development/Languages/Python
Size: 14893
License : Apache-2.0
Signature   : RSA/SHA1, Fri Feb 27 20:08:54 2015, Key ID 893a90dad85f9316
Source RPM  : openstack-neutron-2014.2.3.dev28-1.1.src.rpm
Build Date  : Fri Feb 27 20:07:52 2015
Build Host  : build24
Relocations : (not relocatable)
Vendor  : obs://build.opensuse.org/Cloud:OpenStack
URL : https://launchpad.net/neutron
Summary : OpenStack Network - Open vSwitch
Description :
This package provides the OpenVSwitch Agent.
Distribution: Cloud:OpenStack:Juno / openSUSE_13.1

** Affects: neutron
 Importance: Undecided
 Status: New

** Patch added: etc_init.d_openstack-neutron-openvswitch-agent.patch
   
https://bugs.launchpad.net/bugs/1427365/+attachment/4332544/+files/etc_init.d_openstack-neutron-openvswitch-agent.patch

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

Title:
  openvswitch-agent init script does not source /etc/sysconfig/neutron

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The init script '/etc/init.d/openstack-neutron-openvswitch-agent' does
  not source /etc/sysconfig/neutron, causing the ml2 plugin
  configuration to not be read as the default value for
  NEUTRON_PLUGIN_CONF in the init script is
  '/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini'.

  I resolved this problem by adding the source just after
  NEUTRON_PLUGIN_ARGS= (see attached).

  I'm running on openSUSE-13.1 using the SUSE open build service RPM
  repository
  (https://build.opensuse.org/project/show/Cloud:OpenStack:Juno).

  # rpm -qi openstack-neutron-openvswitch-agent
  Name: openstack-neutron-openvswitch-agent
  Version : 2014.2.3.dev28
  Release : 1.1
  Architecture: noarch
  Install Date: Mon Mar  2 11:55:57 2015
  Group   : Development/Languages/Python
  Size: 14893
  License : Apache-2.0
  Signature   : RSA/SHA1, Fri Feb 27 20:08:54 2015, Key ID 893a90dad85f9316
  Source RPM  : openstack-neutron-2014.2.3.dev28-1.1.src.rpm
  Build Date  : Fri Feb 27 20:07:52 2015
  Build Host  : build24
  Relocations : (not relocatable)
  Vendor  : obs://build.opensuse.org/Cloud:OpenStack
  URL : https://launchpad.net/neutron
  Summary : OpenStack Network - Open vSwitch
  Description :
  This package provides the OpenVSwitch Agent.
  Distribution: Cloud:OpenStack:Juno / openSUSE_13.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427365/+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 1427379] [NEW] AttributeError: 'Assignment' object has no attribute 'get_domain_by_name'

[Matthew Edmonds]

Public bug reported:

2015-03-02 13:16:45.493 19248 CRITICAL keystone [-] AttributeError: 
'Assignment' object has no attribute 'get_domain_by_name'
2015-03-02 13:16:45.493 19248 TRACE keystone Traceback (most recent call last):
2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/bin/keystone-manage, 
line 44, in module
2015-03-02 13:16:45.493 19248 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 311, in main
2015-03-02 13:16:45.493 19248 TRACE keystone CONF.command.cmd_class.main()
2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 250, in main
2015-03-02 13:16:45.493 19248 TRACE keystone mapping['domain_id'] = 
get_domain_id(CONF.command.domain_name)
2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 236, in get_domain_id
2015-03-02 13:16:45.493 19248 TRACE keystone return 
assignment_manager.driver.get_domain_by_name(name)['id']
2015-03-02 13:16:45.493 19248 TRACE keystone AttributeError: 'Assignment' 
object has no attribute 'get_domain_by_name'

** Affects: keystone
 Importance: Undecided
 Assignee: Matthew Edmonds (edmondsw)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) = Matthew Edmonds (edmondsw)

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

Title:
  AttributeError: 'Assignment' object has no attribute
  'get_domain_by_name'

Status in OpenStack Identity (Keystone):
  New

Bug description:
  2015-03-02 13:16:45.493 19248 CRITICAL keystone [-] AttributeError: 
'Assignment' object has no attribute 'get_domain_by_name'
  2015-03-02 13:16:45.493 19248 TRACE keystone Traceback (most recent call 
last):
  2015-03-02 13:16:45.493 19248 TRACE keystone File /usr/bin/keystone-manage, 
line 44, in module
  2015-03-02 13:16:45.493 19248 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 311, in main
  2015-03-02 13:16:45.493 19248 TRACE keystone CONF.command.cmd_class.main()
  2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 250, in main
  2015-03-02 13:16:45.493 19248 TRACE keystone mapping['domain_id'] = 
get_domain_id(CONF.command.domain_name)
  2015-03-02 13:16:45.493 19248 TRACE keystone File 
/usr/lib/python2.7/site-packages/keystone/cli.py, line 236, in get_domain_id
  2015-03-02 13:16:45.493 19248 TRACE keystone return 
assignment_manager.driver.get_domain_by_name(name)['id']
  2015-03-02 13:16:45.493 19248 TRACE keystone AttributeError: 'Assignment' 
object has no attribute 'get_domain_by_name'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427379/+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 1424900] Re: Bootstrapping Vivid: ERROR failed to bootstrap environment, Permission denied (publickey), ci-info: no authorized ssh keys fingerprints found for user ubuntu

[Scott Moser]

this was fixed in 0.7.7~bzr1067-0ubuntu1  uploaded to vivid 2015-02-26.

** Changed in: cloud-init
   Status: Confirmed = Fix Released

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init
   Status: Fix Released = Fix Committed

** Changed in: cloud-init (Ubuntu)
   Status: New = Fix Released

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

** Changed in: cloud-init (Ubuntu)
   Importance: Critical = High

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

Title:
  Bootstrapping Vivid:  ERROR failed to bootstrap environment,
  Permission denied (publickey), ci-info: no authorized ssh keys
  fingerprints found for user ubuntu

Status in Init scripts for use on cloud images:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Bootstrapping Vivid:  ERROR failed to bootstrap environment,
  Permission denied (publickey), ci-info: no authorized ssh keys
  fingerprints found for user ubuntu

  # Scenario
  A user needs Unit 0 to be Vivid.   The user manually sets default-series: 
vivid in ~/.juju/environments.yaml, then issues `juju bootstrap`.

  The bootstrap times out after the default 10 minute wait, with:
  ERROR failed to bootstrap environment: waited for 10m0s without being
  able to connect: Permission denied (publickey).

  The user cannot open an ssh session to the new instance using the
  local user keys, nor the keys in ~/.juju/.  Juju stat and juju debug-
  log do not provide details as the bootstrap node cannot be contacted.
  Information is collected via nova console-log.

  The same user procedure does bootstrap successfully when default-
  series is set to utopic or trusty.  This issue has been confirmed
  using two juju providers:  openstack provider (serverstack) and maas
  provider (dellstack).  It has been confirmed on juju-core
  1.21.1-0ubuntu1~14.04.1~juju1 and 1.22-beta3-0ubuntu1~14.04.1~juju1.

  # The bootstrap node's nova console log reveals trouble:
  Cloud-init v. 0.7.7 running 'modules:final' at Tue, 24 Feb 2015 00:44:33 
+. Up 11.03 seconds.
  ci-info: no authorized ssh keys fingerprints found for user ubuntu.
  ci-info: no authorized ssh keys fingerprints found for user ubuntu.

  # bootstrap output, with default-series: vivid
  jenkins@juju-env0-machine-13:~$ juju bootstrap
  Bootstrapping environment osci-sv10-jdev
  Starting new instance for initial state server
  Launching instance
   - 15abce53-fa1a-427e-83d9-551a642f4fd7
  Installing Juju agent on bootstrap instance
  Waiting for address
  Attempting to connect to 172.17.110.41:22
  ERROR failed to bootstrap environment: waited for 10m0s without being able to 
connect: Permission denied (publickey).

  See attachment for additional details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1424900/+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 1365727] Re: N1kv tenant able to create networks for non-shared network profiles of other N1kv tenants

[Ihar Hrachyshka]

I wonder whether the bug should have been handled by vulnerability team.
It looks like a privilege escalation problem.

** Also affects: ossa
   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/1365727

Title:
  N1kv tenant able to create networks for non-shared network profiles of
  other N1kv tenants

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in OpenStack Security Advisories:
  New

Bug description:
  Tenants are able to create networks within network profiles that are
  not shared with them and belong to some other tenant.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1365727/+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 1427158] [NEW] Rest call for group and user list is not working without domain_id

[Sourav Biswas]

Public bug reported:

In older build in PowerVC to get the group / user, we had used the following 
rest calls:
https://9.114.226.100/powervc/openstack/admin/v3/users 
https://9.114.226.100/powervc/openstack/admin/v3/groups

For the recent builds, we are seeing the above command is not working and 
current working calls are :
https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/groups
https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/users

So, it needs a domain id parameter to get the result. So it would
definitely be nice if keystone would recognize that and not require the
domain_id query parameter to make the /v3/groups and /v3/users commands
work.

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: api

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

Title:
  Rest call for group and user list is not working without domain_id

Status in OpenStack Identity (Keystone):
  New

Bug description:
  In older build in PowerVC to get the group / user, we had used the following 
rest calls:
  https://9.114.226.100/powervc/openstack/admin/v3/users 
  https://9.114.226.100/powervc/openstack/admin/v3/groups

  For the recent builds, we are seeing the above command is not working and 
current working calls are :
  https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/groups
  https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/users

  So, it needs a domain id parameter to get the result. So it would
  definitely be nice if keystone would recognize that and not require
  the domain_id query parameter to make the /v3/groups and /v3/users
  commands work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427158/+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 1427179] [NEW] boot from volume instance failed, because when reschedule delete the volume

[YaoZheng_ZTE]

Public bug reported:


1. Create a volume nova volume-create --display-name test_volume 1
[root@controller51 nova(keystone_admin)]# nova volume-list
+--+---+-+--+-+---+
| ID   | Status| Display Name| 
Size | Volume Type | Attached to
   |
+--+---+-+--+-+---+
| a740ca7b-6881-4e28-9fdb-eb0d80336757 | available | test_volume | 
1| None|
   |
| 1f1c19c7-a5f9-4683-a1f6-e339f02e1410 | in-use| NFVO_system_disk2   | 
30   | None| 6fa391f8-bd8b-483d-9286-3cebc9a93d55   
   |
| d868710e-30d4-4095-bd8f-fea9f16fe8ea | in-use| NFVO_data_software_disk | 
30   | None| 
a07abdd5-07a6-4b41-a285-9b825f7b5623;6fa391f8-bd8b-483d-9286-3cebc9a93d55 |
| b03a39ca-ebc1-4472-9a04-58014e67b37c | in-use| NFVO_system_disk1   | 
30   | None| a07abdd5-07a6-4b41-a285-9b825f7b5623   
   |
+--+---+-+--+-+---+
2. use The following command will boot a new instance and attach a volume at 
the same time：
[root@controller51 nova(keystone_admin)]#  nova boot --flavor 1 --image 
1736471c-3530-49f2-ad34-6ef7da285050 --block-device-mapping 
vdb=a740ca7b-6881-4e28-9fdb-eb0d80336757:blank:1:1 --nic 
net-id=31fce69e-16b9-4114-9fa9-589763e58fb0 test
+--+---+
| Property | Value  
   |
+--+---+
| OS-DCF:diskConfig| MANUAL 
   |
| OS-EXT-AZ:availability_zone  | nova   
   |
| OS-EXT-SRV-ATTR:host | -  
   |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | -  
   |
| OS-EXT-SRV-ATTR:instance_name| instance-0082  
   |
| 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| sWTuKqzrpS32   
   |
| config_drive |
   |
| created  | 2015-03-02T11:34:29Z   
   |
| flavor   | m1.tiny (1)
   |
| hostId   |
   |
| id   | 868cfd12-eb36-4140-b7b3-98cfcec627cd   
   |
| image| 
VMB_X86_64_LX_2.6.32_64_REL_2014_12_26.img 
(1736471c-3530-49f2-ad34-6ef7da285050) |
| key_name | -  
   |
| metadata | {} 
   |
| name | test  

[Yahoo-eng-team] [Bug 1426524] Re: race condition prevents intance deletion

[Evgeniy Afonichev]

couldn't reproduce. Also I suspect that volume attach/detach led to db
inconsistencies

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

Title:
  race condition prevents intance deletion

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  Version: icehouse. Though looking in to the code in the master I believe bug 
is still there
  Hypervisor: libvirt
  Frequency: very rare, under heavy load (stress tests)
  Steps to reproduce: as an operator I issue nova delete command. Instead of 
being deleted that vm gets into ERROR state.

  relevant nova-compute.log: http://paste.openstack.org/show/183111/

  Here's probably why it happens:
  It's a race condition. There are two threads (coroutines if eventlet patched) 
- thread-1 which handles termination request 
(nova.compute.manager.ComputeManager.terminate_instance) and thread-2 which 
dispatches events from hypervisor.
  1) thread-1: manager clears (deletes) all queued events for that vm and 
switches to thread-2 
https://github.com/openstack/nova/blob/983f755562cb87a0b498af5d62be9bd2010bc999/nova/compute/manager.py#L2526
  2) thread-2: hypervisor emits one more event and switches to thread-1 without 
dispatching event
  3) thread-1: manager deletes image files, marks instance as deleted in the 
db. Thread finishes and exits normally
  4) thread-2: manager tries to dispatch one more event. But fails as there is 
no such instance anymore. To be more precise - there is no InstanceInfoCache 
for that vm.

  
  UPD: more logs: 
https://www.dropbox.com/sh/r0ek3w7g95qoetw/AADTfgN9tD2Mt_fOXjB9OCzva?dl=0
  - Cluster is in HA mode (three nova-api files)
  - debug=False
  - conductor-logs contain only connecting, reconnecting to rabbitmq. 
  - cat ... | grep -A 15 -B 15 -r 09ac0ed2-07cb-4394-b0c8-aff3ab74dcdb

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1426524/+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 1427141] [NEW] console auth token timeout has no impact

[Markus Zoeller]

Public bug reported:

Issue
=
The console feature (VNC, SERIAL, ...) returns a connection with an auth
token. This connection *never* times out.

Steps to reproduce
==

The steps below are suitable for testing with the serial console but the
behavior is the same with VNC.

* enable the console feature in nova.conf
  [serial_console]
  enabled=True
* set the token timeout value in nova.conf to a value which fits your 
  testing (e.g.)
  console_token_ttl=10
* start the nova-serialproxy service (e.g. with devstack [1])
* start an instance
* Connect to the serial console of that launched instance
  (e.g. Horizon with console tab or another client [2])
* Execute a command (e.g. date)  
* Wait until the timespan defined by console_token_ttl elapsed
* Execute another command (e.g. date)

Expected behavior
=

The command in the console is refused after the timespan elapsed.

Actual behavior
===

The connection is kept open and each command is executed after the 
defined timespan. This looks weird in the case when Horizon times out
but the console tab is still working.

Logs  Env.
===

OpenStack is installed and started with devstack.
The logs [3] show that the expired token gets removed when a new token
is appended. The append of a new token happens only when the console
tab is reopened and the old token is expired.

Nova version


pedebug@OS-CTRL:/opt/stack/nova$ git log --oneline -n5
017574e Merge Added retries in 'network_set_host' function
a957d56 libvirt: Adjust Nova to support FCP on System z systems
36bae5a Merge fake: fix public API signatures to match virt driver
13223b5 Merge Don't assume contents of values after aggregate_update
c4a9cc5 Merge Fix VNC access, when reverse DNS lookups fail


References
==

[1] Devstack guide; Nova and devstack;
http://docs.openstack.org/developer/devstack/guides/nova.html
[2] larsk/novaconsole; github; https://github.com/larsks/novaconsole/
[3] http://paste.openstack.org/show/184866/

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

Title:
  console auth token timeout has no impact

Status in OpenStack Compute (Nova):
  New

Bug description:
  Issue
  =
  The console feature (VNC, SERIAL, ...) returns a connection with an auth
  token. This connection *never* times out.

  Steps to reproduce
  ==

  The steps below are suitable for testing with the serial console but the
  behavior is the same with VNC.

  * enable the console feature in nova.conf
[serial_console]
enabled=True
  * set the token timeout value in nova.conf to a value which fits your 
testing (e.g.)
console_token_ttl=10
  * start the nova-serialproxy service (e.g. with devstack [1])
  * start an instance
  * Connect to the serial console of that launched instance
(e.g. Horizon with console tab or another client [2])
  * Execute a command (e.g. date)  
  * Wait until the timespan defined by console_token_ttl elapsed
  * Execute another command (e.g. date)

  Expected behavior
  =

  The command in the console is refused after the timespan elapsed.

  Actual behavior
  ===

  The connection is kept open and each command is executed after the 
  defined timespan. This looks weird in the case when Horizon times out
  but the console tab is still working.

  Logs  Env.
  ===

  OpenStack is installed and started with devstack.
  The logs [3] show that the expired token gets removed when a new token
  is appended. The append of a new token happens only when the console
  tab is reopened and the old token is expired.

  Nova version
  

  pedebug@OS-CTRL:/opt/stack/nova$ git log --oneline -n5
  017574e Merge Added retries in 'network_set_host' function
  a957d56 libvirt: Adjust Nova to support FCP on System z systems
  36bae5a Merge fake: fix public API signatures to match virt driver
  13223b5 Merge Don't assume contents of values after aggregate_update
  c4a9cc5 Merge Fix VNC access, when reverse DNS lookups fail

  
  References
  ==

  [1] Devstack guide; Nova and devstack;
  http://docs.openstack.org/developer/devstack/guides/nova.html
  [2] larsk/novaconsole; github; https://github.com/larsks/novaconsole/
  [3] http://paste.openstack.org/show/184866/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427141/+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 1424597] Re: Obscure 'No valid hosts found' if no free fixed IPs left in the network

[Alvaro Lopez]

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

** This bug has been marked a duplicate of bug 1394268
   wrong error message when no IP addresses are available

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

Title:
  Obscure 'No valid hosts found' if no free fixed IPs left in the
  network

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  If network have no free fixed IPs, new instances failed with 'No valid
  hosts found' without proper explanation.

  Example:

  nova boot foobar --flavor SSD.1 --image cirros --nic net-id=f3f2802a-
  c2a1-4d8b-9f43-cf24d0dc8233

  (There is no free IP left in network f3f2802a-c2a1-4d8b-
  9f43-cf24d0dc8233)

  nova show fb4552e5-50cb-4701-a095-c006e4545c04
  ...
  | status   | BUILD
 |

  (few seconds later)

  | fault| {message: No valid host was 
found. Exceeded max scheduling attempts 2 for instance 
fb4552e5-50cb-4701-a095-c006e4545c04. Last exception: [u'Traceback (most recent 
call last):\ |
  |  | ', u'  File 
\/usr/lib/python2.7/dist-packages/nova/compute/manager.py\, line 2036, in 
_do, code: 500, details:   File 
\/usr/lib/python2.7/dist-packages/nova/conductor/manager.py\, line 612, in 
build_instances |
  |  | instances[0].uuid)   


  |
  |  |   File 
\/usr/lib/python2.7/dist-packages/nova/scheduler/utils.py\, line 161, in 
populate_retry  
 |
  |  | raise 
exception.NoValidHost(reason=msg)   

 |
  | status   | ERROR


  |

  
  Expected behaviour: Compains about 'No free IP' before attempting to schedule 
instance.

  See https://bugs.launchpad.net/nova/+bug/1424594 for similar
  behaviour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1424597/+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 1417515] Re: Horizon Input fields swapped when tried to Launch Stack with invalid name

[Thierry Carrez]

Please do not set to FixReleased until the fix is released in a
milestone.

** Changed in: horizon
   Status: Fix Released = Fix Committed

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

Title:
  Horizon Input fields swapped when tried to Launch Stack with invalid
  name

Status in OpenStack Dashboard (Horizon):
  Fix Committed

Bug description:
  Steps:
  1.Open Horizon Dashboard
  2.Open Project-Orchestration-Stack
  3.Click Launch Stack
  4.Template Source - Direct Input

  Use template:
  [heat_template_version: 2013-05-23

  description: Simple template to deploy a single compute instance

  parameters:
key_name:
  type: string
  label: Key Name
  description: Name of key-pair to be used for compute instance
image_id:
  type: string
  label: Image ID
  description: Image to be used for compute instance
instance_type:
  type: string
  label: Instance Type
  description: Type of instance (flavor) to be used

  resources:
my_instance:
  type: OS::Nova::Server
  properties:
key_name: { get_param: key_name }
image: { get_param: image_id }
flavor: { get_param: instance_type }]

  5.Click Next
  6.Fill in the fields:
Stack Name: [111] - invalid value
Password for user admin - your admin pass
  Image ID: [25e3e805-1c42-4eb0-abf2-afdc9e96c62e] or any valid id
Instance Type: [m1.small] or any valid type
  Key Name:[heat_key] - your Key Pair
  7.Click Launch

  Stack don't launch(invalid Stack Name), but fields Instance Type and
  Key Name swapped

  
  devstack$ git show HEAD
  commit e256022a1686eb447da1bbd318c44b58f72f3e0e
  Merge: b9a7d3b ff72c50
  Author: Jenkins jenk...@review.openstack.org
  Date:   Sat Jan 31 00:08:29 2015 +

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1417515/+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 977192] Re: Error message not user friendly while creating security group

[OpenStack Infra]

** Changed in: python-novaclient
   Status: Invalid = In Progress

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

Title:
  Error message not user friendly while creating security group

Status in OpenStack Compute (Nova):
  Invalid
Status in Python client library for Nova:
  In Progress

Bug description:
  While creating Security Group with a name which starts with '-'
  followed by an alphabet then the Error message is not user friendly

  Steps to reproduce:
  nova secgroup-create -A34f ghjk

  Expected Result:
  Error message which indicates name is not an appropriate name 
  Actual Result:
  usage: nova secgroup-create name description
  error: too few arguments

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/977192/+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 1427122] [NEW] dvr case with 1 subnet attaches multi routers, fail to create router netns

[ZongKai LI]

Public bug reported:

 Environment 
1+2 env with DVR enabled, l3agent on all these nodes are configured with 
router_delete_namespaces = True.
Create router R1, subnet sn1 and sn2, attach sn1 and sn4 to router R1.
Create router R2, subnet sn3 and sn4, attach sn3 and sn4 to router R2.
Boot instances vm1 on sn1 on CN1, vm2 on sn2 on CN2, vm3 on sn3 on CN1, vm4 on 
sn4 on CN2.
Create port p1 on sn1's network by running neutron port-create --name p1 n1,  
and attach p1 to R2 by running neutron router-interface-add R2 port=p1(this 
instruction try to connect sn1 with sn3 and sn4 by router R2)

 Steps to raise issue 
1) delete vm1, and make sure qrouter netns will disappear on CN1
2) create vm5 on sn1 on CN1, but qrouter netns doesn't come out.

 Workaround 
restart l3-agent on CN1.

In normal case(a subnet will only be attached to one router), this issue
will not raise.

** Affects: neutron
 Importance: Undecided
 Assignee: ZongKai LI (lzklibj)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = ZongKai LI (lzklibj)

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

Title:
  dvr case with 1 subnet attaches multi routers, fail to create router
  netns

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
   Environment 
  1+2 env with DVR enabled, l3agent on all these nodes are configured with 
router_delete_namespaces = True.
  Create router R1, subnet sn1 and sn2, attach sn1 and sn4 to router R1.
  Create router R2, subnet sn3 and sn4, attach sn3 and sn4 to router R2.
  Boot instances vm1 on sn1 on CN1, vm2 on sn2 on CN2, vm3 on sn3 on CN1, vm4 
on sn4 on CN2.
  Create port p1 on sn1's network by running neutron port-create --name p1 
n1,  and attach p1 to R2 by running neutron router-interface-add R2 
port=p1(this instruction try to connect sn1 with sn3 and sn4 by router R2)

   Steps to raise issue 
  1) delete vm1, and make sure qrouter netns will disappear on CN1
  2) create vm5 on sn1 on CN1, but qrouter netns doesn't come out.

   Workaround 
  restart l3-agent on CN1.

  In normal case(a subnet will only be attached to one router), this
  issue will not raise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427122/+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 1427135] [NEW] Neutron API reflects JavaScript/any input in error message

[Adam Heczko]

Public bug reported:

During security scan of Neutron API, Nessus raises the following
security alert about reflected XSS:

REQUEST:
scriptcross_site_scripting.nasl/script

API RESPONSE :
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Content-Length: 596
Date: Mon, 29 Dec 2014 09:50:52 GMT
Connection: close
File /usr/lib/python2.7/dist-packages/paste/urlmap.py, line 119, [...]
URL fragments must start with / or http:// (you gave %r) % url)
AssertionError: URL fragments must start with / or http:// (you gave 
'scriptcross_site_scripting.nasl/script')

My proposal is to modify API error response in a way that doesn't causes 
reflection of the original input - doesn't matter if JavaScript or not.
IMO error message should end at line Connection: close

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

Title:
  Neutron API reflects JavaScript/any input in error message

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  During security scan of Neutron API, Nessus raises the following
  security alert about reflected XSS:

  REQUEST:
  scriptcross_site_scripting.nasl/script

  API RESPONSE :
  HTTP/1.1 500 Internal Server Error
  Content-Type: text/plain
  Content-Length: 596
  Date: Mon, 29 Dec 2014 09:50:52 GMT
  Connection: close
  File /usr/lib/python2.7/dist-packages/paste/urlmap.py, line 119, [...]
  URL fragments must start with / or http:// (you gave %r) % url)
  AssertionError: URL fragments must start with / or http:// (you gave 
'scriptcross_site_scripting.nasl/script')

  My proposal is to modify API error response in a way that doesn't causes 
reflection of the original input - doesn't matter if JavaScript or not.
  IMO error message should end at line Connection: close

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427135/+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 1380238] Re: Instances won't obtain IPv6 address if they have additional IPv4 interface

[Sergey Belous]

@Ihar, I checked this for ubuntu:
http://paste.openstack.org/show/184928/ and all works fine.

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

Title:
  Instances won't obtain IPv6 address if they have additional IPv4
  interface

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Description of problem:
  ===
  I booted an instance with both IPv4 and IPv6 interfaces, yet that instance 
did no obtain any IPv6 address.
  In order make sure nothing is wrong with my IPv6 configuration (which is 
RADVD SLAAC), I booted additional instance with IPv6 interface only, which 
obtained an IPv6 address with no issues.

  
  Version-Release number of selected component (if applicable):
  =
  openstack-neutron-2014.2-0.7.b3
  How reproducible:
  =
  Always

  Steps to Reproduce:
  ===
  0. Perior to the test, configure the following:
 a. Neutron router
 b. IPv4 Network  Subnet
 c. IPv6 Network  Subnet (SLAAC in my specific case)
-- Created with: --ipv6-address-mode slaac --ipv6_ra_mode slaac
 d. Add router interfaces with those networks.

  1. spwan an instance with both IPv4  IPv6 interfaces.

  2. spwan an instance with IPv6 interface only.

  
  Actual results:
  ===
  1. The instance spawed in step 1 obtained IPv4 address and IPv6 link local 
address only
  2. The instance spawed in step 2 obtained IPv6 addrees proparly.

  Expected results:
  =
  Instances should obtain all IP addresses in both scenarios I mentioned above.

  Additional info:
  
  Using tcpdump from within the instances I noticed that ICMPv6 Router 
Advertisments did not reach the NIC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1380238/+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 1427165] [NEW] unittest2 deprecated in Django

[Matthias Runge]

Public bug reported:

https://docs.djangoproject.com/en/1.7/topics/testing/overview/#writing-
tests

Python 2.7 introduced some major changes to the unittest library, adding
some extremely useful features. To ensure that every Django project
could benefit from these new features, Django used to ship with a copy
of Python 2.7’s unittest backported for Python 2.6 compatibility.

Since Django no longer supports Python versions older than 2.7,
django.utils.unittest is deprecated. Simply use unittest.

openstack_dashboard/test/api_tests/rest_util_tests.py

** Affects: horizon
 Importance: Undecided
 Status: Invalid

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

Title:
  unittest2 deprecated in Django

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  https://docs.djangoproject.com/en/1.7/topics/testing/overview
  /#writing-tests

  Python 2.7 introduced some major changes to the unittest library,
  adding some extremely useful features. To ensure that every Django
  project could benefit from these new features, Django used to ship
  with a copy of Python 2.7’s unittest backported for Python 2.6
  compatibility.

  Since Django no longer supports Python versions older than 2.7,
  django.utils.unittest is deprecated. Simply use unittest.

  openstack_dashboard/test/api_tests/rest_util_tests.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427165/+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 1427165] Re: unittest2 deprecated in Django

[Matthias Runge]

already fixed with commit
https://github.com/openstack/horizon/commit/8e8c084847280f3f8e975910b498ed9fbb3a69c8


** Changed in: horizon
   Status: New = Invalid

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

Title:
  unittest2 deprecated in Django

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  https://docs.djangoproject.com/en/1.7/topics/testing/overview
  /#writing-tests

  Python 2.7 introduced some major changes to the unittest library,
  adding some extremely useful features. To ensure that every Django
  project could benefit from these new features, Django used to ship
  with a copy of Python 2.7’s unittest backported for Python 2.6
  compatibility.

  Since Django no longer supports Python versions older than 2.7,
  django.utils.unittest is deprecated. Simply use unittest.

  openstack_dashboard/test/api_tests/rest_util_tests.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427165/+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 1427209] Re: oslo.log doesn't log request_id, project_id, user_id in nova

[Davanum Srinivas (DIMS)]

** Changed in: oslo.log
 Assignee: (unassigned) = Davanum Srinivas (DIMS) (dims-v)

** Changed in: oslo.log
   Status: New = Confirmed

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

Title:
  oslo.log doesn't log request_id, project_id, user_id in nova

Status in OpenStack Compute (Nova):
  New
Status in Logging configuration library for OpenStack:
  Confirmed

Bug description:
  The switch to oslo.log broke the nova logs so request_id, project_id,
  user_id are no longer logged. This is a critical breakage of the Nova
  logs, and makes them nearly useless.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427209/+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 1427158] Re: Rest call for group and user list is not working without domain_id

[Sourav Biswas]

** Description changed:

- In older build in PowerVC to get the group / user, we had used the following 
rest calls:
- https://9.114.226.100/powervc/openstack/admin/v3/users 
- https://9.114.226.100/powervc/openstack/admin/v3/groups
+ To get the group / user, we had used the following rest calls: v3/users
  
- For the recent builds, we are seeing the above command is not working and 
current working calls are :
- https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/groups
- https://9.114.226.100/powervc/openstack/admin/v3/ibm-roles/users
+ 
+ we are seeing the above command is not working current working calls are : 
v3/domain_id/groups
  
  So, it needs a domain id parameter to get the result. So it would
  definitely be nice if keystone would recognize that and not require the
  domain_id query parameter to make the /v3/groups and /v3/users commands
  work.

** Changed in: keystone
   Status: New = Invalid

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

Title:
  Rest call for group and user list is not working without domain_id

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  To get the group / user, we had used the following rest calls:
  v3/users

  
  we are seeing the above command is not working current working calls are : 
v3/domain_id/groups

  So, it needs a domain id parameter to get the result. So it would
  definitely be nice if keystone would recognize that and not require
  the domain_id query parameter to make the /v3/groups and /v3/users
  commands work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1427158/+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 1419577] [NEW] when live-migrate failed, lun-id couldn't be rollback in havana

[Launchpad Bug Tracker]

*** This bug is a security vulnerability ***

You have been subscribed to a public security bug:

Hi, guys

When live-migrate failed with error, lun-id of connection_info column in Nova's 
block_deivce_mapping table couldn't be rollback.
and failed VM can have others volume.

my test environment is following :

Openstack Version : Havana ( 2013.2.3)
Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

test step is :

1) create 2 Compute node (host#1 and host#2)
2) create 1 VM on host#1 (vm01)
3) create 1 cinder volume (vol01)
4) attach 1 volume to vm01 (/dev/vdb)
5) live-migrate vm01 from host#1 to host#2
6) live-migrate success
 - please check the mapper by using multipath command in host#1 (# 
multipath -ll), then you can find mapper is not deleted.
   and the status of devices is failed faulty
 - please check the lun-id of vol01
7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 
at step 4)
8) live-migrate fail
 - please check the mapper in host#1
 - please check the lun-id of vol01, then you can find the lun hav two 
igroups
 - please check the connection_info column in Nova's block_deivce_mapping 
table, then you can find lun-id couldn't be rollback

This Bug is critical security issue because the failed VM can have
others volume.

and every backend storage of cinder-volume can have same problem because
this is the bug of live-migration's rollback process.

I suggest below methods to solve issue :

1) when live-migrate is complete, nova should delete mapper devices at origin 
host
2) when live-migrate is failed, nova should rollback lun-id in connection_info 
column
3) when live-migrate is failed, cinder should delete the mapping between lun 
and host (Netapp : igroup, EMC : storage_group ...)
4) when volume-attach is requested , cinder volume driver of vendors should 
make lun-id randomly for reduce of probability of mis-mapping

please check this bug.

Thank you.

** Affects: nova
 Importance: Undecided
 Status: Confirmed

** Affects: ossa
 Importance: Undecided
 Status: Incomplete

-- 
when live-migrate failed, lun-id couldn't be rollback in havana
https://bugs.launchpad.net/bugs/1419577
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Compute (nova).

-- 
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 1411478] Re: Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean by LDAP drivers

[Dolph Mathews]

Before we backport this to stable/juno, are there any legitimate use
cases where people would be depending on the old behavior? Just want to
ensure there's no risk to backporting.

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

** Changed in: keystone/juno
   Status: New = Incomplete

** Changed in: keystone/juno
 Assignee: (unassigned) = Lin Hua Cheng (lin-hua-cheng)

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

Title:
  Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean
  by LDAP drivers

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in Keystone juno series:
  Incomplete

Bug description:
  Our core LDAP driver makes a dangerous assumption that any attribute
  that is equal to the string 'TRUE' or 'FALSE' must be a boolean and
  will covert the value accordingly.  For instance the following test:

  def test_hn1(self):
  ref = {
  'name': 'TRUE',
  'domain_id': CONF.identity.default_domain_id}
  ref = self.identity_api.create_user(ref)
  ref1 = self.identity_api.get_user(ref['id'])
  self.assertEqual(ref ,ref1)

  will fail (on an LDAP backend) with:

  MismatchError: !=:
  reference = {'domain_id': 'default',  'enabled': True,  'id': 
'd4202d8717104d2bb2ab49fec5e7fe70',  'name': 'TRUE'}
  actual= {'domain_id': 'default',  'enabled': True, 'id': 
u'd4202d8717104d2bb2ab49fec5e7fe70',  'name': True}

  Ouch!

  Now that we have a schema for our models, perhaps we should use that
  to determine whether something is a boolean or not? e.g. for projects,
  we have:

  _project_properties = {
  'description': validation.nullable(parameter_types.description),
  # NOTE(lbragstad): domain_id isn't nullable according to some backends.
  # The identity-api should be updated to be consistent with the
  # implementation.
  'domain_id': parameter_types.id_string,
  'enabled': parameter_types.boolean,
  'parent_id': validation.nullable(parameter_types.id_string),
  'name': {
  'type': 'string',
  'minLength': 1,
  'maxLength': 64
  }
  }

  For some reason the user/group ones don't exist yet, but we can fix
  that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1411478/+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 1427277] [NEW] [sahara] Detailed error on job binary creation is not shown

[Luigi Toscano]

Public bug reported:

When a job binary with an invalid name is created (for example: too long, like 
currently test_script_name_a5a330ee-bce0-11e4-beaf-3c970e1836cf), Sahara 
returns an well-defined exception, from the logs:
DEBUG sahara.utils.api [-] Validation Error occurred: error_code=400, 
error_message=u'test_script_name_a5a330ee-bce0-11e4-beaf-3c970e1836cf' is too 
long, error_name=VALIDATION_ERROR bad_request 
/usr/lib/python2.7/site-packages/sahara/utils/api.py:245
but Horizon just says:
Error: Unable to create job binary 

Tested on current Horizon master, Sahara from Juno (even if this is an
horizon issue, I think).

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

Title:
  [sahara] Detailed error on job binary creation is not shown

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When a job binary with an invalid name is created (for example: too long, 
like currently test_script_name_a5a330ee-bce0-11e4-beaf-3c970e1836cf), Sahara 
returns an well-defined exception, from the logs:
  DEBUG sahara.utils.api [-] Validation Error occurred: error_code=400, 
error_message=u'test_script_name_a5a330ee-bce0-11e4-beaf-3c970e1836cf' is too 
long, error_name=VALIDATION_ERROR bad_request 
/usr/lib/python2.7/site-packages/sahara/utils/api.py:245
  but Horizon just says:
  Error: Unable to create job binary 

  Tested on current Horizon master, Sahara from Juno (even if this is an
  horizon issue, I think).

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427277/+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 1427289] [NEW] [sahara] Back trace when a job binary is created using an existing script

[Luigi Toscano]

Public bug reported:

From Create Job Binary, add a valid name, storage type internal, and
choose an existing job binary (neither upload..., nor create... in
the Internal Binary box. The following backtrace can be seen in
Horizon logs:

[02/Mar/2015 16:24:14] POST 
/project/data_processing/job_binaries/create-job-binary HTTP/1.1 200 6462
Internal Server Error: /project/data_processing/job_binaries/create-job-binary
Traceback (most recent call last):
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/.venv/lib/python2.7/site-packages/django/core/handlers/base.py,
 line 112, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
36, in dec
return view_func(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
52, in dec
return view_func(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
36, in dec
return view_func(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
84, in dec
return view_func(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/.venv/lib/python2.7/site-packages/django/views/generic/base.py,
 line 69, in view
return self.dispatch(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/.venv/lib/python2.7/site-packages/django/views/generic/base.py,
 line 87, in dispatch
return handler(request, *args, **kwargs)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/.venv/lib/python2.7/site-packages/django/views/generic/edit.py,
 line 171, in post
return self.form_valid(form)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/forms/views.py, 
line 173, in form_valid
exceptions.handle(self.request)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/exceptions.py, line 
364, in handle
six.reraise(exc_type, exc_value, exc_traceback)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/forms/views.py, 
line 170, in form_valid
handled = form.handle(self.request, form.cleaned_data)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py,
 line 183, in handle
_(Unable to create job binary))
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/exceptions.py, line 
364, in handle
six.reraise(exc_type, exc_value, exc_traceback)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py,
 line 169, in handle
bin_url = self.handle_internal(request, context)
  File 
/home/toscano/OpenStack/code/os/openstack/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py,
 line 229, in handle_internal
bin_id = result.id
AttributeError: 'str' object has no attribute 'id'
[02/Mar/2015 16:25:44] POST 
/project/data_processing/job_binaries/create-job-binary HTTP/1.1 500 39108

Reproduced on current Horizon git master.

** Affects: horizon
 Importance: Undecided
 Status: Confirmed


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

Title:
  [sahara] Back trace when a job binary is created using an existing
  script

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  From Create Job Binary, add a valid name, storage type internal,
  and choose an existing job binary (neither upload..., nor
  create... in the Internal Binary box. The following backtrace can
  be seen in Horizon logs:

  [02/Mar/2015 16:24:14] POST 
/project/data_processing/job_binaries/create-job-binary HTTP/1.1 200 6462
  Internal Server Error: /project/data_processing/job_binaries/create-job-binary
  Traceback (most recent call last):
File 
/home/toscano/OpenStack/code/os/openstack/horizon/.venv/lib/python2.7/site-packages/django/core/handlers/base.py,
 line 112, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
36, in dec
  return view_func(request, *args, **kwargs)
File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
52, in dec
  return view_func(request, *args, **kwargs)
File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
36, in dec
  return view_func(request, *args, **kwargs)
File 
/home/toscano/OpenStack/code/os/openstack/horizon/horizon/decorators.py, line 
84, in dec
  return view_func(request, *args, **kwargs)
File 

[Yahoo-eng-team] [Bug 1427295] [NEW] nova-network with multi-host and update_dns_entries crashes during instance termination

[Calvin Walton]

Public bug reported:

I have Openstack Nova set up using nova-network in multi-host mode. I
wanted all instances to be able to resolve each-other via dns, so I
enabled update_dns_entries=True in nova.conf

Upon terminating an instance, I get the following traceback in nova-
compute.log on the compute node hosting the instance:

Traceback (most recent call last):

  File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 134, in _dispatch_and_reply
incoming.message))

  File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 177, in _dispatch
return self._do_dispatch(endpoint, method, ctxt, args)

  File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 123, in _do_dispatch
result = getattr(endpoint, method)(ctxt, **new_args)

  File /usr/lib/python2.7/dist-packages/nova/network/floating_ips.py, line 
187, in deallocate_for_instance
super(FloatingIP, self).deallocate_for_instance(context, **kwargs)

  File /usr/lib/python2.7/dist-packages/nova/network/manager.py, line 568, in 
deallocate_for_instance
network_ids = [fixed_ip.network_id for fixed_ip in fixed_ips]

AttributeError: 'str' object has no attribute 'network_id'

Some spelunking reveals that this was introduced in the following commit:
https://github.com/openstack/nova/commit/03d34c975586788dc25249b5e0b962fc0634008c
which changed the fixed_ips array to contain a list of string ip address, 
rather than fixed_ip objects, but neglected to update the code under the 
CONF.update_dns_entries branch below to match.

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

Title:
  nova-network with multi-host and update_dns_entries crashes during
  instance termination

Status in OpenStack Compute (Nova):
  New

Bug description:
  I have Openstack Nova set up using nova-network in multi-host mode. I
  wanted all instances to be able to resolve each-other via dns, so I
  enabled update_dns_entries=True in nova.conf

  Upon terminating an instance, I get the following traceback in nova-
  compute.log on the compute node hosting the instance:

  Traceback (most recent call last):

File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 134, in _dispatch_and_reply
  incoming.message))

File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 177, in _dispatch
  return self._do_dispatch(endpoint, method, ctxt, args)

File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, 
line 123, in _do_dispatch
  result = getattr(endpoint, method)(ctxt, **new_args)

File /usr/lib/python2.7/dist-packages/nova/network/floating_ips.py, line 
187, in deallocate_for_instance
  super(FloatingIP, self).deallocate_for_instance(context, **kwargs)

File /usr/lib/python2.7/dist-packages/nova/network/manager.py, line 568, 
in deallocate_for_instance
  network_ids = [fixed_ip.network_id for fixed_ip in fixed_ips]

  AttributeError: 'str' object has no attribute 'network_id'

  Some spelunking reveals that this was introduced in the following commit:
  
https://github.com/openstack/nova/commit/03d34c975586788dc25249b5e0b962fc0634008c
  which changed the fixed_ips array to contain a list of string ip address, 
rather than fixed_ip objects, but neglected to update the code under the 
CONF.update_dns_entries branch below to match.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427295/+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 1427261] [NEW] Improve create instance without volume service

[Cedric Brandily]

Public bug reported:

Currently an error notification is raised when creating an instance on an 
OpenStack deployment without volume service.

This change avoids the error notification as volume service is not required to 
boot an instance.

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: 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/1427261

Title:
  Improve create instance without volume service

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Currently an error notification is raised when creating an instance on an 
OpenStack deployment without volume service.
  
  This change avoids the error notification as volume service is not required 
to boot an instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427261/+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 1423695] Re: gate-devstack-dsvm-cells fails attaching volume

[Matt Riedemann]

Released in 2.22.0.

** Changed in: python-novaclient
   Status: Fix Committed = 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/1423695

Title:
  gate-devstack-dsvm-cells fails attaching volume

Status in OpenStack Compute (Nova):
  Invalid
Status in Python client library for Nova:
  Fix Released

Bug description:
  http://logs.openstack.org/07/154607/3/gate/gate-devstack-dsvm-
  cells/302ef5f/console.html#_2015-02-19_19_20_49_062

  2015-02-19 19:20:47.642 | + nova volume-attach 
d16b33f6-7cf7-4e77-b149-84ba3eedf0e6 e2496f30-dac1-484b-b25c-c925a0766fa6 
/dev/vdb
  2015-02-19 19:20:49.034 | ERROR (NotFound): Not found (HTTP 404) (Request-ID: 
req-8ae38d4c-c754-4c45-92bd-0719bc2ecdd5)
  2015-02-19 19:20:49.062 | + die 174 'Failure attaching volume ex-vol-f39662b7 
to ex-vol-inst'
  2015-02-19 19:20:49.062 | + local exitcode=1
  2015-02-19 19:20:49.062 | + set +o xtrace
  2015-02-19 19:20:49.062 | [Call Trace]
  2015-02-19 19:20:49.063 | /opt/stack/new/devstack/exercises/volumes.sh:174:die
  2015-02-19 19:20:49.065 | [ERROR] 
/opt/stack/new/devstack/exercises/volumes.sh:174 Failure attaching volume 
ex-vol-f39662b7 to ex-vol-inst

  Just started today:

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiZXhlcmNpc2VzL3ZvbHVtZXMuc2hcIiBBTkQgbWVzc2FnZTpcIkZhaWx1cmUgYXR0YWNoaW5nIHZvbHVtZVwiIEFORCBtZXNzYWdlOlwidG8gZXgtdm9sLWluc3RcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyNDM4MDc1MDI3Nn0=

  35 hits in 24 hours, check and gate, all failures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1423695/+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 1384112] Re: endpoint, service, region can not be updated when using kvs driver

[Dolph Mathews]

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

** Changed in: keystone/juno
 Assignee: (unassigned) = wanghong (w-wanghong)

** Changed in: keystone/juno
   Status: New = In Progress

** Changed in: keystone/juno
   Importance: Undecided = Low

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

Title:
  endpoint, service, region can not be updated when using kvs driver

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone juno series:
  In Progress

Bug description:
  region:
  curl -i -H X-Auth-Token:$TOKEN -H Content-Type:application/json 
http://192.168.70.105:35357/v3/regions/ed5ff7d3e26c48aeaf1f2f9fb2a4ad7e -d 
'{region:{description:xxx}}' -X PATCH

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: 'id' (Disable debug mode to suppress these
  details.), code: 500, title: Internal Server Error}}

  
  service:
  curl -i -H X-Auth-Token:$TOKEN -H Content-Type:application/json 
http://192.168.70.105:35357/v3/services/f101743b55e54d2ba9cbf71d1f3456fc -d 
'{service:{type:yy}}' -X PATCH

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: 'id' (Disable debug mode to suppress these
  details.), code: 500, title: Internal Server Error}}

  
  endpoint:
  curl -i -H X-Auth-Token:$TOKEN -H Content-Type:application/json 
http://192.168.70.105:35357/v3/endpoints/bbe21bf654e442edb21716cc00fb1c58 -d 
'{endpoint:{zz:tt}}' -X PATCH

  {error: {message: An unexpected error prevented the server from
  fulfilling your request: 'region_id' (Disable debug mode to suppress
  these details.), code: 500, title: Internal Server Error}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1384112/+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 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana

[Thierry Carrez]

Agree that it's a vulnerability in Havana (since live-migration fails so
often there). I wouldn't consider it a vulnerability in Icehouse/Juno,
since you can't trigger live migration failure without administrative or
physical access to the machines.

It is a bug with security consequences there, and it should be fixed as
soon as possible.

** Changed in: nova-project
   Status: New = Confirmed

** Project changed: nova-project = nova

** Changed in: nova
   Importance: Undecided = 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/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in 
Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 
17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
   - please check the mapper by using multipath command in host#1 (# 
multipath -ll), then you can find mapper is not deleted.
     and the status of devices is failed faulty
   - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to 
host#2 at step 4)
  8) live-migrate fail
   - please check the mapper in host#1
   - please check the lun-id of vol01, then you can find the lun hav two 
igroups
   - please check the connection_info column in Nova's block_deivce_mapping 
table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin 
host
  2) when live-migrate is failed, nova should rollback lun-id in 
connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun 
and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should 
make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+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 1427291] [NEW] ML2 hierarchical port binding needs additional tests

[Robert Kukura]

Public bug reported:

Although the current unit tests cover the hierarchical port binding code
reasonably well, additional tests are needed that verify the following:

* Binding loops are properly avoided
* Binding limit is detected
* Dead-end binding attempts are handled properly

** Affects: neutron
 Importance: Medium
 Assignee: Robert Kukura (rkukura)
 Status: New


** Tags: ml2

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

Title:
  ML2 hierarchical port binding needs additional tests

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Although the current unit tests cover the hierarchical port binding
  code reasonably well, additional tests are needed that verify the
  following:

  * Binding loops are properly avoided
  * Binding limit is detected
  * Dead-end binding attempts are handled properly

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427291/+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 1427304] [NEW] [sahara] When the job binary creating fails, the job binary data is created anyway

[Luigi Toscano]

Public bug reported:

If the user tries to create a Job Binary using the internal db as
storage, and the creating fails for a validation error, the job binary
data is created anyway.

The job data creation code should be executed at the same time/in the
same transaction of the job binary creation (and rolled back if the
latter fails).

Found on current Horizon git master (Sahara from Juno, but the problem
seems more Horizon-related).

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

Title:
  [sahara] When the job binary creating fails, the job binary data is
  created anyway

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  If the user tries to create a Job Binary using the internal db as
  storage, and the creating fails for a validation error, the job binary
  data is created anyway.

  The job data creation code should be executed at the same time/in the
  same transaction of the job binary creation (and rolled back if the
  latter fails).

  Found on current Horizon git master (Sahara from Juno, but the problem
  seems more Horizon-related).

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427304/+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 1427328] [NEW] [sahara] The mechanism used to avoid duplicate script names in jobs binaries is fragile

[Luigi Toscano]

Public bug reported:

Create a Job Binary in the internal db, with a specific script name (for
example, script_name).

If the user creates another job binary with the same script name, a unique UUID 
is added so that the name is unique. 
But, if the script name is long, the addition of the UUID can make it longer 
than the field limit (80 characters) and the job creation fails.
Moreover, this mechanism is counterintuitive as it is not implemented for the 
job binary name field (an error is returned).

Proposal:
- remove the mechanism which tries to create an unique script name, and simply 
returns a validation error if a script name is duplicated.

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

Title:
  [sahara] The mechanism used to avoid duplicate script names in jobs
  binaries is fragile

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Create a Job Binary in the internal db, with a specific script name
  (for example, script_name).

  If the user creates another job binary with the same script name, a unique 
UUID is added so that the name is unique. 
  But, if the script name is long, the addition of the UUID can make it longer 
than the field limit (80 characters) and the job creation fails.
  Moreover, this mechanism is counterintuitive as it is not implemented for the 
job binary name field (an error is returned).

  Proposal:
  - remove the mechanism which tries to create an unique script name, and 
simply returns a validation error if a script name is duplicated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427328/+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 1427317] [NEW] Defunct plug-in configuration files

[Matt Kassawara]

Public bug reported:

After ML2, the Open vSwitch and Linux Bridge plug-ins became
mechanisms/agents. However, the configuration files for these agents,
particularly OVS with ovs_neutron_plugin.ini, generates confusion.
Furthermore, distributions that package OpenStack take different routes
for configuring these agents. With OVS in particular, some distributions
add the agent configuration to ml2_conf.ini and others continue to use
ovs_neutron_plugin.ini. These issues particularly impact documentation
[1][2] such as the installation guide that provides step-by-step
instructions on multiple distributions and the (upcoming) networking
guide that attempts to provide several deployable distro-agnostic
scenarios with step-by-step instructions.

I suggest either using ml2_conf.ini for OVS and LB agent configuration
or renaming the configuration files to something more meaningful and
consistent. For example, ml2_conf_ovs.ini, ml2_conf_linuxbridge.ini,
ovs_agent.ini or linuxbridge_agent.ini.

[1] https://bugs.launchpad.net/openstack-manuals/+bug/1422038
[2] https://bugs.launchpad.net/openstack-manuals/+bug/1375746

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

Title:
  Defunct plug-in configuration files

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  After ML2, the Open vSwitch and Linux Bridge plug-ins became
  mechanisms/agents. However, the configuration files for these agents,
  particularly OVS with ovs_neutron_plugin.ini, generates confusion.
  Furthermore, distributions that package OpenStack take different
  routes for configuring these agents. With OVS in particular, some
  distributions add the agent configuration to ml2_conf.ini and others
  continue to use ovs_neutron_plugin.ini. These issues particularly
  impact documentation [1][2] such as the installation guide that
  provides step-by-step instructions on multiple distributions and the
  (upcoming) networking guide that attempts to provide several
  deployable distro-agnostic scenarios with step-by-step instructions.

  I suggest either using ml2_conf.ini for OVS and LB agent configuration
  or renaming the configuration files to something more meaningful and
  consistent. For example, ml2_conf_ovs.ini, ml2_conf_linuxbridge.ini,
  ovs_agent.ini or linuxbridge_agent.ini.

  [1] https://bugs.launchpad.net/openstack-manuals/+bug/1422038
  [2] https://bugs.launchpad.net/openstack-manuals/+bug/1375746

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427317/+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 1426544] Re: Nova switching to oslo_log blows up instance object repr in logs

[Doug Hellmann]

** Changed in: oslo.log
   Status: Fix Committed = Fix Released

** Changed in: oslo.log
Milestone: None = 0.4.0

** Changed in: oslo.log
   Importance: Undecided = Critical

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

Title:
  Nova switching to oslo_log blows up instance object repr in logs

Status in OpenStack Compute (Nova):
  Confirmed
Status in Logging configuration library for OpenStack:
  Fix Released

Bug description:
  Logging with an instance kwarg used to just log the instance uuid but
  now it looks like after the change to use oslo_log we're logging the
  entire representation of the instance object which blows up the logs
  and makes things hard to read:

  http://logs.openstack.org/40/122240/19/gate/gate-tempest-dsvm-neutron-
  full/4ef0a02/logs/screen-n-cpu.txt.gz

  For example:

  2015-02-27 18:03:45.510 8433 WARNING nova.compute.manager [-]
  
Instance(access_ip_v4=None,access_ip_v6=None,architecture=None,auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,config_drive='',created_at=2015-02-27T18:03:40Z,default_ephemeral_device=None,default_swap_device=None,deleted=False,deleted_at=None,disable_terminate=False,display_description
  ='ImagesTestJSON-instance-902123019',display_name='ImagesTestJSON-
  
instance-902123019',ephemeral_gb=0,ephemeral_key_uuid=None,fault=?,flavor=Flavor(6),host
  ='devstack-trusty-rax-dfw-1041350.slave.openstack.org',hostname
  ='imagestestjson-instance-902123019',id=9,image_ref='801203df-
  
0ef4-45c5-bdd2-f981358dff40',info_cache=InstanceInfoCache,instance_type_id=6,kernel_id='525a7006
  -cf4b-45be-
  
b2e8-a6fd46e52d47',key_data=None,key_name=None,launch_index=0,launched_at=2015-02-27T18:03:42Z,launched_on
  ='devstack-trusty-rax-
  
dfw-1041350.slave.openstack.org',locked=False,locked_by=None,memory_mb=64,metadata={},new_flavor=None,node
  ='devstack-trusty-rax-
  
dfw-1041350.slave.openstack.org',numa_topology=?,old_flavor=None,os_type=None,pci_devices=?,pci_requests=?,power_state=1,progress=0,project_id='e619583f4404465ab6d1d85c065c05c3',ramdisk_id='6949db12
  -e5cd-416a-
  
b1c5-7318595d3382',reservation_id='r-l5zukbbw',root_device_name='/dev/vda',root_gb=0,scheduled_at=None,security_groups=SecurityGroupList,shutdown_terminate=False,system_metadata={image_base_image_ref
  ='801203df-
  
0ef4-45c5-bdd2-f981358dff40',image_container_format='ami',image_disk_format='ami',image_kernel_id='525a7006
  -cf4b-45be-
  
b2e8-a6fd46e52d47',image_min_disk='0',image_min_ram='0',image_ramdisk_id='6949db12
  -e5cd-416a-
  
b1c5-7318595d3382'},tags=?,task_state=None,terminated_at=None,updated_at=2015-02-27T18:03:45Z,user_data=None,user_id='78901d21abe4437384eaa007da8558e0',uuid
  =8997322e-a1fe-
  
4f80-ba89-2a34c54a8985,vcpu_model=?,vcpus=1,vm_mode=None,vm_state='active')Image
  not found during snapshot

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1426544/+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 1427343] [NEW] missing entry point for cisco apic topology agent

[Ivar Lazzaro]

Public bug reported:

Cisco APIC topology agent [0] is missing the entry point.


[0] neutron.plugins.ml2.drivers.cisco.apic.apic_topology.ApicTopologyService

** Affects: neutron
 Importance: Undecided
 Assignee: Ivar Lazzaro (mmaleckk)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) = Ivar Lazzaro (mmaleckk)

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

Title:
  missing entry point for cisco apic topology agent

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Cisco APIC topology agent [0] is missing the entry point.

  
  [0] neutron.plugins.ml2.drivers.cisco.apic.apic_topology.ApicTopologyService

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427343/+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 1427351] [NEW] cells: hypervisor API extension can't find compute_node services

[Andrew Laski]

Public bug reported:

After the conversion to use Service objects in the hypervisor API
extension the lookups for services are happening in the parent cell, not
the child cells.  This is due to cells redirects not being implemented
in the Service object.

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

Title:
  cells: hypervisor API extension can't find compute_node services

Status in OpenStack Compute (Nova):
  New

Bug description:
  After the conversion to use Service objects in the hypervisor API
  extension the lookups for services are happening in the parent cell,
  not the child cells.  This is due to cells redirects not being
  implemented in the Service object.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1427351/+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 1424576] Re: RuntimeError: Unable to find group for option fatal_deprecations, maybe it's defined twice in the same group?

[Doug Hellmann]

The config generator from the incubator is deprecated in favor of the
new approach in oslo.config.

** Changed in: oslo-incubator
   Status: New = Won't Fix

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

Title:
  RuntimeError: Unable to find group for option fatal_deprecations,
  maybe it's defined twice in the same group?

Status in OpenStack Compute (Nova):
  In Progress
Status in The Oslo library incubator:
  Won't Fix

Bug description:
  I tried to generate a nova.conf configuration file with the current
  state of the Nova repository (master) and got the following exception
  message:

  % tox -e genconfig
  genconfig create: /home/berendt/Repositories/nova/.tox/genconfig
  genconfig installdeps: -r/home/berendt/Repositories/nova/requirements.txt, 
-r/home/berendt/Repositories/nova/test-requirements.txt
  genconfig develop-inst: /home/berendt/Repositories/nova
  genconfig runtests: PYTHONHASHSEED='0'
  genconfig runtests: commands[0] | bash tools/config/generate_sample.sh -b . 
-p nova -o etc/nova
  Traceback (most recent call last):
    File /usr/lib64/python2.7/runpy.py, line 162, in _run_module_as_main
  __main__, fname, loader, pkg_name)
    File /usr/lib64/python2.7/runpy.py, line 72, in _run_code
  exec code in run_globals
    File 
/home/berendt/Repositories/nova/nova/openstack/common/config/generator.py, 
line 303, in module
  main()
    File 
/home/berendt/Repositories/nova/nova/openstack/common/config/generator.py, 
line 300, in main
  generate(sys.argv[1:])
    File 
/home/berendt/Repositories/nova/nova/openstack/common/config/generator.py, 
line 128, in generate
  for group, opts in _list_opts(mod_obj):
    File 
/home/berendt/Repositories/nova/nova/openstack/common/config/generator.py, 
line 192, in _list_opts
  ret.setdefault(_guess_groups(opt, obj), []).append(opt)
    File 
/home/berendt/Repositories/nova/nova/openstack/common/config/generator.py, 
line 172, in _guess_groups
  % opt.name
  RuntimeError: Unable to find group for option fatal_deprecations, maybe it's 
defined twice in the same group?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1424576/+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 1427097] [NEW] Test case to create provider network

[Wu Hong Guang]

Public bug reported:

Provider networks are created by the admin  and map directly to an existing 
physical network in the data center. Useful network types in this category are 
flat (untagged) and VLAN (802.1Q tagged). It is possible to allow provider
networks to be shared among tenants as part of the network creation process

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: integration-tests

** Description changed:

- Provider networks are created by the admin  and
- map directly to an existing physical network in the data center. Useful 
network types in this
- category are flat (untagged) and VLAN (802.1Q tagged). It is possible to 
allow provider
+ Provider networks are created by the admin  and map directly to an existing 
physical network in the data center. Useful network types in this category are 
flat (untagged) and VLAN (802.1Q tagged). It is possible to allow provider
  networks to be shared among tenants as part of the network creation process

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

Title:
  Test case to create provider network

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Provider networks are created by the admin  and map directly to an existing 
physical network in the data center. Useful network types in this category are 
flat (untagged) and VLAN (802.1Q tagged). It is possible to allow provider
  networks to be shared among tenants as part of the network creation process

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