[Yahoo-eng-team] [Bug 1747095] [NEW] doc: placement API ref for resource classes points to os-traits

2018-02-02 Thread Eric Fried 
Public bug reported:

The placement API reference documentation for POST /resource_classes [1]
says:

The new class must be a custom resource class, prefixed with CUSTOM_ and
distinct from the _standard_ resource classes.

...where _standard_ is a link to os-traits documentation [2].  Since we
don't have os-resource-classes (yet), the linkitude should just be
removed.

[1] https://developer.openstack.org/api-ref/placement/#create-resource-class
[2] https://docs.openstack.org/os-traits/latest/

** Affects: nova
 Importance: Undecided
 Assignee: Eric Fried (efried)
 Status: In Progress


** Tags: placement

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

Title:
  doc: placement API ref for resource classes points to os-traits

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  The placement API reference documentation for POST /resource_classes
  [1] says:

  The new class must be a custom resource class, prefixed with CUSTOM_
  and distinct from the _standard_ resource classes.

  ...where _standard_ is a link to os-traits documentation [2].  Since
  we don't have os-resource-classes (yet), the linkitude should just be
  removed.

  [1] https://developer.openstack.org/api-ref/placement/#create-resource-class
  [2] https://docs.openstack.org/os-traits/latest/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747095/+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 1744361] Re: test_server_security_groups failed to reboot with "Domain not found: no domain with matching uuid" because of missing vif event from linuxbridge agent

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/540168
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=236bb54493385bcfe2034e8b0fd7a387fa66635a
Submitter: Zuul
Branch:master

commit 236bb54493385bcfe2034e8b0fd7a387fa66635a
Author: melanie witt 
Date:   Thu Feb 1 22:27:57 2018 +

Don't wait for vif plug events during _hard_reboot

Originally, in change Id188d48609f3d22d14e16c7f6114291d547a8986 we
added a re-initialization of volumes, encryptors, and vifs to hard
reboot. When creating the libvirt domain and network, we were waiting
for vif plug events from neutron when we replugged the vifs. Then, we
started seeing timeouts in the linuxbridge gate job because compute
was timing out waiting for plug events from neutron during a hard
reboot.

It turns out that the behavior of neutron plug events depends on what
vif type we're using and we're also using a stale network info_cache
throughout the hard reboot code path, so we can't be 100% sure we know
which vifs to wait for plug events from anyway. We coincidentally get
some info_cache refreshes from network-changed events from neutron,
but we shouldn't rely on that.

Ideally, we could do something like wait for an unplug event after we
unplug the vif, then refresh the network_info cache, then wait for the
plug event. BUT, in the case of the os-vif linuxbridge unplug method,
it is a no-op, so I don't think we could expect to get an unplug
event for it (and we don't see any network-vif-unplugged events sent
in the q-svc log for the linuxbridge job during a hard reboot).

Closes-Bug: #1744361

Change-Id: Ib0cf5d55750f13d0499a570f14024dca551ed4d4


** 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 neutron.
https://bugs.launchpad.net/bugs/1744361

Title:
  test_server_security_groups failed to reboot with "Domain not found:
  no domain with matching uuid" because of missing vif event from
  linuxbridge agent

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

Bug description:
  This happened in master (Queens) in tempest-linuxbridge job:

  http://logs.openstack.org/56/534456/1/check/neutron-tempest-
  linuxbridge/7693ca5/logs/testr_results.html.gz

  From tempest log:

  Traceback (most recent call last):
File "tempest/api/compute/security_groups/test_security_groups.py", line 
105, in test_server_security_groups
  'ACTIVE')
File "tempest/common/waiters.py", line 96, in wait_for_server_status
  raise lib_exc.TimeoutException(message)
  tempest.lib.exceptions.TimeoutException: Request timed out
  Details: (SecurityGroupsTestJSON:test_server_security_groups) Server 
dd2ec3b0-f909-4104-ae2a-9b878d936ed4 failed to reach ACTIVE status and task 
state "None" within the required time (196 s). Current status: HARD_REBOOT. 
Current task state: reboot_started_hard.

  In nova-compute log, we see this:

  Jan 19 10:38:37.869397 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
WARNING nova.virt.libvirt.driver [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Timeout waiting 
for vif plugging callback for instance with vm_state active and task_state 
reboot_started_hard.: Timeout: 300 seconds
  Jan 19 10:38:37.880789 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
DEBUG nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Checking state 
{{(pid=28907) _get_power_state 
/opt/stack/new/nova/nova/compute/manager.py:1183}}
  Jan 19 10:38:37.885265 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Cannot reboot 
instance: Domain not found: no domain with matching uuid 
'dd2ec3b0-f909-4104-ae2a-9b878d936ed4' (instance-0023): libvirtError: 
Domain not found: no domain with matching uuid 
'dd2ec3b0-f909-4104-ae2a-9b878d936ed4' (instance-0023)
  Jan 19 10:38:37.981484 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
DEBUG nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Instance has 
been destroyed from under us while trying to set it to ERROR {{(pid=28907) 
_set_instance_obj_error_state /opt/stack/new/nova/nova/compute/manager.py:586}}
  Jan 19 10:38:38.150498 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] Exception during message handling: libvirtError: Domain not 
found: no domain with matching uuid

[Yahoo-eng-team] [Bug 1747001] Re: Use of parse.urlencode with dict in nova/tests/unit/scheduler/client/test_report.py can result in unpredictable query strings and thus unreliable tests

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/540420
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=cab811b89030d6e49f8ef85e29783fce94c763fc
Submitter: Zuul
Branch:master

commit cab811b89030d6e49f8ef85e29783fce94c763fc
Author: Chris Dent 
Date:   Fri Feb 2 15:34:59 2018 +

Don't rely on parse.urlencode in url comparisons

The tests for allocation_candidates query parameters in test_report.py
relied on urlencode with a dict arg to create the expected_url that is
compared with the actual URL that the report client creates when
communicating with the placement service.

This is risky because the ordering of the query parameters is
not reliable when the source data is a dict. This change expands
the tests where it was used to do more explicit comparisons.

Change-Id: I2e51a4574b20c0634ad83a53c0e68261bbf0ac82
Closes-Bug: #1747001


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

Title:
  Use of parse.urlencode with dict in
  nova/tests/unit/scheduler/client/test_report.py can result in
  unpredictable query strings and thus unreliable tests

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  In nova/tests/unit/scheduler/client/test_report.py there are several
  tests which confirm the URLs that get passed to the placement service.
  These create query strings by using code like:

  expected_url = '/allocation_candidates?%s' % parse.urlencode(
  {'resources': 'MEMORY_MB:1024,VCPU:1',
   'required': 'CUSTOM_TRAIT1',
   'limit': 1000})

  This results in a query string that will have an unpredictable order.
  Similarly, the code which is doing the actual query string creation is
  using the same form.

  Most of the time the results are the same, and the tests pass, but
  sometimes they do not.

  There are at least two potential ways to work around this:

  * build the query strings using a sequence of tuples and set the 'doseq' 
