date:20180425

[Yahoo-eng-team] [Bug 1767028] [NEW] loadbalancer can't create with chinese character name

2018-04-25 Thread xuchaochao

Public bug reported:

When create a loadbalancer with chinese character name, It will have
some problems. Because its name will be written in haproxy
configuration, but chinese character can't be written correctly.

** Affects: neutron
 Importance: Undecided
 Assignee: xuchaochao (xuchaochao)
 Status: New

** Changed in: fuel-plugin-contrail
 Assignee: (unassigned) => xuchaochao (xuchaochao)

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

** No longer affects: neutron

** Project changed: fuel-plugin-contrail => neutron

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

Title:
  loadbalancer can't create with chinese character name

Status in neutron:
  New

Bug description:
  When create a loadbalancer with chinese character name, It will have
  some problems. Because its name will be written in haproxy
  configuration, but chinese character can't be written correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1767028/+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 1767028] [NEW] loadbalancer can't create with chinese character name

2018-04-25 Thread Launchpad Bug Tracker

You have been subscribed to a public bug:

When create a loadbalancer with chinese character name, It will have
some problems. Because its name will be written in haproxy
configuration, but chinese character can't be written correctly.

** Affects: neutron
 Importance: Undecided
 Assignee: xuchaochao (xuchaochao)
 Status: New

-- 
loadbalancer can't create with chinese character name
https://bugs.launchpad.net/bugs/1767028
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to neutron.

-- 
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 1767024] [NEW] keystone-manage fails on FIPS compliant system

2018-04-25 Thread Divya K Konoor

Public bug reported:

I took a RHEL 7 system and enabled FIPS compliance (FIPS does not allow
md5) and I see the following when keystone-manage is run. As a general
rule, we should avoid using md5 if we can and move over to SHA wherever
possible. The below also indicates that probably openstack auditing
functional, which is internally dependent on pycadf might also be
impacted.

  File "/usr/bin/keystone-manage", line 6, in 
from keystone.cmd.manage import main
  File "/usr/lib/python2.7/site-packages/keystone/cmd/manage.py", line 19, in 

from keystone.cmd import cli
  File "/usr/lib/python2.7/site-packages/keystone/cmd/cli.py", line 29, in 

from keystone.cmd import doctor
  File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/__init__.py", line 
14, in 
from keystone.cmd.doctor import credential
  File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/credential.py", 
line 16, in 
from keystone.credential.providers import fernet as credential_fernet
  File "/usr/lib/python2.7/site-packages/keystone/credential/__init__.py", line 
15, in 
from keystone.credential import controllers  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/credential/controllers.py", 
line 19, in 
from keystone.common import controller
  File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 
22, in 
from keystone.common import authorization
  File "/usr/lib/python2.7/site-packages/keystone/common/authorization.py", 
line 25, in 
from keystone.models import token_model
  File "/usr/lib/python2.7/site-packages/keystone/models/token_model.py", line 
20, in 
from keystone.federation import constants
  File "/usr/lib/python2.7/site-packages/keystone/federation/__init__.py", line 
15, in 
from keystone.federation.core import *  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/federation/core.py", line 24, 
in 
from keystone import notifications
  File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 29, 
in 
from pycadf import eventfactory
  File "/usr/lib/python2.7/site-packages/pycadf/eventfactory.py", line 16, in 

from pycadf import event
  File "/usr/lib/python2.7/site-packages/pycadf/event.py", line 20, in 
from pycadf import identifier
  File "/usr/lib/python2.7/site-packages/pycadf/identifier.py", line 33, in 

md5_hash = hashlib.md5(CONF.audit.namespace.encode('utf-8'))
ValueError: error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled 
for fip

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  keystone-manage fails on FIPS compliant system

Status in OpenStack Identity (keystone):
  New

Bug description:
  I took a RHEL 7 system and enabled FIPS compliance (FIPS does not
  allow md5) and I see the following when keystone-manage is run. As a
  general rule, we should avoid using md5 if we can and move over to SHA
  wherever possible. The below also indicates that probably openstack
  auditing functional, which is internally dependent on pycadf might
  also be impacted.

File "/usr/bin/keystone-manage", line 6, in 
  from keystone.cmd.manage import main
File "/usr/lib/python2.7/site-packages/keystone/cmd/manage.py", line 19, in 

  from keystone.cmd import cli
File "/usr/lib/python2.7/site-packages/keystone/cmd/cli.py", line 29, in 

  from keystone.cmd import doctor
File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/__init__.py", 
line 14, in 
  from keystone.cmd.doctor import credential
File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/credential.py", 
line 16, in 
  from keystone.credential.providers import fernet as credential_fernet
File "/usr/lib/python2.7/site-packages/keystone/credential/__init__.py", 
line 15, in 
  from keystone.credential import controllers  # noqa
File "/usr/lib/python2.7/site-packages/keystone/credential/controllers.py", 
line 19, in 
  from keystone.common import controller
File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 
22, in 
  from keystone.common import authorization
File "/usr/lib/python2.7/site-packages/keystone/common/authorization.py", 
line 25, in 
  from keystone.models import token_model
File "/usr/lib/python2.7/site-packages/keystone/models/token_model.py", 
line 20, in 
  from keystone.federation import constants
File "/usr/lib/python2.7/site-packages/keystone/federation/__init__.py", 
line 15, in 
  from keystone.federation.core import *  # noqa
File "/usr/lib/python2.7/site-packages/keystone/federation/core.py", line 
24, in 
  from keystone import notifications
File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 29, 
in 
  from pycadf import eventfactory

[Yahoo-eng-team] [Bug 1767021] [NEW] Login form button text is inconsistent

2018-04-25 Thread Adrian Turjak

Public bug reported:

The login form button appears to be by default 'connect', which does not
really match the common text for such a button.

'Log in' or 'Sign in' are more common, and it appears the code
technically should show 'Sign in' under some circumstances
(auth_type==='credentials').

I don't know in what context 'Connect' is ever actually appropriate, and
I think we should just stick with 'Sign in' as the only text here.

** Affects: horizon
 Importance: Undecided
 Assignee: Adrian Turjak (adriant-y)
 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/1767021

Title:
  Login form button text is inconsistent

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The login form button appears to be by default 'connect', which does
  not really match the common text for such a button.

  'Log in' or 'Sign in' are more common, and it appears the code
  technically should show 'Sign in' under some circumstances
  (auth_type==='credentials').

  I don't know in what context 'Connect' is ever actually appropriate,
  and I think we should just stick with 'Sign in' as the only text here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1767021/+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 1759979] Re: xenapi: InstanceNotFound trace in detach_interface during instance delete

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/562838
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=5a42701f89a5139acdc38f8572b1083ba528264c
Submitter: Zuul
Branch:master

commit 5a42701f89a5139acdc38f8572b1083ba528264c
Author: Matt Riedemann 
Date:   Thu Apr 19 17:42:23 2018 -0400

