[Yahoo-eng-team] [Bug 1570113] Re: compute nodes do not get dvrha router update from server

[Brandon Logan]

Thanks for the update Adolfo.  I'll close this bug.  Feel free to change
the status if you disagree or something new arises.

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

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

Title:
  compute nodes do not get dvrha router update from server

Status in neutron:
  Invalid

Bug description:
  branch: master (April 13th 2016):  commit
  2a305c563073a3066aac3f07aab3c895ec2cd2fb

  Topology: 
  1 controller (neutronserver)
  3 network nodes (l3_agent in dvr_snat mode)
  2 compute nodes (l3_agent in dvr mode)

  behavior: when a dvr/ha router is created and a vm instantiated on the
  compute node, the l3_agent on the compute node does not instantiate a
  local router. (the qr-namespace along with all the interfaces).

  expected: when a dvr/ha router is created and a vm is instantiated on
  a compute node, the l3_agent running on that compute node should
  instantiate a local router.  The qr-router-id namespace along with all
  the appropriate interfaces should be present locally on the compute
  node. Similar in behavior to a dvr only router. (without ha).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570113/+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 1570976] Re: neutronclient is missing help text for the purge command

[Brandon Logan]

** Also affects: python-neutronclient
   Importance: Undecided
   Status: New

** No longer affects: neutron

** Changed in: python-neutronclient
 Assignee: (unassigned) => Tin Lam (tl3438)

** Changed in: python-neutronclient
   Status: New => Confirmed

** Changed in: python-neutronclient
   Importance: Undecided => Low

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

Title:
  neutronclient is missing help text for the purge command

Status in python-neutronclient:
  Confirmed

Bug description:
  stack@devstack-1:~/devstack$ neutron --help
  
    port-update   Update port's information.
    purge
    qos-available-rule-types  List available qos rule types.
  

  stack@devstack-1:~/devstack$ neutron --version
  4.2.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-neutronclient/+bug/1570976/+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 1570892] Re: Openswan/Libreswan: support sha256 for auth algorithm

[Brandon Logan]

** Also affects: openstack-api-site
   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/1570892

Title:
  Openswan/Libreswan: support sha256 for auth algorithm

Status in neutron:
  New
Status in openstack-api-site:
  New

Bug description:
  https://review.openstack.org/303684
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit b73e1002555cfa70ccfea8ffe685672c0b679212
  Author: nick.zhuyj 
  Date:   Fri Apr 8 23:48:33 2016 -0500

  Openswan/Libreswan: support sha256 for auth algorithm
  
  Add support for sha256 as it is requirement from customer.
  Currently, there is no ike/esp fields in strongswan ipsec.conf
  template, so by default. sha256 is used. But for openswan auth
  algorithm is get from configuration, so only sha1 is supported.
  This patch enable Openswan/Libreswan to support sha256.
  
  Note: this change is DocImpact and APIImpact
  
  Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2
  Closes-Bug: #1567846

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570892/+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 1571142] [NEW] Unable to launch instance

[razi ahmed]

Public bug reported:

I tried to launch an instance using the following 
openstack server create --flavor m1.tiny --image cirros   --nic net-id=provider 
--security-group default   --key-name mykey provider-instance
An exception was returned :2016-04-15 22:14:20.324 18294 ERROR 
nova.api.openstack.extensions [req-45fd4baf-2b19-46e3-9fdf-b19c0d01361e 
ab97d10635c04213bb9889845a601fa8 5a68df1d31e1433189a99e097fe65cfb - - -] 
Unexpected exception in API method
I checked and listed the flavor, network, security to verify the values used in 
launching the instance and they are fine

Steps to reproduce:
Verify the following options are available

rahmed@controller:~$ openstack network list

+--+--+-+
| ID   | Name | Subnets |
+--+--+-+
| dff6ba3d-d1d2-4e8a-b5f2-34fe1e7c685f | provider | |
+--+--+-+
rahmed@controller:~$ 
rahmed@controller:~$ openstack security group list
+--+-++--+
| ID   | Name| Description| 
Project  |
+--+-++--+
| 01ac569e-8f63-4f12-ab88-13b0074d1a81 | default | Default security group | 
5a68df1d31e1433189a99e097fe65cfb |
+--+-++--+
rahmed@controller:~$ openstack flavor list
++---+---+--+---+---+---+
| ID | Name  |   RAM | Disk | Ephemeral | VCPUs | Is Public |
++---+---+--+---+---+---+
| 0  | m1.nano   |64 |1 | 0 | 1 | True  |
| 1  | m1.tiny   |   512 |1 | 0 | 1 | True  |
| 2  | m1.small  |  2048 |   20 | 0 | 1 | True  |
| 3  | m1.medium |  4096 |   40 | 0 | 2 | True  |
| 4  | m1.large  |  8192 |   80 | 0 | 4 | True  |
| 5  | m1.xlarge | 16384 |  160 | 0 | 8 | True  |
++---+---+--+---+---+---+
rahmed@controller:~$ openstack image  list
+--+++
| ID   | Name   | Status |
+--+++
| d11d504e-9047-4487-94da-75cd620957ba | cirros | active |
+--+++

Actual Result:
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-8b87723d-61fa-472a-8e91-de29c45a497b)
rahmed@controller:~$ openstack server create --flavor m1.tiny --image cirros   
--nic net-id=provider --security-group default   --key-name mykey 
provider-instance

Expected Result:
$ openstack server list
+--+---++-+
| ID   | Name  | Status | Networks  
  |
+--+---++-+
| 181c52ba-aebc-4c32-a97d-2e8e82e4eaaf | provider-instance | ACTIVE | 
provider=203.0.113.103 |
+--+---++-+



Environment:
ii  nova-api 2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - API frontend
ii  nova-cert2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - certificate management
ii  nova-common  2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - common files
ii  nova-conductor   2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - conductor service
ii  nova-consoleauth 2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - Console Authenticator
ii  nova-novncproxy  2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - NoVNC proxy
ii  nova-scheduler   2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute - virtual machine scheduler
ii  python-nova  2:13.0.0-0ubuntu2~cloud0  
all  OpenStack Compute Python libraries
ii  python-novaclient2:3.3.1-2~cloud0  
all  client library for OpenStack Compute API - Python 2.7

** Affects: nova
 Importance: Undecided
 Status: New

** Attachment added: "sosreport"
   

[Yahoo-eng-team] [Bug 1567743] Re: Quotas tests are not covered enough at each resources.

[OpenStack Infra]

Reviewed:  https://review.openstack.org/303236
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=e6345a49a01dd20c2ad411655cae8059fbba3143
Submitter: Jenkins
Branch:master

commit e6345a49a01dd20c2ad411655cae8059fbba3143
Author: Maho Koshiya 
Date:   Fri Apr 8 15:09:13 2016 +0900

Add quota tests in unit tests.

The quotas tests in the case of create resources over limit value
are not covered enough in unit tests/functional tests.

This patch include test case of unit tests.

Change-Id: I760fabeab1d480b139eea3b83508fe65c124c9dc
Closes-bug: #1567743


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

Title:
  Quotas tests are not covered enough at each resources.

Status in neutron:
  Fix Released

Bug description:
  The quotas tests in the case of create resources over limit value are
  not covered enough in unit tests/functional tests.

  A part of the quota test of the network already exists.
  But these tests do not exist - subnet/port/router/security group/security 
group rule/floatingip.

  These tests are necessary for it avoid that the user can create
  resources by mistake.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1567743/+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 1568206] Re: host dvr macs remain after agents deleted

[OpenStack Infra]

Reviewed:  https://review.openstack.org/303668
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=92527c2de2afaf4862fddc101143e4d02858924d
Submitter: Jenkins
Branch:master

commit 92527c2de2afaf4862fddc101143e4d02858924d
Author: Kevin Benton 
Date:   Fri Apr 8 17:52:14 2016 -0700

Clear DVR MAC on last agent deletion from host

Once all agents are deleted from a host, the DVR MAC generated
for that host should be deleted as well to prevent a buildup of
pointless flows generated in the OVS agent for hosts that don't
exist.

Closes-Bug: #1568206
Change-Id: I51e736aa0431980a595ecf810f148ca62d990d20


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

Title:
  host dvr macs remain after agents deleted

Status in neutron:
  Fix Released

Bug description:
  The DVR macs and the subsequent rules for them stay around
  indefinitely even after all agents related to that host are removed
  from the database.

  So a system with lots of host churn (e.g. container based deployment),
  will end up with flow tables that look like this on the active agents:
  http://paste.openstack.org/show/493554/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1568206/+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 1571113] [NEW] SNAT interface not created for dvrha in some scenarios

[Adolfo Duarte]

Public bug reported:

branch: master
commit: 4e3a9c2b9c0ada6c2a471d24a20927aa8e8f5740


Depending on the order neutron router commands are given, the snat interface 
for a dvrha router on the dvr_snat agent might not get created. 


look at following interaction: 


--create a couple of network and subnets we will use (public and private)
neutron net-create public --router:external
neutron subnet-create public 192.168.201.0/24 --disable_dhcp
neutron net-create n1 
neutron subnet-create n1 101.0.0.0/24 --name s1

-- now we create and attach router in particular order: first set
external gateway and then attach private subnet.

neutron router-create dvrha --distributed=True --ha=True
neutron router-gateway-set dvrha public 
neutron router-interface-add dvrha s1


neutron router-port-list dvrha -c fixed_ips
+--+
| fixed_ips 
   |
+--+
| {"subnet_id": "b4a81968-8a08-4054-985f-e4e1cf687945", "ip_address": 
"101.0.0.3"} |
| {"subnet_id": "b4a81968-8a08-4054-985f-e4e1cf687945", "ip_address": 
"101.0.0.1"} |
| {"subnet_id": "782574e8-fabb-41da-a1a0-9817994ec0a5", "ip_address": 
"169.254.192.2"} |
| {"subnet_id": "782574e8-fabb-41da-a1a0-9817994ec0a5", "ip_address": 
"169.254.192.3"} |
| {"subnet_id": "0173f29d-746d-45a1-ad10-16dde529eb34", "ip_address": 
"192.168.201.4"} |
| {"subnet_id": "782574e8-fabb-41da-a1a0-9817994ec0a5", "ip_address": 
"169.254.192.1"} |


*** as you can see there are two interfaces on subnet 101/24: 101.0.0.3, and 
101.0.0.1, one is the router interface the other is the snat interface
THIS IS CORRECT BEHAVIOR

*** next we change the order of the commands:
-- first clean up
neutron router-interface-delete dvrha s1 
neutron router-gateway-clear dvrha 
neutron router-delete dvrha

-- This time, we add the internal interface before setting the external
gateway. (reverse order of steps)

neutron router-create dvrha --distributed=True --ha=True
neutron router-interface-add dvrha s1
neutron router-gateway-set dvrha public 
neutron router-port-list dvrha -c fixed_ips
+--+
| fixed_ips 
   |
+--+
| {"subnet_id": "0173f29d-746d-45a1-ad10-16dde529eb34", "ip_address": 
"192.168.201.7"} |
| {"subnet_id": "e9c7148e-04e5-4343-ac66-ac1651514b88", "ip_address": 
"169.254.192.1"} |
| {"subnet_id": "b4a81968-8a08-4054-985f-e4e1cf687945", "ip_address": 
"101.0.0.1"} |
| {"subnet_id": "e9c7148e-04e5-4343-ac66-ac1651514b88", "ip_address": 
"169.254.192.2"} |
+--+

