[Yahoo-eng-team] [Bug 1764272] Re: no records logged which show that httpd.service is dead

2018-06-22 Thread Launchpad Bug Tracker
[Expired for OpenStack Identity (keystone) because there has been no
activity for 60 days.]

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

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

Title:
  no records logged which show that httpd.service is dead

Status in OpenStack Identity (keystone):
  Expired

Bug description:
  There are no records logged which show that httpd.service is dead. The
  error is logged in /var/log/messages, this can make it difficult for
  the administrator to trace the error because /var/log/messages
  contains the general purpose error logs for overall system.

  As keystone service runs inside httpd, the non-availability of httpd
  can make the entire openstack environment stop working.

  To avoid this issue, there can be two possible solutions:
  Log the error message in component level log. Here the error message should 
be logged in keystone.log so that monitoring remains within keystone component. 
In this case, changes should be done in keystone client end.
  High level monitoring mechanism such as email containing the error message 
can also be sent to admin so that monitoring can be made more convenient.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1764272/+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 1764274] Re: An extra GET request is executed to fetch tenant information

2018-06-22 Thread Launchpad Bug Tracker
[Expired for OpenStack Identity (keystone) because there has been no
activity for 60 days.]

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

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

Title:
  An extra GET request is executed to fetch tenant information

Status in OpenStack Identity (keystone):
  Expired

Bug description:
  In Create user operation an extra GET request is executed to fetch tenant 
information. tenant information can not be acquired by tenant_name as API is 
not supported directly for tenant_name. The first GET request is executed with 
tenant_name then initially 404 error is returned. Id need to be given to get 
tenant details. So in next GET request the Tenant_ID information is fetched.
  Here the first GET request is an overhead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1764274/+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 1766181] Re: error trying to lunch a test VM

2018-06-22 Thread Launchpad Bug Tracker
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

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

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

Title:
  error trying to lunch a test VM

Status in OpenStack Compute (nova):
  Expired

Bug description:
  5 "GET /v2.1/flavors/0 HTTP/1.1" status: 200 len: 692 time: 0.0270371
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
[req-3057451d-26a3-4850-b14b-9bef41609b6f a35d1ca086054f44bc8d12ce0a4ff07f 
623e4bc119bf426d89f4c980a4349cfb - default default] Unexpected exception in API 
method
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 338, 
in wrapped
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 108, 
in wrapper
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/servers.py", line 
642, in create
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
**create_kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/hooks.py", line 154, in inner
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions rv = 
f(*args, **kwargs)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 1620, in create
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
check_server_group_quota=check_server_group_quota)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 1170, in 
_create_instance
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
image_id, boot_meta = self._get_image(context, image_href)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 806, in _get_image
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions image = 
self.image_api.get(context, image_href)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/image/api.py", line 95, in get
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
show_deleted=show_deleted)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/image/glance.py", line 468, in show
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
_reraise_translated_image_exception(image_id)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/image/glance.py", line 1050, in 
_reraise_translated_image_exception
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions 
six.reraise(type(new_exc), new_exc, exc_trace)
  2018-04-23 10:09:48.552 49114 ERROR nova.api.openstack.extensions   File 

[Yahoo-eng-team] [Bug 1745633] Re: L3 service providers driver controller lacks sufficient notifications to enable L3 flavors

2018-06-22 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/523257
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=b9fabd82675e2b74dd4afd3b7d1f8fbda6951ecd
Submitter: Zuul
Branch:master

commit b9fabd82675e2b74dd4afd3b7d1f8fbda6951ecd
Author: Isaku Yamahata 
Date:   Mon Nov 27 16:42:29 2017 -0800

l3 flavor: more events/notifications and callback priority

After the addition of a new resource and related events with [1],
this patch adds the necessary notifications for l3 flavor,
resource(ROUTER_CONTROLLER) and events(PRECOMMIT_ADD_ASSOCIATION and
PRECOMMIT_DELETE_ASSOCIATIONS) so that l3 flavor driver can subscribe to
them when flavor is changed.

Apply callback priority to ensure that the ordering of callback the
following.
- l3_*_db callbacks to extend l3 extended attributes
  This callbacks need to be called first so that rest callbacks can
  see those extended attributes.
- l3 driver controller callbacks
- l3 flavor driver callbacks
extra routes/l3_gwmode/l3_hamode need care because they are
updated via update_router but within different db transaction.

[1] I1e72ee843851004d26410a90da4030ab3b024741

Closes-Bug: #1745633

Co-Authored-By: Manjeet Singh Bhatia
Change-Id: If20b11f0587f1ed30db72d97c15b20d4c6e87543
Depends-On: https://review.openstack.org/#/c/541766/


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

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

Title:
  L3 service providers driver controller lacks sufficient notifications
  to enable L3 flavors

