[Yahoo-eng-team] [Bug 1741613] Re: manila-ui related document in horizon should be moved to manila-ui doc
Reviewed: https://review.openstack.org/531543 Committed: https://git.openstack.org/cgit/openstack/manila-ui/commit/?id=28a96c3577e5062dc89eac548acfff5466c7579c Submitter: Zuul Branch:master commit 28a96c3577e5062dc89eac548acfff5466c7579c Author: Akihiro Motoki Date: Sat Jan 6 20:48:55 2018 +0900 Import user and admin guide from horizon User and admin guide was moved accidentally from openstack-manuals to horizon during the doc-migration in Pike. This commit moves them from horizon to manila-ui repository for better future maintenance. Change-Id: I918dfcbb6d5498c2a2732c0ae7627da261bf4b87 Closes-Bug: #1741613 ** Changed in: manila-ui 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/1741613 Title: manila-ui related document in horizon should be moved to manila-ui doc Status in OpenStack Dashboard (Horizon): In Progress Status in manila-ui: Fix Released Bug description: Horizon documentation contains manila-ui related documents [1]. They should be moved to manila-ui document because the horizon team cannot take care of them. [1] https://docs.openstack.org/horizon/latest/user/manage-shares.html [2] https://docs.openstack.org/horizon/latest/admin/manage-shares.html To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1741613/+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 1743445] Re: Switch from msgpack-python to msgpack
** Changed in: python-tooz Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1743445 Title: Switch from msgpack-python to msgpack Status in OpenStack Identity (keystone): New Status in OpenStack Global Requirements: New Status in oslo.privsep: New Status in oslo.serialization: New Status in tooz: Fix Released Bug description: msgpack-python has been renamed to msgpack, see https://pypi.python.org/pypi/msgpack-python/0.5.1: This package is deprecated. Install msgpack instead. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1743445/+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 1744032] [NEW] Hyper-V: log warning on PortBindingFailed exception
Public bug reported: Description === When spawning an Hyper-V instance with NICs having the vif_type "hyperv", neutron will fail to bind the port to the Hyper-V host if the neutron server doesn't have the "hyperv" mechanism driver installed and configured, resulting in a PortBindingFailed exception on the nova- compute side. When this exception is encountered, the logs will say to check the neutron-server logs, but the problem and its solution are not obvious or clear, resulting in plenty of questions / reports, all having the same solution: install networking-hyperv and configure neutron-server to use the "hyperv" mechanism_driver. Steps to reproduce == 1. Do not configure neutron-server with a "hyperv" mechanism_driver. 2. Spawn an instance having NICs with the vif_type "hyperv". Expected result === PortBindingFailed, and a clear explanation and / or solution for it. After the execution of the steps above, what should have happened if the issue wasn't present? Actual result = PortBindingFailed, telling users to check the neutron-server logs, which doesn't contain the obvious problem / solution. Environment === Hyper-V compute nodes, with neutron-hyperv-agent agent. Any OpenStack version. Logs & Configs == Logs: http://paste.openstack.org/show/646888/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) -- 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/1744032 Title: Hyper-V: log warning on PortBindingFailed exception Status in OpenStack Compute (nova): New Bug description: Description === When spawning an Hyper-V instance with NICs having the vif_type "hyperv", neutron will fail to bind the port to the Hyper-V host if the neutron server doesn't have the "hyperv" mechanism driver installed and configured, resulting in a PortBindingFailed exception on the nova-compute side. When this exception is encountered, the logs will say to check the neutron-server logs, but the problem and its solution are not obvious or clear, resulting in plenty of questions / reports, all having the same solution: install networking-hyperv and configure neutron-server to use the "hyperv" mechanism_driver. Steps to reproduce == 1. Do not configure neutron-server with a "hyperv" mechanism_driver. 2. Spawn an instance having NICs with the vif_type "hyperv". Expected result === PortBindingFailed, and a clear explanation and / or solution for it. After the execution of the steps above, what should have happened if the issue wasn't present? Actual result = PortBindingFailed, telling users to check the neutron-server logs, which doesn't contain the obvious problem / solution. Environment === Hyper-V compute nodes, with neutron-hyperv-agent agent. Any OpenStack version. Logs & Configs == Logs: http://paste.openstack.org/show/646888/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744032/+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 1603121] Re: db_sync doesn't work with sql_mode = 'TRADITIONAL'
** Changed in: keystone
Status: Expired => Fix Committed
** Changed in: keystone
Status: Fix Committed => Confirmed
--
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/1603121
Title:
db_sync doesn't work with sql_mode = 'TRADITIONAL'
Status in OpenStack Identity (keystone):
Confirmed
Bug description:
Hi
The keystone-manage db_sync command fails with the following error :
2016-07-14 16:13:17.670 19170 ERROR keystone DBError:
(_mysql_exceptions.ProgrammingError) (1064, 'You have an error in your
SQL syntax; check the manual that corresponds to your MariaDB server
version for the right syntax to use near \'"keystone"\' at line 1')
[SQL: 'SHOW FULL TABLES FROM "keystone"']
OS: Debian 8.5
Keystone ver : 2:9.0.0-2~bpo8+1
Mysql: Server version: 5.5.44-MariaDB-log MariaDB Server
The problem seems to be related with :
cfg.StrOpt('mysql_sql_mode',
default='TRADITIONAL',
from /usr/lib/python2.7/dist-packages/oslo_db/options.py
It seems that on MariaDB if you set:
set session sql_mode = 'TRADITIONAL';
the query :
show full tables from "keystone"
fails
I've solve the problem by adding ANSI to default sql mode:
cfg.StrOpt('mysql_sql_mode',
default='TRADITIONAL,ANSI',
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1603121/+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 1739571] Re: Can't delete root resource provider because of the self foreign key
Reviewed: https://review.openstack.org/529519
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=4dd1406289825554aa48522454de473dff103c0d
Submitter: Zuul
Branch:master
commit 4dd1406289825554aa48522454de473dff103c0d
Author: Yikun Jiang
Date: Thu Dec 21 16:11:37 2017 +0800
[placement] Fix resource provider delete
Due to foreign key constraints for the
resource_provider.root_provider_id in mysql and the way of column
filling it is impossible to delete newly created RP now.
Patch sets root_provider_id to NULL before deletion
if root_provider_id == id.
Closes-Bug: #1739571
Co-Authored-by: Andrey Volkov
Change-Id: I256c901fdc02b1f764ea9f8d1a1a708e82cc369a
** 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/1739571
Title:
Can't delete root resource provider because of the self foreign key
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Description
===
Current, we can't delete the root resource provider record
because it has a foreign key reference it id on itself, we will
get back DBReferenceError, the reason is "Cannot delete or
update a parent row: a foreign key constraint fails".
NOTE: it is a essential case(just create and delete), but it doesn't
be triggered in test case because SQLLite allow us to delete it, but
we found this error in MYSQL database.
Steps to reproduce
==
1. First create a resource provider without parent uuid.
curl -X POST http://10.76.6.31/placement/resource_providers -H "X-Auth-Token:
$TOKEN" -H "OpenStack-API-Version: placement 1.15" -H "Accept:
application/json" -H "Content-Type: application/json" -d '{"name": "rp1",
"uuid": "7d2590ae--4080-9306-058b4c915e32"}'
We fill the id as it default the root_provider_uuid, code as below:
https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/objects/resource_provider.py#L802-L809
2. Ensure it has been created.
curl -X GET
http://10.76.6.31/placement/resource_providers/7d2590ae--4080-9306-058b4c915e32
-H "X-Auth-Token: $TOKEN" -H "OpenStack-API-Version: placement 1.15" -H
"Accept: application/json"
3. Try delete it
curl -X DELETE
http://10.76.6.31/placement/resource_providers/7d2590ae--4080-9306-058b4c915e32
-H "X-Auth-Token: $TOKEN" -H "OpenStack-API-Version: placement 1.15" -H
"Accept: application/json"
yea, we can't delete it, and get back 500 ERROR: {"computeFault":
{"message": "The server has either erred or is incapable of performing
the requested operation.", "code": 500}}
Logs & Traceback
==
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack
[req-9975de8b-6784-4555-981c-fb57314535bc admin admin] Caught error:
(pymysql.err.IntegrityError) (1451, u'Cannot delete or update a parent row: a
foreign key constraint fails (`nova_api`.`resource_providers`, CONSTRAINT
`resource_providers_ibfk_1` FOREIGN KEY (`root_provider_id`) REFERENCES
`resource_providers` (`id`))') [SQL: u'DELETE FROM resource_providers WHERE
resource_providers.id = %(id_1)s'] [parameters: {u'id_1': 3}]:
DBReferenceError: (pymysql.err.IntegrityError) (1451, u'Cannot delete or update
a parent row: a foreign key constraint fails (`nova_api`.`resource_providers`,
CONSTRAINT `resource_providers_ibfk_1` FOREIGN KEY (`root_provider_id`)
REFERENCES `resource_providers` (`id`))') [SQL: u'DELETE FROM
resource_providers WHERE resource_providers.id = %(id_1)s'] [parameters:
{u'id_1': 3}]
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack Traceback (most recent
call last):
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack File
"/opt/stack/nova/nova/api/openstack/__init__.py", line 82, in __call__
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack return
req.get_response(self.application)
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1327, in send
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack application,
catch_exc_info=False)
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1291, in
call_application
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack app_iter =
application(self.environ, start_response)
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 131, in __call__
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack resp =
self.call_func(req, *args, **self.kwargs)
2017-12-21 01:14:12.019 23740 ERROR nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 196, in call_func
2017-12-21 01:14:12.019 23740
[Yahoo-eng-team] [Bug 1744062] [NEW] L3 HA: multiple agents are active at the same time
Public bug reported: This is the same issue reported in https://bugs.launchpad.net/neutron/+bug/1731595, however that is marked as 'Fix Released' and the issue is still occurring and I can't change back to 'New' so it seems best to just open a new bug. It seems as if this bug surfaces due to load issues. While the fix provided by Venkata (https://review.openstack.org/#/c/522641/) should help clean things up at the time of l3 agent restart, issues seem to come back later down the line in some circumstances. xavpaice mentioned he saw multiple routers active at the same time when they had 464 routers configured on 3 neutron gateway hosts using L3HA, and each router was scheduled to all 3 hosts. However, jhebden mentions that things seem stable at the 400 L3HA router mark, and it's worth noting this is the same deployment that xavpaice was referring to. It seems to me that something is being pushed to it's limit, and possibly once that limit is hit, master router advertisements aren't being received, causing a new master to be elected. If this is the case it would be great to get to the bottom of what resource is getting constrained. ** Affects: cloud-archive Importance: High Status: Triaged ** Affects: cloud-archive/mitaka Importance: High Status: Triaged ** Affects: cloud-archive/newton Importance: High Status: Triaged ** Affects: cloud-archive/ocata Importance: High Status: Triaged ** Affects: cloud-archive/pike Importance: High Status: Triaged ** Affects: cloud-archive/queens Importance: High Status: Triaged ** Affects: neutron Importance: Undecided Status: New ** Affects: neutron (Ubuntu) Importance: High Status: Triaged ** Affects: neutron (Ubuntu Xenial) Importance: High Status: Triaged ** Affects: neutron (Ubuntu Artful) Importance: High Status: Triaged ** Affects: neutron (Ubuntu Bionic) Importance: High Status: Triaged ** Description changed: This is the same issue as https://bugs.launchpad.net/neutron/+bug/1731595 however that bug is 'Fix Released' and the issue is still occurring. There are a lot of details - in the linked bug so I won't add them here unless it's useful. + in the linked bug so I won't add too many here. + + It seems as if this bug surfaces due to load issues. While the fix + provided by Venkata (https://review.openstack.org/#/c/522641/) should + help clean things up at the time of l3 agent restart, issues seem to + come back later down the line in some circumstances. xavpaice mentioned + he saw multiple routers active at the same time when they had 464 + routers configured on 3 neutron gateway hosts using L3HA, and each + router was scheduled to all 3 hosts. However, jhebden mentions that + things seem stable at the 400 L3HA router mark, and it's worth noting + this is the same deployment that xavpaice was referring to. + + It seems to me that something is being pushed to it's limit, and + possibly once that limit is hit, master router advertisements aren't + being received, causing a new master to be elected. If this is the case + it would be great to get to the bottom of what resource is getting + constrained. ** Also affects: neutron (Ubuntu) Importance: Undecided Status: New ** Description changed: - This is the same issue as - https://bugs.launchpad.net/neutron/+bug/1731595 however that bug is 'Fix - Released' and the issue is still occurring. There are a lot of details - in the linked bug so I won't add too many here. - - It seems as if this bug surfaces due to load issues. While the fix - provided by Venkata (https://review.openstack.org/#/c/522641/) should - help clean things up at the time of l3 agent restart, issues seem to - come back later down the line in some circumstances. xavpaice mentioned - he saw multiple routers active at the same time when they had 464 - routers configured on 3 neutron gateway hosts using L3HA, and each - router was scheduled to all 3 hosts. However, jhebden mentions that - things seem stable at the 400 L3HA router mark, and it's worth noting - this is the same deployment that xavpaice was referring to. - - It seems to me that something is being pushed to it's limit, and - possibly once that limit is hit, master router advertisements aren't - being received, causing a new master to be elected. If this is the case - it would be great to get to the bottom of what resource is getting - constrained. + - ** No longer affects: neutron ** Summary changed: - L3 HA: multiple agents are active at the same time + - ** Changed in: neutron (Ubuntu) Status: New => Incomplete ** Summary changed: - - + L3 HA: multiple agents are active at the same time ** Description changed: - - + This is the same issue reported in + https://bugs.launchpad.net/neutron/+bug/1731595, however that is marked + as 'Fix Released' and the issue is still occurring. + + It seems
[Yahoo-eng-team] [Bug 1744079] [NEW] disk over-commit still not correctly calculated during live migration
Public bug reported: Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is disabled for microversion >=2.25 anyway. IOW we should fix it, but it's probably not a high priority. ** 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/1744079 Title: disk over-commit still not correctly calculated during live migration Status in OpenStack Compute (nova): New Bug description: Change I8a705114d47384fcd00955d4a4f204072fed57c2 (written by me... sigh) addressed a bug which prevented live migration to a target host with overcommitted disk when made with microversion <2.25. It achieved this, but the fix is still not correct. We now do: if disk_over_commit: disk_available_gb = dst_compute_info['local_gb'] Unfortunately local_gb is *total* disk, not available disk. We actually want free_disk_gb. Fun fact: due to the way we calculate this for filesystems, without taking into account reserved space, this can also be negative. The test we're currently running is: could we fit this guest's allocated disks on the target if the target disk was empty. This is at least better than it was before, as we don't spuriously fail early. In fact, we're effectively disabling a test which is disabled for microversion >=2.25 anyway. IOW we should fix it, but it's probably not a high priority. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744079/+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 1744101] [NEW] vxlan interfaces doesn't get MTU
Public bug reported: When vxlans are created, f.ex. via ensure_vxlan in neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py - no mtu is assigned. This explains why we get vxlan interfaces with 1500 byte mtu even-though neutron has been instructed to use 9000 bytes mtu. The function called: def add_vxlan(self, name, vni, group=None, dev=None, ttl=None, tos=None, local=None, srcport=None, dstport=None, proxy=False): cmd = ['add', name, 'type', 'vxlan', 'id', vni] ... Creates the interface, and from what I understand mtu should be between 'add' and 'type'. I have been unable to find any other place where the mtu would be propagated to the vxlan interface and our tests indicate that it never happens. The problem is that this causes the bridge to set it self to the lower mtu and... noone is happy =) This is on: git describe 11.0.2-8-g7fd30cb (stable/pike) ** 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/1744101 Title: vxlan interfaces doesn't get MTU Status in neutron: New Bug description: When vxlans are created, f.ex. via ensure_vxlan in neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py - no mtu is assigned. This explains why we get vxlan interfaces with 1500 byte mtu even- though neutron has been instructed to use 9000 bytes mtu. The function called: def add_vxlan(self, name, vni, group=None, dev=None, ttl=None, tos=None, local=None, srcport=None, dstport=None, proxy=False): cmd = ['add', name, 'type', 'vxlan', 'id', vni] ... Creates the interface, and from what I understand mtu should be between 'add' and 'type'. I have been unable to find any other place where the mtu would be propagated to the vxlan interface and our tests indicate that it never happens. The problem is that this causes the bridge to set it self to the lower mtu and... noone is happy =) This is on: git describe 11.0.2-8-g7fd30cb (stable/pike) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1744101/+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 1744103] [NEW] nova interface-attach 500 on conflict
Public bug reported:
Nova returns with 5xx response instead of 4xx in case of user error.
In this case it is clearly user issue, the user can know the 10.0.0.3 ip
address already allocated from the subnet and it cannot be allocated
twice.
nuva must return with 409/Conflict status code and state the problem to
the user as neutron did to nova.
$ nova boot --image cirros-0.3.5-x86_64-disk --flavor 42 --nic net-
id=ef952752-b81c-478e-a114-04083c63827c test
$ nova list
+--+--+++-++
| ID | Name | Status | Task State | Power
State | Networks |
+--+--+++-++
| 7a453305-2684-4684-8005-04a98aebfc7e | test | ACTIVE | - | Running
| private=fd64:8b83:fea2:0:f816:3eff:fe5f:3da3, 10.0.0.3 |
+--+--+++-++
$ nova interface-attach 7a453305-2684-4684-8005-04a98aebfc7e
--net-id=ef952752-b81c-478e-a114-04083c63827c --fixed-ip 10.0.0.3
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-64d655fe-0564-46ec-85c2-c982d34f796c)
Jan 18 15:21:29 afazekas-1516283855.localdomain devstack@n-api.service[15371]:
DEBUG nova.api.openstack.wsgi [None req-64d655fe-0564-46ec-85c2-c982d34f796c
demo demo] Action: 'create', calling method:
Jan 18 15:21:30 afazekas-1516283855.localdomain devstack@n-api.service[15371]:
DEBUG nova.api.openstack.wsgi [None req-64d655fe-0564-46ec-85c2-c982d34f796c
demo demo] Returning 500 to user: Unexpected API Error.
Jan 18 15:21:30 afazekas-1516283855.localdomain devstack@n-api.service[15371]:
{{(pid=15372) __call__
/opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
Tested on Fedora 27 on Jan 18 2018 sources, the issue reproducible on
older versions (pike).
** Affects: nova
Importance: Undecided
Status: New
** Description changed:
Nova returns with 5xx response instead of 4xx in case of user error.
In this case it is clearly user issue, the user can know the 10.0.0.3 ip
address already allocated from the subnet and it cannot be allocated
twice.
nuva must return with 409/Conflict status code and state the problem to
the user as neutron did to nova.
$ nova boot --image cirros-0.3.5-x86_64-disk --flavor 42 --nic net-
id=ef952752-b81c-478e-a114-04083c63827c test
$ nova list
+--+--+++-++
| ID | Name | Status | Task State | Power
State | Networks |
+--+--+++-++
| 7a453305-2684-4684-8005-04a98aebfc7e | test | ACTIVE | - | Running
| private=fd64:8b83:fea2:0:f816:3eff:fe5f:3da3, 10.0.0.3 |
+--+--+++-++
$ nova interface-attach 7a453305-2684-4684-8005-04a98aebfc7e
--net-id=ef952752-b81c-478e-a114-04083c63827c --fixed-ip 10.0.0.3
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-64d655fe-0564-46ec-85c2-c982d34f796c)
Jan 18 15:21:29 afazekas-1516283855.localdomain
devstack@n-api.service[15371]: DEBUG nova.api.openstack.wsgi [None
req-64d655fe-0564-46ec-85c2-c982d34f796c demo demo] Action: 'create', calling
method:
Jan 18 15:21:30 afazekas-1516283855.localdomain
devstack@n-api.service[15371]: DEBUG nova.api.openstack.wsgi [None
req-64d655fe-0564-46ec-85c2-c982d34f796c demo demo] Returning 500 to user:
Unexpected API Error.
Jan 18 15:21:30 afazekas-1516283855.localdomain
devstack@n-api.service[15371]:
{{(pid=15372) __call__ /opt/stack/nova/nova/api/openstack/wsgi.py:1079}}
-
- Tested on Fedora 27 on Jan 18 2018 sources, the issue reproducible on older
versions (pike).
+ Tested on Fedora 27 on Jan 18 2018 sources, the issue reproducible on
+ older versions (pike).
--
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/1744103
Title:
nova interface-attach 500 on conflict
Status in OpenStack Compute (nova):
New
Bug description:
Nova returns with 5xx response instead of 4xx in case of user error.
In this case it is cl
[Yahoo-eng-team] [Bug 1743728] Re: giturl not working for api-ref (nova, neutron-lib)
Reviewed: https://review.openstack.org/534712 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=62ea2ff04dd7bb634eba5cdaf8ff1b9d7fd1ea32 Submitter: Zuul Branch:master commit 62ea2ff04dd7bb634eba5cdaf8ff1b9d7fd1ea32 Author: Stephen Finucane Date: Wed Jan 17 10:03:51 2018 + Fix openstackdocstheme options for api-ref Initialize the parameter for current openstackdocstheme so that report a bug feature works and displays all parameter including git URL and SHA. We need to add openstackdocstheme as extension so that the parameter are properly initialized. html_context is not needed anymore. The display of time of last commit is done by openstackdocstheme. Change-Id: Ic46f5ff6bc42b48ce9de5f5bf3a2193ed75fb063 Closes-Bug: #1743728 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1743728 Title: giturl not working for api-ref (nova, neutron-lib) Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: The report a bug link does not have a valid giturl for: https://developer.openstack.org/api-ref/network/ https://developer.openstack.org/api-ref/compute/ Note https://developer.openstack.org/api-ref/baremetal/ works fine. Did not check more. Note https://review.openstack.org/534666 might be part of the solution. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1743728/+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 1699060] Re: Impossible to define policy rule based on domain ID
** Changed in: manila Importance: Undecided => Wishlist ** Changed in: manila Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1699060 Title: Impossible to define policy rule based on domain ID Status in Cinder: New Status in Glance: New Status in OpenStack Heat: Triaged Status in Manila: Opinion Status in neutron: New Status in OpenStack Compute (nova): Opinion Status in watcher: New Bug description: We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. Related mail-list thread: https://openstack.nimeyo.com/115438 /openstack-dev-all-policy-rules-for-apis-based-on-domain_id To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1699060/+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 1629133] Re: New neutron subnet pool support breaks multinode testing.
** Changed in: manila Status: New => 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/1629133 Title: New neutron subnet pool support breaks multinode testing. Status in networking-bgpvpn: Fix Released Status in devstack: Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in neutron: Incomplete Status in OpenStack DBaaS (Trove): In Progress Bug description: The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts. For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools. I think the correct way to fix this is to use a much smaller subnet pool range to avoid conflicting with every possible 10.0.0.0/8 network in the wild, possibly by defaulting to the existing FIXED_RANGE information. Using the existing information will help ensure that anyone with networks in 10.0.0.0/8 will continue to work if they have specified a range that doesn't conflict using this variable. In addition to this we need to clearly document what this new stuff in devstack does and how people can work around it should they conflict with the new defaults we end up choosing. I have proposed https://review.openstack.org/379543 which mostly works except it fails one tempest test that apparently depends on this new subnet pool stuff. Specifically the V6 range isn't large enough aiui. To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1629133/+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 1699060] Re: Impossible to define policy rule based on domain ID
Agree with above. If we want this, this needs to be a general policy change across projects, and not something each project needs to address. This is a new feature request (probably for oslo.policy) and not a bug. ** Also affects: oslo.policy Importance: Undecided Status: New ** No longer affects: cinder -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1699060 Title: Impossible to define policy rule based on domain ID Status in Glance: New Status in OpenStack Heat: Triaged Status in Manila: Opinion Status in neutron: New Status in OpenStack Compute (nova): Opinion Status in oslo.policy: New Status in watcher: New Bug description: We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. Related mail-list thread: https://openstack.nimeyo.com/115438 /openstack-dev-all-policy-rules-for-apis-based-on-domain_id To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1699060/+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 1744123] [NEW] novaclient removed novaclient.v2.certs
Public bug reported: python-novaclient has removed support for its deprecated certs CLIs and python bindings in [1]. This is not in any released version yet, but once it is tagged it will impact Horizon, since it is used in [2]. [1] - https://review.openstack.org/532974 [2] - https://github.com/openstack/horizon/blob/24cc9c75fbb16962624df4aafc4874e311e9ffc1/openstack_dashboard/test/test_data/nova_data.py#L19 ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1744123 Title: novaclient removed novaclient.v2.certs Status in OpenStack Dashboard (Horizon): New Bug description: python-novaclient has removed support for its deprecated certs CLIs and python bindings in [1]. This is not in any released version yet, but once it is tagged it will impact Horizon, since it is used in [2]. [1] - https://review.openstack.org/532974 [2] - https://github.com/openstack/horizon/blob/24cc9c75fbb16962624df4aafc4874e311e9ffc1/openstack_dashboard/test/test_data/nova_data.py#L19 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1744123/+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 1724729] Re: ovs-lib not support qos type egress-policer for ovs-dpdk
Reviewed: https://review.openstack.org/513398 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1be857435288e4008a41fe67bbc8795dd3d8b134 Submitter: Zuul Branch:master commit 1be857435288e4008a41fe67bbc8795dd3d8b134 Author: Sławek Kapłoński Date: Thu Oct 19 14:13:41 2017 + Fix ingress bw limit for OVS DPDK ports For OVS based DPDK ports ingress bandwidth limit is now implemented using egress-policer qos type. Additionally limit values are set in other_config of QoS because there is no queue used in this case. This patch moves also helper methods used to conversion between bytes and bits and between bits and kilobits to neutron.common.utils to be able to use it also in ovs_lib module. Change-Id: I94d1e8dfb82df5c602476db8aaa884ae91fecd7f Closes-Bug: #1724729 ** 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/1724729 Title: ovs-lib not support qos type egress-policer for ovs-dpdk Status in neutron: Fix Released Bug description: IN the ovs-dpdk, the Qos cmd use the type "egress-policer", while now the tpye is only "linux-htb" in the ovs-lib.py. May be the type should be setted by config file, on behalf of ovs or ovs-dpdk. The ovs-dpdk qos configure file can be seen: http://docs.openvswitch.org/en/latest/howto/dpdk/ And the normal ovs qos configure file is here: http://docs.openvswitch.org/en/latest/faq/qos/ And the whole cmd line is different. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1724729/+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 1715486] Re: py35 tests failing due to iso8601 module change
glance: http://logs.openstack.org/73/535173/3/check/cross-glance-
py35/9b06b73/testr_results.html.gz
** Also 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/1715486
Title:
py35 tests failing due to iso8601 module change
Status in Cinder:
Fix Released
Status in CloudPulse:
In Progress
Status in Cue:
In Progress
Status in Glance:
New
Status in IoTronic:
Fix Released
Status in Ironic:
Fix Released
Status in Magnum:
Fix Released
Status in Manila:
Fix Released
Status in masakari:
Fix Released
Status in Mogan:
Fix Released
Status in oslo.versionedobjects:
Fix Committed
Status in senlin:
Fix Released
Status in watcher:
Fix Released
Bug description:
Python 3.x moved where the iso8601 Utc() method is located. Need to
handle new path.
Traceback (most recent call last):
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/tests/unit/api/contrib/test_admin_actions.py",
line 829, in setUp
self.svc = self.start_service('volume', host='test')
File "/home/jenkins/workspace/gate-cross-cinder-python35/cinder/test.py",
line 323, in start_service
svc = service.Service.create(**kwargs)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
425, in create
cluster=cluster)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
203, in __init__
self._create_service_ref(ctxt, manager_class.RPC_API_VERSION)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
374, in _create_service_ref
service_ref.create()
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/objects/service.py",
line 143, in create
self._from_db_object(self._context, self, db_service)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/objects/service.py",
line 86, in _from_db_object
service[name] = value
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/base.py",
line 765, in __setitem__
setattr(self, name, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/base.py",
line 72, in setter
field_value = field.coerce(self, name, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/fields.py",
line 195, in coerce
return self._type.coerce(obj, attr, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/fields.py",
line 471, in coerce
value = value.replace(tzinfo=iso8601.iso8601.Utc())
AttributeError: module 'iso8601.iso8601' has no attribute 'Utc'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1715486/+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 1744160] [NEW] Change in iso8601 1.12.0 date format breaks parsing with py35
Public bug reported: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' ** Affects: cinder Importance: Undecided Status: New ** Affects: glance Importance: Undecided Status: New ** Affects: keystone Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Affects: oslo.utils Importance: Undecided Status: New ** Also affects: cinder Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New ** Also affects: glance Importance: Undecided Status: New ** Also affects: keystone Importance: Undecided Status: New ** Summary changed: - Change in iso8601 1.12.0 date format breaks parsing + Change in iso8601 1.12.0 date format breaks parsing with py35 -- 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/1744160 Title: Change in iso8601 1.12.0 date format breaks parsing with py35 Status in Cinder: New Status in Glance: New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): New Status in oslo.utils: New Bug description: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1744160/+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 1715486] Re: py35 tests failing due to iso8601 module change
Opened https://bugs.launchpad.net/glance/+bug/1744160 to track this new
failure.
** No longer affects: glance
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1715486
Title:
py35 tests failing due to iso8601 module change
Status in Cinder:
Fix Released
Status in CloudPulse:
In Progress
Status in Cue:
In Progress
Status in IoTronic:
Fix Released
Status in Ironic:
Fix Released
Status in Magnum:
Fix Released
Status in Manila:
Fix Released
Status in masakari:
Fix Released
Status in Mogan:
Fix Released
Status in oslo.versionedobjects:
Fix Committed
Status in senlin:
Fix Released
Status in watcher:
Fix Released
Bug description:
Python 3.x moved where the iso8601 Utc() method is located. Need to
handle new path.
Traceback (most recent call last):
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/tests/unit/api/contrib/test_admin_actions.py",
line 829, in setUp
self.svc = self.start_service('volume', host='test')
File "/home/jenkins/workspace/gate-cross-cinder-python35/cinder/test.py",
line 323, in start_service
svc = service.Service.create(**kwargs)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
425, in create
cluster=cluster)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
203, in __init__
self._create_service_ref(ctxt, manager_class.RPC_API_VERSION)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/service.py", line
374, in _create_service_ref
service_ref.create()
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/objects/service.py",
line 143, in create
self._from_db_object(self._context, self, db_service)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/cinder/objects/service.py",
line 86, in _from_db_object
service[name] = value
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/base.py",
line 765, in __setitem__
setattr(self, name, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/base.py",
line 72, in setter
field_value = field.coerce(self, name, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/fields.py",
line 195, in coerce
return self._type.coerce(obj, attr, value)
File
"/home/jenkins/workspace/gate-cross-cinder-python35/.tox/py35/lib/python3.5/site-packages/oslo_versionedobjects/fields.py",
line 471, in coerce
value = value.replace(tzinfo=iso8601.iso8601.Utc())
AttributeError: module 'iso8601.iso8601' has no attribute 'Utc'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1715486/+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 1743579] Re: Concurrent report_state from multiple agents: segment_host_mapping fails - StaleDataError
Reviewed: https://review.openstack.org/534449
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=f84781f246004651e0636f8b6507ee1e48bac6b0
Submitter: Zuul
Branch:master
commit f84781f246004651e0636f8b6507ee1e48bac6b0
Author: Harald Jensas
Date: Tue Jan 16 21:15:22 2018 +0100
Add retry decorator update_segment_host_mapping()
When multiple agents register at the same time there is
a possible race condition causing segment host mappings
updates to fail. StaleDataError raised by SQLAlchemy ORM.
Adding retry_if_session_inactive() decorator to the method
fixes the issue.
Also serialize the method with lockutils. It takes 25+
seconds to update segment host mappings for 10 agents with
the retry decorator alone. With the method serialized the
same operation completes in less than 1 second. The retry
decorator is still required for active/active scenarios.
Closes-Bug: #1743579
Change-Id: I616457f094d000a4016c610b454be8269d9b4948
** 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/1743579
Title:
Concurrent report_state from multiple agents: segment_host_mapping
fails - StaleDataError
Status in neutron:
Fix Released
Bug description:
When multiple host agents rapidly report_state for the first time we
get StaleDataError and _update_segment_host_mapping_for_agent does not
complete for all hosts.
Attached is a file with logs as well as reproducer script and
instruction on how to set up devstack environment similar to the one I
am using.
To Reproduce:
-
Run script with the delay, time.sleep(10), commented.
Results:
* 2x StaleDataError
* Only 1 attempt to add host to placement/host-aggregate.
MariaDB [neutron]> MariaDB [neutron]> SELECT * FROM segmenthostmappings;
+--+-+
| segment_id | host|
+--+-+
| a974ae4c-1389-4e41-9ab9-820165c26acd | host2 |
| a974ae4c-1389-4e41-9ab9-820165c26acd | routed-devstack.lab.example.com |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | host2 |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | routed-devstack.lab.example.com |
| ec7717dd-8533-464f-a3c8-4ecc7dc08d10 | host2 |
| ec7717dd-8533-464f-a3c8-4ecc7dc08d10 | routed-devstack.lab.example.com |
+--+-+
Conclutions:
* 2x StaleDataError
* 1x successfull _update_segment_host_mapping after_create.
*** We should see 3x attempts to add to placement/host-aggregate, one
for each host agent.
Running the reproducer script with the delay uncommented (No issue):
Run script with the delay, time.sleep(10), enabled.
Results:
* No StaleDataError
* 3 attempts to add the host to placemenb/host-aggregate.
MariaDB [neutron]> SELECT * FROM segmenthostmappings;
+--+-+
| segment_id | host|
+--+-+
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host0 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host1 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host2 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | routed-devstack.lab.example.com |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host0 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host1 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host2 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | routed-devstack.lab.example.com |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host0 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host1 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host2 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | routed-devstack.lab.example.com |
+--+-+
Conclution:
* 3x successfull _update_segment_host_mapping after_create.
** NOTE: **
The RESP BODY: {"itemNotFound": {"message": "Compute host host1 could not be
found.", "code": 404}} errors in the logs is expected, the fake host is not in
Nova, so this is expeced.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1743579/+subscriptions
--
Mailing list: https://
[Yahoo-eng-team] [Bug 1744160] Re: Change in iso8601 1.12.0 date format breaks parsing with py35
Traced this through, and seems to be coming from the fact that iso8601 switched from using their own internal TZ info, to using Python3's TZ info. The difference in these objects end up being that the custom iso8601 one stringifies to 'UTC', while the python one stringifies to 'UTC+00:00'. This causes problems in oslo.versionedobjects to_primative call here: https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/_utils.py#L28 Could be simple enough as change "tz == 'UTC'" to something like "'UTC' in tz". I will try that out locally and see how it goes. ** Also affects: oslo.versionedobjects Importance: Undecided Status: New ** Changed in: oslo.versionedobjects Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1744160 Title: Change in iso8601 1.12.0 date format breaks parsing with py35 Status in Cinder: New Status in Glance: New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): New Status in oslo.utils: New Status in oslo.versionedobjects: Confirmed Bug description: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1744160/+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 1744182] [NEW] can not create instance when using vmware nova driver
Public bug reported:
Hi,everybody.
Environment
===
OpenStack: pike version install with kolla-ansible
OS:Centos7.4
Logs
==
I am getting the follow error when I try to create a instance from vmdk.
2018-01-18 06:40:01.045 7 DEBUG oslo_concurrency.lockutils
[req-bc40738a-a3ee-4d9c-bd67-32e6fb32df08 32e0ed602bc549f48f7caf401420b628
7179dd1be7ef4cf2906b41b97970a0f6 - default default] Releasing semaphore
"refresh_cache-b4b7cabe-f78b-40d9-8856-3b6c213efd73" lock
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:225
2018-01-18 06:40:01.046 7 DEBUG nova.compute.manager
[req-bc40738a-a3ee-4d9c-bd67-32e6fb32df08 32e0ed602bc549f48f7caf401420b628
7179dd1be7ef4cf2906b41b97970a0f6 - default default] [instance:
b4b7cabe-f78b-40d9-8856-3b6c213efd73] Instance network_info: |[{"profile": {},
"ovs_interfaceid": "61393d4a-5b1f-4113-ac7b-251dc4afe066",
"preserve_on_delete": false, "network": {"bridge": "br-int", "subnets":
[{"ips": [{"meta": {}, "version": 4, "type": "fixed", "floating_ips": [],
"address": "10.0.0.9"}], "version": 4, "meta": {"dhcp_server": "10.0.0.2"},
"dns": [{"meta": {}, "version": 4, "type": "dns", "address": "8.8.8.8"}],
"routes": [], "cidr": "10.0.0.0/24", "gateway": {"meta": {}, "version": 4,
"type": "gateway", "address": "10.0.0.1"}}], "meta": {"injected": false,
"tenant_id": "7179dd1be7ef4cf2906b41b97970a0f6", "mtu": 1450}, "id":
"afa8c911-a770-4b9d-a8e8-13c65e691d46", "label": "demo-net"}, "devname":
"tap61393d4a-5b", "vnic_type": "normal", "qbh_params": null, "meta": {},
"details": {"port_filter": true, "datapath_type": "system", "ovs_hybrid_plug":
true}, "address": "fa:16:3e:b5:bd:28", "active": false, "type": "ovs", "id":
"61393d4a-5b1f-4113-ac7b-251dc4afe066", "qbg_params": null}]|
_allocate_network_async
/var/lib/kolla/venv/lib/python2.7/site-packages/nova/compute/manager.py:1387
2018-01-18 06:40:01.075 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-294a05f6-f165-425d-bdce-df36982ae5b3 request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.090 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-d5435f67-2b69-44c9-996d-1550f6139c9d request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.105 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-b4d7bf28-4877-40fc-a425-2f520501e3f8 request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.118 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-1c210dfa-c695-4a88-bfc9-140ae913c53e request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.132 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-04a1a599-5fe5-41d1-838f-5a50a76cf9c2 request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.143 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-6681887f-3579-40ec-b7c3-0bd5d1f51fb2 request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.154 7 DEBUG oslo_vmware.service [-] Invoking
PropertyCollector.RetrievePropertiesEx with
opID=oslo.vmware-72e556d4-863d-4f7e-9e91-bb3396f86fb2 request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.169 7 DEBUG nova.virt.vmwareapi.vm_util
[req-bc40738a-a3ee-4d9c-bd67-32e6fb32df08 32e0ed602bc549f48f7caf401420b628
7179dd1be7ef4cf2906b41b97970a0f6 - default default] [instance:
b4b7cabe-f78b-40d9-8856-3b6c213efd73] Creating VM on the ESX host create_vm
/var/lib/kolla/venv/lib/python2.7/site-packages/nova/virt/vmwareapi/vm_util.py:1312
2018-01-18 06:40:01.170 7 DEBUG oslo_vmware.service [-] Invoking
Folder.CreateVM_Task with opID=oslo.vmware-d28e35a6-3139-4592-8b9c-b9f8772f164e
request_handler
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/service.py:354
2018-01-18 06:40:01.209 7 DEBUG oslo_vmware.api
[req-bc40738a-a3ee-4d9c-bd67-32e6fb32df08 32e0ed602bc549f48f7caf401420b628
7179dd1be7ef4cf2906b41b97970a0f6 - default default] Waiting for the task:
(returnval){
value = "task-137"
_type = "Task"
} to complete. wait_for_task
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/api.py:395
2018-01-18 06:40:01.224 7 DEBUG oslo_vmware.api [-] Task: {'id': task-137,
'name': CreateVM_Task} progress is 0%. _poll_task
/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_vmware/api.py:431
2018-01-18 06:40:01.325 7 DEBUG nova.compute.manager
[req-2771ee21-f6dc-46c2-9c23-4f64a6e8e4eb bfe8bd0ac2e8471f93e455f10e4f6a61
a423e2518d1e42a5
[Yahoo-eng-team] [Bug 1744195] [NEW] unit tests don't enable Foreign Key for Sqlite
Public bug reported: Now Keystone runs unit test with sqlite backend by default. But sqlite doesn't enable Foreign Key function by default. It means that we lost the case for all FK related test. Even after enabled FK for the test. There still some problems: 1. We lost root domain (<>) when setup tests. So that a lot of tests will fail. 2. Some tests, such as test_sql_upgrade and identity.backens.test_sql, use global db engine. It means that the test will meet conflict if the FK is enabled for the global db engine. So we should refactor our test code to satisfy sqilte FK function. There are some steps: 1. Add FK support for the tests. Disable it by default 2. Enable FK for the test one by one. 3. Make sure the Fk is disabled for test_sql_upgrade and identity.backens.test_sql ** 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/1744195 Title: unit tests don't enable Foreign Key for Sqlite Status in OpenStack Identity (keystone): New Bug description: Now Keystone runs unit test with sqlite backend by default. But sqlite doesn't enable Foreign Key function by default. It means that we lost the case for all FK related test. Even after enabled FK for the test. There still some problems: 1. We lost root domain (<>) when setup tests. So that a lot of tests will fail. 2. Some tests, such as test_sql_upgrade and identity.backens.test_sql, use global db engine. It means that the test will meet conflict if the FK is enabled for the global db engine. So we should refactor our test code to satisfy sqilte FK function. There are some steps: 1. Add FK support for the tests. Disable it by default 2. Enable FK for the test one by one. 3. Make sure the Fk is disabled for test_sql_upgrade and identity.backens.test_sql To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1744195/+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 1743685] Re: Resizing the window security groups causes text clipping
Reviewed: https://review.openstack.org/535003 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7d0d8be25224920885a9490962db3e4ae5bef151 Submitter: Zuul Branch:master commit 7d0d8be25224920885a9490962db3e4ae5bef151 Author: Emma Hogan Date: Thu Jan 18 15:33:40 2018 +1300 Text clippin in window security groups Fixed text overflow from form by removing limiting max-height media in scss. Change-Id: I4960a01ab2a78bb80f0877a8b5b4a3a06590b392 Closes-Bug: #1743685 ** 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/1743685 Title: Resizing the window security groups causes text clipping Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Networks-->Security Groups-->Add Rule once in the adding rule page shrinking the page causes the text to go outside of the window, making reading it difficult, and the add and cancel buttons invisible. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1743685/+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 1710792] Re: openstack server list Unexpected API Error.
[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.] ** Changed in: nova Status: Incomplete => Expired -- 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/1710792 Title: openstack server list Unexpected API Error. Status in OpenStack Compute (nova): Expired Bug description: Ubuntu Version: Ubuntu 16.04.3 LTS Openstack - Ocata Getting the below error while checking the status of my instance & unable to proceed further root@controller:~# openstack server list 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-3df735ee-cb94-45ac-8d4f-42845207091b) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1710792/+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 1744160] Re: Change in iso8601 1.12.0 date format breaks parsing with py35
** Changed in: cinder Assignee: junboli (junboli) => (unassigned) ** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Assignee: (unassigned) => junboli (junboli) -- 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/1744160 Title: Change in iso8601 1.12.0 date format breaks parsing with py35 Status in Cinder: New Status in Glance: In Progress Status in OpenStack Identity (keystone): New Status in Manila: In Progress Status in OpenStack Compute (nova): New Status in oslo.utils: New Status in oslo.versionedobjects: In Progress Bug description: New package of iso8601 returns string in the format: '2012-02-14T20:53:07UTC+00:00' instead of: '2012-02-14T20:53:07Z' This is resulting in date string comparison failures and timeutils.parse_isotime errors with: ValueError: Unable to parse date string '2014-08-08T00:00:00UTC+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1744160/+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 1728533] Re: Serial console should be resizable
Reviewed: https://review.openstack.org/513671 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=75e4e750df5cc17194c980a275f57bd130bb9852 Submitter: Zuul Branch:master commit 75e4e750df5cc17194c980a275f57bd130bb9852 Author: Shu Muto Date: Thu Oct 19 20:25:57 2017 +0900 Make serial console resizable This patch makes serial console resizable according to parent element size like window or div container. Change-Id: Ie4bc4d7302ce80ed9925db4156ff52f928460aca Closes-Bug: #1728533 Needed-By: Ia26be196758e5f3617b31750702a6c54436efb93 ** 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/1728533 Title: Serial console should be resizable Status in OpenStack Dashboard (Horizon): Fix Released Bug description: We can not set size (number of rows and cols) of serial console. Serial console should be resizable according to the space to show it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1728533/+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 1744223] [NEW] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations
Public bug reported: During fixing bug #1464387, we stores local side's tunnel IP in the database for later retrieval, in order to support the use case that VPN service is provided outside of the Neutron router. However, for the default IPsec service provider, the local tunnel IPs(external_v*_ip) are only set when A VPN service is created, and never have a chance to get updated. This leads to the following problems: - User cannot create IPsec site connection with IPv6 peer address if the router is not connected to an external IPv6 subnet upon the creation of the VPN service, even though it is connected before the creation of the IPsec site connection - If router gateway's IP changes after the VPN service is created, later-created IPsec site connections would still use the one that was stored in the db instead of the new correct one - Router gateway's IP cannot be changed even when it is not used by any active/enabled IPsec site connections (related to bug #1692130) - Currently there is no checking to ensure the VPN service has an external IP with the same IP version as the peer address upon the creation of IPsec site connection As today the VPN endpoint groups separate the "what gets connected" from the "how to connect" for a VPN service. The local side's tunnel IP should be considered a part of "how to connect" and thus it should be handled during ipsec-site-connection operations, instead of only set upon the creation of a VPN service. ** Affects: neutron Importance: Undecided Assignee: Hunt Xu (huntxu) Status: New ** Tags: vpnaas ** Description changed: During fixing bug #1464387, we stores local side's tunnel IP in the database for later retrieval, in order to support the use case that VPN service is provided outside of the Neutron router. However, for the default IPsec service provider, the local tunnel IPs(external_v*_ip) are only set when A VPN service is created, and never have a chance to get updated. This leads to the following problems: - - User cannot create IPsec site connection with IPv6 peer address if the router is not connected - to an external IPv6 subnet upon the creation of the VPN service, even though it is connected - before the creation of the IPsec site connection - - If router gateway's IP changes after the VPN service is created, later-created IPsec site - connections would still use the one that was stored in the db instead of the new correct one - - Router gateway's IP cannot be changed even when it is not used by any active/enabled IPsec site - connections (related to bug #1692130) - - Currently there is no checking to ensure the VPN service has an external IP with the same IP - version as the peer address upon the creation of IPsec site connection + - User cannot create IPsec site connection with IPv6 peer address if the + router is not connected to an external IPv6 subnet upon the creation + of the VPN service, even though it is connected before the creation + of the IPsec site connection + - If router gateway's IP changes after the VPN service is created, + later-created IPsec site connections would still use the one that was + stored in the db instead of the new correct one + - Router gateway's IP cannot be changed even when it is not used by any + active/enabled IPsec site connections (related to bug #1692130) + - Currently there is no checking to ensure the VPN service has an + external IP with the same IP version as the peer address upon the + creation of IPsec site connection As today the VPN endpoint groups separate the "what gets connected" from the "how to connect" for a VPN service. The local side's tunnel IP should be considered a part of "how to connect" and thus it should be handled during ipsec-site-connection operations, instead of only set upon the creation of a VPN service. ** Changed in: neutron Assignee: (unassigned) => Hunt Xu (huntxu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1744223 Title: VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations Status in neutron: New Bug description: During fixing bug #1464387, we stores local side's tunnel IP in the database for later retrieval, in order to support the use case that VPN service is provided outside of the Neutron router. However, for the default IPsec service provider, the local tunnel IPs(external_v*_ip) are only set when A VPN service is created, and never have a chance to get updated. This leads to the following problems: - User cannot create IPsec site connection with IPv6 peer address if the router is not connected to an external IPv6 subnet upon the creation of the VPN service, even though it is connected before the creation of the IPsec site connection