*** this time the snat interface is NOT created. 
-- we can fix this by toggling the internal subnet connection to the router:
 neutron router-interface-delete dvrha s1 
Removed interface from router dvrha.
neutron router-interface-add dvrha s1 
Added interface c3cb410d-08a0-46a5-84fb-ec7bbead4eb3 to router dvrha.
neutron router-port-list dvrha -c fixed_ips
+--+
| fixed_ips 
   |
+--+
| {"subnet_id": "0173f29d-746d-45a1-ad10-16dde529eb34", "ip_address": 
"192.168.201.7"} |
| {"subnet_id": "e9c7148e-04e5-4343-ac66-ac1651514b88", "ip_address": 
"169.254.192.1"} |
| {"subnet_id": "b4a81968-8a08-4054-985f-e4e1cf687945", "ip_address": 
"101.0.0.5"} |
| {"subnet_id": "b4a81968-8a08-4054-985f-e4e1cf687945", "ip_address": 
"101.0.0.1"} |
| {"subnet_id": "e9c7148e-04e5-4343-ac66-ac1651514b88", "ip_address": 
"169.254.192.2"} |

now  the snat port is created (101.0.0.5)

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

Title:
  SNAT interface not created for dvrha in some scenarios

Status in neutron:
  New

Bug description:
  branch: master
  commit: 4e3a9c2b9c0ada6c2a471d24a20927aa8e8f5740

  
  Depending on the order neutron router commands are given, the snat interface 
for a dvrha router on the dvr_snat agent might not get created. 

  
  look at following interaction: 

  
  --create a couple of network and subnets we will use (public and private)
  neutron net-create public --router:external
  neutron subnet-create public 192.168.201.0/24 --disable_dhcp
  neutron net-create n1 
  neutron subnet-create n1 101.0.0.0/24 --name s1

  -- now we create and attach router 

[Yahoo-eng-team] [Bug 1571097] [NEW] unable to delete lbaasv2 health monitor if its listener deleted

[alex kang]

Public bug reported:

problem is in Kilo neutron-lbaas branch.

monitor is attached a pool.
When pool and listener were deleted, not error reported that there is a 
health-monitor associated to pool.

If all lbaas resoruces except health-monitor were deleted, health
monitor can not be deleted.

See the following procedure to reproduce this issue:

$ neutron lbaas-loadbalancer-create --name=v-lb2 lb2-v-1574810802
$ neutron lbaas-listener-create --protocol=HTTP --protocol-port=80 
--name=v-lb2-1 --loadbalancer=v-lb2
$ neutron lbaas-pool-create --lb-algorithm=ROUND_ROBIN --protocol=HTTP 
--name=v-lb2-pool  --listener=v-lb2-1
$ neutron lbaas-member-create --subnet lb2-v-1574810802 --address 10.199.88.3 
--protocol-port=80 v-lb2-pool
$ neutron lbaas-member-create --subnet lb2-v-1574810802 --address 10.199.88.4 
--protocol-port=80 v-lb2-pool
$ neutron lbaas-healthmonitor-create --max-retries=3 --delay=3 --timeout=10 
--type=HTTP --pool=v-lb2-pool
$ neutron lbaas-member-delete 4d2977fc-5600-4dbf-8af2-35c017c8f4a0 v-lb2-pool 
$ neutron lbaas-member-delete 2f60a49b-add1-43d6-97d8-4e53a925b25f  v-lb2-pool 
$ neutron lbaas-pool-delete v-lb2-pool
$ neutron lbaas-listener-delete v-lb2-1
$ neutron lbaashealthmonitor-delete 044f98a5-755d-498d-a38e-18eb8ca13884

neutron log seems point to lbaas resources were gone.
In this specific issue, we should just remove the health monitor from system.

2016-04-10 16:57:38.220 INFO neutron.wsgi 
[req-7e697943-e70d-4ac8-a840-b1edf441806a Venus Venus] 10.34.57.68 - - 
[10/Apr/2016 16:57:38] "GET 
/v2.0/lbaas/healthmonitors.json?fields=id=044f98a5-755d-498d-a38e-18eb8ca13884
 HTTP/1.1" 200 444 0.112257
2016-04-10 16:57:38.252 ERROR neutron.api.v2.resource 
[req-aaeae392-33b2-427c-96a0-918782882c9a Venus Venus] delete failed
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource Traceback (most 
recent call last):
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 490, in delete
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource 
obj_deleter(request.context, id, **kwargs)
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/plugin.py", line 
906, in delete_healthmonitor
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource 
constants.PENDING_DELETE)
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", 
line 163, in test_and_set_status
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource 
db_lb_child.root_loadbalancer.id)
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/db/loadbalancer/models.py", line 115, 
in root_loadbalancer
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource return 
self.pool.listener.loadbalancer
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource AttributeError: 
'NoneType' object has no attribute 'listener'
2016-04-10 16:57:38.252 4158 TRACE neutron.api.v2.resource 
2016-04-10 16:57:38.253 INFO neutron.wsgi 
[req-aaeae392-33b2-427c-96a0-918782882c9a Venus Venus] 10.34.57.68 - - 
[10/Apr/2016 16:57:38] "DELETE 
/v2.0/lbaas/healthmonitors/044f98a5-755d-498d-a38e-18eb8ca13884.json HTTP/1.1" 
500 383 0.030720

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

Title:
  unable to delete lbaasv2 health monitor if its listener deleted

Status in neutron:
  New

Bug description:
  problem is in Kilo neutron-lbaas branch.

  monitor is attached a pool.
  When pool and listener were deleted, not error reported that there is a 
health-monitor associated to pool.

  If all lbaas resoruces except health-monitor were deleted, health
  monitor can not be deleted.

  See the following procedure to reproduce this issue:

  $ neutron lbaas-loadbalancer-create --name=v-lb2 lb2-v-1574810802
  $ neutron lbaas-listener-create --protocol=HTTP --protocol-port=80 
--name=v-lb2-1 --loadbalancer=v-lb2
  $ neutron lbaas-pool-create --lb-algorithm=ROUND_ROBIN --protocol=HTTP 
--name=v-lb2-pool  --listener=v-lb2-1
  $ neutron lbaas-member-create --subnet lb2-v-1574810802 --address 10.199.88.3 
--protocol-port=80 v-lb2-pool
  $ neutron lbaas-member-create --subnet lb2-v-1574810802 --address 10.199.88.4 
--protocol-port=80 v-lb2-pool
  $ neutron lbaas-healthmonitor-create --max-retries=3 --delay=3 --timeout=10 
--type=HTTP --pool=v-lb2-pool
  $ neutron lbaas-member-delete 4d2977fc-5600-4dbf-8af2-35c017c8f4a0 v-lb2-pool 
  $ neutron 

[Yahoo-eng-team] [Bug 1538054] Re: attach_interface in nova.compute.manager didn't handle NotImplemented Error

[OpenStack Infra]

Reviewed:  https://review.openstack.org/272471
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=4ad414f3b1216393301ef268a64e61ca1a3d5be9
Submitter: Jenkins
Branch:master

commit 4ad414f3b1216393301ef268a64e61ca1a3d5be9
Author: Kevin_Zheng 
Date:   Tue Jan 26 18:51:29 2016 +0800

Add checks for driver attach_interfaces capability

Currently Ironic driver does not support attach interfaces
for instances, and the error of NotImplementedError has
not been handled.

Accodring to the comments of the previous patchset 3,
a better solution of this problem will be add a check
of driver capability before the actual interface attach
job, as it won't have the problem of orphan port [1]

This patch addes checks for driver attach interface
capabalities.

[1] https://review.openstack.org/#/c/272471/3/nova/compute/manager.py

Change-Id: I3fa376f866e70e1b90a6aa10b1fe6b169a0ffa43
Closes-Bug: #1538054


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

Title:
  attach_interface in nova.compute.manager didn't handle NotImplemented
  Error

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  In 
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4958~L4965
  we handled only exception.NovaException but we didn't handle NotImplemented 
Error,
  but since ironic driver didn't support this method, so NotImplemented Error 
will raise, we need
  to handle it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1538054/+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 1568637] Re: network config of initramfs devices writes 'auto', breaking iscsi root boot

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.7~bzr1212-0ubuntu1

---
cloud-init (0.7.7~bzr1212-0ubuntu1) xenial; urgency=medium

  * New upstream snapshot.
- fix iscsi root by not writing interface as 'auto' when networking
  information comes from kernel command line (LP: #1568637)
- apply networking less often, when possible only on first
  instance boot (LP: #1571004).
- no longer delete /etc/network/interfaces.d/eth0.cfg on
  ubuntu (LP: #1563487)

 -- Scott Moser   Fri, 15 Apr 2016 16:25:43 -0400

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  network config of initramfs devices writes 'auto', breaking iscsi root
  boot

Status in cloud-init:
  Confirmed
Status in maas-images:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  when i removed the symlink in the maas ephemeral image from 
/etc/network/interfaces the iscsi root boot fails, and maas deployment would 
also fail.
  The real reason for the difference was that cloud-init was rendering 'auto' 
for the device that was brought up in the initramfs.

  Instead it needs to leave it to be manually controled (no 'auto' or
  'allow-hotplug').

  Related bugs:
   * bug 1570142: [open-isci]  net-interface-handler needs updating for newer 
ifupdown

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1568637/+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 1563487] Re: do not delete /etc/network/interfaces.d/eth0.cfg

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.7~bzr1212-0ubuntu1

---
cloud-init (0.7.7~bzr1212-0ubuntu1) xenial; urgency=medium

  * New upstream snapshot.
- fix iscsi root by not writing interface as 'auto' when networking
  information comes from kernel command line (LP: #1568637)
- apply networking less often, when possible only on first
  instance boot (LP: #1571004).
- no longer delete /etc/network/interfaces.d/eth0.cfg on
  ubuntu (LP: #1563487)

 -- Scott Moser   Fri, 15 Apr 2016 16:25:43 -0400

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  do not delete /etc/network/interfaces.d/eth0.cfg

Status in cloud-images:
  Confirmed
Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released

Bug description:
  currently cloud-init is removing /etc/network/interfaces.d/eth0.cfg .
  This is because cloud-init now has a 'fallback' mode for getting 
configuration which should be superior to the statically written one by the 
image build process in all cases.

  That said, still best to *not* delete the file.

  This change is then 2 phased:
a.) CPC not write that file on xenial in cloud images
b.) cloud-init stop deleting it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1563487/+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 1549957] Re: When using the material theme the delete button is red and flashy

[OpenStack Infra]

Reviewed:  https://review.openstack.org/293117
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=88968353537c455d084fd1cca0a7405082d4b164
Submitter: Jenkins
Branch:master

commit 88968353537c455d084fd1cca0a7405082d4b164
Author: Diana Whitten 
Date:   Tue Mar 15 11:08:57 2016 -0700

Angular vs. Django Table Danger Button Inconsistency

A button should have either btn-default OR btn-danger ... not both.

This also removes the flashing red change this  problem caused when
adding a 'disabled' class to the button after its already been
rendered on the page.

Closes-bug: #1557729
Closes-bug: #1549957

Change-Id: I6e035868be4df653438b4d31b462729c3fe06d9f


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

Title:
  When using the material theme the delete button is red and flashy

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  While testing out https://review.openstack.org/#/c/277220/ I notice
  when using the material theme, the Delete button on most (all?) pages
  is initially shown as Red/enabled and pretty quickly switches to
  Grey/disabled. The red flashing is distracting when navigating from
  page to page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1549957/+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 1557729] Re: Branding: Material: Angular vs. Django Table Action Danger Button Inconsistency

[OpenStack Infra]

Reviewed:  https://review.openstack.org/293117
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=88968353537c455d084fd1cca0a7405082d4b164
Submitter: Jenkins
Branch:master

commit 88968353537c455d084fd1cca0a7405082d4b164
Author: Diana Whitten 
Date:   Tue Mar 15 11:08:57 2016 -0700

Angular vs. Django Table Danger Button Inconsistency

A button should have either btn-default OR btn-danger ... not both.

This also removes the flashing red change this  problem caused when
adding a 'disabled' class to the button after its already been
rendered on the page.

Closes-bug: #1557729
Closes-bug: #1549957

Change-Id: I6e035868be4df653438b4d31b462729c3fe06d9f


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

Title:
  Branding: Material: Angular vs. Django Table Action Danger Button
  Inconsistency

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  https://i.imgur.com/KUHpaae.png

  vs.

  https://i.imgur.com/zicXft0.png

  The morale of the story is ... a button should have either btn-default
  OR btn-danger ... not both.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1557729/+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 1569641] Re: server group members are not deleted on failed server create overquota