xenapi: handle InstanceNotFound in detach_interface()

CI tests frequently teardown by rolling back interface
attachments and then deleting the server, both of which
are asynchronous. If we're trying to detach an interface
on a guest that is gone, we don't need to log a traceback
exception in the logs, just let the InstanceNotFound
raise up to the ComputeManager which will handle the
error and log it appropriately.

Change-Id: I9428be0e6e5b640fdda00410817925001361fd2c
Closes-Bug: #1759979


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

Title:
  xenapi: InstanceNotFound trace in detach_interface during instance
  delete

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  The xenserver CI n-cpu logs are full of InstanceNotFound tracebacks in
  detach_interface during what appears to be instance delete, which
  should be an OK situation that we shouldn't log a traceback ERROR.

  http://dd6b71949550285df7dc-
  dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/37/557837/1/check
  /dsvm-tempest-neutron-network/86c316e/logs/screen-n-cpu.txt.gz

  Mar 29 16:29:49.390491 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [None 
req-84263977-247f-4c70-9ddf-003680e4eaf8 service nova] [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca] detach network interface 
1de85994-b333-4ea1-946b-ce3b11c2f8c5 failed.: InstanceNotFound: Instance 
instance-0054 could not be found.
  Mar 29 16:29:49.390900 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca] Traceback (most recent call last):
  Mar 29 16:29:49.391239 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca]   File 
"/opt/stack/new/nova/nova/virt/xenapi/vmops.py", line 2696, in detach_interface
  Mar 29 16:29:49.391522 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca] vm_ref = 
self._get_vm_opaque_ref(instance)
  Mar 29 16:29:49.391802 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca]   File 
"/opt/stack/new/nova/nova/virt/xenapi/vmops.py", line 983, in _get_vm_opaque_ref
  Mar 29 16:29:49.392067 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca] raise 
exception.InstanceNotFound(instance_id=instance['name'])
  Mar 29 16:29:49.392331 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca] InstanceNotFound: Instance 
instance-0054 could not be found.
  Mar 29 16:29:49.393133 dsvm-devstack-citrix-mia-nodepool-934537 
nova-compute[18313]: ERROR nova.virt.xenapi.vmops [instance: 
4e642f5f-abf3-4db9-b630-a1bff1fd1cca]

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1759979/+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 1766306] Re: api-ref: block_device_mapping_v2.boot_index is required until queens

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/563728
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=048fa2310014e6282e183da0abee87c73b6d71b9
Submitter: Zuul
Branch:master

commit 048fa2310014e6282e183da0abee87c73b6d71b9
Author: Matt Riedemann 
Date:   Mon Apr 23 14:01:36 2018 -0400

api-ref: mark block_device_mapping_v2.boot_index as required

This was marked optional in change If57aa3e37 but it has
only been optional since Queens due to change I8a3e7e6c4,
before that you will get a 400 error if you do not provide
boot_index in the BDMs, e.g.:

2018-04-23 12:34:13,308 INFO [nova.api.openstack.wsgi] \
   HTTP exception thrown: Block Device Mapping is Invalid: \
   Boot sequence for the instance and image/block device \
   mapping combination is not valid.
2018-04-23 12:34:13,310 INFO [nova.api.openstack.requestlog] \
   127.0.0.1 "POST /v2.1/6f70656e737461636b20342065766572/servers"
   status: 400 len: 164 microversion: 2.1 time: 0.129485

One could argue that I8a3e7e6c4b72eb1c3707d54049d18dc29f606fe5
is a behavior change that should have gone with a microversion,
which if people agree with that, could be reverted separately.

Change-Id: I14d44dbc0b6a8fb25932c333e695cad9edaefbed
Closes-Bug: #1766306


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

Title:
  api-ref: block_device_mapping_v2.boot_index is required until queens

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  Change https://review.openstack.org/#/c/550648/ marked the
  block_device_mapping_v2.boot_index parameter for POST /servers as
  optional, but it's only optional since this change in Queens:

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

  Before that, you'll get an error like this if you boot from volume but
  don't specify a boot_index for each BDM in the list:

  2018-04-23 12:34:13,308 INFO [nova.api.openstack.wsgi] HTTP exception thrown: 
Block Device Mapping is Invalid: Boot sequence for the instance and image/block 
device mapping combination is not valid.
  2018-04-23 12:34:13,310 INFO [nova.api.openstack.requestlog] 127.0.0.1 
"POST /v2.1/6f70656e737461636b20342065766572/servers" status: 400 len: 164 
microversion: 2.1 time: 0.129485

  Therefore we should probably mark the parameter as required since the
  API reference applies to older versions/releases of the API too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1766306/+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 1660001] Re: Hyper-V PCI Passthrough

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/510467
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=e536b0692ac24e336bd75e1626c65442addc6468
Submitter: Zuul
Branch:master

commit e536b0692ac24e336bd75e1626c65442addc6468
Author: Claudiu Belu 
Date:   Mon Oct 9 13:15:25 2017 +0300

doc: Adds Hyper-V PCI passthrough details

Feature was introduced in Ocata [1].

[1] https://review.openstack.org/#/c/420614/

Change-Id: I480d6080b9df4a697934eb9498cbb790207ebf64
Closes-Bug: #1660001


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

Title:
  Hyper-V PCI Passthrough

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  https://review.openstack.org/420614
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/nova" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 9d6f9e9cd5dcb1dc9205ace9476dcb3a404ac497
  Author: Claudiu Belu 
  Date:   Mon Jan 16 11:52:35 2017 +0200

  Hyper-V PCI Passthrough
  
  Discrete Device Assignment is a new feature in Windows Server 2016,
  offering users the possibility of taking some of the PCI Express
  devices in their systems and pass them through directly to a guest VM.
  
  DocImpact: The compute-pci-passthrough page in the admin-guide will
  have to be updated to include details regarding PCI passthrough on
  Hyper-V.
  
  Co-Authored-By: Iulia Toader 
  
  Depends-On: I8e7782d3e1e9f8e92406604f05504a7754ffa3c2
  
  Change-Id: I5a243213ff4241b6f70d21a02c606e8fc96ce6e6
  Implements: blueprint hyper-v-pci-passthrough

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1660001/+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 1767002] [NEW] When stop(deallocate) and then start a RHEL 7.5 VM, cloud-init cannot mount /dev/sdb1 to /mnt.

2018-04-25 Thread Daniel Sol

Public bug reported:

When stop(deallocate) and then start a RHEL VM, cloud-init cannot mount
/dev/sdb1 to /mnt.

You see this error:

/var/log/cloud-init.log:
2018-03-23 06:30:52,018 - util.py[DEBUG]: Running command ['mount', '-o', 
'ro,sync', '-t', 'auto', '/dev/disk/cloud/azure_resource-part1', 
'/tmp/tmp9iIt2n'] with allowed return codes [0] (shell=False, capture=True)
2018-03-23 06:30:52,038 - util.py[DEBUG]: Failed mount of 
'/dev/disk/cloud/azure_resource-part1' as 'auto': Unexpected error while 
running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', 
'/dev/disk/cloud/azure_resource-part1', '/tmp/tmp9iIt2n']
Exit code: 32
Reason: -
Stdout: -
Stderr: mount: unknown filesystem type 'ntfs'
2018-03-23 06:30:52,038 - util.py[DEBUG]: Recursively deleting /tmp/tmp9iIt2n
2018-03-23 06:30:52,038 - DataSourceAzure.py[DEBUG]: reformattable=False: 
partition 1 (/dev/disk/cloud/azure_resource-part1 -> /dev/sdb1) on device 
/dev/disk/cloud/azure_resource was ntfs formatted but mount of 
/dev/disk/cloud/azure_resource-part1 failed: Failed mounting 
/dev/disk/cloud/azure_resource-part1 to /tmp/tmp9iIt2n due to: Unexpected error 
while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', 
'/dev/disk/cloud/azure_resource-part1', '/tmp/tmp9iIt2n']
Exit code: 32
Reason: -
Stdout: -
Stderr: mount: unknown filesystem type 'ntfs'

This has been patched here: https://code.launchpad.net/~paul-meyer
/cloud-init/+git/cloud-init/+ref/fix-ntfs-mount.

Thanks,

** Affects: cloud-init
 Importance: Undecided
 Status: New

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

Title:
  When stop(deallocate) and then start a RHEL 7.5 VM, cloud-init cannot
  mount /dev/sdb1 to /mnt.

Status in cloud-init:
  New

Bug description:
  When stop(deallocate) and then start a RHEL VM, cloud-init cannot
  mount /dev/sdb1 to /mnt.

  You see this error:

  /var/log/cloud-init.log:
  2018-03-23 06:30:52,018 - util.py[DEBUG]: Running command ['mount', '-o', 
'ro,sync', '-t', 'auto', '/dev/disk/cloud/azure_resource-part1', 
'/tmp/tmp9iIt2n'] with allowed return codes [0] (shell=False, capture=True)
  2018-03-23 06:30:52,038 - util.py[DEBUG]: Failed mount of 
'/dev/disk/cloud/azure_resource-part1' as 'auto': Unexpected error while 
running command.
  Command: ['mount', '-o', 'ro,sync', '-t', 'auto', 
'/dev/disk/cloud/azure_resource-part1', '/tmp/tmp9iIt2n']
  Exit code: 32
  Reason: -
  Stdout: -
  Stderr: mount: unknown filesystem type 'ntfs'
  2018-03-23 06:30:52,038 - util.py[DEBUG]: Recursively deleting /tmp/tmp9iIt2n
  2018-03-23 06:30:52,038 - DataSourceAzure.py[DEBUG]: reformattable=False: 
partition 1 (/dev/disk/cloud/azure_resource-part1 -> /dev/sdb1) on device 
/dev/disk/cloud/azure_resource was ntfs formatted but mount of 
/dev/disk/cloud/azure_resource-part1 failed: Failed mounting 
/dev/disk/cloud/azure_resource-part1 to /tmp/tmp9iIt2n due to: Unexpected error 
while running command.
  Command: ['mount', '-o', 'ro,sync', '-t', 'auto', 
'/dev/disk/cloud/azure_resource-part1', '/tmp/tmp9iIt2n']
  Exit code: 32
  Reason: -
  Stdout: -
  Stderr: mount: unknown filesystem type 'ntfs'

  This has been patched here: https://code.launchpad.net/~paul-meyer
  /cloud-init/+git/cloud-init/+ref/fix-ntfs-mount.

  Thanks,

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1767002/+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 1761536] Re: Nova compute manager failed to create virtual interface

2018-04-25 Thread David Ames

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

Title:
  Nova compute manager failed to create virtual interface

Status in OpenStack neutron-gateway charm:
  In Progress
Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Rally test scenario: 
NovaServers.boot_server_associate_and_dissociate_floating_ip fails.
  All 5 nova-compute-kvm instances timeout:

  

  Task 2ccf3cf6-c252-4e0f-8fdd-ca58ad819aff has 5 error(s)
  


  TimeoutException: Rally tired waiting 300.00 seconds for Server
  s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to
  become ('ACTIVE') current status BUILD

  Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/rally/task/runner.py", line 
71, in _run_scenario_once
  getattr(scenario_inst, method_name)(**scenario_kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/servers.py",
 line 1116, in run
  server = self._boot_server(image, flavor, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/rally/task/atomic.py", line 
91, in func_atomic_actions
  f = func(self, *args, **kwargs)
File 
"/usr/local/lib/python2.7/dist-packages/rally/plugins/openstack/scenarios/nova/utils.py",
 line 86, in _boot_server
  check_interval=CONF.openstack.nova_server_boot_poll_interval
File "/usr/local/lib/python2.7/dist-packages/rally/task/utils.py", line 
252, in wait_for_status
  timeout=timeout)
  TimeoutException: Rally tired waiting 300.00 seconds for Server 
s_rally_504bd98b_fLz3akho:23cbd6ad-67f7-4e0f-9095-390f50897b62 to become 
('ACTIVE') current status BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-gateway/+bug/1761536/+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 1680062] Re: CORS allow headers broken with Safari

2018-04-25 Thread Ben Nemec

It looks to me like this is set on a per-project basis.  oslo.middleware
doesn't have any default headers:
https://github.com/openstack/oslo.middleware/blob/2c557312519cd368c50eaaa5448049da19cc6281/oslo_middleware/cors.py#L50

A quick search suggests that the accepted headers are being set in
Glance itself:
https://github.com/openstack/glance/blob/8a2d1542348e8aaaee163ba629fd37c534d469d9/glance/common/config.py#L851
I think that's where this would need to be changed.

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

** Changed in: oslo.middleware
   Status: New => Invalid

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

Title:
  CORS allow headers broken with Safari

Status in Glance:
  New
Status in oslo.middleware:
  Invalid

Bug description:
  I'm seeing Glance images failing to upload via Horizon with CORS because:
  2017-04-05 07:07:33.103 7034 DEBUG oslo_middleware.cors [-] Request header 
'origin' not in permitted list: ['CONTENT-MD5', 'X-IMAGE-META-CHECKSUM', 
'X-STORAGE-TOKEN', 'ACCEPT-ENCODING', 'X-AUTH-TOKEN', 'X-IDENTITY-STATUS', 
'X-ROLES', 'X-SERVICE-CATALOG', 'X-USER-ID', 'X-TENANT-ID', 
'X-OPENSTACK-REQUEST-ID', 'ACCEPT', 'ACCEPT-LANGUAGE', 'CONTENT-TYPE', 
'CACHE-CONTROL', 'CONTENT-LANGUAGE', 'EXPIRES', 'LAST-MODIFIED', 'PRAGMA'] 
_apply_cors_preflight_headers 
/openstack/venvs/glance-14.1.0/lib/python2.7/site-packages/oslo_middleware/cors.py:381

  The request headers Safari is sending are:
  Access-Control-Request-Headersaccept, content-type, origin, 