Status in neutron:
  Fix Released

Bug description:
  Notifications for l3 flavor for resource(ROUTER_CONTROLLER) and
  events(PRECOMMIT_ADD/DEL_ASSOCIATION) are needed so that l3 flavor
  drivers can subscribe to them

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1745633/+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 1778118] Re: missing transaction in driver_controller.py for l3 flavors

2018-06-22 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/577246
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d97cce0403eb0ca10fb26ba23facb37c86934835
Submitter: Zuul
Branch:master

commit d97cce0403eb0ca10fb26ba23facb37c86934835
Author: Manjeet Singh Bhatia 
Date:   Thu Jun 21 18:17:41 2018 +

Add missing transaction in driver_controller.

All the operations related to router associations (add/del)
were executed under transactions, there was a case
'get_provider_for_router' doing add_resource_association
out of db transaction, luckily due to autocommit there were no
issues but this patch adds the missing transaction.

Closes-Bug: #1778118

Change-Id: Iaec9a40614c7e6ce1120e9fa7ef3a4fdb4d59963


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

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

Title:
  missing transaction in driver_controller.py for l3 flavors

Status in neutron:
  Fix Released

Bug description:
  All the operations related to router associations like add or delete
  etc were executed under transactions, there was a case
  'get_provider_for_router' doing add_resource_association out of db
  transaction, luckily due to autocommit there were no issues.

  
https://github.com/openstack/neutron/blob/master/neutron/services/l3_router/service_providers/driver_controller.py#L160

  need to be in under transaction.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1778118/+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 1778305] [NEW] Nova may erronously look up service version of a deleted service, when hostname have been reused

2018-06-22 Thread Trygve Vea
Public bug reported:

Prerequisites:

- A compute node running an old version of nova has been deleted. (In our case, 
version 9)
- The hostname of said compute node has been reused, and has been upgraded as 
per normal. (To version 16)
- The services table in the nova database contains both the old and the new 
node defined, where the deleted one are clearly marked as deleted - and with 
the old version specified in the version column.  The new node also exist, 
upgraded as it is.
- One has at least one instance running on the upgraded node.
- Perform upgrade from ocata to pike
- Any projects with instances running on the upgraded node, may erronously get 
an error message that "ERROR (BadRequest): This service is older (v9) than the 
minimum (v16) version of the rest of the deployment. Unable to continue. (HTTP 
400) (Request-ID: req-3e0ababe-e09b-4ef8-ba3a-43060bc1f807)" --- when 
performing 'nova list'.


Example of how this may look in the database:

MariaDB [nova]> SELECT * FROM services WHERE host = 'node11.acme.org';
+-+-+-+-+-+--+-+--+--+-+-+-+-+-+--+
| created_at  | updated_at  | deleted_at  | id  | host  
  | binary   | topic   | report_count | disabled | deleted | 
disabled_reason | last_seen_up| forced_down | version | uuid
 |
+-+-+-+-+-+--+-+--+--+-+-+-+-+-+--+
| 2017-10-17 13:06:10 | 2018-06-22 21:42:42 | NULL| 179 | 
node11.acme.org | nova-compute | compute |  2138069 |0 |   0 | 
NULL| 2018-06-22 21:42:42 |   0 |  22 | 
63e1cb55-ee00-4cb8-b304-160dd5c45fdd |
| 2016-08-13 08:20:05 | 2016-11-15 00:01:21 | 2016-11-27 15:11:30 | 104 | 
node11.acme.org | nova-compute | compute |   796220 |1 | 104 | 
NULL| 2016-11-15 00:01:21 |   0 |   9 | NULL
 |
+-+-+-+-+-+--+-+--+--+-+-+-+-+-+--+
2 rows in set (0.01 sec)


Removing the old service from the database is an effective workaround
for this problem.

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

Title:
  Nova may erronously look up service version of a deleted service, when
  hostname have been reused

Status in OpenStack Compute (nova):
  New

Bug description:
  Prerequisites:

  - A compute node running an old version of nova has been deleted. (In our 
case, version 9)
  - The hostname of said compute node has been reused, and has been upgraded as 
per normal. (To version 16)
  - The services table in the nova database contains both the old and the new 
node defined, where the deleted one are clearly marked as deleted - and with 
the old version specified in the version column.  The new node also exist, 
upgraded as it is.
  - One has at least one instance running on the upgraded node.
  - Perform upgrade from ocata to pike
  - Any projects with instances running on the upgraded node, may erronously 
get an error message that "ERROR (BadRequest): This service is older (v9) than 
the minimum (v16) version of the rest of the deployment. Unable to continue. 
(HTTP 400) (Request-ID: req-3e0ababe-e09b-4ef8-ba3a-43060bc1f807)" --- when 
performing 'nova list'.

  
  Example of how this may look in the database:

  MariaDB [nova]> SELECT * FROM services WHERE host = 'node11.acme.org';
  