[Matt Riedemann]

This can prevent archiving/purging instances so bumping to medium
severity and marking it for backport.

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

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

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

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

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

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

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

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

Title:
  server group members are not deleted on failed server create overquota

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) liberty series:
  Confirmed
Status in OpenStack Compute (nova) mitaka series:
  Confirmed

Bug description:
  When creating instances in the database in the compute API, if we fail
  after creating them we attempt to delete the instances from the DB
  here:

  
https://github.com/openstack/nova/blob/af7e83fef3bc2c005c581587e9230a4070f8feb9/nova/compute/api.py#L1033

  However, if there is a failure it's ignored and we continue and just
  re-raise the exception.

  The instances can fail to delete because of a referential constraint
  on the block device mappings created here:

  
https://github.com/openstack/nova/blob/af7e83fef3bc2c005c581587e9230a4070f8feb9/nova/compute/api.py#L1471

  So if we don't delete those first, we can't cleanup the instances. You
  can recreate this by changing CONF.quota_server_group_members=0 and
  trying to boot a server into a server group.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1569641/+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 1570142] Re: net-interface-handler needs updating for newer ifupdown

[Scott Moser]

** No longer affects: cloud-init (Ubuntu)

** No longer affects: maas-images

** No longer affects: cloud-init

** Description changed:

  newer ifupdown versions (those in xenial) now keep interface state in
  /run/network/ifstate. rather than combined in
  /run/network/ifstate .
  
  We need to update /lib/open-iscsi/net-interface-handler to write the
  interface name into /run/network/ifstate. and then also
  tear that down on down.
  
  The failure can be seen when booting a maas image, if you first move the 
included symlink out of the way:
  p="/etc/network/interfaces";
   [ -e "$p.link" -o -L "$p.link" ] || mv "$p" "$p.link"; cp "$p.dist" "$p"
  
  (maas images ship with /etc/network/interfaces as a symlink to 
../../run/network/dynamic-interfaces
  and /run/network/dynamic-interfaces is populated by 
cloud-initramfs-dyn-netconf).
  
  This affects:
-   * cloud-init: cloud-init's fallback config currently writes 'auto' for the 
network device. the cloud-initramfs-dyn-netconf writes 'manual', and so 
ifupdown doesn't try to bring up *or* down the device.
-   * maas-images: the single difference from filesystem viewpoint from xenial 
lxd image to maas image is 'ln -snf ../../run/dynamic-interfaces 
/etc/network/interfaces'
-   * open-iscsi: the real need for open-iscsi's udev integration is to get the 
resolvconf updates applied.
+   * cloud-init: cloud-init's fallback config currently writes 'auto' for the 
network device. the cloud-initramfs-dyn-netconf writes 'manual', and so 
ifupdown doesn't try to bring up *or* down the device.
+   * maas-images: the single difference from filesystem viewpoint from xenial 
lxd image to maas image is 'ln -snf ../../run/dynamic-interfaces 
/etc/network/interfaces'
+   * open-iscsi: the real need for open-iscsi's udev integration is to get the 
resolvconf updates applied.
+ 
+ Related bugs:
+  * bug 1568637:  network config of initramfs devices writes 'auto', breaking 
iscsi root boot 
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: open-iscsi 2.0.873+git0.3b4b4500-14ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Wed Apr 13 23:58:27 2016
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: open-iscsi
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  net-interface-handler needs updating for newer ifupdown

Status in open-iscsi package in Ubuntu:
  In Progress

Bug description:
  newer ifupdown versions (those in xenial) now keep interface state in
  /run/network/ifstate. rather than combined in
  /run/network/ifstate .

  We need to update /lib/open-iscsi/net-interface-handler to write the
  interface name into /run/network/ifstate. and then also
  tear that down on down.

  The failure can be seen when booting a maas image, if you first move the 
included symlink out of the way:
  p="/etc/network/interfaces";
   [ -e "$p.link" -o -L "$p.link" ] || mv "$p" "$p.link"; cp "$p.dist" "$p"

  (maas images ship with /etc/network/interfaces as a symlink to 
../../run/network/dynamic-interfaces
  and /run/network/dynamic-interfaces is populated by 
cloud-initramfs-dyn-netconf).

  This affects:
    * cloud-init: cloud-init's fallback config currently writes 'auto' for the 
network device. the cloud-initramfs-dyn-netconf writes 'manual', and so 
ifupdown doesn't try to bring up *or* down the device.
    * maas-images: the single difference from filesystem viewpoint from xenial 
lxd image to maas image is 'ln -snf ../../run/dynamic-interfaces 
/etc/network/interfaces'
    * open-iscsi: the real need for open-iscsi's udev integration is to get the 
resolvconf updates applied.

  Related bugs:
   * bug 1568637:  network config of initramfs devices writes 'auto', breaking 
iscsi root boot 

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: open-iscsi 2.0.873+git0.3b4b4500-14ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Wed Apr 13 23:58:27 2016
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  SourcePackage: open-iscsi
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1570142/+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 1564921] Re: nova rebuild fails after two rebuild requests when ironic is used

[Vladyslav Drok]

** Changed in: ironic
   Status: In Progress => Won't Fix

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

Title:
  nova rebuild fails after two rebuild requests when ironic is used

Status in Ironic:
  Won't Fix
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  First nova rebuild request passes fine, but further requests fail with
  the following message:

  Instance b460e640-e601-4e68-b0e8-231e15201412 is already associated
  with a node, it cannot be associated with this other node
  10c0b922-cb39-412e-849a-27e66042d4c0 (HTTP 409)", "code": 500,
  "details": "  File \"/opt/stack/nova/nova/compute/manager.py\"

  The reason for this is that nova tries to reshcedule an instance
  during rebuild, and in case of ironic, there can't be 2 nodes
  associated with the same instance_uuid.

  This can be checked on devstack since change
  I0233f964d8f294f0ffd9edcb16b1aaf93486177f that introduced it with
  ironic virt driver and neutron.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1564921/+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 1571004] [NEW] apply networking only on first instance boot

[Scott Moser]

Public bug reported:

Currently cloud-init is applying networking on every boot.
On 'local' data sources that provides network information this is great.
On any other datasource:
  * local datasource without networking info
  * network based datasource

then the fallback networking is rendered on every boot.
In the scenario:
 a.) boot instance
 b.) fallback networking picks eth0.cfg and that is fine
 c.) attach network device
 d.) reboot

things can get hairy.

The suggested change is to only apply the networking configuration once per 
instance.
This is less dynamic and less surprising.

ie, if a user modifies /etc/network/interfaces.d/my.cfg and adds to or
improves on the fallback (or unconfigures the fallback) then their
changes might not interact well.

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

Title:
  apply networking only on first instance boot

Status in cloud-init:
  New

Bug description:
  Currently cloud-init is applying networking on every boot.
  On 'local' data sources that provides network information this is great.
  On any other datasource:
* local datasource without networking info
* network based datasource

  then the fallback networking is rendered on every boot.
  In the scenario:
   a.) boot instance
   b.) fallback networking picks eth0.cfg and that is fine
   c.) attach network device
   d.) reboot

  things can get hairy.

  The suggested change is to only apply the networking configuration once per 
instance.
  This is less dynamic and less surprising.

  ie, if a user modifies /etc/network/interfaces.d/my.cfg and adds to or
  improves on the fallback (or unconfigures the fallback) then their
  changes might not interact well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1571004/+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 1571001] [NEW] Document Multi ldap support

[Adam Young]

Public bug reported:

"When defining the URL for connecting to the LDAP server in the Keystone
configuration, looking for a way to specify multiple LDAP servers for
redundancy.  For example if an AD domain controller were not available,
Keystone would try an alternate domain controller."

This is suopported, but config comment does not indicatei t.  Needs an
update.

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

Title:
  Document Multi ldap support

Status in OpenStack Identity (keystone):
  New

Bug description:
  "When defining the URL for connecting to the LDAP server in the
  Keystone configuration, looking for a way to specify multiple LDAP
  servers for redundancy.  For example if an AD domain controller were
  not available, Keystone would try an alternate domain controller."

  This is suopported, but config comment does not indicatei t.  Needs an
  update.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1571001/+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 1569941] Re: missed assertTrue in instance tests to validate notification messages

[OpenStack Infra]

Reviewed:  https://review.openstack.org/305163
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=65eb9e9b8cbd5e4533953d741a16648f754b91bb
Submitter: Jenkins
Branch:master

commit 65eb9e9b8cbd5e4533953d741a16648f754b91bb
Author: Sergei Chipiga 
Date:   Wed Apr 13 15:35:13 2016 +0300

Fix explicit waiting if instance has error status

This patches includes:
- don't wait instance launching if instance in error status
- add missed assertTrue to validate notification messages
- check that message is present and is displayed

Change-Id: If731751fa4deabdeebe373748b169ac7ac617f8c
Closes-Bug: #1569941


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

Title:
  missed assertTrue in instance tests to validate notification messages

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  There are some missed assertTrue inside
  
openstack_dashboard/test/integration_tests/pages/project/compute/instancespage.py
  for notification messages, which may lead to malfunction of the tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1569941/+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 1570884] Re: Functional test_name_validation unexpectedly passing

[OpenStack Infra]

Reviewed:  https://review.openstack.org/306465
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=72a0a7c174f2ba0787defc10af6f67403a705647
Submitter: Jenkins
Branch:master

commit 72a0a7c174f2ba0787defc10af6f67403a705647
Author: Michal Pryc 
Date:   Fri Apr 15 16:16:16 2016 +0200

Fixes unexpectedly passing functional test.

This fix allows all functional tests passing rather
then one unexpectedly passing:

test_bug_1541691.TestServerValidation.test_name_validation

The bug 1541691 was merged, however test never got updated.

Change-Id: I84597ad5f5ca9ef457f34769e3fe299b780acadd
Closes-Bug: 1570884
Related-Bug: 1541691


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