x-auth-token

  
  The same upload works fine in Chrome, where the request headers are:
  Access-Control-Request-Headers: content-type,x-auth-token

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1680062/+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 1765144] Re: [keystone_authtoken] auth_url = http://controller:35357 port error, it should be 5000

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/562812
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=698630e1a432aa1f292fabe8d738a2f5867f73fe
Submitter: Zuul
Branch:master

commit 698630e1a432aa1f292fabe8d738a2f5867f73fe
Author: Matt Riedemann 
Date:   Thu Apr 19 15:43:35 2018 -0400

Update docs for [keystone_authtoken] changes since Queens

The auth_uri option was deprecated and renamed in Queens:

  I0cf11da3d395749df28077427689fdafc8a6b981

The auth_uri option is also no longer necessary, at least
for the purpose of the nova install guide, since all identity
service requests can be served through the single auth_url.

This change removes auth_uri usage and also updates the
auth_url value to match what is in the keystone install
guide:


https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

Change-Id: Iff332890cbe1ba5b3876874e351b09c377d8dd5d
Closes-Bug: #1765144


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

** Changed in: nova/queens
   Status: Confirmed => In Progress

** Changed in: nova/queens
 Assignee: (unassigned) => Matt Riedemann (mriedem)

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

Title:
  [keystone_authtoken]  auth_url = http://controller:35357 port error,
  it should be 5000

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  In Progress

Bug description:
  [api]
  # ...
  auth_strategy = keystone

  [keystone_authtoken]
  # ...
  auth_uri = http://controller:5000
  auth_url = http://controller:35357
  memcached_servers = controller:11211
  auth_type = password
  project_domain_name = default
  user_domain_name = default
  project_name = service
  username = nova
  password = NOVA_PASS

  
  above configuration has the port error, should replace 35357 to 5000

  
  Thanks
  Yufei



  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:

  - [ ] This doc is inaccurate in this way: __
  - [ ] 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: 17.0.3.dev13 on 2018-04-17 17:03
  SHA: 991c2926cbcb16dab9cf0ef059b0393b6c895490
  Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/install/controller-install-ubuntu.rst
  URL: 
https://docs.openstack.org/nova/queens/install/controller-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1765144/+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 1745340] Re: Nova assumes that USB Host is present

2018-04-25 Thread Matt Riedemann

** Changed in: nova
   Importance: Undecided => Medium

** Also affects: nova/pike
   Importance: Undecided
   Status: New

** Changed in: nova/pike
   Status: New => In Progress

** Changed in: nova/pike
   Importance: Undecided => Medium

** Changed in: nova/pike
 Assignee: (unassigned) => Mohammed Naser (mnaser)

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

Title:
  Nova assumes that USB Host is present

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  In Progress

Bug description:
  I am working on getting OpenStack running on aarch64 architecture. And
  it is there. But I wanted to have graphical console like it is present
  on x86.

  Went though settings, enabled VNC/Spice and got "libvirtError:
  internal error: No free USB ports" message instead.

  Digged into code and it looks like Nova blindly assumes that USB host
  is present in VM instance as it just adds usbtablet device and starts
  an instance.

  But it should add USB host device first...

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1745340/+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 1761536] Re: Nova compute manager failed to create virtual interface

2018-04-25 Thread David Ames

Root cause of the instance boot failures is app armor on the neutron-
gateway blocking neutron agents from creating temporary directories:

1vlRG/" pid=1412869 comm="neutron-dhcp-ag" requested_mask="c" denied_mask="c" 
fsuid=115 ouid=115
[76035.437502] audit: type=1400 audit(1524677252.781:36019): apparmor="DENIED" 
operation="mkdir" profile="/usr/bin/neutron-dhcp-agent" name="/tmp/tmp4AIVtB/" 
pid=1412869 comm="neutron-dhcp-ag" requested_mask="c" denied_mask="c" fsuid=115 
ouid=115

Both the dhcp-agent and the l3-agent both show the problem.

Assigning this bug to neutron-gateway for the app armor bug


A secondary issue that is as yet not root caused is DBConnection errors
from all the API charms connecting to percona cluster. After changing
the neutron-gateway aa-profile-mode to complain we saw these errors much
less frequently but they did not go away entirely.

2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
[req-dcf87632-8b6e-4071-a336-64b1442dc7fe - - - - -] Database connection was 
found disconnected; reconnecting: DBConnectionError: 
(pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during 
query') [SQL: u'SELECT 1']
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines Traceback (most 
recent call last):
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 73, in 
_connect_ping_listener
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
connection.scalar(select([1]))
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 877, in 
scalar
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines return 
self.execute(object, *multiparams, **params).scalar()
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 945, in 
execute
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines return 
meth(self, multiparams, params)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py", line 263, in 
_execute_on_connection
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines return 
connection._execute_clauseelement(self, multiparams, params)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1053, in 
_execute_clauseelement
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
compiled_sql, distilled_params
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1189, in 
_execute_context
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines context)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1398, in 
_handle_dbapi_exception
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
util.raise_from_cause(newraise, exc_info)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in 
raise_from_cause
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
reraise(type(exception), exception, tb=exc_tb, cause=cause)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1182, in 
_execute_context
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines context)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 470, in 
do_execute
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
cursor.execute(statement, parameters)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/pymysql/cursors.py", line 165, in execute
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines result = 
self._query(query)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/pymysql/cursors.py", line 321, in _query
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
conn.query(q)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 860, in query
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines 
self._affected_rows = self._read_query_result(unbuffered=unbuffered)
2018-04-25 17:49:33.562 617800 ERROR oslo_db.sqlalchemy.engines   File 
"/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1061, in 
_read_query_result
2018-04-25 17:49:33.562 617800 ERROR

[Yahoo-eng-team] [Bug 1766919] [NEW] inspect.getargspec usage is deprecated in python 3

2018-04-25 Thread Matt Riedemann

Public bug reported:

As seen in py35 CI logs:

b'/home/osboxes/git/nova/.tox/functional-py35/lib/python3.5/site-packages/paste/deploy/loadwsgi.py:22:
 DeprecationWarning: Parameters to load are deprecated.  Call .resolve and 
.require separately.'
b'  return pkg_resources.EntryPoint.parse("x=" + s).load(False)'
b'/home/osboxes/git/nova/nova/utils.py:751: DeprecationWarning: 
inspect.getargspec() is deprecated, use inspect.signature() instead'
b'  arg_names, a, kw, _default = inspect.getargspec(base_f)'


Also seen all over:

http://logs.openstack.org/01/558001/5/check/openstack-tox-py35/b9ea932
/job-output.txt.gz

** Affects: nova
 Importance: Low
 Status: Confirmed