param to urlencode to True. This will preserve order.
  * Parse the expected_url's query params in the tests back to a dict and 
compare dicts

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747001/+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 1744361] Re: test_server_security_groups failed to reboot with "Domain not found: no domain with matching uuid" because of missing vif event from linuxbridge agent

2018-02-02 Thread Matt Riedemann 
We'll also have to backport the nova change to stable/pike since we
merged this which caused the regression:

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

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

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

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

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

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

Title:
  test_server_security_groups failed to reboot with "Domain not found:
  no domain with matching uuid" because of missing vif event from
  linuxbridge agent

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

Bug description:
  This happened in master (Queens) in tempest-linuxbridge job:

  http://logs.openstack.org/56/534456/1/check/neutron-tempest-
  linuxbridge/7693ca5/logs/testr_results.html.gz

  From tempest log:

  Traceback (most recent call last):
File "tempest/api/compute/security_groups/test_security_groups.py", line 
105, in test_server_security_groups
  'ACTIVE')
File "tempest/common/waiters.py", line 96, in wait_for_server_status
  raise lib_exc.TimeoutException(message)
  tempest.lib.exceptions.TimeoutException: Request timed out
  Details: (SecurityGroupsTestJSON:test_server_security_groups) Server 
dd2ec3b0-f909-4104-ae2a-9b878d936ed4 failed to reach ACTIVE status and task 
state "None" within the required time (196 s). Current status: HARD_REBOOT. 
Current task state: reboot_started_hard.

  In nova-compute log, we see this:

  Jan 19 10:38:37.869397 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
WARNING nova.virt.libvirt.driver [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Timeout waiting 
for vif plugging callback for instance with vm_state active and task_state 
reboot_started_hard.: Timeout: 300 seconds
  Jan 19 10:38:37.880789 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
DEBUG nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Checking state 
{{(pid=28907) _get_power_state 
/opt/stack/new/nova/nova/compute/manager.py:1183}}
  Jan 19 10:38:37.885265 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Cannot reboot 
instance: Domain not found: no domain with matching uuid 
'dd2ec3b0-f909-4104-ae2a-9b878d936ed4' (instance-0023): libvirtError: 
Domain not found: no domain with matching uuid 
'dd2ec3b0-f909-4104-ae2a-9b878d936ed4' (instance-0023)
  Jan 19 10:38:37.981484 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
DEBUG nova.compute.manager [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] [instance: dd2ec3b0-f909-4104-ae2a-9b878d936ed4] Instance has 
been destroyed from under us while trying to set it to ERROR {{(pid=28907) 
_set_instance_obj_error_state /opt/stack/new/nova/nova/compute/manager.py:586}}
  Jan 19 10:38:38.150498 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server [None req-838e0ebe-afe5-4cca-abcc-4ba116889cba 
service nova] Exception during message handling: libvirtError: Domain not 
found: no domain with matching uuid 'dd2ec3b0-f909-4104-ae2a-9b878d936ed4' 
(instance-0023)
  Jan 19 10:38:38.150813 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server Traceback (most recent call last):
  Jan 19 10:38:38.151125 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 
163, in _process_incoming
  Jan 19 10:38:38.151388 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message)
  Jan 19 10:38:38.151668 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
220, in dispatch
  Jan 19 10:38:38.151939 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, 
ctxt, args)
  Jan 19 10:38:38.152205 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
190, in _do_dispatch
  Jan 19 10:38:38.152491 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args)
  Jan 19 10:38:38.152705 ubuntu-xenial-rax-iad-0002010825 nova-compute[28907]: 
ERROR

[Yahoo-eng-team] [Bug 1745572] Re: ml2 mechanism is call again if it calls continue binding

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/530357
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=892c1ec6900c7834964dd912cadab5d7ee3d4f62
Submitter: Zuul
Branch:master

commit 892c1ec6900c7834964dd912cadab5d7ee3d4f62
Author: Bo Chi 
Date:   Thu Dec 28 21:35:31 2017 +0800

fix same mechanism driver called twice bug

when a mechinism driver calls context.continue_binding to
continue binding, it will be called again because
_check_driver_to_bind compares driver name with driver.

Closes-Bug: #1745572
Change-Id: I62b32c9b9d01dd929fe8cd3634c78dc0cbe325b6


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

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

Title:
  ml2 mechanism is call again if it calls continue binding

Status in neutron:
  Fix Released

Bug description:
  if there're multiple mechanism driver configured, and the first driver
  call context.continue_binding at level 0, it will be called again on
  level 1.

  this is because parameter "driver" passed to _check_driver_to_bind is
  not correct, which should be dirver name instead of driver itself

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1745572/+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 1747082] [NEW] OVS-FIREWALL - can't create Loadbalancer when firewall_driver = openvswitch

2018-02-02 Thread Yossi Boaron 
Public bug reported:


steps to reproduce: 
=

A. Download the following local.conf file
:https://github.com/openstack/octavia/blob/master/devstack/samples/singlenode/local.conf

B. Add the following at end of above file  (set ML2 firewall_driver to
OVS)

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[securitygroup]
firewall_driver = openvswitch

C. Deploy devstack

D. Create LoadBalancer:

  openstack loadbalancer create --vip-subnet-id private-subnet --name
tst_lb


 
Observations :
==

A. Loadbalancer is stuck in ‘Provisioning_status’ = 'PENDING_UPDATE'.

B. Disable port security of Amaphora's 'lb-mgmt-net' port - solved the
problem

C. Based on Octavia's experts  feedback [1] , seems like the  bug is
solely in ovs-firewall .

“The issue is that one port is placed directly at the hypervisor while
ovs firewall works with VM ports only”


[1] - https://storyboard.openstack.org/#!/story/2001426

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

Title:
  OVS-FIREWALL - can't create Loadbalancer when firewall_driver =
  openvswitch

Status in neutron:
  New

Bug description:
  
  steps to reproduce: 
  =

  A. Download the following local.conf file
  
:https://github.com/openstack/octavia/blob/master/devstack/samples/singlenode/local.conf

  B. Add the following at end of above file  (set ML2 firewall_driver to
  OVS)

  [[post-config|/$Q_PLUGIN_CONF_FILE]]
  [securitygroup]
  firewall_driver = openvswitch

  C. Deploy devstack

  D. Create LoadBalancer:

openstack loadbalancer create --vip-subnet-id private-subnet --name
  tst_lb

  
   
  Observations :
  ==

  A. Loadbalancer is stuck in ‘Provisioning_status’ = 'PENDING_UPDATE'.

  B. Disable port security of Amaphora's 'lb-mgmt-net' port - solved the
  problem

  C. Based on Octavia's experts  feedback [1] , seems like the  bug is
  solely in ovs-firewall .

  “The issue is that one port is placed directly at the hypervisor while
  ovs firewall works with VM ports only”

  
  [1] - https://storyboard.openstack.org/#!/story/2001426

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1747082/+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 1747070] [NEW] ds-identify does not see nocloud seed in core snap

2018-02-02 Thread Scott Moser 
Public bug reported:

If ubuntu-image is built with cloud-config, it puts data into 
/writable/system-data/var/lib/cloud.
That directory is then bind mounted to /var/lib/cloud via /etc/fstab etnry like:
  /writable/system-data/var/lib/cloud /var/lib/cloud none bind 0 0


ds-identify, which is run from 
/lib/systemd/system-generators/cloud-init-generator runs before /var/lib/cloud 
bind mount is done, so it does not see the seed.

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

Title:
  ds-identify does not see nocloud seed in core snap

Status in cloud-init:
  New

Bug description:
  If ubuntu-image is built with cloud-config, it puts data into 
/writable/system-data/var/lib/cloud.
  That directory is then bind mounted to /var/lib/cloud via /etc/fstab etnry 
like:
/writable/system-data/var/lib/cloud /var/lib/cloud none bind 0 0

  
  ds-identify, which is run from 
/lib/systemd/system-generators/cloud-init-generator runs before /var/lib/cloud 
bind mount is done, so it does not see the seed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1747070/+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 1747063] [NEW] TestProviderOperations.test_get_allocation_candidates randomly fails AssertionError because of hash seed

2018-02-02 Thread Matt Riedemann 
Public bug reported:

Seen here:

http://logs.openstack.org/89/532689/6/gate/openstack-tox-py35/825fbb9
/job-output.txt.gz#_2018-02-02_17_02_50_361819

2018-02-02 17:02:50.361819 | ubuntu-xenial | 
nova.tests.unit.scheduler.client.test_report.TestProviderOperations.test_get_allocation_candidates
2018-02-02 17:02:50.361939 | ubuntu-xenial | 
--
2018-02-02 17:02:50.361957 | ubuntu-xenial |
2018-02-02 17:02:50.361998 | ubuntu-xenial | Captured pythonlogging:
2018-02-02 17:02:50.362069 | ubuntu-xenial | ~~~
2018-02-02 17:02:50.362259 | ubuntu-xenial | b'2018-02-02 17:00:28,797 
WARNING [oslo_config.cfg] Config option key_manager.api_class  is deprecated. 
Use option key_manager.backend instead.'
2018-02-02 17:02:50.362423 | ubuntu-xenial | b"2018-02-02 17:00:28,811 
WARNING [nova.scheduler.utils] Only (required) traits are supported. Received 
'preferred' for key traitNone."
2018-02-02 17:02:50.362478 | ubuntu-xenial | b''
2018-02-02 17:02:50.362502 | ubuntu-xenial |
2018-02-02 17:02:50.362546 | ubuntu-xenial | Captured traceback:
2018-02-02 17:02:50.362584 | ubuntu-xenial | ~~~
2018-02-02 17:02:50.362643 | ubuntu-xenial | b'Traceback (most recent call 
last):'
2018-02-02 17:02:50.362821 | ubuntu-xenial | b'  File 
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/unit/scheduler/client/test_report.py",
 line 1512, in test_get_allocation_candidates'
2018-02-02 17:02:50.362919 | ubuntu-xenial | b"expected_url, 
raise_exc=False, microversion='1.17')"
2018-02-02 17:02:50.363092 | ubuntu-xenial | b'  File 
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/mock/mock.py",
 line 948, in assert_called_once_with'
2018-02-02 17:02:50.363179 | ubuntu-xenial | b'return 
self.assert_called_with(*args, **kwargs)'
2018-02-02 17:02:50.363368 | ubuntu-xenial | b'  File 
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/mock/mock.py",
 line 937, in assert_called_with'
2018-02-02 17:02:50.363461 | ubuntu-xenial | b'
six.raise_from(AssertionError(_error_message(cause)), cause)'
2018-02-02 17:02:50.363536 | ubuntu-xenial | b'  File "", line 3, 
in raise_from'
2018-02-02 17:02:50.363742 | ubuntu-xenial | b"AssertionError: Expected 
call: 
get('/allocation_candidates?resources=MEMORY_MB%3A1024%2CVCPU%3A1=CUSTOM_TRAIT1=1000',
 microversion='1.17', raise_exc=False)"
2018-02-02 17:02:50.363922 | ubuntu-xenial | b"Actual call: 
get('/allocation_candidates?resources=MEMORY_MB%3A1024%2CVCPU%3A1=1000=CUSTOM_TRAIT1',
 microversion='1.17', raise_exc=False)"
2018-02-02 17:02:50.363947 | ubuntu-xenial | b''

It's failing because we're getting random results of the entries in the
query string params.

** Affects: nova
 Importance: High
 Status: Triaged


** Tags: placement testing

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

Title:
  TestProviderOperations.test_get_allocation_candidates randomly fails
  AssertionError because of hash seed

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Seen here:

  http://logs.openstack.org/89/532689/6/gate/openstack-tox-py35/825fbb9
  /job-output.txt.gz#_2018-02-02_17_02_50_361819

  2018-02-02 17:02:50.361819 | ubuntu-xenial | 
nova.tests.unit.scheduler.client.test_report.TestProviderOperations.test_get_allocation_candidates
  2018-02-02 17:02:50.361939 | ubuntu-xenial | 
--
  2018-02-02 17:02:50.361957 | ubuntu-xenial |
  2018-02-02 17:02:50.361998 | ubuntu-xenial | Captured pythonlogging:
  2018-02-02 17:02:50.362069 | ubuntu-xenial | ~~~
  2018-02-02 17:02:50.362259 | ubuntu-xenial | b'2018-02-02 17:00:28,797 
WARNING [oslo_config.cfg] Config option key_manager.api_class  is deprecated. 
Use option key_manager.backend instead.'
  2018-02-02 17:02:50.362423 | ubuntu-xenial | b"2018-02-02 17:00:28,811 
WARNING [nova.scheduler.utils] Only (required) traits are supported. Received 
'preferred' for key traitNone."
  2018-02-02 17:02:50.362478 | ubuntu-xenial | b''
  2018-02-02 17:02:50.362502 | ubuntu-xenial |
  2018-02-02 17:02:50.362546 | ubuntu-xenial | Captured traceback:
  2018-02-02 17:02:50.362584 | ubuntu-xenial | ~~~
  2018-02-02 17:02:50.362643 | ubuntu-xenial | b'Traceback (most recent 
call last):'
  2018-02-02 17:02:50.362821 | ubuntu-xenial | b'  File 
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/unit/scheduler/client/test_report.py",
 line 1512, in test_get_allocation_candidates'
  2018-02-02 17:02:50.362919 | ubuntu-xenial | b"expected_url, 
raise_exc=False,

[Yahoo-eng-team] [Bug 1485578] Re: It is not possible to select AZ for new Cinder volume during the VM creation

2018-02-02 Thread Akihiro Motoki 
In my understanding, the only way is to create a volume in advance and
then launch an instance with a precreated volume.

When considering how to fix it, we need to care whether cross AZ attach is 
allowed or not.
- In case of cross AZ attach is not allowed, a volume should be created with a 
same name as Nova AZ.
- In case of cross AZ attach is allowed, we need to provide a way to specify a 
volume AZ.

Right?


** Changed in: horizon
   Status: Invalid => 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/1485578