Title:
  Functional test_name_validation unexpectedly passing

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

Bug description:
  Functional test is unexpectedly passing:

  
nova.tests.functional.regressions.test_bug_1541691.TestServerValidation.test_name_validation

  It's because bug was fixed but test never updated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570884/+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 1570803] Re: complicated wrong logic inside selenium wrapper _execute method

[OpenStack Infra]

Reviewed:  https://review.openstack.org/306325
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=755d07cbdf66b2b01940dc2031692dce07c3e75b
Submitter: Jenkins
Branch:master

commit 755d07cbdf66b2b01940dc2031692dce07c3e75b
Author: Sergei Chipiga 
Date:   Fri Apr 15 12:35:32 2016 +0300

Fix longtime tests

The core problem is in usage `while True:` to wait element,
but implicit_wait delegates its to browser already.
Just we need to catch StaleElement exception, reload
chain of element parents and then to execute command again.

Change-Id: I9c94b8adb04489c9675644d1501919af35e5bf99
Closes-Bug: #1570803


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

Title:
  complicated wrong logic inside selenium wrapper _execute method

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  I found that method _execute inside horizon/tests/webdriver.py has
  complicated and wrong logic, that in race condition leads to long
  tests, for example we have tests with 10 min duration.

  The core problem is that `while True` is used to wait for an element, but 
`implicit_wait` delegates this to browser already.
  We need just to catch StaleElementRereferenceException, reload the chain of 
element's parents and then execute a command again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1570803/+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 1570976] [NEW] neutronclient is missing help text for the purge command

[Sean M. Collins]

Public bug reported:

stack@devstack-1:~/devstack$ neutron --help

  port-update   Update port's information.
  purge
  qos-available-rule-types  List available qos rule types.


stack@devstack-1:~/devstack$ neutron --version
4.2.0

** Affects: neutron
 Importance: Undecided
 Status: New

** Description changed:

  $neutron --help
  
  ...
-   port-update   Update port's information.
-   purge
-   qos-available-rule-types  List available qos rule types.
+   port-update   Update port's information.
+   purge
+   qos-available-rule-types  List available qos rule types.
  ...

** Description changed:

- $neutron --help
- 
- ...
+ stack@devstack-1:~/devstack$ neutron --help
+ 
    port-update   Update port's information.
    purge
    qos-available-rule-types  List available qos rule types.
- ...
+ 
+ 
+ stack@devstack-1:~/devstack$ neutron --version
+ 4.2.0

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

Title:
  neutronclient is missing help text for the purge command

Status in neutron:
  New

Bug description:
  stack@devstack-1:~/devstack$ neutron --help
  
    port-update   Update port's information.
    purge
    qos-available-rule-types  List available qos rule types.
  

  stack@devstack-1:~/devstack$ neutron --version
  4.2.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570976/+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 1532243] Re: glance fails silently if a task flow can't be loaded

[OpenStack Infra]

Reviewed:  https://review.openstack.org/265329
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=38158e554560621fa85d36aa2c288c04a94fb527
Submitter: Jenkins
Branch:master

commit 38158e554560621fa85d36aa2c288c04a94fb527
Author: Stuart McLaren 
Date:   Fri Jan 8 16:01:18 2016 +

Log when task is not configured properly

Currently we fail silently when a task is not configured properly.
Silent failures make things particularly hard to understand when behaviour
does not match expectations.

Change-Id: Ib4d8f2bdf3299caaf91bd5a99c6a014f87143e4a
Closes-bug: 1532243


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

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

Title:
  glance fails silently if a task flow can't be loaded

Status in Glance:
  Fix Released

Bug description:
  In this try block:

  try:
  # NOTE(flaper87): ImportToLocal and DeleteFromLocal shouldn't be here.
  # Ideally, we should have the different import flows doing this for us
  # and this function should clean up duplicated tasks. For example, say
  # 2 flows need to have a local copy of the image - ImportToLocal - in
  # order to be able to complete the task - i.e Introspect-. In that
  # case, the introspect.get_flow call should add both, ImportToLocal 
and
  # DeleteFromLocal, to the flow and this function will reduce the
  # duplicated calls to those tasks by creating a linear flow that
  # ensures those are called before the other tasks.  For now, I'm
  # keeping them here, though.
  limbo = lf.Flow(task_type).add(_ImportToFS(task_id,
 task_type,
 task_repo,
 uri))

  for subflow in _get_import_flows(**kwargs):
  limbo.add(subflow)

  # NOTE(flaper87): We have hard-coded 2 tasks,
  # if there aren't more than 2, it means that
  # no subtask has been registered.
  if len(limbo) > 1:
  flow.add(limbo)

  # NOTE(flaper87): Until this implementation gets smarter,
  # make sure ImportToStore is called *after* the imported
  # flow stages. If not, the image will be set to saving state
  # invalidating tasks like Introspection or Convert.
  flow.add(import_to_store)

  # NOTE(flaper87): Since this is an "optional" task but required
  # when `limbo` is executed, we're adding it in its own subflow
  # to isolate it from the rest of the flow.
  delete_flow = lf.Flow(task_type).add(_DeleteFromFS(task_id,
 task_type))
  flow.add(delete_flow)
  else:
  flow.add(import_to_store)
  except exception.BadTaskConfiguration:
  # NOTE(flaper87): If something goes wrong with the load of
  # import tasks, make sure we go on.
  flow.add(import_to_store)

  We silently suppress a bad task configuration exception (with no
  information logged).

  The exception contains useful information which should at least be
  logged:

   BadTaskConfiguration: 8ada245a-28f6-4675-ab1d-3fa3300e8393 of import
  not configured properly. Missing work dir: None

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1532243/+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 1570958] [NEW] Need neutron-ns-metadata-proxy child ProcessMonitor for dhcp agent

[Kevin Stevens]

Public bug reported:

Related to bug 1257775 and bug 1257524

The l3-agent is able to periodically check that child process neutron-
ns-metadata-proxy is still running and respawn it if not.

It seems we should periodically check child processes (in addition to
dnsmasq) of the dhcp agent as well since the dhcp agent is responsible
for spawning the neutron-ns-metadata-proxy process for networks not
attached to a router.

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

Title:
  Need neutron-ns-metadata-proxy child ProcessMonitor for dhcp agent

Status in neutron:
  New

Bug description:
  Related to bug 1257775 and bug 1257524

  The l3-agent is able to periodically check that child process neutron-
  ns-metadata-proxy is still running and respawn it if not.

  It seems we should periodically check child processes (in addition to
  dnsmasq) of the dhcp agent as well since the dhcp agent is responsible
  for spawning the neutron-ns-metadata-proxy process for networks not
  attached to a router.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570958/+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 1542282] Re: Q_PLUGIN_EXTRA_CONF_FILES documented with incorrect syntax

[Boden R]

See comment #8 for summary.

** Project changed: neutron => devstack

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

Title:
  Q_PLUGIN_EXTRA_CONF_FILES documented with incorrect syntax

Status in devstack:
  In Progress

Bug description:
  When we use multiple service plugin that each have their own
  service_providers configured, the neutron-server service fails to come
  up.

  For example , when we try to load LBaaS +  BGPVPN + L2GatewayPlugin
  services together into the neutron server,  only the last
  service_provider entry is retained by
  neutron/services/provider_configuration, that results in unmatching
  service plugins to EXIT on load, thereby bringing down the neutron
  service.

  Workaround exists: 
  Put in all the service_provider entries into a single service_providers 
section under neutron.conf, and then all the services are able to start up.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1542282/+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 1460630] Re: nova should not verify "port_security_enabled" according the info from network

[OpenStack Infra]

*** This bug is a duplicate of bug 1175464 ***
https://bugs.launchpad.net/bugs/1175464

Reviewed:  https://review.openstack.org/284095
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=ee7a01982611cdf8012a308fa49722146c51497f
Submitter: Jenkins
Branch:master

commit ee7a01982611cdf8012a308fa49722146c51497f
Author: Sahid Orentino Ferdjaoui 
Date:   Wed Feb 24 06:55:30 2016 -0500

network: make nova to handle port_security_enabled=False

In somes cases we need to have network without any security rules
applied, unfortunatly nova does not provide way to remove l3
assignements and always at least expose the default security group.
This commit updates code to clear security groups applied to the
network when option port_security_enabled=False is activated on the
network.

Change-Id: I630008a9733624a9d9b59b7aa3b8b2a3f8985d61
Closes-Bug: #1460630
Related-Bug: #1175464


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

Title:
  nova should not verify "port_security_enabled" according the info from
  network

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  New
Status in OpenStack Compute (nova) mitaka series:
  In Progress

Bug description:
  nova version:
  2.25.0

  according the bp :
  https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity

  repro:
  1.create a network with port_security_enabled is false, and create a sample 
subnet.
  2.create a port with port_security_enabled is true on this network through 
neutron.
  3. boot a server based on this port.

  expect:
  This server should be fine.

  But it hit the error as:
  SecurityGroupCannotBeApplied: Network requires port_security_enabled and 
subnet associated in order to apply security groups.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1460630/+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 1570946] [NEW] Improve Help Text of Configuration Options in Glance and Glance Store

[Hemanth Makkapati]

Public bug reported:

The overall aim is operators should not need to read and understand the
code to know how to configure the system.

This lite-spec is focusing on making sure oslo.config has all the
information required to generate good sample configuration files and
generating good documentation for the configuration options. This spec
is not focusing on how the documentation is generated from the option
definitions.

Most importantly, we need a good description for each of the
configuration options, set in the help text of the option. This means
developers reviewing each configuration option descriptions and adding
any missing details.

Nova has found standardizing around a template has helped build some
consistency in what is described in the help text for each option. This
template, shown below, probably works well for Glance too.

# A short description about what it does. If it is a unit (e.g. timeout)
# describe the unit which is used (seconds, megabyte, mebibyte, ...)

# A long description what the impact and scope is. The operators should
# know the expected change in the behavior of Glance if they tweak this.

Services which consume this:

# A list of services which consume this option. Operators should not be
# required to read code to know which one of the services will change its
# behavior. Nor should they set this in every configuration file to be
# sure. This can really help deployers understand how the option is used.

Possible values:

# Description of possible values. Especially if this is an option
# with numeric values (int, float), describe the edge cases (like the
# min value, max value, 0, -1). Further, for choices which are not
# obviously named, please describe the affect of each choice.
# Note: this does not replace the need for StrOpt.choices, StrOpt.regex,
# IntOpt.min, etc.

Related options:

# Which other config options have to be considered when I change this
# one? If it stands solely on its own, use "None"
# Note: this does not replace the proposed Opt.related_options, it's used
# when extra details are required.

When reviewing the description of the configuration, it's worth
reviewing the other parameters passed to ``oslo.config``. There have
been features added to make the opt definition more precise, but some of
the options have not been updated since those new features were added.

We must pay particular attention to:

* Option type: make sure you are using the best type, and in some cases making 
better use of custom option types.
* Check if there is any extra options that could be used for that type of 
option to help improve the documentation, such as StrOpt.choices, IntOpt.min
* Deprecated: look at deprecating options that are best removed rather than 
having the documentation improved. Look at removing options that have been 
deprecated for several releases, but not yet removed. Be sure to set the 
deprecated_reason setting.
* Look out for bad defaults that force install guides to tell users to set 
configuration value because the default would never work. Always optimize the 
default for operators rather than the test environment.