** Tags: python3

** Changed in: nova
   Status: New => Confirmed

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

Title:
  inspect.getargspec usage is deprecated in python 3

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  As seen in py35 CI logs:

  
b'/home/osboxes/git/nova/.tox/functional-py35/lib/python3.5/site-packages/paste/deploy/loadwsgi.py:22:
 DeprecationWarning: Parameters to load are deprecated.  Call .resolve and 
.require separately.'
  b'  return pkg_resources.EntryPoint.parse("x=" + s).load(False)'
  b'/home/osboxes/git/nova/nova/utils.py:751: DeprecationWarning: 
inspect.getargspec() is deprecated, use inspect.signature() instead'
  b'  arg_names, a, kw, _default = inspect.getargspec(base_f)'

  
  Also seen all over:

  http://logs.openstack.org/01/558001/5/check/openstack-tox-py35/b9ea932
  /job-output.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1766919/+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 1750829] Re: RFE: libvirt: Add ability to configure extra CPU flags for named CPU models

2018-04-25 Thread Matt Riedemann

** Also affects: nova/ocata
   Importance: Undecided
   Status: New

** Changed in: nova/ocata
   Status: New => Fix Released

** Changed in: nova/ocata
   Importance: Undecided => Medium

** Changed in: nova/ocata
 Assignee: (unassigned) => Lee Yarwood (lyarwood)

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

Title:
  RFE: libvirt: Add ability to configure extra CPU flags for named CPU
  models

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Committed
Status in OpenStack Compute (nova) queens series:
  Fix Committed

Bug description:
  Motivation
  --

  The recent "Meltdown" CVE fixes resulted in critical performance
  penalty, From here[*]:

  [...] However, in examining both the various fixes rolled out in
  actual Linux distros over the past few days and doing some very
  informal surveying of environments I have access to, I discovered
  that the PCID ["process-context identifiers"] processor feature,
  which used to be a virtual no-op, is now a performance AND security
  critical item.[...]

  So if a Nova user has applied all the "Meltdown" CVE fixes, and is using
  a named CPU model (like "IvyBridge", or "Westmere" — which specifically
  lack the said obscure "PCID" feature) they will incur severe performance
  degradation[*].

  Note that some of Intel *physical* CPUs themselves include the 'pcid'
  CPU feature flag; but the named CPU models provided by libvirt & QEMU
  lack that flag — hence we explicitly specify it for virtual CPUs via the
  following proposed config attribute.

  [*] https://groups.google.com/forum/m/#!topic/mechanical-
  sympathy/L9mHTbeQLNU

  Proposed change
  ---

  Modify Nova's libvirt driver such that it will be possible to set
  granular CPU feature flags for named CPU models.  E.g. to explicitly
  specify the 'pcid' feature flag with Intel IvyBridge CPU model, set the
  following in /etc/nova.conf:

  ...
  [libvirt]
  cpu_model=IvyBridge
  cpu_model_extra_flags="pcid"
  ...

  The list of known CPU feature flags ('vmx', 'xtpr', 'pcid', et cetera)
  can be found in /usr/share/libvirt/cpu_map.xml.

  Note that before specifying extra CPU feature flags, one should check if
  the named CPU models (provided by libvirt) already include the said
  flags.  E.g. the 'Broadwell', 'Haswell-noTSX' named CPU models provided
  by libvirt already provides the 'pcid' CPU feature flag.

  Other use cases
  ---

    - Nested Virtualization — an operator can specify the Intel 'vmx' or
  AMD 'svm' flags in the level-1 guest (i.e. the guest hypervisor)

    - Ability to use 1GB huge pages with Haswell model as one use case for
  extra flags (thanks: Daniel Berrangé, for mentioning this scenario):

  cpu_model_extra_flags=Haswell
  cpu_model_extra_flags="pdpe1gb"

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1750829/+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 1766208] Re: Lift the restriction on choices for `cpu_model_extra_flags` config attribute

2018-04-25 Thread Matt Riedemann

This isn't a bug, it's already tracked with a blueprint so just use
that:

https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-model-extra-
flags

** Changed in: nova
   Status: In Progress => 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/1766208

Title:
  Lift the restriction on choices for `cpu_model_extra_flags` config
  attribute

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  In the patch[*] that introduced the Nova configuration attribute
  `[libvirt]/cpu_model_extra_flags`, we have restricted the choices to be
  only 'PCID' -- to alleviate the immediate guest performance degradation
  as a result of applying the "Meltdown" CVE fixes.

  Now remove that restriction to allow adding and removing multiple CPU
  flags, making way for other use cases.

  Use cases:

    - Ability to use 1GB huge pages with Haswell model as one use case for
  extra flags:

  cpu_model=Haswell-noTSX-IBRS
  cpu_model_extra_flags="pdpe1gb"

    - Nested Virtualization -- an operator can specify the Intel 'vmx' or
  AMD 'svm' flags in the level-1 Nova guest.

  [*] http://git.openstack.org/cgit/openstack/nova/commit/?h=master;
  id=6b601b7 -- libvirt: Allow to specify granular CPU feature flags

  
  A potential example of specifying multiple CPU feature flags
  

  If you specify:

  [libvirt]
  cpu_mode=custom
  cpu_model=IvyBridge
  cpu_model_extra_flags="+pcid,-mtrr,pdpe1gb"

  Then, Nova should generate the below XML:

  
    IvyBridge
    Intel
    
    
  

  The +/- for individual flags in nova.conf will be optional.  If nothing
  is specified, assume '+'.

  You might ask: "Why would you want to remove a CPU flag though?"  One
  scenario for that is: An Operator wants to generate a baseline CPU
  config.  And a certain CPU flag is causing performance issue or other
  nuisance, and if the Operator isolated the problem to _that_ specific
  CPU flag, then she may want to remove the flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1766208/+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 1746863] Re: scheduler affinity doesn't work with multiple cells

2018-04-25 Thread melanie witt

** Also affects: nova/queens
   Importance: Undecided
   Status: New

** Changed in: nova/queens
   Importance: Undecided => High

** Changed in: nova/queens
   Status: New => Confirmed

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

Title:
  scheduler affinity doesn't work with multiple cells

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) pike series:
  Confirmed
Status in OpenStack Compute (nova) queens series:
  Confirmed