Title:
  It is not possible to select AZ for new Cinder volume during the VM
  creation

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Steps To Reproduce:
  1. Deploy OpenStack cluster with several Nova availability zones, for 
example, 'nova1' and 'nova2' and with several Cinder availability zones, for 
example, 'storage1' and 'storage2' (availability zones for Nova and Cinder 
should be different).
  2. Login to Horizon dashboard and navigate to Project > Instances
  3. Click on 'Launch Instance' button
  4. Set all required parameters, select Nova AZ 'nova1' for new VM and select 
Instance Boot Source = "Boot from image (creates new volume)"
  5. Click on 'Launch' button

  Observed Result:
  Instance will fail with "Failure prepping block device" error (please see 
attached screenshot horizon_az_bug.png)

  Expected Result:
  As a user I expect that Horizon UI will provide me the ability to select the 
availability zone for new volume if I want to create new volume and boot VM 
from it. We can't use Nova AZ as availability zone for Cinder volume because 
these zones are different availability zones (we can have, for example, 1 Nova 
availability zones and many Cinder availability zone or one Cinder AZ and many 
Nova AZs - it depends on users needs).

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1485578/+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 1746977] Re: The VNIC Type parameter is invalid on project creation port page

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/540353
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=17b2c25d50d977ac07c98bc4907ea09b1dec66c7
Submitter: Zuul
Branch:master

commit 17b2c25d50d977ac07c98bc4907ea09b1dec66c7
Author: wei.ying 
Date:   Thu Feb 1 23:37:26 2018 +0800

Missing VNIC type parameter when using it to create a port

In the project creation port page, regardless of the choice of VNIC
Type, the created port VNIC Type is displayed as Normal, since the
creation port does not specify the 'binding__vnic_type' parameter.

Change-Id: I29700b29e163363dbd7c85a2d5c68c8a6b635ee6
Closes-Bug:#1746977


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

Title:
  The VNIC Type  parameter is invalid on project creation port page

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Env: devstack master branch

  Steps to reproduce:
  1. Go to Porject/Networks panel.
  2. Click on the name of an existing network and select the ports tab.
  3. Click the "Create Port" button and select VNIC Type as Bare Metal.

  After the port is created, click the port name to view the VNIC Type
  display as Normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1746977/+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 1744394] Re: test_distributed_port_binding_deleted_by_port_deletion failed due to warnings during port binding delete

2018-02-02 Thread Armando Migliaccio 
** Changed in: neutron
   Status: Fix Committed => Fix Released

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

Title:
  test_distributed_port_binding_deleted_by_port_deletion failed due to
  warnings during port binding delete

Status in neutron:
  Fix Released

Bug description:
  http://logs.openstack.org/56/534456/1/check/openstack-tox-
  py35/151aefe/testr_results.html.gz (Queens)

  ft1.6: 
neutron.tests.unit.plugins.ml2.test_db.Ml2DvrDBTestCase.test_distributed_port_binding_deleted_by_port_deletion_StringException:
 Traceback (most recent call last):
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/tests/base.py", 
line 132, in func
  return f(self, *args, **kwargs)
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/tests/unit/plugins/ml2/test_db.py",
 line 438, in test_distributed_port_binding_deleted_by_port_deletion
  self.assertEqual([], warning_list)
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
 line 411, in assertEqual
  self.assertThat(observed, matcher, message)
File 
"/home/zuul/src/git.openstack.org/openstack/neutron/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
 line 498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: !=:
  reference = []
  actual= [,
   ]

  It's not clear which warnings those objects are (we may extend the
  test to expose those on failure).

  The failure itself may be related to OVO adoption for port bindings
  that landed lately: https://review.openstack.org/407868

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1744394/+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 1742505] Re: gre_sys set to default 1472 when using path_mtu > 1500 with ovs 2.8.x

2018-02-02 Thread Launchpad Bug Tracker 
This bug was fixed in the package openvswitch - 2.8.1-0ubuntu3

---
openvswitch (2.8.1-0ubuntu3) bionic; urgency=medium

  * Updates to systemd configuration:
- Move to distinct units for ovsdb-server and ovs-vswitchd.
  * Drop obsolete upstart configuration file.
  * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
  * d/control: Bump minimum debhelper version to 10, drop BD on
dh-systemd.
  * d/p/dpif-kernel-gre-mtu-workaround.patch,
d/p/dpif-netlink-rtnl-Use-65000-instead-of-65535-as-tunnel-MTU.patch:
Cherry pick in-flight fixes for workaround to correctly set MTU
of GRE devices via netlink (LP: #1742505).

 -- James Page   Thu, 18 Jan 2018 15:26:41 +0200

** Changed in: openvswitch (Ubuntu Bionic)
   Status: In Progress => Fix Released

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

Title:
  gre_sys set to default 1472 when using path_mtu > 1500 with ovs 2.8.x

Status in Ubuntu Cloud Archive:
  In Progress
Status in Ubuntu Cloud Archive pike series:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  In Progress
Status in neutron:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Fix Released
Status in linux source package in Artful:
  Confirmed
Status in openvswitch source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Confirmed
Status in openvswitch source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  OpenStack Clouds using GRE overlay tunnels with > 1500 MTU's will observe 
packet fragmentation/networking issues for traffic in overlay networks.

  [Test Case]
  Deploy OpenStack Pike (xenial + pike UCA or artful)
  Create tenant networks using GRE segmentation
  Boot instances
  Instance networking will be broken/slow

  gre_sys devices will be set to mtu=1472 on hypervisor hosts.

  [Regression Potential]
  Minimal; the fix to OVS works around an issue for GRE tunnel port setup via 
rtnetlink by performing a second request once the gre device is setup to set 
the MTU to a high value (65000).

  
  [Original Bug Report]
  Setup:
  Pike neutron 11.0.2-0ubuntu1.1~cloud0
  OVS 2.8.0
  Jumbo frames setttings per: 
https://docs.openstack.org/mitaka/networking-guide/config-mtu.html
  global_physnet_mtu = 9000
  path_mtu = 9000

  Symptoms:
  gre_sys MTU is 1472
  Instances with MTUs > 1500 fail to communicate across GRE

  Temporary Workaround:
  ifconfig gre_sys MTU 9000
  Note: When ovs rebuilds tunnels, such as on a restart, gre_sys MTU is set 
back to default 1472.

  Note: downgrading from OVS 2.8.0 to 2.6.1 resolves the issue.

  Previous behavior:
  With Ocata or Pike and OVS 2.6.x
  gre_sys MTU defaults to 65490
  It remains at 65490 through restarts.

  This may be related to some combination of the following changes in OVS which 
seem to imply MTUs must be set in the ovs database for tunnel interfaces and 
patches:
  
https://github.com/openvswitch/ovs/commit/8c319e8b73032e06c7dd1832b3b31f8a1189dcd1
  
https://github.com/openvswitch/ovs/commit/3a414a0a4f1901ba015ec80b917b9fb206f3c74f
  
https://github.com/openvswitch/ovs/blob/6355db7f447c8e83efbd4971cca9265f5e0c8531/datapath/vport-internal_dev.c#L186

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1742505/+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 1741051] Re: Views accessible via url even if user doesn't match policy rules

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/530928
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=3f585d3b1efca1b2379d6c0a80246fd6e5a87640
Submitter: Zuul
Branch:master