(NOTE: This is mostly taken from the cross-project spec [0] and adapted to 
Glance)
[0] https://review.openstack.org/#/c/295543/

** Affects: glance
 Importance: Wishlist
 Status: New

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

Title:
  Improve Help Text of Configuration Options in Glance and Glance Store

Status in Glance:
  New

Bug description:
  The overall aim is operators should not need to read and understand
  the code to know how to configure the system.

  This lite-spec is focusing on making sure oslo.config has all the
  information required to generate good sample configuration files and
  generating good documentation for the configuration options. This spec
  is not focusing on how the documentation is generated from the option
  definitions.

  Most importantly, we need a good description for each of the
  configuration options, set in the help text of the option. This means
  developers reviewing each configuration option descriptions and adding
  any missing details.

  Nova has found standardizing around a template has helped build some
  consistency in what is described in the help text for each option.
  This template, shown below, probably works well for Glance too.

  # A short description about what it does. If it is a unit (e.g. timeout)
  # describe the unit which is used (seconds, megabyte, mebibyte, ...)

  # A long description what the impact and scope is. The operators should
  # know the expected change in the behavior of Glance if they tweak this.

  Services which consume this:

  # A list of services which consume this option. Operators should not be
  # required to read code to know which one of the services will change its
  # behavior. Nor should they set this in 

[Yahoo-eng-team] [Bug 1570931] [NEW] Attach the Nova API log if possible." Keystoneclient.exceptions.BadRequest"

[Atrícia Sabino]

Public bug reported:

This bug occurs when a new instcacia is initialised at liberty OpenStack. The 
error message. "Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. ". 
I am using the recommended environment, and the official installation of 
OpenStack. A controller with network services. And two computers nodes.
Also there are two networks created. One internal and one external.

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

Title:
  Attach the Nova API log if possible."
  Keystoneclient.exceptions.BadRequest"

Status in OpenStack Compute (nova):
  New

Bug description:
  This bug occurs when a new instcacia is initialised at liberty OpenStack. The 
error message. "Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. ". 
  I am using the recommended environment, and the official installation of 
OpenStack. A controller with network services. And two computers nodes.
  Also there are two networks created. One internal and one external.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570931/+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 1570633] Re: Nodes fail to remain powered after Trusty commission with "Allow SSH" selected

[Chris Gregan]

Cloud-init seems to be ignoring MAAS signal to keep powered after
commissioning.

** Summary changed:

- [2.0 beta2] Machine power's off after commissioning with 'Allow SSH...' 
option enabled, when using Trusty as commissioning image.
+ Nodes fail to remain powered after Trusty commission with "Allow SSH" selected

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

Title:
  [2.0 beta 2] Nodes fail to remain powered after Trusty commission with
  "Allow SSH" selected

Status in cloud-init:
  New
Status in MAAS:
  Incomplete

Bug description:
  Build Version/Date: MAAS 2.0 Beta2
  Environment used for testing: Xenial

  Summary: 
  When commissioning nodes with the "Allow SSH" option selected, at least 50% 
of nodes fail to remain powered and in "Ready" state

  Steps to Reproduce: 
  Enlist 5+ nodes
  Commission all nodes at once

  Expected result: 
  All nodes Ready and powered

  Actual result:
  50-75% of nodes are Ready but powered off

  Syslog shows the following errors
  Apr 14 19:03:41 donphan sh[28839]: 2016-04-14 19:03:41+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:05:37 donphan sh[28839]: 2016-04-14 19:05:37+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:05:37 donphan sh[28839]: 2016-04-14 19:05:37+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:07:12 donphan sh[28839]: 2016-04-14 19:07:12+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:07:48 donphan sh[28839]: 2016-04-14 19:07:48+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:08:08 donphan sh[28839]: 2016-04-14 19:08:08+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:11:37 donphan sh[28839]: 2016-04-14 19:11:37+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:11:44 donphan sh[28839]: 2016-04-14 19:11:44+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:11:47 donphan sh[28839]: 2016-04-14 19:11:47+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:12:24 donphan sh[28839]: 2016-04-14 19:12:24+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:12:24 donphan sh[28839]: 2016-04-14 19:12:24+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:13:14 donphan sh[28839]: 2016-04-14 19:13:14+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:13:17 donphan sh[28575]: Failure: 
twisted.internet.error.ConnectionDone: Connection was closed cleanly.
  Apr 14 19:13:18 donphan sh[28575]: Failure: 
twisted.internet.error.ConnectionDone: Connection was closed cleanly.
  Apr 14 19:43:41 donphan sh[28839]: 2016-04-14 19:43:41+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:43:50 donphan sh[28839]: 2016-04-14 19:43:50+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:43:57 donphan sh[28839]: 2016-04-14 19:43:57+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:44:05 donphan sh[28839]: 2016-04-14 19:44:05+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:44:06 donphan sh[28839]: 2016-04-14 19:44:06+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:45:10 donphan sh[28839]: 2016-04-14 19:45:10+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 19:46:19 donphan sh[28575]: #011twisted.internet.error.ConnectionDone: 
Connection was closed cleanly.
  Apr 14 21:34:08 donphan sh[28839]: 2016-04-14 21:34:08+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:34:09 donphan sh[28839]: 2016-04-14 21:34:09+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:34:20 donphan sh[28839]: 2016-04-14 21:34:20+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:34:35 donphan sh[28839]: 2016-04-14 21:34:35+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:34:36 donphan sh[28839]: 2016-04-14 21:34:36+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:35:05 donphan sh[28575]: Failure: 
twisted.internet.error.ConnectionDone: Connection was closed cleanly.
  Apr 14 21:35:46 donphan sh[28839]: 2016-04-14 21:35:46+ 
[RemoteOriginReadSession (UDP)] Got error: 
  Apr 14 21:36:51 donphan sh[28575]: #011twisted.internet.error.ConnectionDone: 
Connection was closed cleanly.
  Apr 14 21:37:00 donphan sh[28575]: #011twisted.internet.error.ConnectionDone: 
Connection was closed cleanly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1570633/+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 1569783] Re: JS dev dependencies are outdated

[OpenStack Infra]

Reviewed:  https://review.openstack.org/303379
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=8da92fb400c3a1c9e8ab20be801263bd59a900c0
Submitter: Jenkins
Branch:master

commit 8da92fb400c3a1c9e8ab20be801263bd59a900c0
Author: Rob Cresswell 
Date:   Fri Apr 8 12:09:40 2016 +0100

Update JS dev dependencies

A lot of the JavaScript dev dependencies are quite outdated. This patch
updates them.

Closes-Bug: 1569783
Change-Id: I8b47e573a3a3160c824e21f6865b5e9af32c8d64


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

Title:
  JS dev dependencies are outdated

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The JS dev dependencies are outdated. This is specifically important
  for Jasmine, since it should mirror the xstatic package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1569783/+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 1570884] Re: Functional test_name_validation unexpectedly passing

[Matt Riedemann]

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

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

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

** Changed in: nova/mitaka
   Importance: Undecided => Low

** Tags added: api 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/1570884

Title:
  Functional test_name_validation unexpectedly passing

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

Bug description:
  Functional test is unexpectedly passing:

  
nova.tests.functional.regressions.test_bug_1541691.TestServerValidation.test_name_validation

  It's because bug was fixed but test never updated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570884/+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 1563487] Re: do not delete /etc/network/interfaces.d/eth0.cfg

[Scott Moser]

** Also affects: livecd-rootfs (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: livecd-rootfs (Ubuntu)
   Status: New => Confirmed

** Changed in: livecd-rootfs (Ubuntu)
   Importance: Undecided => Medium

** Changed in: livecd-rootfs (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  do not delete /etc/network/interfaces.d/eth0.cfg

Status in cloud-images:
  Confirmed
Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in livecd-rootfs package in Ubuntu:
  Fix Released

Bug description:
  currently cloud-init is removing /etc/network/interfaces.d/eth0.cfg .
  This is because cloud-init now has a 'fallback' mode for getting 
configuration which should be superior to the statically written one by the 
image build process in all cases.

  That said, still best to *not* delete the file.

  This change is then 2 phased:
a.) CPC not write that file on xenial in cloud images
b.) cloud-init stop deleting it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1563487/+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 1567846] Re: VPNaaS: require to support sha256

[OpenStack Infra]

Reviewed:  https://review.openstack.org/303684
Committed: 
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=b73e1002555cfa70ccfea8ffe685672c0b679212
Submitter: Jenkins
Branch:master

commit b73e1002555cfa70ccfea8ffe685672c0b679212
Author: nick.zhuyj 
Date:   Fri Apr 8 23:48:33 2016 -0500

Openswan/Libreswan: support sha256 for auth algorithm

Add support for sha256 as it is requirement from customer.
Currently, there is no ike/esp fields in strongswan ipsec.conf
template, so by default. sha256 is used. But for openswan auth
algorithm is get from configuration, so only sha1 is supported.
This patch enable Openswan/Libreswan to support sha256.

Note: this change is DocImpact and APIImpact

Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2
Closes-Bug: #1567846


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

Title:
  VPNaaS: require to support sha256

Status in neutron:
  Fix Released

Bug description:
  Currently, only sha1 is supported in auth-algorithm. But there is
  requirements to support sha256.

  In current implementation, strongswan ipsec.conf.template doesn't include ike 
& esp filed, so by default. sha256 is used.
  In this bug, we only talking about openswan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1567846/+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 1570892] [NEW] Openswan/Libreswan: support sha256 for auth algorithm

[OpenStack Infra]

Public bug reported:

https://review.openstack.org/303684
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.

commit b73e1002555cfa70ccfea8ffe685672c0b679212
Author: nick.zhuyj 
Date:   Fri Apr 8 23:48:33 2016 -0500

Openswan/Libreswan: support sha256 for auth algorithm

Add support for sha256 as it is requirement from customer.
Currently, there is no ike/esp fields in strongswan ipsec.conf
template, so by default. sha256 is used. But for openswan auth
algorithm is get from configuration, so only sha1 is supported.
This patch enable Openswan/Libreswan to support sha256.

Note: this change is DocImpact and APIImpact

Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2
Closes-Bug: #1567846

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc neutron-vpnaas

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

Title:
  Openswan/Libreswan: support sha256 for auth algorithm

Status in neutron:
  New

Bug description:
  https://review.openstack.org/303684
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.

  commit b73e1002555cfa70ccfea8ffe685672c0b679212
  Author: nick.zhuyj 
  Date:   Fri Apr 8 23:48:33 2016 -0500

  Openswan/Libreswan: support sha256 for auth algorithm
  
  Add support for sha256 as it is requirement from customer.
  Currently, there is no ike/esp fields in strongswan ipsec.conf
  template, so by default. sha256 is used. But for openswan auth
  algorithm is get from configuration, so only sha1 is supported.
  This patch enable Openswan/Libreswan to support sha256.
  
  Note: this change is DocImpact and APIImpact
  
  Change-Id: I02c80ec3494eb0edef2fdaa5d21ca0c3bbcacac2
  Closes-Bug: #1567846

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570892/+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 1492254] Re: neutron should not try to bind port on compute with hypervisor_type ironic

[Timur Nurlygayanov]

** Project changed: neutron => mos

** Also affects: mos/10.0.x
   Importance: Undecided
   Status: New

