[Yahoo-eng-team] [Bug 1626796] Re: There should show project name to make more sense

2017-09-16 Thread Launchpad Bug Tracker
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

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

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

Title:
  There should show project name to make more sense

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  1 Open Admin/SYSTEM/Floating IPs panel. 
  2 Click into the floating ip detail page.
  3 There only show the project ID in the detail page. 
  There should also show the project name will make more sense.
  Other detail page, such as Router, Network also have this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1626796/+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 1697634] Re: AH01630: client denied by server configuration

2017-09-16 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/1697634

Title:
  AH01630: client denied by server configuration

Status in OpenStack Identity (keystone):
  Expired

Bug description:
  openstack :Newton

  [root@controller01 ~]# tail -f /var/log/httpd/error_log

  [Tue Jun 13 15:54:24.720280 2017] [authz_core:error] [pid 8700]
  [client 172.16.21.5:56228] AH01630: client denied by server
  configuration: /usr/bin/keystone-wsgi-public, referer:
  http://172.16.21.100/dashboard/admin/flavors/

  
  [Tue Jun 13 15:54:30.433343 2017] [authz_core:error] [pid 501] [client 
172.16.21.5:56346] AH01630: client denied by server configuration: 
/usr/bin/keystone-wsgi-public, referer: http://172.16.21.100/dashboard/identity/


  
  Where is it wrong?

  Does the refreshing update of the instances in the dashboard be
  related to this error?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1697634/+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 1687401] Re: Keystone 403 Forbidden

2017-09-16 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/1687401

Title:
  Keystone 403 Forbidden

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in OpenStack Identity (keystone):
  Expired

Bug description:
  Hello there,
  I have been struggling a bit with moving the horizon page from 