+-+-+-+-+-+--+-+--+--+-+-+-+-+-+--+
  | created_at  | updated_at  | deleted_at  | id  | 
host| binary   | topic   | report_count | disabled | deleted | 
disabled_reason | last_seen_up| forced_down | version | uuid
 |
  
+-+-+-+-+-+--+-+--+--+-+-+-+-+-+--+
  | 2017-10-17 13:06:10 | 2018-06-22 21:42:42 | NULL  

[Yahoo-eng-team] [Bug 1778044] Re: libvirt.libvirtError: internal error: unable to execute QEMU command 'object-add': Incorrect number of padding bytes

2018-06-22 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/577164
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=78891c2305bff6e16706339a9c5eca99a84e409c
Submitter: Zuul
Branch:master

commit 78891c2305bff6e16706339a9c5eca99a84e409c
Author: Lee Yarwood 
Date:   Wed Jun 20 18:06:13 2018 +0100

libvirt: Log breadcrumb for known encryption bug

The initial implementation of native LUKS support within Libvirt
introduced a small issue when using a passphrase that is a multiple of
16 bytes in size. This is documented in the following bug and associated
patch posted to the Libvirt development list:

Unable to use LUKS passphrase that is exactly 16 bytes long
https://bugzilla.redhat.com/show_bug.cgi?id=1447297

[libvirt] [PATCH] Fix padding of encrypted data
https://www.redhat.com/archives/libvir-list/2017-May/msg00030.html

This change introduces a known issue release note and logs an additional
breadcrumb when we appear to hit this with pointers to the above.

Closes-Bug: #1778044
Change-Id: Id346bce6e47431988cce7001abcf29a9faf2936a


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

** Bug watch added: Red Hat Bugzilla #1447297
   https://bugzilla.redhat.com/show_bug.cgi?id=1447297

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

Title:
  libvirt.libvirtError: internal error: unable to execute QEMU command
  'object-add': Incorrect number of padding bytes

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===
  When attempting to attach an encrypted volume the following trace is logged 
[1]:

  File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py",
  line 1463, in attach_volume
   guest.attach_device(conf, persistent=True, live=live)
 File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py",
  line 303, in attach_device
   self._domain.attachDeviceFlags(device_xml, flags=flags)
 File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 186, in
  doit
   result = proxy_call(self._autowrap, f, *args, **kwargs)
 File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 144, in
  proxy_call
   rv = execute(f, *args, **kwargs)
 File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 125, in
  execute
   six.reraise(c, e, tb)
 File "/usr/lib/python3/dist-packages/eventlet/support/six.py", line
  625, in reraise
   raise value
 File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 83, in
  tworker
   rv = meth(*args, **kwargs)
 File "/usr/lib/python3/dist-packages/libvirt.py", line 585, in
  attachDeviceFlags
   if ret == -1: raise libvirtError ('virDomainAttachDeviceFlags()
  failed', dom=self)
   libvirt.libvirtError: internal error: unable to execute QEMU command
  'object-add': Incorrect number of padding bytes (57) found on decrypted data

  This is due to a known libvirt issue detailed in the following bug
  report and fix:

  Unable to use LUKS passphrase that is exactly 16 bytes long 
  https://bugzilla.redhat.com/show_bug.cgi?id=1447297

  [libvirt] [PATCH] Fix padding of encrypted data
  https://www.redhat.com/archives/libvir-list/2017-May/msg00030.html

  Nova should log a breadcrumb when this issue is encountered directing
  the operator to update Libvirt to resolve this issue.

  [1] http://lists.openstack.org/pipermail/openstack-
  dev/2018-June/131653.html

  Steps to reproduce
  ==
  Using a version of Libvirt without the above fix simply attempt to attach and 
encrypted volume using the native LUKS decryption feature in Nova.

  Expected result
  ===
  Breadcrumb line logged if this issue is hit.

  Actual result
  =
  Only the trace is logged.

  Environment
  ===
  1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/

 Current Rocky master.

  2. Which hypervisor did you use?
 (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
 What's the version of that?

 Libvirt

  2. Which storage type did you use?
 (For example: Ceph, LVM, GPFS, ...)
 What's the version of that?

 N/A

  3. Which networking type did you use?
 (For example: nova-network, Neutron with OpenVSwitch, ...)

 N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1778044/+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 1774234] Re: api-ref: cold migrate reference doesn't mention asynchronous post conditions

2018-06-22 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/571375
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=55c86166326069f9fdf156b60d63f9f20b80f957
Submitter: Zuul
Branch:master

commit 55c86166326069f9fdf156b60d63f9f20b80f957
Author: tianhui 
Date:   Thu May 31 11:53:04 2018 +0800

Fix bug to api-ref

The API reference for the server 'migrate' (cold migrate) action
doesn't mention any asynchronous post conditions. We should have
something similar to what's in the 'resize' action API reference.

Change-Id: I596b95cbd276e8d16a1cc8ce20d77f0ff6985317
Closes-bug: #1774234


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

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

Title:
  api-ref: cold migrate reference doesn't mention asynchronous post
  conditions

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The API reference for the server 'migrate' (cold migrate) action
  doesn't mention any asynchronous post conditions, like that the server
  goes to VERIFY_RESIZE status after a successful cold migration and
  then must be confirmed or reverted.

  https://developer.openstack.org/api-ref/compute/#migrate-server-
  migrate-action

  We should have something similar to what's in the 'resize' action API
  reference:

  https://developer.openstack.org/api-ref/compute/#resize-server-resize-
  action

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1774234/+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 1761140] Re: dpkg eror processing package nova-compute