** Also affects: mos/9.0.x
   Importance: Undecided
   Status: Confirmed

** Changed in: mos/10.0.x
 Assignee: (unassigned) => MOS Neutron (mos-neutron)

** Changed in: mos/9.0.x
 Assignee: (unassigned) => MOS Neutron (mos-neutron)

** Changed in: mos/10.0.x
Milestone: None => 10.0

** Changed in: mos/9.0.x
Milestone: None => 9.0

** Changed in: mos/10.0.x
   Importance: Undecided => High

** Changed in: mos/9.0.x
   Importance: Undecided => High

** Changed in: mos/10.0.x
   Status: New => Confirmed

** Tags added: area-neutron

** Tags removed: swarm-blocker
** Tags added: area-ironic

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

Title:
  neutron should not try to bind port on compute with hypervisor_type
  ironic

Status in neutron:
  Confirmed

Bug description:
  Neutron tries to bind port on compute where instance is launched.  It
  doesn't make sense when hypervisor_type is ironic, since VM  does not
  live on hypervisor in this case.  Furthermore it leads to failed
  provisioning of baremetal node, when neutron is not configured on
  ironic compute node.

  Setup:
  node-1: controller
  node-2: ironic-compute without neutron

  neutron-server.log: http://paste.openstack.org/show/445388/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492254/+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 1492254] Re: neutron should not try to bind port on compute with hypervisor_type ironic

[Timur Nurlygayanov]

** No longer affects: mos/10.0.x

** No longer affects: mos/9.0.x

** Project changed: mos => neutron

** Changed in: neutron
Milestone: 9.0 => None

** Changed in: neutron
 Assignee: MOS Neutron (mos-neutron) => (unassigned)

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

Title:
  neutron should not try to bind port on compute with hypervisor_type
  ironic

Status in neutron:
  Confirmed

Bug description:
  Neutron tries to bind port on compute where instance is launched.  It
  doesn't make sense when hypervisor_type is ironic, since VM  does not
  live on hypervisor in this case.  Furthermore it leads to failed
  provisioning of baremetal node, when neutron is not configured on
  ironic compute node.

  Setup:
  node-1: controller
  node-2: ironic-compute without neutron

  neutron-server.log: http://paste.openstack.org/show/445388/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492254/+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 1570884] [NEW] Functional test_name_validation unexpectedly passing

[Michal Pryc]

Public bug reported:

Functional test is unexpectedly passing:

nova.tests.functional.regressions.test_bug_1541691.TestServerValidation.test_name_validation

It's because bug was fixed but test never updated.

** Affects: nova
 Importance: Undecided
 Assignee: Michal Pryc (mpryc)
 Status: In Progress

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

Title:
  Functional test_name_validation unexpectedly passing

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Functional test is unexpectedly passing:

  
nova.tests.functional.regressions.test_bug_1541691.TestServerValidation.test_name_validation

  It's because bug was fixed but test never updated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570884/+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 1492254] [NEW] neutron should not try to bind port on compute with hypervisor_type ironic

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Neutron tries to bind port on compute where instance is launched.  It
doesn't make sense when hypervisor_type is ironic, since VM  does not
live on hypervisor in this case.  Furthermore it leads to failed
provisioning of baremetal node, when neutron is not configured on ironic
compute node.

Setup:
node-1: controller
node-2: ironic-compute without neutron

neutron-server.log: http://paste.openstack.org/show/445388/

** Affects: neutron
 Importance: High
 Assignee: MOS Neutron (mos-neutron)
 Status: Confirmed


** Tags: area-ironic area-neutron need-info
-- 
neutron should not try to bind port on compute with hypervisor_type ironic
https://bugs.launchpad.net/bugs/1492254
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 1570852] [NEW] vpn service can't be active again if the openswan process crash

[MingShuang Xian]

Public bug reported:

We are using VPNaaS with OpenSwan on Ubuntu and  found that the OpenSwan
will crash when it receives some kinds of IKE2 attack packets. But I'm
not very sure the format of the packet. After the OpenSwan crash, VPN-
agent can't bring up it again and the VPN service status will be alway
DOWN.

We could use following steps to reproduce it.
1. Bring up a VPN connection and show the VPN service status
vpn-service-list
+--+--+--++
| id   | name | router_id   
 | status |
+--+--+--++
| c354e5d7-aa81-44c0-9aa7-0f157a2c7b7d | s1   | 
dde4af28-31ff-4dff-bff9-8355998c5d0c | ACTIVE |
| daa15ef8-3e99-4e37-a839-18dcf7910f9d | s2   | 
0e8fb378-3e25-493c-9610-e48025b640ba | ACTIVE |
+--+--+--++

2.  Kill the OpenSwan process

3. Show the VPN service status again
vpn-service-list
+--+--+--++
| id   | name | router_id   
 | status |
+--+--+--++
| c354e5d7-aa81-44c0-9aa7-0f157a2c7b7d | s1   | 
dde4af28-31ff-4dff-bff9-8355998c5d0c | DOWN   |
| daa15ef8-3e99-4e37-a839-18dcf7910f9d | s2   | 
0e8fb378-3e25-493c-9610-e48025b640ba | ACTIVE |
+--+--+--++

The VPN service will keep DOWN until the VPN-agent is restarted.

So we expect the VPN-agent can bring the OpenSwan process again if it
crashed.

We found this issue with vpnaas-agent master

** Affects: neutron
 Importance: Undecided
 Assignee: MingShuang Xian (xianms)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => MingShuang Xian (xianms)

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

Title:
  vpn service can't be active again if the openswan process crash

Status in neutron:
  New

Bug description:
  We are using VPNaaS with OpenSwan on Ubuntu and  found that the
  OpenSwan will crash when it receives some kinds of IKE2 attack
  packets. But I'm not very sure the format of the packet. After the
  OpenSwan crash, VPN-agent can't bring up it again and the VPN service
  status will be alway DOWN.

  We could use following steps to reproduce it.
  1. Bring up a VPN connection and show the VPN service status
  vpn-service-list
  
+--+--+--++
  | id   | name | router_id 
   | status |
  
+--+--+--++
  | c354e5d7-aa81-44c0-9aa7-0f157a2c7b7d | s1   | 
dde4af28-31ff-4dff-bff9-8355998c5d0c | ACTIVE |
  | daa15ef8-3e99-4e37-a839-18dcf7910f9d | s2   | 
0e8fb378-3e25-493c-9610-e48025b640ba | ACTIVE |
  
+--+--+--++

  2.  Kill the OpenSwan process

  3. Show the VPN service status again
  vpn-service-list
  
+--+--+--++
  | id   | name | router_id 
   | status |
  
+--+--+--++
  | c354e5d7-aa81-44c0-9aa7-0f157a2c7b7d | s1   | 
dde4af28-31ff-4dff-bff9-8355998c5d0c | DOWN   |
  | daa15ef8-3e99-4e37-a839-18dcf7910f9d | s2   | 
0e8fb378-3e25-493c-9610-e48025b640ba | ACTIVE |
  
+--+--+--++

  The VPN service will keep DOWN until the VPN-agent is restarted.

  So we expect the VPN-agent can bring the OpenSwan process again if it
  crashed.

  We found this issue with vpnaas-agent master

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570852/+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 1570833] [NEW] No ports have port_id starting with mac repeated in neutron server log

[Sridhar Venkat]

Public bug reported:

"No ports have port_id starting with " message is repeated in
neutron server log. After investigation, found that these correspond to
ports on host but not managed by neutron. Neutron agent tries to find
these ports to update and fails with these messages.

get_bound_port_context in neutron/plugins/ml2/plugin.py tries to find
these ports in database and fails with NoResultFound exception. While
handling this exception, a warning message is printed, this needs to be
converted to debug instead of info. Then unless debug is enabled, this
message will not appear in neutron server log.

** Affects: neutron
 Importance: Undecided
 Assignee: Sridhar Venkat (svenkat)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Sridhar Venkat (svenkat)

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

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

Title:
  No ports have port_id starting with mac repeated in neutron server log

Status in neutron:
  In Progress

Bug description:
  "No ports have port_id starting with " message is repeated in
  neutron server log. After investigation, found that these correspond
  to ports on host but not managed by neutron. Neutron agent tries to
  find these ports to update and fails with these messages.

  get_bound_port_context in neutron/plugins/ml2/plugin.py tries to find
  these ports in database and fails with NoResultFound exception. While
  handling this exception, a warning message is printed, this needs to
  be converted to debug instead of info. Then unless debug is enabled,
  this message will not appear in neutron server log.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570833/+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 1570801] [NEW] tasks: disk_format ignored when 'work_dir' is set

[Stuart McLaren]

Public bug reported:

If, in glance-api.conf work_dir is not defined:

[task]
#work_dir


The following API call (with disk_format=qcow2):


 POST /v2/tasks HTTP/1.1.
 User-Agent: curl/7.38.0.
 Host: localhost:9292.
 Accept: */*.
 x-auth-token: 1acdf9b1f89f4aaf983079250fcefb3d.
 Content-Length: 232.
 Content-Type: application/x-www-form-urlencoded.
 . 
 {
  "type": "import",
  "input": {
"import_from": "http://localhost:54321/hi.txt;,
"import_from_format": "bare",
"image_properties": {
  "name": "imgx",
  "disk_format": "qcow2",
  "container_format": "bare"
}
  }
 }

results in an image with disk_format qcow2:

 $ glance image-show e315a86f-5b58-478a-9f34-c99f2d6e8365
 +--+--+
 | Property | Value|
 +--+--+
 | checksum | 764efa883dda1e11db47671c4a3bbd9e |
 | container_format | bare |
 | created_at   | 2016-04-15T11:01:52Z |
 | disk_format  | qcow2|
 | id   | e315a86f-5b58-478a-9f34-c99f2d6e8365 |
 | min_disk | 0|
 | min_ram  | 0|
 | name | imgx |
 | owner| 3f2ce9bf40a443f2b072a69ff10bba92 |
 | protected| False|
 | size | 3|
 | status   | active   |
 | tags | []   |
 | updated_at   | 2016-04-15T11:01:54Z |
 | virtual_size | None |
 | visibility   | private  |
 +--+--+

If the work_dir is defined

[task]
work_dir = /tmp/work

and the same API call is made, the disk_format is not qcow2, but 'raw':

 $ glance image-show 5d6c4437-c7c2-4e95-aa81-c973fed2f2bd
 +--+--+
 | Property | Value|
 +--+--+
 | checksum | 764efa883dda1e11db47671c4a3bbd9e |
 | container_format | bare |
 | created_at   | 2016-04-15T11:03:01Z |
 | disk_format  | raw  | <<<
 | id   | 5d6c4437-c7c2-4e95-aa81-c973fed2f2bd |
 | min_disk | 0|
 | min_ram  | 0|
 | name | imgx |
 | owner| 3f2ce9bf40a443f2b072a69ff10bba92 |
 | protected| False|
 | size | 3|
 | status   | active   |
 | tags | []   |
 | updated_at   | 2016-04-15T11:03:03Z |
 | virtual_size | 512  |
 | visibility   | private  | 
 +--+--+

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  tasks: disk_format ignored when 'work_dir' is set

Status in Glance:
  New

Bug description:
  If, in glance-api.conf work_dir is not defined:

  [task]
  #work_dir

  
  The following API call (with disk_format=qcow2):

  
   POST /v2/tasks HTTP/1.1.
   User-Agent: curl/7.38.0.
   Host: localhost:9292.
   Accept: */*.
   x-auth-token: 1acdf9b1f89f4aaf983079250fcefb3d.
   Content-Length: 232.
   Content-Type: application/x-www-form-urlencoded.
   . 
   {
"type": "import",
"input": {
  "import_from": "http://localhost:54321/hi.txt;,
  "import_from_format": "bare",
  "image_properties": {
"name": "imgx",
"disk_format": "qcow2",
"container_format": "bare"
  }
}
   }

  results in an image with disk_format qcow2:

   $ glance image-show e315a86f-5b58-478a-9f34-c99f2d6e8365
   +--+--+
   | Property | Value|
   +--+--+
   | checksum | 764efa883dda1e11db47671c4a3bbd9e |
   | container_format | bare |
   | created_at   | 2016-04-15T11:01:52Z |
   | disk_format  | qcow2|
   | id   | e315a86f-5b58-478a-9f34-c99f2d6e8365 |
   | min_disk | 0|
   | 