Bug description:
  I happened upon this while hacking on my WIP CellDatabases fixture
  patch.

  Some of the nova/tests/functional/test_server_group.py tests started
  failing with multiple cells and I found that it's because there's a
  database query 'objects.InstanceList.get_by_filters' for all instances
  who are members of the server group to do the affinity check. The
  query for instances doesn't check all cells, so it fails to return any
  hosts that group members are currently on.

  This makes the ServerGroup[Anti|]AffinityFilter a no-op for multiple
  cells. Affinity is checked again via the late-affinity check in
  compute, but compute is using the same InstanceGroup.get_hosts method
  and will only find group member's hosts that are in its cell.

  This is the code that populates the RequestSpec.instance_group.hosts via a
  lazy-load on first access:

  nova/objects/instance_group.py:

  def obj_load_attr(self, attrname):
  ...
  self.hosts = self.get_hosts()
  self.obj_reset_changes(['hosts'])

  ...

  @base.remotable
  def get_hosts(self, exclude=None):
  """Get a list of hosts for non-deleted instances in the group
  This method allows you to get a list of the hosts where instances in
  this group are currently running.  There's also an option to exclude
  certain instance UUIDs from this calculation.
  """
  filter_uuids = self.members
  if exclude:
  filter_uuids = set(filter_uuids) - set(exclude)
  filters = {'uuid': filter_uuids, 'deleted': False}
  instances = objects.InstanceList.get_by_filters(self._context,
  filters=filters)
  return list(set([instance.host for instance in instances
   if instance.host]))

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746863/+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 1765830] Re: migration from osp 10 -> 11 -> 12 fails because migration script 22 is not idempotent

2018-04-25 Thread Ade Lee

This only happens because we  tried to backport a fix downstream, and
upstream has chosen not to backport this fix.

Closing as this should not affect upstream.

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

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

Title:
  migration from osp 10 -> 11 -> 12 fails because migration script 22 is
  not idempotent

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  This is described in
  https://bugzilla.redhat.com/show_bug.cgi?id=1569605

  Basically, the fix for
  https://bugzilla.redhat.com/show_bug.cgi?id=1541142 was backported to
  pike and queens and included the migration script #22 (renamed to #17
  and #5)

  On upgrade, we attempt to run script again, and fail because the
  script is not idempotent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1765830/+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 1750121] Re: Dynamic routing: adding speaker to agent fails

2018-04-25 Thread Corey Bryant

** No longer affects: neutron-dynamic-routing (Ubuntu Cc-series)

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

Title:
  Dynamic routing: adding speaker to agent fails

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

Bug description:
  SRU details for Ubuntu
  --
  [Impact]
  See "Original description" below.

  [Test Case]
  See "Original description" below.

  [Regression Potential]
  Low. This is fixed upstream in corresponding stable branches.

  
  Original description
  
  When following 
https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
 everything works fine because the speaker is scheduled to the agent 
automatically (in contrast to what the docs say). But if I remove the speaker 
from the agent and add it again with

  $ neutron bgp-dragent-speaker-remove 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker
  $ neutron bgp-dragent-speaker-add 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker

  the following error is seen in the log:

  Feb 17 10:56:30 test-node01 neutron-bgp-dragent[18999]: ERROR
  neutron_dynamic_routing.services.bgp.agent.bgp_dragent [None req-
  da9a22ae-52a2-4be7-a3e8-2dc2dc970fdd admin admin] Call to driver for
  BGP Speaker d2aa5935-30c2-4369-83ee-b3a0ff77cc49 add_bgp_peer has
  failed with exception 'auth_type'.

  The same thing happens when there are multiple agents and one tries to
  add the speaker to one of the other agents.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1750121/+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 1751564] Re: unable to attach multiattach volume to server

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/547856
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=1e2dfc4bb47e9873cbb5286ef351269ca557578a
Submitter: Zuul
Branch:master

commit 1e2dfc4bb47e9873cbb5286ef351269ca557578a
Author: Matt Riedemann 
Date:   Sun Feb 25 14:38:43 2018 -0500

Use microversion 2.60 when attaching a multiattach volume

Multiattach capable volumes can only be attached with microversion
2.60 or later, so this checks if the volume being attached is
multiattach capable and if microversion 2.60 is available, use it.

Part of blueprint multi-attach-volume

Closes-Bug: #1751564

Change-Id: If708e3edb05cff6e93cfc3dfccb91b1441dcd181


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

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

Title:
  unable to attach multiattach volume to server

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The compute API 2.60 microversion allows attaching multiattach-capable
  volumes to server instances.

  However, when attempting to do so in Horizon it fails because Horizon
  doesn't specify microversion 2.60 during the attach call to nova (see
  screenshot).

  And you can see the error in the nova-api logs:

  [None req-9e43e495-a9ee-4460-85bb-1545ce1efbeb demo demo] Returning
  400 to user: Multiattach volumes are only supported starting with
  compute API version 2.60.

  Note that if Horizon is using python-novaclient for the attach volume
  call, it must have novaclient >= 10.1.0:

  https://github.com/openstack/python-
  novaclient/commit/4e94fe53618638c37285d61c322b663192678bfb

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1751564/+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 1703369] Re: get_identity_providers policy should be singular

2018-04-25 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/564150
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=93bb571888a1bff4fa1e110356dbf2cb9fb4ee52
Submitter: Zuul
Branch:master

commit 93bb571888a1bff4fa1e110356dbf2cb9fb4ee52
Author: Radomir Dopieralski 
Date:   Wed Apr 25 11:37:05 2018 +0200

Replace all mentions of get_identity_providers with get_identity_provider

There was a typo in keystone's policy files, and it has been fixed in
Keystone already, we should also fix it to match.

Change-Id: I41e4381765f3bfc5988ca235e6cbeb6d1ba62fc2
Closes-bug: #1703369


** Changed in: horizon
   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/1703369

Title:
  get_identity_providers policy should be singular

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Committed
Status in OpenStack Identity (keystone) ocata series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  identity:get_identity_providers should be
  identity:get_identity_provider (singular) since a GET is targeted on a
  single provider and the code is setup to check for
  identity:get_identity_provider (singular). See
  
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112

  found in master (pike)

  The ocata default policy.json also has this problem. Unless someone
  manually overrode policy to specify identity:get_identity_provider
  (singular), the result would be that the default rule was actually
  used for that check instead of identity:get_identity_providers. We
  could go back and fix the default policy.json for past releases, but
  the default actually has the same value as
  identity:get_identity_providers, and if nobody has complained it's
  probably safer to just leave it. It is, after all, just defaults there
  and anyone can override by specifying the correct value.

  But we must fix in pike to go along with the shift of policy into
  code. Policy defaults in code definitely need to match up with what
  the code actually checks. There should no longer be any reliance on
  the default rule.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1703369/+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 1750121] Re: Dynamic routing: adding speaker to agent fails

2018-04-25 Thread Corey Bryant

** Also affects: neutron-dynamic-routing (Ubuntu Cc-series)
   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/1750121

Title:
  Dynamic routing: adding speaker to agent fails

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in neutron:
  Fix Released
Status in neutron-dynamic-routing package in Ubuntu:
  Triaged
Status in neutron-dynamic-routing source package in Artful:
  Triaged
Status in neutron-dynamic-routing source package in Bionic:
  Triaged
Status in neutron-dynamic-routing source package in CC-Series:
  New

Bug description:
  SRU details for Ubuntu
  --
  [Impact]
  See "Original description" below.

  [Test Case]
  See "Original description" below.

  [Regression Potential]
  Low. This is fixed upstream in corresponding stable branches.

  
  Original description
  
  When following 