2018-06-22 Thread Corey Bryant
I was able to install nova-compute=2:17.0.4-0ubuntu1~cloud0
successfully.

** Changed in: nova (Ubuntu)
   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/1761140

Title:
  dpkg eror processing package nova-compute

Status in OpenStack Compute (nova):
  Invalid
Status in nova package in Ubuntu:
  Invalid

Bug description:
  Hello! 
  I've encountered the bug while installing Nova on compute nodes:

  ...
  Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-kvm (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up qemu-utils (1:2.11+dfsg-1ubuntu5~cloud0) ...
  Setting up python-keystone (2:13.0.0-0ubuntu1~cloud0) ...
  Processing triggers for initramfs-tools (0.122ubuntu8.11) ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic
  Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ...
  adduser: The user `nova' does not exist.
  dpkg: error processing package nova-compute-libvirt (--configure):
   subprocess installed post-installation script returned error exit status 1
  dpkg: dependency problems prevent configuration of nova-compute-kvm:
   nova-compute-kvm depends on nova-compute-libvirt (= 
2:17.0.1-0ubuntu1~cloud0); however:
Package nova-compute-libvirt is not configured yet.

  dpkg: error processing package nova-compute-kvm (--configure):
   dependency problems - leaving unconfigured
  Setting up python-os-brick (2.3.0-0ubuntu1~cloud0) ...
  No apport report written because the error message indicates its a followup 
error from a previous failure.
  Setting up python-nova (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-common (2:17.0.1-0ubuntu1~cloud0) ...
  Setting up nova-compute (2:17.0.1-0ubuntu1~cloud0) ...
  Processing triggers for libc-bin (2.23-0ubuntu10) ...
  Processing triggers for systemd (229-4ubuntu21.2) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
  Errors were encountered while processing:
   nova-compute-libvirt
   nova-compute-kvm
  ...

  Installation failed when executing 'post-installation script'. 
  After some investigation I've found out that if I've create 'nova' user 
BEFORE running package installation, it's will be succeded. 

  Steps to reproduce
  --
  1. Prepare the node for installing nova-compute packages
  2. Run 'apt-get install nova-compute'

  Expected result
  --
  Nova-compute installed successfully without errors

  Actual result
  --
  Installation failed with dpkg error

  Workaround
  --
  1. Create system user: add to /etc/passwd
 nova:x:64060:64060::/var/lib/nova:/bin/false
  2. Create system group: add to /etc/group
 nova:x:64060:
  3. Run 'apt-get install nova-compute'
 
  My Environment
  --
  Ubuntu 16.04.4 LTS, 4.4.0-116-generic
  Openstack Queens Release
  Nova 17.0.1-0ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1761140/+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 1777977] Re: Install and configure controller node in Neutron

2018-06-22 Thread Brian Haley
Already fixed in master branch.

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

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

Title:
  Install and configure controller node in Neutron

Status in neutron:
  Invalid

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way:

  The Neutron install doc for QUEENS points to an incorrect port for
  keystone. 'auth_url = http://controller:35357' should be 'auth_url =
  http://controller:5000' as that's what the install doc for keystone
  uses.

  Keystone install guide reference:
  https://docs.openstack.org/keystone/queens/install/keystone-install-
  ubuntu.html#install-and-configure-components

  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 12.0.4.dev6 on 2018-06-19 21:03
  SHA: e3be3f913c6f402648691c5ea6a278592adc6810
  Source: 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-ubuntu.rst
  URL: 
https://docs.openstack.org/neutron/queens/install/controller-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1777977/+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 1751396] Re: DVR: Inter Tenant Traffic between two networks and connected through a shared network not reachable with DVR routers

2018-06-22 Thread Corey Bryant
12.0.2 is available in the Queens cloud archive.

** Changed in: cloud-archive/queens
   Status: Fix Committed => Fix Released

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

Title:
  DVR: Inter Tenant Traffic between two networks and connected through a
  shared network not reachable with DVR routers

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Artful:
  Triaged
Status in neutron source package in Bionic:
  Fix Released

Bug description:
  Inter Tenant Traffic between Two Tenants on two different private
  networks connected through a common shared network (created by Admin)
  is not route able through DVR routers

  Steps to reproduce it:

  (NOTE: No external, just shared network)
  This is only reproducable in Multinode scenario. ( 1 Controller - 2 compute ).
  Make sure that the two VMs are isolated in two different computes.

  openstack network create --share shared_net

  openstack subnet create shared_net_sn --network shared_net --subnet-
  range 172.168.10.0/24

  
  openstack network create net_A
  openstack subnet create net_A_sn --network net_A --subnet-range 10.1.0.0/24

  
  openstack network create net_B
  openstack subnet create net_B_sn --network net_B --subnet-range 10.2.0.0/24

  
  openstack router create router_A

  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.20 port_router_A_shared_net
  openstack router add port router_A port_router_A_shared_net
  openstack router add subnet router_A net_A_sn

  openstack router create router_B
  openstack port create --network=shared_net --fixed-ip 
subnet=shared_net_sn,ip-address=172.168.10.30 port_router_B_shared_net
  openstack router add port router_B port_router_B_shared_net
  openstack router add subnet router_B net_B_sn

  openstack server create server_A --flavor m1.tiny --image cirros --nic 
net-id=net_A
  openstack server create server_B --flavor m1.tiny --image cirros --nic 
net-id=net_B

  Add static routes to the router.
  openstack router set router_A --route 
destination=10.1.0.0/24,gateway=172.168.10.20
  openstack router set router_B --route 
destination=10.2.0.0/24,gateway=172.168.10.30
  ```

  Ping from one instance to the other times out

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1751396/+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 1759971] Re: [dvr][fast-exit] a route to a tenant network does not get created in fip namespace if an external network is attached after a tenant network have been attached (race

2018-06-22 Thread Corey Bryant
12.0.2 is available in the Queens cloud archive.

** Changed in: cloud-archive/queens
   Status: Fix Committed => Fix Released

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

Title:
  [dvr][fast-exit] a route to a tenant network does not get created in
  fip namespace if an external network is attached after a tenant
  network have been attached (race condition)

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Artful:
  Triaged
Status in neutron source package in Bionic:
  Fix Released

Bug description:
  Overall, similar scenario to
  https://bugs.launchpad.net/neutron/+bug/1759956 but a different
  problem.

  Relevant agent config options:
  http://paste.openstack.org/show/718418/

  OpenStack Queens from UCA (xenial, GA kernel, deployed via OpenStack
  charms), 2 external subnets (one routed provider network), 1 tenant
  subnet, all subnets in the same address scope to trigger "fast exit"
  logic.

  Tenant subnet cidr: 192.168.100.0/24

  openstack address scope create dev
  openstack subnet pool create --address-scope dev --pool-prefix 10.232.40.0/21 
--pool-prefix 10.232.16.0/21 dev
  openstack subnet pool create --address-scope dev --pool-prefix 
192.168.100.0/24 tenant
  openstack network create --external --provider-physical-network physnet1 
--provider-network-type flat pubnet
  openstack network segment set --name segment1 
d8391bfb-4466-4a45-972c-45ffcec9f6bc
  openstack network segment create --physical-network physnet2 --network-type 
flat --network pubnet segment2
  openstack subnet create --no-dhcp --subnet-pool dev --subnet-range 
10.232.16.0/21 --allocation-pool start=10.232.17.0,end=10.232.17.255 
--dns-nameserver 10.232.36.101 --ip-version 4 --network pubnet 
--network-segment segment1 pubsubnetl1
  openstack subnet create --gateway 10.232.40.100 --no-dhcp --subnet-pool dev 
--subnet-range 10.232.40.0/21 --allocation-pool 
start=10.232.41.0,end=10.232.41.255 --dns-nameserver 10.232.36.101 --ip-version 
4 --network pubnet --network-segment segment2 pubsubnetl2
  openstack network create --internal --provider-network-type vxlan tenantnet
   openstack subnet create --dhcp --ip-version 4 --subnet-range 
192.168.100.0/24 --subnet-pool tenant --dns-nameserver 10.232.36.101 --network 
tenantnet tenantsubnet

  # ---
  # Works in this order when an external network is attached first

  openstack router create --disable --no-ha --distributed pubrouter
  openstack router set --disable-snat --external-gateway pubnet --enable 
pubrouter

  openstack router add subnet pubrouter tenantsubnet

  2018-03-29 23:30:48.933 2050638 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'ne
  tns', 'exec', 'fip-d0f008fc-dc45-4237-9ce0-a9e1977735eb', 'ip', '-4', 
'route', 'replace', '192.168.100.0/24', 'via', '169.254.106.114', 'dev', 
'fpr-09fd1
  424-7'] create_process 
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:92

  # --
  # Doesn't work the other way around - as a fip namespace does not get created 
before a tenant network is attached
  openstack router create --disable --no-ha --distributed pubrouter

  openstack router add subnet pubrouter tenantsubnet
  openstack router set --disable-snat --external-gateway pubnet --enable 
pubrouter

  # to "fix" this we need to re-trigger the right code path

  openstack router remove subnet pubrouter tenantsubnet
  openstack router add subnet pubrouter tenantsubnet

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1759971/+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 1471957] Re: Invalid subnet cidr cause dhcp runtimerror