[Yahoo-eng-team] [Bug 1570803] [NEW] complicated wrong logic inside selenium wrapper _execute method

[Sergei Chipiga]

Public bug reported:

I found that method _execute inside horizon/tests/webdriver.py has
complicated and wrong logic, that in race condition leads to long tests,
for example we have tests with 10 min duration.

The core problem is in usage while True to wait element, but implicit_wait 
delegates its to browser already.
Just we need to catch StaleElement exception, reload chain of element parents 
and then to execute command again.

** Affects: horizon
 Importance: Undecided
 Assignee: Sergei Chipiga (schipiga)
 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/1570803

Title:
  complicated wrong logic inside selenium wrapper _execute method

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  I found that method _execute inside horizon/tests/webdriver.py has
  complicated and wrong logic, that in race condition leads to long
  tests, for example we have tests with 10 min duration.

  The core problem is in usage while True to wait element, but implicit_wait 
delegates its to browser already.
  Just we need to catch StaleElement exception, reload chain of element parents 
and then to execute command again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1570803/+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 1214176] Re: Fix copyright headers to be compliant with Foundation policies

[ZhiQiang Fan]

** Changed in: devstack
   Status: Fix Committed => Fix Released

** Changed in: tempest
   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/1214176

Title:
  Fix copyright headers to be compliant with Foundation policies

Status in Ceilometer:
  Fix Released
Status in devstack:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  Fix Released
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released

Bug description:
  Correct the copyright headers to be consistent with the policies
  outlined by the OpenStack Foundation at http://www.openstack.org/brand
  /openstack-trademark-policy/

  Remove references to OpenStack LLC, replace with OpenStack Foundation

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1214176/+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 1570719] Re: Compute node failed to create vm instance on launching command openstack server create

[Sylvain Bauza]

MessagingTimeout is most of the time due to a configuration error where
the request from the API is not able to go to the compute node for
creating the instance, hence the error (because the message queue is
maybe not there, or because the creds are not good, etc.)

Please make sure your configuration is okay (and please use nova list
for checking, insteand of openstackclient) and in case you think it's
not a deployment issue, please modify back that bug report state to New.

** Changed in: nova
   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/1570719

Title:
   Compute node failed to create vm instance on launching command
  openstack server create

Status in OpenStack Compute (nova):
  Invalid

Bug description:
   Compute node failed to create vm instance on launching command
  openstack server create.

  [admin@controller ~]$ openstack server create --flavor m1.tiny --image cirros 
\
  >   --nic net-id=1aabac77-e3d1-4f4c-bfa0-dc32d24c0776 --security-group 
default \
  >   --key-name mykey selfservice-instance
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-e63e0908-befa-43d5-b8a7-ec00a8b623a9)
  [admin@controller ~]$


  
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in 
run_subcommand
  result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/openstackclient/common/command.py", 
line 38, in run
  return super(Command, self).run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
  column_names, data = self.take_action(parsed_args)
File 
"/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", line 
519, in take_action
  server = compute_client.servers.create(*boot_args, **boot_kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 
1233, in create
  **boot_kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 667, 
in _boot
  return_raw=return_raw, **kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 345, in 
_create
  resp, body = self.api.client.post(url, body=body)
File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 179, 
in post
  return self.request(url, 'POST', **kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 94, in 
request
  raise exceptions.from_response(resp, body, url, method)
  ClientException: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
  clean_up CreateServer: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 118, 
in run
  ret_val = super(OpenStackShell, self).run(argv)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 226, in run
  result = self.run_subcommand(remainder)
File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 153, 
in run_subcommand
  ret_value = super(OpenStackShell, self).run_subcommand(argv)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in 
run_subcommand
  result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/openstackclient/common/command.py", 
line 38, in run
  return super(Command, self).run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
  column_names, data = self.take_action(parsed_args)
File 
"/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", line 
519, in take_action
  server = compute_client.servers.create(*boot_args, **boot_kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 
1233, in create
  **boot_kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 667, 
in _boot
  return_raw=return_raw, **kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 345, in 
_create
  resp, body = self.api.client.post(url, body=body)
File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 179, 
in post
  return self.request(url, 'POST', **kwargs)
File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 94, in 
request
  raise 

[Yahoo-eng-team] [Bug 1570471] Re: reset-state on shelve-offloaded server makes it unusable

[Sylvain Bauza]

(meh, tab+space posted my comment)

I was saying :


Maybe we could change the API behaviour to return a 401 when someone is asking 
to reset-state when the instance is not in ERROR state?

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

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

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

Title:
  reset-state on shelve-offloaded server makes it unusable

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  shelve_offloading a server, and then resetting it state, makes it
  unavailable for any command:

  shoham@ubuntu:~/devstack$ nova list
  nova 
s+--+--+++-+--+
  | ID   | Name | Status | Task State | Power 
State | Networks |
  
+--+--+++-+--+
  | 1abddec6-06a3-4e91-bf47-899a0b76c1dd | b| ACTIVE | -  | Running 
| private=10.0.0.2 |
  
+--+--+++-+--+
  shoham@ubuntu:~/devstack$ nova shelve b 
  shoham@ubuntu:~/devstack$ nova list
  
+--+--+---++-+--+
  | ID   | Name | Status| Task 
State | Power State | Networks |
  
+--+--+---++-+--+
  | 1abddec6-06a3-4e91-bf47-899a0b76c1dd | b| SHELVED_OFFLOADED | - 
 | Shutdown| private=10.0.0.2 |
  
+--+--+---++-+--+
  shoham@ubuntu:~/devstack$ nova reset-state --active b
  Reset state for server b succeeded; new state is active
  shoham@ubuntu:~/devstack$ nova list
  
+--+--+++-+--+
  | ID   | Name | Status | Task State | Power 
State | Networks |
  
+--+--+++-+--+
  | 1abddec6-06a3-4e91-bf47-899a0b76c1dd | b| ACTIVE | -  | 
Shutdown| private=10.0.0.2 |
  
+--+--+++-+--+
  shoham@ubuntu:~/devstack$ nova stop b
  Instance 1abddec6-06a3-4e91-bf47-899a0b76c1dd is not ready (HTTP 409) 
(Request-ID: req-35fbdc75-9465-48dc-a2b6-321568d953cd)
  ERROR (CommandError): Unable to stop the specified server(s).
  shoham@ubuntu:~/devstack$ nova list
  
+--+--+++-+--+
  | ID   | Name | Status | Task State | Power 
State | Networks |
  
+--+--+++-+--+
  | 1abddec6-06a3-4e91-bf47-899a0b76c1dd | b| ACTIVE | -  | 
Shutdown| private=10.0.0.2 |
  
+--+--+++-+--+
  shoham@ubuntu:~/devstack$ nova shelve b
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-d019cdc2-e02c-42ec-a8f7-a6ce85087ff3)

  nova version is 13.0.0.0b3.dev169

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570471/+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 1570789] [NEW] various md-* create and update api's return 500 error if 4 bytes unicode characters is passed

[Bhagyashri Shewale]

Public bug reported:

md-* create and update apis are returning 500 error when you pass 4
bytes unicode characters in the request.

Steps to reproduce:

$ glance md-object-create --schema '{}' --name  

or

$ curl -g -i -X POST
http://172.31.21.75:9292/v2/metadefs/namespaces/OS::Glance::CommonImageProperties/objects
-H "User-Agent: python-glanceclient" -H "Content-Type: application/json"
-H "X-Auth-Token: 79e33042569e4c128945d623c3228ca6" -d '{"name":
"\ud83d\ude93"}'

Result:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line 
595, in main
args.func(client, args)
  File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py", line 
898, in do_md_tag_update
**fields)
  File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/metadefs.py", 
line 461, in update
self.http_client.put(url, data=tag)
  File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 
185, in put
return self.request(url, 'PUT', **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 332, in request
return self._handle_response(resp)
  File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 83, in _handle_response
raise exc.from_response(resp, resp.content)
HTTPInternalServerError: 500 Internal Server Error: The server has either erred 
or is incapable of
performing the requested operation. (HTTP 500) 500 Internal Server Error: The 
server has either erred or is
incapable of performing the requested operation. (HTTP 500)

List of APIs failing:

1. md-namespace-create
2. md-namespace-update
3. md-property-create
4. md-property-update
5. md-object-create
6. md-object-update
7. md-tag-create
8. md-tag-update

** Affects: glance
 Importance: Undecided
 Assignee: Bhagyashri Shewale (bhagyashri-shewale)
 Status: New

** Changed in: glance
 Assignee: (unassigned) => Bhagyashri Shewale (bhagyashri-shewale)

** Description changed:

  md-* create and update apis are returning 500 error when you pass 4
  bytes unicode characters in the request.
  
  Steps to reproduce:
  
  $ glance md-object-create --schema '{}' --name  
  
  or
  
- $ curl -g -i -X POST 
http://172.31.21.75:9292/v2/metadefs/namespaces/OS::Glance::CommonImageProperties/objects
 
-   -H "User-Agent: python-glanceclient" -H "Content-Type: application/json" 
-   -H "X-Auth-Token: 79e33042569e4c128945d623c3228ca6" -d '{"name": 
"\ud83d\ude93"}'
+ $ curl -g -i -X POST
+ 
http://172.31.21.75:9292/v2/metadefs/namespaces/OS::Glance::CommonImageProperties/objects
+ -H "User-Agent: python-glanceclient" -H "Content-Type: application/json"
+ -H "X-Auth-Token: 79e33042569e4c128945d623c3228ca6" -d '{"name":
+ "\ud83d\ude93"}'
  
  Result:
  
  Traceback (most recent call last):
-   File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line 
595, in main
- args.func(client, args)
-   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py", 
line 898, in do_md_tag_update
- **fields)
-   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/metadefs.py", 
line 461, in update
- self.http_client.put(url, data=tag)
-   File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", 
line 185, in put
- return self.request(url, 'PUT', **kwargs)
-   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 332, in request
- return self._handle_response(resp)
-   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 83, in _handle_response
- raise exc.from_response(resp, resp.content)
- HTTPInternalServerError: 500 Internal Server Error: The server has either 
erred or is incapable of 
- performing the requested operation. (HTTP 500) 500 Internal Server Error: The 
server has either erred or is 
+   File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line 
595, in main
+ args.func(client, args)
+   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py", 
line 898, in do_md_tag_update
+ **fields)
+   File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/metadefs.py", 
line 461, in update
+ self.http_client.put(url, data=tag)
+   File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", 
line 185, in put
+ return self.request(url, 'PUT', **kwargs)
+   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 332, in request
+ return self._handle_response(resp)
+   File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py", 
line 83, in _handle_response
+ raise exc.from_response(resp, resp.content)
+ HTTPInternalServerError: 500 Internal Server Error: The server has either 
erred or is incapable of
+ performing the requested operation. (HTTP 500) 500 Internal Server Error: The 
server has either erred or is
  incapable of performing the requested operation. (HTTP 500)
  
  