https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
 everything works fine because the speaker is scheduled to the agent 
automatically (in contrast to what the docs say). But if I remove the speaker 
from the agent and add it again with

  $ neutron bgp-dragent-speaker-remove 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker
  $ neutron bgp-dragent-speaker-add 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker

  the following error is seen in the log:

  Feb 17 10:56:30 test-node01 neutron-bgp-dragent[18999]: ERROR
  neutron_dynamic_routing.services.bgp.agent.bgp_dragent [None req-
  da9a22ae-52a2-4be7-a3e8-2dc2dc970fdd admin admin] Call to driver for
  BGP Speaker d2aa5935-30c2-4369-83ee-b3a0ff77cc49 add_bgp_peer has
  failed with exception 'auth_type'.

  The same thing happens when there are multiple agents and one tries to
  add the speaker to one of the other agents.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1750121/+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 1750121] Re: Dynamic routing: adding speaker to agent fails

2018-04-25 Thread Corey Bryant

** Also affects: neutron (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/pike
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/queens
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/pike
   Status: New => Triaged

** Changed in: cloud-archive/queens
   Status: New => Triaged

** Changed in: cloud-archive/pike
   Importance: Undecided => High

** Changed in: cloud-archive/queens
   Importance: Undecided => High

** No longer affects: neutron (Ubuntu)

** Also affects: neutron-dynamic-routing (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: neutron-dynamic-routing (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: neutron-dynamic-routing (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: neutron-dynamic-routing (Ubuntu Artful)
   Status: New => Triaged

** Changed in: neutron-dynamic-routing (Ubuntu Artful)
   Importance: Undecided => High

** Changed in: neutron-dynamic-routing (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: neutron-dynamic-routing (Ubuntu Bionic)
   Importance: Undecided => High

** Description changed:

- When following https://docs.openstack.org/neutron-dynamic-
- routing/latest/contributor/testing.html everything works fine because
- the speaker is scheduled to the agent automatically (in contrast to what
- the docs say). But if I remove the speaker from the agent and add it
- again with
+ SRU details for Ubuntu
+ --
+ [Impact]
+ See "Original description" below.
+ 
+ [Test Case]
+ See "Original description" below.
+ 
+ [Regression Potential]
+ Low. This is fixed upstream in corresponding stable branches.
+ 
+ 
+ Original description
+ 
+ When following 
https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
 everything works fine because the speaker is scheduled to the agent 
automatically (in contrast to what the docs say). But if I remove the speaker 
from the agent and add it again with
  
  $ neutron bgp-dragent-speaker-remove 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker
  $ neutron bgp-dragent-speaker-add 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker
  
  the following error is seen in the log:
  
  Feb 17 10:56:30 test-node01 neutron-bgp-dragent[18999]: ERROR
  neutron_dynamic_routing.services.bgp.agent.bgp_dragent [None req-
  da9a22ae-52a2-4be7-a3e8-2dc2dc970fdd admin admin] Call to driver for BGP
  Speaker d2aa5935-30c2-4369-83ee-b3a0ff77cc49 add_bgp_peer has failed
  with exception 'auth_type'.
  
  The same thing happens when there are multiple agents and one tries to
  add the speaker to one of the other agents.

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

Title:
  Dynamic routing: adding speaker to agent fails

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

Bug description:
  SRU details for Ubuntu
  --
  [Impact]
  See "Original description" below.

  [Test Case]
  See "Original description" below.

  [Regression Potential]
  Low. This is fixed upstream in corresponding stable branches.

  
  Original description
  
  When following 
https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
 everything works fine because the speaker is scheduled to the agent 
automatically (in contrast to what the docs say). But if I remove the speaker 
from the agent and add it again with

  $ neutron bgp-dragent-speaker-remove 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker
  $ neutron bgp-dragent-speaker-add 0159fc0a-22de-4995-8fad-8fb8835a4d86 
bgp-speaker

  the following error is seen in the log:

  Feb 17 10:56:30 test-node01 neutron-bgp-dragent[18999]: ERROR
  neutron_dynamic_routing.services.bgp.agent.bgp_dragent [None req-
  da9a22ae-52a2-4be7-a3e8-2dc2dc970fdd admin admin] Call to driver for
  BGP Speaker d2aa5935-30c2-4369-83ee-b3a0ff77cc49 add_bgp_peer has
  failed with exception 'auth_type'.

  The same thing happens when there are multiple agents and one tries to
  add the speaker to one of the other agents.

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

[Yahoo-eng-team] [Bug 1766856] [NEW] wrong eni_path for debian

2018-04-25 Thread Christoph Ziebuhr

Public bug reported:

eni_path for debian is configured as /etc/network/interfaces.d/50-cloud-
init.cfg, but the file doesn't get used by ifupdown. According to the
interfaces manpage, the filename has to match ^[a-zA-Z0-9_-]+$. It works
when the extension .cfg is removed.

I'm using DataSourceNoCloud with a Networking Config Version 1.

** Affects: cloud-init
 Importance: Undecided
 Status: New

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

Title:
  wrong eni_path for debian

Status in cloud-init:
  New

Bug description:
  eni_path for debian is configured as /etc/network/interfaces.d/50
  -cloud-init.cfg, but the file doesn't get used by ifupdown. According
  to the interfaces manpage, the filename has to match ^[a-zA-Z0-9_-]+$.
  It works when the extension .cfg is removed.

  I'm using DataSourceNoCloud with a Networking Config Version 1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1766856/+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 1703369] Re: get_identity_providers policy should be singular

2018-04-25 Thread Radomir Dopieralski

** Also 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 Identity (keystone).
https://bugs.launchpad.net/bugs/1703369

Title:
  get_identity_providers policy should be singular

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Committed
Status in OpenStack Identity (keystone) ocata series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  identity:get_identity_providers should be
  identity:get_identity_provider (singular) since a GET is targeted on a
  single provider and the code is setup to check for
  identity:get_identity_provider (singular). See
  
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112

  found in master (pike)

  The ocata default policy.json also has this problem. Unless someone
  manually overrode policy to specify identity:get_identity_provider
  (singular), the result would be that the default rule was actually
  used for that check instead of identity:get_identity_providers. We
  could go back and fix the default policy.json for past releases, but
  the default actually has the same value as
  identity:get_identity_providers, and if nobody has complained it's
  probably safer to just leave it. It is, after all, just defaults there
  and anyone can override by specifying the correct value.

  But we must fix in pike to go along with the shift of policy into
  code. Policy defaults in code definitely need to match up with what
  the code actually checks. There should no longer be any reliance on
  the default rule.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1703369/+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 1766812] [NEW] the machine running dhcp agent will have very high cpu load when start dhcp agent after the agent down more than 150 seconds

2018-04-25 Thread Jiaping LI

Public bug reported:

This issue can be reproduced by following steps:

openstack Ocata version, centos 7.2

1. two dhcp agent nodes
2. neutron-server side config allow_automatic_dhcp_failover is True and 
dhcp_agents_per_network is 2
3. create a lot of networks and each one have one subnet, I created 200.The 
more networks, the higher cpu load of dhcp agent node, and the longer high cpu 
load duration
4. stop one dhcp agent, and wait at least more than 150s (agent_down_time * 2). 
It is best to check the distribution of networks on two dhcp agent nodes. 
Neutron-server will remove the networks of the dead dhcp agent after 150s, it 
is better to wait until all the networks is removed from the dead dhcp agent in 
the db. So if have 200 networks, you can do the next step after more than 5 
minites.
5. start the dhcp agent above, and use top to check the cpu situation, after a 
while, you will see very high cpu load.

If you have rabbitmq web UI, after do the 5 step, the dhcp agent will
sync the networks and the dhcp agent consumer has not been created yet.
Neutron-server find that the dhcp agent is active and re schedule
network to the dhcp agent, you will find that the messages heap up in
the dhcp agent side. After the dhcp agent finished syncing networks, the
dhcp agent consumer is created and will consume the messages but not
deal. When the dhcp agent queue consumes the heap messages and deal, the
cpu load of dhcp agent node will become higher and higher.

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

Title:
  the machine running dhcp agent will have very high cpu load when start
  dhcp agent after the agent down more than 150 seconds

Status in neutron:
  New

Bug description:
  This issue can be reproduced by following steps:

  openstack Ocata version, centos 7.2

  1. two dhcp agent nodes
  2. neutron-server side config allow_automatic_dhcp_failover is True and 
dhcp_agents_per_network is 2
  3. create a lot of networks and each one have one subnet, I created 200.The 
more networks, the higher cpu load of dhcp agent node, and the longer high cpu 
load duration
  4. stop one dhcp agent, and wait at least more than 150s (agent_down_time * 
2). It is best to check the distribution of networks on two dhcp agent nodes. 
Neutron-server will remove the networks of the dead dhcp agent after 150s, it 
is better to wait until all the networks is removed from the dead dhcp agent in 
the db. So if have 200 networks, you can do the next step after more than 5 
minites.
  5. start the dhcp agent above, and use top to check the cpu situation, after 
a while, you will see very high cpu load.

  If you have rabbitmq web UI, after do the 5 step, the dhcp agent will
  sync the networks and the dhcp agent consumer has not been created
  yet. Neutron-server find that the dhcp agent is active and re schedule
  network to the dhcp agent, you will find that the messages heap up in
  the dhcp agent side. After the dhcp agent finished syncing networks,
  the dhcp agent consumer is created and will consume the messages but
  not deal. When the dhcp agent queue consumes the heap messages and
  deal, the cpu load of dhcp agent node will become higher and higher.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1766812/+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 1703369] Re: get_identity_providers policy should be singular

2018-04-25 Thread Luke Hinds

Sounds right Mircea, but it won't be a security issue this time, as its
in docs / unit tests, rather than code that could be used in production.
Still needs a bug raised in horizon though, and well spotted.

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

Title:
  get_identity_providers policy should be singular

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Committed
Status in OpenStack Identity (keystone) ocata series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  identity:get_identity_providers should be
  identity:get_identity_provider (singular) since a GET is targeted on a
  single provider and the code is setup to check for
  identity:get_identity_provider (singular). See
  
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112

  found in master (pike)

  The ocata default policy.json also has this problem. Unless someone
  manually overrode policy to specify identity:get_identity_provider
  (singular), the result would be that the default rule was actually
  used for that check instead of identity:get_identity_providers. We
  could go back and fix the default policy.json for past releases, but
  the default actually has the same value as
  identity:get_identity_providers, and if nobody has complained it's
  probably safer to just leave it. It is, after all, just defaults there
  and anyone can override by specifying the correct value.

  But we must fix in pike to go along with the shift of policy into
  code. Policy defaults in code definitely need to match up with what
  the code actually checks. There should no longer be any reliance on
  the default rule.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+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 1767028] [NEW] loadbalancer can't create with chinese character name

[Yahoo-eng-team] [Bug 1767028] [NEW] loadbalancer can't create with chinese character name

[Yahoo-eng-team] [Bug 1767024] [NEW] keystone-manage fails on FIPS compliant system

[Yahoo-eng-team] [Bug 1767021] [NEW] Login form button text is inconsistent

[Yahoo-eng-team] [Bug 1759979] Re: xenapi: InstanceNotFound trace in detach_interface during instance delete

[Yahoo-eng-team] [Bug 1766306] Re: api-ref: block_device_mapping_v2.boot_index is required until queens

[Yahoo-eng-team] [Bug 1660001] Re: Hyper-V PCI Passthrough

[Yahoo-eng-team] [Bug 1767002] [NEW] When stop(deallocate) and then start a RHEL 7.5 VM, cloud-init cannot mount /dev/sdb1 to /mnt.

[Yahoo-eng-team] [Bug 1761536] Re: Nova compute manager failed to create virtual interface

[Yahoo-eng-team] [Bug 1680062] Re: CORS allow headers broken with Safari

[Yahoo-eng-team] [Bug 1765144] Re: [keystone_authtoken] auth_url = http://controller:35357 port error, it should be 5000

[Yahoo-eng-team] [Bug 1745340] Re: Nova assumes that USB Host is present

[Yahoo-eng-team] [Bug 1761536] Re: Nova compute manager failed to create virtual interface

[Yahoo-eng-team] [Bug 1766919] [NEW] inspect.getargspec usage is deprecated in python 3

[Yahoo-eng-team] [Bug 1750829] Re: RFE: libvirt: Add ability to configure extra CPU flags for named CPU models

[Yahoo-eng-team] [Bug 1766208] Re: Lift the restriction on choices for `cpu_model_extra_flags` config attribute

[Yahoo-eng-team] [Bug 1746863] Re: scheduler affinity doesn't work with multiple cells

[Yahoo-eng-team] [Bug 1765830] Re: migration from osp 10 -> 11 -> 12 fails because migration script 22 is not idempotent

[Yahoo-eng-team] [Bug 1750121] Re: Dynamic routing: adding speaker to agent fails

[Yahoo-eng-team] [Bug 1751564] Re: unable to attach multiattach volume to server

[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular

[Yahoo-eng-team] [Bug 1750121] Re: Dynamic routing: adding speaker to agent fails

[Yahoo-eng-team] [Bug 1750121] Re: Dynamic routing: adding speaker to agent fails

[Yahoo-eng-team] [Bug 1766856] [NEW] wrong eni_path for debian

[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular

[Yahoo-eng-team] [Bug 1766812] [NEW] the machine running dhcp agent will have very high cpu load when start dhcp agent after the agent down more than 150 seconds

[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular

27 matches

Site Navigation

Mail list logo

Footer information