2018-06-22 Thread OpenStack Infra
Fix proposed to branch: master
Review: https://review.openstack.org/577463

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

** Changed in: neutron
 Assignee: (unassigned) => Andrew Karpow (andyonce)

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

Title:
  Invalid subnet cidr cause dhcp runtimerror

Status in neutron:
  In Progress

Bug description:
  Trace:
  ERROR neutron.agent.linux.utils [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61 
demo 12b3399d1cb64da488e20f6a7c355d10] 
  Command: ['sudo', '/usr/local/bin/neutron-rootwrap', 
'/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 
'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace', 
'default', 'via', '0.0.0.1', 'dev', 'tapb81e677c-8c']
  Exit code: 2
  Stdout: ''
  Stderr: 'RTNETLINK answers: Network is unreachable\n'
  ERROR neutron.agent.dhcp_agent [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61 demo 
12b3399d1cb64da488e20f6a7c355d10] Unable to enable dhcp for 
6cdefebf-ab88-4f55-b2b9-719286a7b75b.
  Traceback (most recent call last):
File "/opt/stack/neutron/neutron/agent/dhcp_agent.py", line 128, in 
call_driver
  getattr(driver, action)(**action_kwargs)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 205, in enable
  interface_name = self.device_manager.setup(self.network)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 1056, in setup
  self._set_default_route(network, interface_name)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 928, in 