commit 3f585d3b1efca1b2379d6c0a80246fd6e5a87640
Author: David Gutman 
Date:   Wed Jan 3 14:25:46 2018 +0100

Views accessible via url even if user doesn't match policy rules

When a user doesn't match the policy rules of a panel then the panel tab
is removed from the menu of the left, but panel views are still
accessible using directly the url (ex /admin/flavors/).

In most of the case, views won't work correctly because of the lack of
right in the backend, but it may cause trouble when you play with
policies.

I think it could be more elegant to return directly a "You are not
authorized to access this page" from the frontend when user try to
access a view of a panel (via url) without matching the policy rules.

Change-Id: I7bc93fed29568adfc14d5bcadfc8728d3b5cf633
Closes-Bug: #1741051


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

Title:
  Views accessible via url even if user doesn't match policy rules

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  When a user doesn't match the policy rules of a panel then the panel
  tab is removed from the menu of the left, but panel views are still
  accessible using directly the url (ex /admin/flavors/).

  In most of the case, views won't work correctly because of the lack of
  right in the backend, but it may cause trouble when you play with
  policies.

  I think it could be more elegant to return directly a "You are not
  authorized to access this page" from the frontend when user try to
  access a view of a panel (via url) without matching the policy rules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1741051/+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 1747000] [NEW] Use of parse.urlencode with dict in nova/tests/unit/scheduler/client/test_report.py can result in unpredictable query strings and thus unreliable tests

2018-02-02 Thread Chris Dent 
Public bug reported:

In nova/tests/unit/scheduler/client/test_report.py there are several
tests which confirm the URLs that get passed to the placement service.
These create query strings by using code like:

expected_url = '/allocation_candidates?%s' % parse.urlencode(
{'resources': 'MEMORY_MB:1024,VCPU:1',
 'required': 'CUSTOM_TRAIT1',
 'limit': 1000})

This results in a query string that will have an unpredictable order.
Similarly, the code which is doing the actual query string creation is
using the same form.

Most of the time the results are the same, and the tests pass, but
sometimes they do not.

There are at least two potential ways to work around this:

* build the query strings using a sequence of tuples and set the 'doseq' param 
to urlencode to True. This will preserve order.
* Parse the expected_url's query params in the tests back to a dict and compare 
dicts

** Affects: nova
 Importance: Low
 Status: Triaged


** Tags: placement scheduler

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

Title:
  Use of parse.urlencode with dict in
  nova/tests/unit/scheduler/client/test_report.py can result in
  unpredictable query strings and thus unreliable tests

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  In nova/tests/unit/scheduler/client/test_report.py there are several
  tests which confirm the URLs that get passed to the placement service.
  These create query strings by using code like:

  expected_url = '/allocation_candidates?%s' % parse.urlencode(
  {'resources': 'MEMORY_MB:1024,VCPU:1',
   'required': 'CUSTOM_TRAIT1',
   'limit': 1000})

  This results in a query string that will have an unpredictable order.
  Similarly, the code which is doing the actual query string creation is
  using the same form.

  Most of the time the results are the same, and the tests pass, but
  sometimes they do not.

  There are at least two potential ways to work around this:

  * build the query strings using a sequence of tuples and set the 'doseq' 
param to urlencode to True. This will preserve order.
  * Parse the expected_url's query params in the tests back to a dict and 
compare dicts

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747000/+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 1747001] [NEW] Use of parse.urlencode with dict in nova/tests/unit/scheduler/client/test_report.py can result in unpredictable query strings and thus unreliable tests

2018-02-02 Thread Chris Dent 
Public bug reported:

In nova/tests/unit/scheduler/client/test_report.py there are several
tests which confirm the URLs that get passed to the placement service.
These create query strings by using code like:

expected_url = '/allocation_candidates?%s' % parse.urlencode(
{'resources': 'MEMORY_MB:1024,VCPU:1',
 'required': 'CUSTOM_TRAIT1',
 'limit': 1000})

This results in a query string that will have an unpredictable order.
Similarly, the code which is doing the actual query string creation is
using the same form.

Most of the time the results are the same, and the tests pass, but
sometimes they do not.

There are at least two potential ways to work around this:

* build the query strings using a sequence of tuples and set the 'doseq' param 
to urlencode to True. This will preserve order.
* Parse the expected_url's query params in the tests back to a dict and compare 
dicts

** Affects: nova
 Importance: Low
 Status: Triaged


** Tags: placement scheduler

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

Title:
  Use of parse.urlencode with dict in
  nova/tests/unit/scheduler/client/test_report.py can result in
  unpredictable query strings and thus unreliable tests

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  In nova/tests/unit/scheduler/client/test_report.py there are several
  tests which confirm the URLs that get passed to the placement service.
  These create query strings by using code like:

  expected_url = '/allocation_candidates?%s' % parse.urlencode(
  {'resources': 'MEMORY_MB:1024,VCPU:1',
   'required': 'CUSTOM_TRAIT1',
   'limit': 1000})

  This results in a query string that will have an unpredictable order.
  Similarly, the code which is doing the actual query string creation is
  using the same form.

  Most of the time the results are the same, and the tests pass, but
  sometimes they do not.

  There are at least two potential ways to work around this:

  * build the query strings using a sequence of tuples and set the 'doseq' 
param to urlencode to True. This will preserve order.
  * Parse the expected_url's query params in the tests back to a dict and 
compare dicts

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747001/+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 1732294] Re: Probable DOS in linuxbridge

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/520249
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=08108c41992a13c6959b717cccfe2b929e55d2eb
Submitter: Zuul
Branch:master

commit 08108c41992a13c6959b717cccfe2b929e55d2eb
Author: Brian Haley 
Date:   Wed Nov 15 19:24:22 2017 -0500

Move Linuxbridge ARP spoofing to nat table PREROUTING chain

It was found that adding ebtables rules to the filter table
FORWARD chain could be vulnerable to a DoS attack.  Moving
to the nat table PREROUTING chain should mitigate this as
it is consulted prior to allowing the frame in.

In order to make this work with upgrades, had to make the code
detect and remove any old rules that might still exist in
the filter table.  That can be removed after a cycle.

Added some unit tests in addition to the existing functional
tests.

Change-Id: I87852b21db4404c58c83789cc267812030ac7d5f
Closes-bug: #1732294


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

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

Title:
  Probable DOS in linuxbridge

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  We experienced a DOS yesterday on a system (not openstack based) which
  would have been mitigated if a mac address whitelist in ebtables had
  occurred in the nat PREROUTING chain rather than the filter FORWARD
  chain.

  At least with kernel version 4.9, with rapidly cycling mac addresses
  the linux bridge appears to get bogged down in learning new MAC
  addresses if this is not explicitly turned off with brctl setageing
   0.

  We deployed a workaround to our own infrastructure but I believe
  
