[Yahoo-eng-team] [Bug 1760832] [NEW] Shows external networks even if they are not shared

2018-04-03 Thread Dmitriy R. 
Public bug reported:

Hi,

I think, that this case might be somehow related to the one, described
here: https://bugs.launchpad.net/horizon/+bug/1384975

Steps to reproduce are the same:
Login as tenant "A", create couple of networks:
- Network 1, external network shared.
- Network 2, external network (not-shared).

Now Login as tenant "B", go to project and network listing page:
- We see as well as shared external networks, as not shared ones. 
- Not shared networks are displayed without subnets, and they are not available 
for instance/port creation

I was able to hide not shared external networks (while shared ones are
still present) with setting include_external=False here
https://github.com/openstack/horizon/blob/9ca9b5cd81db29bddf6dbcc5fc535009a9ec63b0/openstack_dashboard/dashboards/project/networks/views.py#L55

So this setting makes expected changes and behaviour. Probably, there is
a reason, why this was hardcoded, and current behaviour is required for
some features. But probably it's worth to consider to move this to the
settings section?

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: pike

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

Title:
  Shows external networks even if they are not shared

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Hi,

  I think, that this case might be somehow related to the one, described
  here: https://bugs.launchpad.net/horizon/+bug/1384975

  Steps to reproduce are the same:
  Login as tenant "A", create couple of networks:
  - Network 1, external network shared.
  - Network 2, external network (not-shared).

  Now Login as tenant "B", go to project and network listing page:
  - We see as well as shared external networks, as not shared ones. 
  - Not shared networks are displayed without subnets, and they are not 
available for instance/port creation

  I was able to hide not shared external networks (while shared ones are
  still present) with setting include_external=False here
  
https://github.com/openstack/horizon/blob/9ca9b5cd81db29bddf6dbcc5fc535009a9ec63b0/openstack_dashboard/dashboards/project/networks/views.py#L55

  So this setting makes expected changes and behaviour. Probably, there
  is a reason, why this was hardcoded, and current behaviour is required
  for some features. But probably it's worth to consider to move this to
  the settings section?

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1760832/+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 1765024] [NEW] requires_keypair does not affect NG interface

2018-04-18 Thread Dmitriy R. 
Public bug reported:

Hi,

Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES does
not affect new server creation form (angular one). So it is impossible
to make key_pair as a required field now with this setting. Meanwhile
this approach still works in the legacy form.

It is reproduced in environments with horizon versions 13.0.0 and 12.0.2

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: angularjs pike queens

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

Title:
  requires_keypair does not affect NG interface

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Hi,

  Setting "'requires_keypair': True" in OPENSTACK_HYPERVISOR_FEATURES
  does not affect new server creation form (angular one). So it is
  impossible to make key_pair as a required field now with this setting.
  Meanwhile this approach still works in the legacy form.

  It is reproduced in environments with horizon versions 13.0.0 and
  12.0.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1765024/+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 1777123] [NEW] Nova 17.04 fails to create ephemeral storage with rbd driver

2018-06-15 Thread Dmitriy R. 
Public bug reported:

Description
===

Nova-compute is unable to create ephemeral storage due to type error, as
it sends unicode object to rbd.Image() class as a storage name.
Meanwhile, rbd.Image() accepts only string value.


Steps to reproduce
==

Try to create an instance without cinder drive or with flavor which has
a swap defined. Also, nova-compute should be configured to interact with
ceph.


Steps to fix the problem
==
in nova/virt/libvirt/storage/rbd_utils.py make the following changes:
- L69:  self.volume = tpool.Proxy(rbd.Image(ioctx, name,
+ L69:  self.volume = tpool.Proxy(rbd.Image(ioctx, str(name),


Expected result
===

Instance should be created with swap storage and/or with ephemeral drive
in ceph.


Actual result
=
Instance creation fails with:

Exceeded maximum number of retries. Exhausted all hosts available for retrying 
build failures for instance bdd019bd-4127-4186-a1ee-f4b1891e1730.
File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/conductor/manager.py",
 line 580, in build_instances raise exception.MaxRetriesExceeded(reason=msg)


Environment
===
1. I've installed openstack with OSA (OpenStack-Ansible) version 17.0.5. So it 
would be openstack queens version
(nova-17.0.5) root@uacloud-nova01:~# pip freeze | grep nova
nova==17.0.4
nova-lxd==17.0.0
nova-powervm==6.0.2.dev3
python-novaclient==9.1.1
(nova-17.0.5) root@uacloud-nova01:~#
2. KVM hypervisor
3. CEPH storage
4. Neutron networking


Logs & Configs
==
In logs I see the following error:
2018-06-15 14:38:56.904 13411 INFO nova.compute.claims 
[req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de 
d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 
309afdf3dd6242338cd5eb4cda07f1d9] [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] vcpu limit: 320.00 VCPU, free: 311.00 VCPU
2018-06-15 14:38:56.909 13411 INFO nova.compute.claims 
[req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de 
d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 
309afdf3dd6242338cd5eb4cda07f1d9] [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] Claim successful on node 
uacloud-nova01.twinservers.net
2018-06-15 14:38:57.837 13411 INFO nova.virt.libvirt.driver 
[req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de 
d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 
309afdf3dd6242338cd5eb4cda07f1d9] [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] Creating image
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager 
[req-b7277d7c-14b6-4f0c-97fb-bb29a6c379a5 cf35f21e050d462db0e0ecf20da2a9de 
d605898aeb654bfea6e18c3c0321d8a8 - 309afdf3dd6242338cd5eb4cda07f1d9 
309afdf3dd6242338cd5eb4cda07f1d9] [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] Instance failed to spawn: TypeError: name 
must be a string
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] Traceback (most recent call last):
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730]   File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/compute/manager.py",
 line 2248, in _build_resources
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] yield resources
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730]   File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/compute/manager.py",
 line 2031, in _build_and_run_instance
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] block_device_info=block_device_info)
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730]   File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
 line 3072, in spawn
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] block_device_info=block_device_info)
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730]   File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
 line 3450, in _create_image
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] fallback_from_host)
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730]   File 
"/openstack/venvs/nova-17.0.5/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
 line 3541, in _create_and_inject_local_root
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance: 
bdd019bd-4127-4186-a1ee-f4b1891e1730] instance, size, fallback_from_host)
2018-06-15 14:38:57.899 13411 ERROR nova.compute.manager [instance:

[Yahoo-eng-team] [Bug 1778771] [NEW] Backups panel is visible even if enable_backup is False

2018-06-26 Thread Dmitriy R. 
Public bug reported:

Hi,

Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py

Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.

As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', {}).get('enable_backup', 
False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)

And for permanent fix I see the following decision. In 
openstack_dashboard/dashboards/project/backups/panel.py make the following 
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', 
{}).get('enable_backup', False):
+L22: return False
...

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

Title:
  Backups panel is visible even if enable_backup is False

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Hi,

  Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
  {'enable_backup': False} in local_settings.py

  Meanwhile setting enable_backup to false removes an option to create
  backup of a volume in the volume drop-down options. But panel with
  backups itself stays visible for both admins and users.

  As a work-around I use the following customization script:
  import horizon
  from django.conf import settings
  if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', 
{}).get('enable_backup', False):
  project = horizon.get_dashboard("project")
  backup = project.get_panel("backups")
  project.unregister(backup.__class__)

  And for permanent fix I see the following decision. In 
openstack_dashboard/dashboards/project/backups/panel.py make the following 
changes:
  ...
  +L16: from django.conf import settings
  ...
  +L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES', 
{}).get('enable_backup', False):
  +L22: return False
  ...

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