domain.com/horizon to domain.com/ + setting up HTTPS, here's what I have tied:

   - [General 403 
debugging](https://askubuntu.com/questions/292968/apache2-forbidden-you-dont-have-permission-to-access-dir-on-this-server)
   - [General 403 
debugging](https://unix.stackexchange.com/questions/169513/403-forbidden-you-dont-have-permission-to-access-on-this-server-apache2)
   - [403 fix for 
Horizon](https://fosshelp.blogspot.co.uk/2014/02/openstack-horizon-you-dont-have.html)
   - [General 403 
debugging](https://stackoverflow.com/questions/10873295/error-message-forbidden-you-dont-have-permission-to-access-on-this-server)
   - [Launchpad 403 knwon (and fixed) bug 
](https://bugs.launchpad.net/devstack/+bug/1243075)
   - [HTTPS config guide (from 
Juno)](https://docs.openstack.org/juno/config-reference/content/configure-dashboard.html#after-example)

  ### Environment
   - Followed the latest installation guide (Ocata)
   - Apache2 version: Apache/2.4.18 (Ubuntu)
   - Ubuntu 16.04.2 LTS AMD64

  ### Configuration

  **local_settings.py**
  https://paste.debian.net/930199/

  **openstack-dashboard.conf**
  https://paste.debian.net/930200/

  **error.log**
  https://paste.debian.net/930201/

  This leaves me with some funny results, the login page loads but is
  missing CSS, only plain HTML. When I log in, everything else gives me
  a `403`.

  Any help would be appreciated.

  Thank you,

  Tiago Ferreira

  m...@tiferrei.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1687401/+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 1717707] Re: nova-compute failed to communicate with nova-conductor on start

2017-09-16 Thread Huang Cheng
** Project changed: nova => openstack-requirements

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

Title:
  nova-compute failed to communicate with nova-conductor on start

Status in OpenStack Compute (nova):
  New
Status in OpenStack Global Requirements:
  New

Bug description:
  Related to bug #1696094.

  An 'Timed out waiting for nova-conductor.  Is it running? Or did this
  service start before nova-conductor?  Reattempting establishment of
  nova-conductor connection...' error occurs in nova-compute.log when:

  on compute node
  1. no usable nameserver in /etc/resolv.conf
  2. only ipv4 or only ipv6 address of 'controller' (as rabbitmq server) is 
mapped in /etc/hosts
  3. use 'controller' as rabbitmq server in nova.conf

  The eventlet greendns has been always enabled by monkey_patch since
  0.20.0, and this will introduce some compatibility problems, e.g.

  1. We create a connection to rabbitmq server using 'controller:5672'
  2. patched socket.getaddrinfo('controller', 5672, 0) is called by amqp (0 for 
both ipv4 and ipv6)
  3. greendns will use '127.0.0.1' as dns nameserver if there is no usable 
nameserver in /etc/resolv.conf
  4. greendns will perform name resolving for 'controller', ipv6 dns lookup 
will be performed if there is no ipv6 mapping for 'controller' in /etc/hosts, 
so is ipv4. One of the dns lookup is leading to a timeout, and cause the 
problem mentioned above.

  The original socket.getaddrinfo is ok with this situation, I think
  it's better not to use eventlet greendns patch for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1717707/+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 1717707] [NEW] nova-compute failed to communicate with nova-conductor on start

2017-09-16 Thread Huang Cheng
Public bug reported:

Related to bug #1696094.

An 'Timed out waiting for nova-conductor.  Is it running? Or did this
service start before nova-conductor?  Reattempting establishment of
nova-conductor connection...' error occurs in nova-compute.log when:

on compute node
1. no usable nameserver in /etc/resolv.conf
2. only ipv4 or only ipv6 address of 'controller' (as rabbitmq server) is 
mapped in /etc/hosts
3. use 'controller' as rabbitmq server in nova.conf

The eventlet greendns has been always enabled by monkey_patch since
0.20.0, and this will introduce some compatibility problems, e.g.

1. We create a connection to rabbitmq server using 'controller:5672'
2. patched socket.getaddrinfo('controller', 5672, 0) is called by amqp (0 for 
both ipv4 and ipv6)
3. greendns will use '127.0.0.1' as dns nameserver if there is no usable 
nameserver in /etc/resolv.conf
4. greendns will perform name resolving for 'controller', ipv6 dns lookup will 
be performed if there is no ipv6 mapping for 'controller' in /etc/hosts, so is 
ipv4. One of the dns lookup is leading to a timeout, and cause the problem 
mentioned above.

I think it's better to use an eventlet version < 0.20.0.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: amqp dns eventlet

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

Title:
  nova-compute failed to communicate with nova-conductor on start

Status in OpenStack Compute (nova):
  New

Bug description:
  Related to bug #1696094.

  An 'Timed out waiting for nova-conductor.  Is it running? Or did this
  service start before nova-conductor?  Reattempting establishment of
  nova-conductor connection...' error occurs in nova-compute.log when:

  on compute node
  1. no usable nameserver in /etc/resolv.conf
  2. only ipv4 or only ipv6 address of 'controller' (as rabbitmq server) is 
mapped in /etc/hosts
  3. use 'controller' as rabbitmq server in nova.conf

  The eventlet greendns has been always enabled by monkey_patch since
  0.20.0, and this will introduce some compatibility problems, e.g.

  1. We create a connection to rabbitmq server using 'controller:5672'
  2. patched socket.getaddrinfo('controller', 5672, 0) is called by amqp (0 for 
both ipv4 and ipv6)
  3. greendns will use '127.0.0.1' as dns nameserver if there is no usable 
nameserver in /etc/resolv.conf
  4. greendns will perform name resolving for 'controller', ipv6 dns lookup 
will be performed if there is no ipv6 mapping for 'controller' in /etc/hosts, 
so is ipv4. One of the dns lookup is leading to a timeout, and cause the 
problem mentioned above.

  I think it's better to use an eventlet version < 0.20.0.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1717707/+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 1717342] Re: [RFE] View and modify cinder volume type quotas in horizon

2017-09-16 Thread Sean McGinnis
** Also affects: horizon
   Importance: Undecided
   Status: New

** No longer affects: cinder

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

Title:
  [RFE] View and modify cinder volume type quotas  in horizon

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Description of problem:
  cinder volume types are governed by their own quotas. Currently, horizon can 
neither display nor modify those quotas.

  
https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/volume-type.html
  https://docs.openstack.org/horizon/latest/admin/manage-volumes.html

  Looking at the quotas:
  ~~~
  [stack@undercloud-1 ~]$ cinder quota-show db2b3d12c0c644a19780132399321045
  +--+---+
  | Property | Value |
  +--+---+
  | backup_gigabytes | 1000  |
  | backups  | 10|
  | gigabytes| 1000  |
  | gigabytes_low-iops   | -1|
  | per_volume_gigabytes | -1|
  | snapshots| 10|
  | snapshots_low-iops   | -1|
  | volumes  | 10|
  | volumes_low-iops | -1|
  +--+---+
  ~~~

  ~~~
  [stack@undercloud-1 ~]$ cinder quota-usage db2b3d12c0c644a19780132399321045
  +--++--+---+
  | Type | In_use | Reserved | Limit |
  +--++--+---+
  | backup_gigabytes | 0  | 0| 1000  |
  | backups  | 0  | 0| 10|
  | gigabytes| 8  | 0| 1000  |
  | gigabytes_low-iops   | 4  | 0| -1|
  | per_volume_gigabytes | 0  | 0| -1|
  | snapshots| 0  | 0| 10|
  | snapshots_low-iops   | 0  | 0| -1|
  | volumes  | 2  | 0| 10|
  | volumes_low-iops | 1  | 0| -1|
  +--++--+---+
  ~~~

  The only places I found for quotas or for volume types where this
  could possibly be are:

  Which is this URL (with different IP/hostname of course):
  http://10.0.0.6/dashboard/admin/defaults/

  Next, there's obviously
  http://10.0.0.6/dashboard/project/

  None provides a way to set the per volume type quotas.

  Another place where this could be possible is:
  http://10.0.0.6/dashboard/admin/volumes/  and then under the Volume Types tab.

  None of the above provides a way to see or edit the quotas for the new
  volume types.

  Obviously, this would lead to completely invalid quota display in
  horizon if the default volume type is set to anything other than
  , in which case the display will likely still show the global
  default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1717342/+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 1717662] [NEW] Material theme freezes in Ocata

2017-09-16 Thread Giuseppe Attardi
Public bug reported:

I upgraded OpenStack from Newton to Ocata.
I selected the theme Material but after that, the page freezes, I cannot issue 
any commands.
I am stuck in the Project panel.
The top left menu does not pop up, if I try setting back the theme to Ubuntu, 
nothing happens.
I tried opening an incognito window and also using a different browser, the 
page is still frozen.

Before the upgrade the Material theme worked for me and I could switch
back and forward between themes.

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

Title:
  Material theme freezes in Ocata

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I upgraded OpenStack from Newton to Ocata.
  I selected the theme Material but after that, the page freezes, I cannot 
issue any commands.
  I am stuck in the Project panel.
  The top left menu does not pop up, if I try setting back the theme to Ubuntu, 
nothing happens.
  I tried opening an incognito window and also using a different browser, the 
page is still frozen.

  Before the upgrade the Material theme worked for me and I could switch
  back and forward between themes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1717662/+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 1717661] [NEW] neutron's test test_create_floatingip_with_specified_ip_address should be executed only for ML2 plugin

2017-09-16 Thread Andrey Pavlov
Public bug reported:

test 
neutron.tests.tempest.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON.test_create_floatingip_with_specified_ip_address
 uses specific feature of ML2 plugin - it tries to detect allocated floating 
ips through listing of ports.
This way doesn't work for non ML2 plugins (ex: Contrail).

Contrail plugin doesn't create port for newly allocated floating ip like
ML2. When common test's function get_unused_ip returns floating ip that
is allocated but not attached then then test case tries to allocate it
again it gets HTTP 409.

It can be one of these changes to fix this:
1. Do not create a floating ip in setup (it wouldn't help if IP was allocated 
by someone else)
2. When finding first free ip, also skip over floating ip objects.
3. Use a random available ip address for the test.

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

Title:
  neutron's test test_create_floatingip_with_specified_ip_address should
  be executed only for ML2 plugin

Status in neutron:
  New

Bug description:
  test 
neutron.tests.tempest.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON.test_create_floatingip_with_specified_ip_address
 uses specific feature of ML2 plugin - it tries to detect allocated floating 
ips through listing of ports.
  This way doesn't work for non ML2 plugins (ex: Contrail).

  Contrail plugin doesn't create port for newly allocated floating ip
  like ML2. When common test's function get_unused_ip returns floating
  ip that is allocated but not attached then then test case tries to
  allocate it again it gets HTTP 409.

  It can be one of these changes to fix this:
  1. Do not create a floating ip in setup (it wouldn't help if IP was allocated 
by someone else)
  2. When finding first free ip, also skip over floating ip objects.
  3. Use a random available ip address for the test.

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