https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/linuxbridge/agent/arp_protect.py#n158
  means that openstack has the same vulnerability.

  It should be possible to move all logic related to checking the input
  to the ebtables nat PREROUTING chain using the ebtables_nat module.

  To duplicate, in a VM on a host with bridged networking and mac
  spoofing protection in place, install dsniff and run:

  macof -i  -s  -d  -n
  5000 &> /dev/null

  Observe on the host that ksoftirqd usage goes to near 100% on one
  core, that 'perf top' will show br_fdb_update as taking significant
  resources, and that 'brctl showmacs ' will probably hang.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1732294/+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 1747028] [NEW] Segments extension documentation does not explain why you would want to use it

2018-02-02 Thread Ian Wells 
Public bug reported:

https://docs.openstack.org/neutron/pike/contributor/internals/segments.html

The segments extension says 'this lets you operate on segments',
basically.  It doesn't say what a segment is (or refer to external
documentation that does) and it does not say why you might want an API
to operate on them, nor what that API is.  So it doesn't tell me what I
would want this service plugin for or how I would use it if I worked out
that I wanted it.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc

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

Title:
  Segments extension documentation does not explain why you would want
  to use it

Status in neutron:
  New

Bug description:
  https://docs.openstack.org/neutron/pike/contributor/internals/segments.html

  The segments extension says 'this lets you operate on segments',
  basically.  It doesn't say what a segment is (or refer to external
  documentation that does) and it does not say why you might want an API
  to operate on them, nor what that API is.  So it doesn't tell me what
  I would want this service plugin for or how I would use it if I worked
  out that I wanted it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1747028/+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 1598282] Re: location strategy config shouldn't be ristricted

2018-02-02 Thread Brian Rosmaita 
The patch to fix this issue has been abandoned, so moving this to
"Opinion".  Not moving it to "Won't Fix" because I personally am still
sympathetic to this change!  Anyone interested should read through the
discussion on https://review.openstack.org/#/c/268865/ and then put it
on the agenda for the weekly Glance meeting.

** Changed in: glance
   Status: In Progress => Opinion

** Changed in: glance
 Assignee: Feilong Wang (flwang) => (unassigned)

** Summary changed:

- location strategy config shouldn't be ristricted
+ location strategy config shouldn't be restricted

** Description changed:

- The idea of location strategy is allowing cloud provider can add a
- customized location strategy. That said, no code change should be
- involved. But seems it's not true for this case.
+ NOTE: Anyone interested in this issue should read through the discussion
+ on https://review.openstack.org/#/c/268865/ and then put it on the
+ agenda for the weekly Glance meeting.
+ 
+ ---
+ The idea of location strategy is allowing cloud provider can add a customized 
location strategy. That said, no code change should be involved. But seems it's 
not true for this case.
  
  See
  
https://github.com/openstack/glance/blob/master/glance/common/location_strategy/__init__.py#L26

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

Title:
  location strategy config shouldn't be restricted

Status in Glance:
  Opinion

Bug description:
  NOTE: Anyone interested in this issue should read through the
  discussion on https://review.openstack.org/#/c/268865/ and then put it
  on the agenda for the weekly Glance meeting.

  ---
  The idea of location strategy is allowing cloud provider can add a customized 
location strategy. That said, no code change should be involved. But seems it's 
not true for this case.

  See
  
https://github.com/openstack/glance/blob/master/glance/common/location_strategy/__init__.py#L26

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1598282/+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 1747003] [NEW] A bad _RC_CACHE can rarely cause unit tests to fail

2018-02-02 Thread Chris Dent 
Public bug reported:

Very rarely (so rarely in fact that it only seems to happen when test
order is much different from the norm) some unit tests which encounter
the resource_class_cache can fail as follows:

http://logs.openstack.org/49/540049/2/check/openstack-tox-
py27/176a6b3/testr_results.html.gz

-=-=-
ft1.1: 
nova.tests.unit.cmd.test_status.TestUpgradeCheckResourceProviders.test_check_resource_providers_no_compute_rps_one_compute_StringException:
 pythonlogging:'': {{{2018-02-02 11:30:00,443 WARNING [oslo_config.cfg] Config 
option key_manager.api_class  is deprecated. Use option key_manager.backend 
instead.}}}

Traceback (most recent call last):
  File "nova/tests/unit/cmd/test_status.py", line 588, in 
test_check_resource_providers_no_compute_rps_one_compute
self._create_resource_provider(FAKE_IP_POOL_INVENTORY)
  File "nova/tests/unit/cmd/test_status.py", line 561, in 
_create_resource_provider
rp.set_inventory(inv_list)
  File "nova/api/openstack/placement/objects/resource_provider.py", line 737, 
in set_inventory
exceeded = _set_inventory(self._context, self, inv_list)
  File 
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
 line 986, in wrapper
return fn(*args, **kwargs)
  File "nova/api/openstack/placement/objects/resource_provider.py", line 372, 
in _set_inventory
_add_inventory_to_provider(context, rp, inv_list, to_add)
  File "nova/api/openstack/placement/objects/resource_provider.py", line 201, 
in _add_inventory_to_provider
if inv_record.capacity <= 0:
AttributeError: 'NoneType' object has no attribute 'capacity'
-=-=-

The find() method on InventoryList can return None if that cache is bad.

This can be resolved (apparently) by resetting the _RC_CACHE between
test runs in the same way that _TRAITS_SYNCED is reset, in nova/test.py:

-# Reset the traits sync flag
-objects.resource_provider._TRAITS_SYNCED = False
+# Reset the traits sync flag and rc cache
+resource_provider._TRAITS_SYNCED = False
+resource_provider._RC_CACHE = None

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: placement scheduler

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

Title:
  A bad _RC_CACHE can rarely cause unit tests to fail

Status in OpenStack Compute (nova):
  New

Bug description:
  Very rarely (so rarely in fact that it only seems to happen when test
  order is much different from the norm) some unit tests which encounter
  the resource_class_cache can fail as follows:

  http://logs.openstack.org/49/540049/2/check/openstack-tox-
  py27/176a6b3/testr_results.html.gz

  -=-=-
  ft1.1: 
nova.tests.unit.cmd.test_status.TestUpgradeCheckResourceProviders.test_check_resource_providers_no_compute_rps_one_compute_StringException:
 pythonlogging:'': {{{2018-02-02 11:30:00,443 WARNING [oslo_config.cfg] Config 
option key_manager.api_class  is deprecated. Use option key_manager.backend 
instead.}}}

  Traceback (most recent call last):
File "nova/tests/unit/cmd/test_status.py", line 588, in 
test_check_resource_providers_no_compute_rps_one_compute
  self._create_resource_provider(FAKE_IP_POOL_INVENTORY)
File "nova/tests/unit/cmd/test_status.py", line 561, in 
_create_resource_provider
  rp.set_inventory(inv_list)
File "nova/api/openstack/placement/objects/resource_provider.py", line 737, 
in set_inventory
  exceeded = _set_inventory(self._context, self, inv_list)