[Yahoo-eng-team] [Bug 1430232] Re: [UI] In "Job execution" i can select cluster in "Error" state

[Vitaly Gridnev]

Moving to invalid in favour of the blueprint
https://blueprints.launchpad.net/sahara/+spec/cluster-choice-for-jobs

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

** Changed in: sahara
   Importance: Low => Undecided

** Changed in: sahara
 Assignee: Michael Ionkin (msionkin) => (unassigned)

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

Title:
  [UI] In "Job execution" i can select cluster in "Error" state

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in Sahara:
  Invalid

Bug description:
  ENVIRONMENT: devstack

  STEPS TO REPRODUCE:
  1. Create Vanilla2 cluster
  2. Create wrong cluster and retain in "Error" state
  3. Create Job
  4. Click on "Launch on existing cluster"

  ACTUAL RESULT:
  In "Cluster" i can select all clusters

  EXPECTED RESULT:
  In "Cluster" i can select clusters in only "Active" state

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1430232/+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 1570776] [NEW] mcollective reconfiguration sometimes doesn't work

[Georgy Kibardin]

Public bug reported:

When mcollective is already installed in the system it may happen that
it starts before cloud-init starts to reconfigure it. This leads to a
situation when cloud-init changes mcollective config and invokes
"service mcollective start" which does nothing because the service is
already started - ending up mcollective running with a default
configuration.

The fix could be to invoke "service mcollective restart" instead.

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

Title:
  mcollective reconfiguration sometimes doesn't work

Status in cloud-init:
  New

Bug description:
  When mcollective is already installed in the system it may happen that
  it starts before cloud-init starts to reconfigure it. This leads to a
  situation when cloud-init changes mcollective config and invokes
  "service mcollective start" which does nothing because the service is
  already started - ending up mcollective running with a default
  configuration.

  The fix could be to invoke "service mcollective restart" instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1570776/+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 1569693] Re: Ports not recreated during neutron agent restart

[Rossella Sblendido]

If l2pop is not enabled, tunnel ports  are created in tunnel_sync that it's 
executed at agent startup.  In this case tunnels are opened to all the hosts. 
When l2pop is enabled only tunnels to hosts that have VM running on the same 
network are opened. 
Not sure what's happening in your environment but it looks more like some 
misconfiguration than some real bug.


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

** Tags removed: needs-attention

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

Title:
  Ports not recreated during neutron agent restart

Status in neutron:
  Invalid

Bug description:
  Ports are not recreated during neutron agent restart with l2_pop=False.
  When the agent is restarted after deleting br-int and br-tun, the bridges are 
recreated but the tunnel ports and some of the integration bridge ports are not 
recreated.
  When l2_pop is turned True, and the same procedure is retried, the bridges 
and tunnel ports to all compute nodes running instances are recreated properly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1569693/+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 1570748] [NEW] Bug: resize instance after edit flavor with horizon

[Hyun Ha]

Public bug reported:

Error occured when resize instance after edit flavor with horizon (and
also delete flavor used by instance)

Reproduce step :

1. create flavor A
2. boot instance using flavor A
3. edit flavor with horizon (or delete flavor A)
-> the result is same to edit or to delelet flavor because edit flavor 
means delete/recreate flavor)
4. resize or migrate instance
5. Error occured

Log : 
nova-compute.log
   File "/opt/openstack/src/nova/nova/conductor/manager.py", line 422, in 
_object_dispatch
 return getattr(target, method)(*args, **kwargs)

   File "/opt/openstack/src/nova/nova/objects/base.py", line 163, in wrapper
 result = fn(cls, context, *args, **kwargs)

   File "/opt/openstack/src/nova/nova/objects/flavor.py", line 132, in get_by_id
 db_flavor = db.flavor_get(context, id)

   File "/opt/openstack/src/nova/nova/db/api.py", line 1479, in flavor_get
 return IMPL.flavor_get(context, id)

   File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 233, in 
wrapper
 return f(*args, **kwargs)

   File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 4732, in 
flavor_get
 raise exception.FlavorNotFound(flavor_id=id)

 FlavorNotFound: Flavor 7 could not be found.


This Error is occured because of below code:
/opt/openstack/src/nova/nova/compute/manager.py

def resize_instance(self, context, instance, image,
reservations, migration, instance_type,
clean_shutdown=True):

if (not instance_type or
not isinstance(instance_type, objects.Flavor)):
instance_type = objects.Flavor.get_by_id(
context, migration['new_instance_type_id'])


I think that deleted flavor should be taken when resize instance. 
I tested this in stable/kilo, but I think stable/liberty and stable/mitaka has 
same bug because source code is not changed.

thanks.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: migrate nova resize

** Summary changed:

- Bug: Error resize instance after edit flavor with horizon 
+ Bug: resize instance after edit flavor with horizon

** Tags added: nova

** Tags added: migrate resize

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

Title:
  Bug: resize instance after edit flavor with horizon

Status in OpenStack Compute (nova):
  New

Bug description:
  Error occured when resize instance after edit flavor with horizon (and
  also delete flavor used by instance)

  Reproduce step :

  1. create flavor A
  2. boot instance using flavor A
  3. edit flavor with horizon (or delete flavor A)
  -> the result is same to edit or to delelet flavor because edit flavor 
means delete/recreate flavor)
  4. resize or migrate instance
  5. Error occured

  Log : 
  nova-compute.log
 File "/opt/openstack/src/nova/nova/conductor/manager.py", line 422, in 
_object_dispatch
   return getattr(target, method)(*args, **kwargs)

 File "/opt/openstack/src/nova/nova/objects/base.py", line 163, in wrapper
   result = fn(cls, context, *args, **kwargs)

 File "/opt/openstack/src/nova/nova/objects/flavor.py", line 132, in 
get_by_id
   db_flavor = db.flavor_get(context, id)

 File "/opt/openstack/src/nova/nova/db/api.py", line 1479, in flavor_get
   return IMPL.flavor_get(context, id)

 File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 233, in 
wrapper
   return f(*args, **kwargs)

 File "/opt/openstack/src/nova/nova/db/sqlalchemy/api.py", line 4732, in 
flavor_get
   raise exception.FlavorNotFound(flavor_id=id)

   FlavorNotFound: Flavor 7 could not be found.

  
  This Error is occured because of below code:
  /opt/openstack/src/nova/nova/compute/manager.py

  def resize_instance(self, context, instance, image,
  reservations, migration, instance_type,
  clean_shutdown=True):
  
  if (not instance_type or
  not isinstance(instance_type, objects.Flavor)):
  instance_type = objects.Flavor.get_by_id(
  context, migration['new_instance_type_id'])
  

  I think that deleted flavor should be taken when resize instance. 
  I tested this in stable/kilo, but I think stable/liberty and stable/mitaka 
has same bug because source code is not changed.

  thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570748/+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 1570734] [NEW] create snapshot failed with libvirt error which can pass

[Jinquan Ni]

Public bug reported:


Create instance’s snapshot failed with libvirt error. 

 The error msg as follow：

libvirtError (\'virDomainBlockJobAbort() failed\', dom=self)\n'
libvirtError: Requested operation is not valid: No active operation on device: 
drive-virtio-disk0\n'


“virDomainBlockJobAbort”  used to abort block job, the error will be raise if 
device has no block job.

Pass this exception is the  correct way to handling.  However, the
current process did not do.

** Affects: nova
 Importance: Undecided
 Assignee: Jinquan Ni (ni-jinquan)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Jinquan Ni (ni-jinquan)

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

Title:
  create snapshot failed with libvirt error which can pass

Status in OpenStack Compute (nova):
  New

Bug description:
  
  Create instance’s snapshot failed with libvirt error. 

   The error msg as follow：

  libvirtError (\'virDomainBlockJobAbort() failed\', dom=self)\n'
  libvirtError: Requested operation is not valid: No active operation on 
device: drive-virtio-disk0\n'

  
  “virDomainBlockJobAbort”  used to abort block job, the error will be raise if 
device has no block job.

  Pass this exception is the  correct way to handling.  However, the
  current process did not do.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570734/+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 1570719] [NEW] Compute node failed to create vm instance on launching command openstack server create

[amitchandpurkar]

Public bug reported:

 Compute node failed to create vm instance on launching command
openstack server create.

[admin@controller ~]$ openstack server create --flavor m1.tiny --image cirros \
>   --nic net-id=1aabac77-e3d1-4f4c-bfa0-dc32d24c0776 --security-group default \
>   --key-name mykey selfservice-instance
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-e63e0908-befa-43d5-b8a7-ec00a8b623a9)
[admin@controller ~]$


Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/site-packages/openstackclient/common/command.py", 
line 38, in run
return super(Command, self).run(parsed_args)
  File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", 
line 519, in take_action
server = compute_client.servers.create(*boot_args, **boot_kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 1233, 
in create
**boot_kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 667, 
in _boot
return_raw=return_raw, **kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 345, in 
_create
resp, body = self.api.client.post(url, body=body)
  File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 179, 
in post
return self.request(url, 'POST', **kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 94, in 
request
raise exceptions.from_response(resp, body, url, method)
ClientException: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
clean_up CreateServer: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 118, 
in run
ret_val = super(OpenStackShell, self).run(argv)
  File "/usr/lib/python2.7/site-packages/cliff/app.py", line 226, in run
result = self.run_subcommand(remainder)
  File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 153, 
in run_subcommand
ret_value = super(OpenStackShell, self).run_subcommand(argv)
  File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in 
run_subcommand
result = cmd.run(parsed_args)
  File "/usr/lib/python2.7/site-packages/openstackclient/common/command.py", 
line 38, in run
return super(Command, self).run(parsed_args)
  File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
column_names, data = self.take_action(parsed_args)
  File "/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", 
line 519, in take_action
server = compute_client.servers.create(*boot_args, **boot_kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 1233, 
in create
**boot_kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/v2/servers.py", line 667, 
in _boot
return_raw=return_raw, **kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 345, in 
_create
resp, body = self.api.client.post(url, body=body)
  File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 179, 
in post
return self.request(url, 'POST', **kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 94, in 
request
raise exceptions.from_response(resp, body, url, method)
ClientException: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-c5dadd4a-35cc-4abe-a9ad-e2e9dda15b88)


Error:

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

Title:
   Compute node failed to create vm instance on launching command
  openstack server create

Status in OpenStack Compute (nova):
  New

Bug description:
   Compute node failed to create vm instance on launching command
  openstack server create.

  [admin@controller ~]$ openstack server create --flavor m1.tiny --image cirros 
\
  >   --nic net-id=1aabac77-e3d1-4f4c-bfa0-dc32d24c0776 --security-group 
default \
  >   --key-name mykey selfservice-instance
  Unexpected API