_set_default_route
  device.route.add_gateway(subnet.gateway_ip)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 395, in 
add_gateway
  self._as_root(*args)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 242, in 
_as_root
  kwargs.get('use_root_namespace', False))
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 74, in 
_as_root
  log_fail_as_error=self.log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 86, in 
_execute
  log_fail_as_error=log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 84, in execute
  raise RuntimeError(m)
  TRACE neutron.agent.dhcp_agent RuntimeError: 
  TRACE neutron.agent.dhcp_agent Command: ['sudo', 
'/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 
'exec', 'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace', 
'default', 'vi
  a', '0.0.0.1', 'dev', 'tapb81e677c-8c']
  TRACE neutron.agent.dhcp_agent Exit code: 2
  TRACE neutron.agent.dhcp_agent Stdout: ''
  TRACE neutron.agent.dhcp_agent Stderr: 'RTNETLINK answers: Network is 
unreachable\n'
  TRACE neutron.agent.dhcp_agent 

  
  Steps to reproduce:
  NET_NAME=test-ip
  neutron net-create ${NET_NAME}
  neutron port-create ${NET_NAME}
  neutron subnet-create ${NET_NAME} 0.0.0.0/8

  
  Impact:
  cause logs to grow more than necessary

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1471957/+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 1777585] Re: support vlan transparent in neutron network.

2018-06-22 Thread Miguel Lavalle
Based on the submitter's description and code, we already have this
extension:

1) This is the spec approved and implemented back in Kilo:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-
trunks.html

2) This is the neutron-lib definition: https://github.com/openstack
/neutron-lib/blob/master/neutron_lib/api/definitions/vlantransparent.py

3) This is the DB layer code in Neutron:
https://github.com/openstack/neutron/blob/master/neutron/db/vlantransparent_db.py

4) This is the extension code in Neutron:
https://github.com/openstack/neutron/blob/master/neutron/extensions/vlantransparent.py

5) And this is the ML2 plugin using the extension:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L126

Marking this RFE invalid. Feel free to to change if the proposed
extension differs from what we already have

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

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

Title:
  support vlan transparent in neutron network.

Status in neutron:
  Invalid

Bug description:
  Now, if we use 'neutron net-create' to create a network, which didn't
  work, because neutron api can't resolve the parameter 'vlan-
  transparent'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1777585/+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 1778227] [NEW] Docs needed for optional placement database

2018-06-22 Thread Matt Riedemann
Public bug reported:

Blueprint https://blueprints.launchpad.net/nova/+spec/optional-
placement-database added support for configuring a separate database for
the placement service so it's not just part of the nova_api database
(even though it's the same schema for now).

This is important for extracting placement from nova, and should be part
of a new base install so people don't have to migrate later.

There are at least two places we should update in the docs:

1. The install guide for fresh installs should tell people to create a
database for placement and configure nova.conf appropriately using the
new placement database config options.

Looking at the install guide, we have 3 different guides to update
(ubuntu, rdo, suse), but looks like:

a) https://docs.openstack.org/nova/latest/install/controller-install-
ubuntu.html#prerequisites - create a placement database using the
nova_api schema.

b) configure the placement db

https://docs.openstack.org/nova/latest/install/controller-install-
ubuntu.html#install-and-configure-components

I think that's it. "nova-manage api_db sync" will sync the placement
database and the nova_api database, so we should be good there.

2. Update the placement upgrade docs for Rocky to mention the new config
option and, at a high level, the options people have for migrating from
nova_api to placement db, e.g. stop api services, copy the nova_api db,
deploy placement db using the nova_api copy, config and restart api
services.

https://docs.openstack.org/nova/latest/user/placement.html#rocky-18-0-0

** Affects: nova
 Importance: Medium
 Status: Confirmed


** Tags: docs placement

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

Title:
  Docs needed for optional placement database

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Blueprint https://blueprints.launchpad.net/nova/+spec/optional-
  placement-database added support for configuring a separate database
  for the placement service so it's not just part of the nova_api
  database (even though it's the same schema for now).

  This is important for extracting placement from nova, and should be
  part of a new base install so people don't have to migrate later.

  There are at least two places we should update in the docs:

  1. The install guide for fresh installs should tell people to create a
  database for placement and configure nova.conf appropriately using the
  new placement database config options.

  Looking at the install guide, we have 3 different guides to update
  (ubuntu, rdo, suse), but looks like:

  a) https://docs.openstack.org/nova/latest/install/controller-install-
  ubuntu.html#prerequisites - create a placement database using the
  nova_api schema.

  b) configure the placement db

  https://docs.openstack.org/nova/latest/install/controller-install-
  ubuntu.html#install-and-configure-components

  I think that's it. "nova-manage api_db sync" will sync the placement
  database and the nova_api database, so we should be good there.

  2. Update the placement upgrade docs for Rocky to mention the new
  config option and, at a high level, the options people have for
  migrating from nova_api to placement db, e.g. stop api services, copy
  the nova_api db, deploy placement db using the nova_api copy, config
  and restart api services.

  https://docs.openstack.org/nova/latest/user/placement.html#rocky-18-0-0

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1778227/+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 1778109] Re: The token data for a trust-scoped token can contain duplicate roles

2018-06-22 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/576611
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=50fd6933e8ab5ccf4ef232837fbe582d90c5c913
Submitter: Zuul
Branch:master

commit 50fd6933e8ab5ccf4ef232837fbe582d90c5c913
Author: Jeremy Freudberg 
Date:   Tue Jun 19 18:54:36 2018 +

Fix duplicate role names in trusts bug

Closes-Bug: #1778109

Change-Id: Id0953190b3b1e0b6765430fbb10d16e7f53f53ee


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

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

Title:
  The token data for a trust-scoped token can contain duplicate roles

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  When dealing with implied roles, the token data for a trust-scoped
  token might contain duplicate roles.

  (This can break the interaction between, for example, Sahara and
  Heat.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1778109/+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 1778206] [NEW] Compute leaks volume attachments if we fail in driver.pre_live_migration

2018-06-22 Thread Matthew Booth
Public bug reported:

ComputeManager.pre_live_migration fails to clean up volume attachments
if the call to driver.pre_live_migration() fails. There's a try block in
there to clean up attachments, but its scope isn't large enough. The
result is a volume in a perpetual attaching state.

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

Title:
  Compute leaks volume attachments if we fail in
  driver.pre_live_migration

Status in OpenStack Compute (nova):
  New

Bug description:
  ComputeManager.pre_live_migration fails to clean up volume attachments
  if the call to driver.pre_live_migration() fails. There's a try block
  in there to clean up attachments, but its scope isn't large enough.
  The result is a volume in a perpetual attaching state.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1778206/+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 1778207] [NEW] fwaas v2 add port into firewall group failed

2018-06-22 Thread Derek Yang
Public bug reported:

Hey, stackers. There are some errors when I added router ports with
DVR/HA mode into a fwaasv2 firewall group.

The error msg was that:

Error: Failed to update firewallgroup 3c8dbcab-
0cfb-4189-bd60-dc4b40a346a4: Port 002c3fff-5b00-42b5-83ab-6413afc083c4
of firewall group is invalid. Neutron server returns request_ids: ['req-
da8b946c-aa69-456f-b1d3-d956eff49110']

My router HA interface:

Device Owner
network:router_ha_interface
Device ID
a804ad96-42c4-437b-a945-9ecc4cdef34c


And I traced the related source code about how to validate the port for 
firewall group
https://github.com/openstack/neutron-fwaas/blob/9346ced4b0f90e1c7acf855ac9db76ed960510e6/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L147

I found that there is not any condition to determine whether the router
is in DVR/HA mode or not. So, maybe we have to update this code snippet
https://github.com/openstack/neutron-
fwaas/blob/9346ced4b0f90e1c7acf855ac9db76ed960510e6/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L147

to support router with DVR/HA mode.

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

Title:
  fwaas v2 add port into firewall group failed

Status in neutron:
  New

Bug description:
  Hey, stackers. There are some errors when I added router ports with
  DVR/HA mode into a fwaasv2 firewall group.

  The error msg was that:

  Error: Failed to update firewallgroup 3c8dbcab-
  0cfb-4189-bd60-dc4b40a346a4: Port 002c3fff-5b00-42b5-83ab-6413afc083c4
  of firewall group is invalid. Neutron server returns request_ids:
  ['req-da8b946c-aa69-456f-b1d3-d956eff49110']

  My router HA interface:

  Device Owner
  network:router_ha_interface
  Device ID
  a804ad96-42c4-437b-a945-9ecc4cdef34c

  
  And I traced the related source code about how to validate the port for 
firewall group
  
https://github.com/openstack/neutron-fwaas/blob/9346ced4b0f90e1c7acf855ac9db76ed960510e6/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L147

  I found that there is not any condition to determine whether the
  router is in DVR/HA mode or not. So, maybe we have to update this code
  snippet https://github.com/openstack/neutron-
  
fwaas/blob/9346ced4b0f90e1c7acf855ac9db76ed960510e6/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L147

  to support router with DVR/HA mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1778207/+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 1778199] [NEW] Migrate Volume dialogue box not displaying full destination host

2018-06-22 Thread michael-mcaleer
Public bug reported:

When viewing the 'Destination Host' options in the 'Migrate Volume'
dialogue box it is not possible to see the entire hostname, making it
very difficult to migrate to the correct host, this will become even
tougher if a longer hostname and/or back end name is used as it would
not be possible to see the rest of the pool details pertaining to
specific pool settings.

This drop down box would benefit from a dynamically sized drop down menu
which adjusts to the size of the destination host value.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "Screenshot"
   
https://bugs.launchpad.net/bugs/1778199/+attachment/5155468/+files/MigrateVolumeUIBug.png

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

Title:
  Migrate Volume dialogue box not displaying full destination host

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When viewing the 'Destination Host' options in the 'Migrate Volume'
  dialogue box it is not possible to see the entire hostname, making it
  very difficult to migrate to the correct host, this will become even
  tougher if a longer hostname and/or back end name is used as it would
  not be possible to see the rest of the pool details pertaining to
  specific pool settings.

  This drop down box would benefit from a dynamically sized drop down
  menu which adjusts to the size of the destination host value.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1778199/+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 1778189] [NEW] Certain panels showing incorrect page heading for non-en-US languages

2018-06-22 Thread Robert Donovan
Public bug reported:

Version: 13.0.1 Queens

When accessing one of the "Images", "Roles", or "Key Pairs" panels, the
page heading is displayed as "m", "o", or "e" respectively when the
Accept-Language header is "en-GB" rather than "en" or "en-US". I'm not
familiar with the Horizon codebase, but it appears that this is due to
the following code execution path being taken for these panels but not
others:

ctrl.pageName = ctrl.resourceType.getName();

Source: horizon/static/framework/widgets/panel/hz-resource-
panel.controller.js

This results in a call (for the Images panel for example) to
django.ngettext("Image", "Images"), which returns the second letter "m".
This doesn't happen for the "en" or "en-US" languages because no
translation dictionary is used. I believe this will occur for any
language which has a translation mapping for these panel titles.

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

Title:
  Certain panels showing incorrect page heading for non-en-US languages

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Version: 13.0.1 Queens

  When accessing one of the "Images", "Roles", or "Key Pairs" panels,
  the page heading is displayed as "m", "o", or "e" respectively when
  the Accept-Language header is "en-GB" rather than "en" or "en-US". I'm
  not familiar with the Horizon codebase, but it appears that this is
  due to the following code execution path being taken for these panels
  but not others:

  ctrl.pageName = ctrl.resourceType.getName();

  Source: horizon/static/framework/widgets/panel/hz-resource-
  panel.controller.js

  This results in a call (for the Images panel for example) to
  django.ngettext("Image", "Images"), which returns the second letter
  "m". This doesn't happen for the "en" or "en-US" languages because no
  translation dictionary is used. I believe this will occur for any
  language which has a translation mapping for these panel titles.

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