File 
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
 line 986, in wrapper
  return fn(*args, **kwargs)
File "nova/api/openstack/placement/objects/resource_provider.py", line 372, 
in _set_inventory
  _add_inventory_to_provider(context, rp, inv_list, to_add)
File "nova/api/openstack/placement/objects/resource_provider.py", line 201, 
in _add_inventory_to_provider
  if inv_record.capacity <= 0:
  AttributeError: 'NoneType' object has no attribute 'capacity'
  -=-=-

  The find() method on InventoryList can return None if that cache is
  bad.

  This can be resolved (apparently) by resetting the _RC_CACHE between
  test runs in the same way that _TRAITS_SYNCED is reset, in
  nova/test.py:

  -# Reset the traits sync flag
  -objects.resource_provider._TRAITS_SYNCED = False
  +# Reset the traits sync flag and rc cache
  +resource_provider._TRAITS_SYNCED = False
  +resource_provider._RC_CACHE = None

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747003/+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 1746996] Re: bagpipe: IPAllocation DB query failing, engine facade mismatch

2018-02-02 Thread Thomas Morin 
The issue we have seems to be related to the fact that this unit test mixes:
- old engine facade code from networking-bagpipe OVO code
- new engine facade code for IPAllocations

This issue is strongly related to bug 1744829 .

My current understanding is that:
- [2] resulted in the use of OVO for IPAllocations
- networking-bgpvpn then started to make use of OVO, resulting in IPAllocation 
in OVO objects construction (both old engine facade, so all good)
- when [1] merged to revert [2] because of bug 174829, IPAllocation went back 
to non-OVO, hence
using the new engine facade, while we still use OVO to query IPAllocations in 
networking-bagpipe OVO objects

[1] https://review.openstack.org/#/c/536913
[2] https://review.openstack.org/#/c/407868

** Also affects: networking-bagpipe
   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/1746996

Title:
  bagpipe: IPAllocation DB query failing, engine facade mismatch

Status in networking-bgpvpn:
  New
Status in BaGPipe:
  New
Status in neutron:
  New

Bug description:
  
networking_bgpvpn.tests.unit.services.bagpipe.test_bagpipe.TestBagpipeServiceDriverV2RPCs.test_router_itf_event_network_assoc
  is currently failing

  Traceback (most recent call last):
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 260, in registry_router_interface_before_delete
  context, router_id, network_id)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/oslo_log/helpers.py",
 line 67, in wrapper
  return method(*args, **kwargs)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 218, in notify_router_interface_deleted
  network_id=net_id) +
File "neutron/objects/base.py", line 561, in get_objects
  return [cls._load_object(context, db_obj) for db_obj in db_objs]
File "neutron/objects/base.py", line 496, in _load_object
  obj.from_db_object(db_obj)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 156, in from_db_object
  self._load_subnets(obj)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 150, in _load_subnets
  subnets_info = _get_subnets_info(self.obj_context, self.network_id)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 62, in _get_subnets_info
  for subnet in subnets
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 47, in _get_gateway_mac_by_subnet
  port = Port.get_object(obj_context, id=ip_allocation.port_id)
File "neutron/objects/base.py", line 538, in get_object
  return cls._load_object(context, db_obj)
File "neutron/objects/base.py", line 496, in _load_object
  obj.from_db_object(db_obj)
File "neutron/objects/ports.py", line 409, in from_db_object
  super(Port, self).from_db_object(db_obj)
File "neutron/objects/base.py", line 440, in from_db_object
  self.load_synthetic_db_fields(db_obj)
File "neutron/objects/base.py", line 737, in load_synthetic_db_fields
  for obj in synth_db_objs]
File "neutron/objects/base.py", line 498, in _load_object
  context.session.expunge(obj.db_obj)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
 line 1650, in expunge
  state_str(state))
  InvalidRequestError: Instance  is not present 
in this Session

  
  "git bisect" show that neutron commit 
906eda44d2c230be99fc5c61daa0f359ab46a3ad [1] introduces the issue

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1746996/+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 1746996] [NEW] bagpipe: IPAllocation DB query failing, engine facade mismatch

2018-02-02 Thread Thomas Morin 
Public bug reported:

networking_bgpvpn.tests.unit.services.bagpipe.test_bagpipe.TestBagpipeServiceDriverV2RPCs.test_router_itf_event_network_assoc
is currently failing

Traceback (most recent call last):
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 260, in registry_router_interface_before_delete
context, router_id, network_id)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/oslo_log/helpers.py",
 line 67, in wrapper
return method(*args, **kwargs)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 218, in notify_router_interface_deleted
network_id=net_id) +
  File "neutron/objects/base.py", line 561, in get_objects
return [cls._load_object(context, db_obj) for db_obj in db_objs]
  File "neutron/objects/base.py", line 496, in _load_object
obj.from_db_object(db_obj)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 156, in from_db_object
self._load_subnets(obj)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 150, in _load_subnets
subnets_info = _get_subnets_info(self.obj_context, self.network_id)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 62, in _get_subnets_info
for subnet in subnets
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 47, in _get_gateway_mac_by_subnet
port = Port.get_object(obj_context, id=ip_allocation.port_id)
  File "neutron/objects/base.py", line 538, in get_object
return cls._load_object(context, db_obj)
  File "neutron/objects/base.py", line 496, in _load_object
obj.from_db_object(db_obj)
  File "neutron/objects/ports.py", line 409, in from_db_object
super(Port, self).from_db_object(db_obj)
  File "neutron/objects/base.py", line 440, in from_db_object
self.load_synthetic_db_fields(db_obj)
  File "neutron/objects/base.py", line 737, in load_synthetic_db_fields
for obj in synth_db_objs]
  File "neutron/objects/base.py", line 498, in _load_object
context.session.expunge(obj.db_obj)
  File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
 line 1650, in expunge
state_str(state))
InvalidRequestError: Instance  is not present 
in this Session


"git bisect" show that neutron commit 906eda44d2c230be99fc5c61daa0f359ab46a3ad 
[1] introduces the issue

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

** Affects: bgpvpn
 Importance: Undecided
 Status: New

** Affects: networking-bagpipe
 Importance: Undecided
 Status: New

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  bagpipe: IPAllocation DB query failing, engine facade mismatch

Status in networking-bgpvpn:
  New
Status in BaGPipe:
  New
Status in neutron:
  New

Bug description:
  
networking_bgpvpn.tests.unit.services.bagpipe.test_bagpipe.TestBagpipeServiceDriverV2RPCs.test_router_itf_event_network_assoc
  is currently failing

  Traceback (most recent call last):
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 260, in registry_router_interface_before_delete
  context, router_id, network_id)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/oslo_log/helpers.py",
 line 67, in wrapper
  return method(*args, **kwargs)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe_v2.py",
 line 218, in notify_router_interface_deleted
  network_id=net_id) +
File "neutron/objects/base.py", line 561, in get_objects
  return [cls._load_object(context, db_obj) for db_obj in db_objs]
File "neutron/objects/base.py", line 496, in _load_object
  obj.from_db_object(db_obj)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 156, in from_db_object
  self._load_subnets(obj)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/src/networking-bagpipe/networking_bagpipe/objects/bgpvpn.py",
 line 150, in _load_subnets
  subnets_info = _get_subnets_info(self.obj_context, self.network_id)
File

[Yahoo-eng-team] [Bug 1746985] [NEW] Can not specified security groups when creating a port

2018-02-02 Thread wei.ying 
Public bug reported:

Env: devstack master branch

Currently, after a user creates a port through Horizon, the port
security group defaults to 'default', and the user can modify the port's
security group by 'Edit Port' row action.

According to the neutron api doc[1], when creating a port, we can
actually specify security groups as well.

[1] https://developer.openstack.org/api-ref/network/v2/index.html
#create-port

** Affects: horizon
 Importance: Undecided
 Assignee: wei.ying (wei.yy)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => wei.ying (wei.yy)

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

Title:
  Can not specified security groups when creating a port

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Env: devstack master branch

  Currently, after a user creates a port through Horizon, the port
  security group defaults to 'default', and the user can modify the
  port's security group by 'Edit Port' row action.

  According to the neutron api doc[1], when creating a port, we can
  actually specify security groups as well.

  [1] https://developer.openstack.org/api-ref/network/v2/index.html
  #create-port

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1746985/+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 1746977] [NEW] The VNIC Type parameter is invalid on project creation port page

2018-02-02 Thread wei.ying 
Public bug reported:

Env: devstack master branch

Steps to reproduce:
1. Go to Porject/Networks panel.
2. Click on the name of an existing network and select the ports tab.
3. Click the "Create Port" button and select VNIC Type as Bare Metal.

After the port is created, click the port name to view the VNIC Type
display as Normal.

** Affects: horizon
 Importance: Undecided
 Assignee: wei.ying (wei.yy)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => wei.ying (wei.yy)

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

Title:
  The VNIC Type  parameter is invalid on project creation port page

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Env: devstack master branch

  Steps to reproduce:
  1. Go to Porject/Networks panel.
  2. Click on the name of an existing network and select the ports tab.
  3. Click the "Create Port" button and select VNIC Type as Bare Metal.

  After the port is created, click the port name to view the VNIC Type
  display as Normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1746977/+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 1746972] [NEW] After setting the password failed, the VM state is set to error

2018-02-02 Thread yangjie 
Public bug reported:

Description
===
After we execute the command ‘nova set-password’  failed, the virtual machine 
state is set to error，while its power state is still running，we should not 
change vm_state at this situation。

Steps to reproduce
==
1、choose a running VM which was not installed QGA, 
2、execute ‘nova set-password ’
3、the command executed failed, and the vm_state turnned to ERROR.

Expected result
===
command executed failed, vm_state still ACTIVE.

Actual result
=
vm_state turned to ERROR.

Environment
===
Pike 
Nova16.0.4
libvirt & KVM

Logs & Configs
==
[root@E9000slot5 ~(keystone_admin)]# nova set-password 
9f9330c2-4ab4-45f1-a9f9-2770dd34cf30
New password: 
Again: 
ERROR (Conflict): Failed to set admin password on 
9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 because error setting admin password (HTTP 
409) (Request-ID: req-0b533563-132e-42e2-8ef3-5665fa8e7187)

2018-02-02 18:55:06.529 35382 ERROR oslo_messaging.rpc.server 
[req-0b533563-132e-42e2-8ef3-5665fa8e7187 d118d43c722e4cf48be77d6cff727810 3ac8
6e9ee3014040832eae0191490b3f - default default] Exception during message 
handling: InstancePasswordSetFailed: Failed to set admin password on
 9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 because error setting admin password

[root@E9000slot5 ~(keystone_admin)]# nova list 
+--++++-+--+
| ID   | Name   | Status | Task State | Power 
State | Networks |
+--++++-+--+
| 9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 | testyj | ERROR  | -  | Running 
| test=192.168.3.9 |
+--++++-+--+

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

Title:
  After setting the password failed, the VM state is set to error

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  After we execute the command ‘nova set-password’  failed, the virtual machine 
state is set to error，while its power state is still running，we should not 
change vm_state at this situation。

  Steps to reproduce
  ==
  1、choose a running VM which was not installed QGA, 
  2、execute ‘nova set-password ’
  3、the command executed failed, and the vm_state turnned to ERROR.

  Expected result
  ===
  command executed failed, vm_state still ACTIVE.

  Actual result
  =
  vm_state turned to ERROR.

  Environment
  ===
  Pike 
  Nova16.0.4
  libvirt & KVM

  Logs & Configs
  ==
  [root@E9000slot5 ~(keystone_admin)]# nova set-password 
9f9330c2-4ab4-45f1-a9f9-2770dd34cf30
  New password: 
  Again: 
  ERROR (Conflict): Failed to set admin password on 
9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 because error setting admin password (HTTP 
409) (Request-ID: req-0b533563-132e-42e2-8ef3-5665fa8e7187)

  2018-02-02 18:55:06.529 35382 ERROR oslo_messaging.rpc.server 
[req-0b533563-132e-42e2-8ef3-5665fa8e7187 d118d43c722e4cf48be77d6cff727810 3ac8
  6e9ee3014040832eae0191490b3f - default default] Exception during message 
handling: InstancePasswordSetFailed: Failed to set admin password on
   9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 because error setting admin password

  [root@E9000slot5 ~(keystone_admin)]# nova list 
  
+--++++-+--+
  | ID   | Name   | Status | Task State | Power 
State | Networks |
  
+--++++-+--+
  | 9f9330c2-4ab4-45f1-a9f9-2770dd34cf30 | testyj | ERROR  | -  | 
Running | test=192.168.3.9 |
  
+--++++-+--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746972/+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 1746973] [NEW] image format not filled(once again)

2018-02-02 Thread lahari 
Public bug reported:

Create image wizard does not update the format of the image automatically based 
on the extension.
It used to update in mitaka. I'm using pike now and I observe that the format 
field is not automatically filled

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

Title:
  image format not filled(once again)

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Create image wizard does not update the format of the image automatically 
based on the extension.
  It used to update in mitaka. I'm using pike now and I observe that the format 
field is not automatically filled

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1746973/+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 1733365] Re: dvr extension not documented in api-ref

2018-02-02 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/538946
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=9068055d68ced8a46c4b1f7e2f1e930f03f7e793
Submitter: Zuul
Branch:master

commit 9068055d68ced8a46c4b1f7e2f1e930f03f7e793
Author: Michal Kelner Mishali 
Date:   Mon Jan 29 17:25:03 2018 +0200

Adding DVR extension docs in routers api-ref

Closes-Bug: #1733365

Change-Id: I424ec00a5f757b83eb7a8cd208e9e4494b5ed42f
Signed-off-by: Michal Kelner Mishali 


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

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

Title:
  dvr extension not documented in api-ref

Status in neutron:
  Fix Released

Bug description:
  The dvr extension is not documented in our API-ref:
  - The routers api-ref needs to have a subsection for the extension as well as 
included the param(s) the extension adds.

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