[Yahoo-eng-team] [Bug 1844152] Re: nova-conductor is having problem with rabbitmq
** Also affects: oslo.messaging 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/1844152 Title: nova-conductor is having problem with rabbitmq Status in Ubuntu Cloud Archive: New Status in OpenStack Compute (nova): New Status in oslo.messaging: New Bug description: Using stable/stein on Ubuntu 18.04 and having error while creating new instance. This is not a network or firewall related issue because all other services work like a charm. I was having the same issue with nova-api and eventlet monkey patching fixed it. I'm not sure this is related with it too. 2019-09-16 17:24:14.716 6 ERROR oslo.messaging._drivers.impl_rabbit [req-b8faac40-ef24-4c54-a2c7-dd0cd325821d 266e838cc8dc472ead771dcfb15c08b7 e639622000cc419486083d784015215b - default default] Connection failed: [Errno 111] ECONNREFUSED (retrying in 32.0 seconds): ConnectionRefusedError: [Errno 111] ECONNREFUSED To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1844152/+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 1844595] Re: openstackNova(Rocky)--chinese incorrect codes for db character error
** Project changed: nova => neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1844595
Title:
openstackNova(Rocky)--chinese incorrect codes for db character error
Status in neutron:
Incomplete
Bug description:
Description
===
When search security-group, a message "Incorrect string value" is sent.
Environment
===
[root@controller1 ~]# lsb_release -a
LSB Version:
:core-4.1-mips64el:core-4.1-noarch:cxx-4.1-mips64el:cxx-4.1-noarch:desktop-4.1-mips64el:desktop-4.1-noarch:languages-4.1-mips64el:languages-4.1-noarch:printing-4.1-mips64el:printing-4.1-noarch
Distributor ID: Loongnix
Description: Loongnix release 1.0 (20190331)
Release: 1.0
Codename: 20190331
Steps to reproduce & Expected result
==
execute a cli：
[root@controller1 ~]# openstack security group list
HttpException: 500: Server Error for url:
http://controller1:9696/v2.0/security-groups, {"NeutronError": {"message":
"\u8bf7\u6c42\u5931\u8d25\uff1a\u5728\u5904\u7406\u8bf7\u6c42\u65f6\uff0c\u53d1\u751f\u5185\u90e8\u670d\u52a1\u5668\u9519\u8bef\u3002",
"type": "HTTPInternalServerError", "detail": ""}}
2019-09-17 15:29:49.660 1845 ERROR neutron.api.v2.resource DBDataError:
(pymysql.err.InternalError) (1366, u"Incorrect string value:
'\\xE7\\xBC\\xBA\\xE7\\x9C\\x81...' for column 'description' at row 1") [SQL:
u'INSERT INTO standa rdattributes (resource_type, description, created_at,
updated_at) VALUES (%(resource_type)s, %(description)s, %(created_at)s,
%(updated_at)s)'] [parameters: {'created_at': datetime.datetime(2019, 9, 17, 7,
29, 49), 'description': u '\u7f3a\u7701\u5b89\u5168\u7ec4',
'resource_type': 'securitygroups', 'updated_at': datetime.datetime(2019, 9, 17,
7, 29, 49)}] (Background on this error at: http://sqlalche.me/e/2j85)
Logs & Configs
==
MariaDB [(none)]> show variables like 'character%';
+--+--+
| Variable_name| Value|
+--+--+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results| utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mariadb/charsets/ |
+--+--+
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1844595/+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 1832265] Re: py3: inconsistent encoding of token fields
Reviewed: https://review.opendev.org/665617
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=ffa0918f5a92fd18c86703916d768012b0bea61b
Submitter: Zuul
Branch:master
commit ffa0918f5a92fd18c86703916d768012b0bea61b
Author: James Page
Date: Mon Jun 17 09:56:11 2019 +0100
token: consistently decode binary types
Ensure that any binary types unpacked from message payloads
are correctly converted from binary to text type.
Under Python 3 msgpack returns the serialized input as a
byte string. Similar to other msgpack'd values in the payload,
we need to explicitly decode it to a string value.
This is specifically more of an issue under Python 3; however
the decode operation is safe back to Python 2 so there is no
need to limit the decode codepath to just Python 3.
Change-Id: Ib1073acf5677a60714d0a386de3bcd14ce6cd134
Closes-Bug: 1832265
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1832265
Title:
py3: inconsistent encoding of token fields
Status in OpenStack Keystone LDAP integration:
Invalid
Status in Ubuntu Cloud Archive:
Fix Committed
Status in Ubuntu Cloud Archive rocky series:
Fix Committed
Status in Ubuntu Cloud Archive stein series:
Fix Committed
Status in Ubuntu Cloud Archive train series:
Fix Released
Status in OpenStack Identity (keystone):
Fix Released
Status in keystone package in Ubuntu:
Fix Released
Status in keystone source package in Cosmic:
Won't Fix
Status in keystone source package in Disco:
Fix Committed
Bug description:
When using an LDAP domain user on a bionic-rocky cloud within horizon,
we are unable to see the projects listed in the project selection
drop-down, and are unable to query resources from any projects to
which we are assigned the role Member.
It appears that the following log entries in keystone may be helpful
to troubleshooting this issue:
(keystone.middleware.auth): 2019-06-10 19:47:02,700 DEBUG RBAC: auth_context:
{'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_id': None,
'domain_name': None, 'group_ids': [], 'token': , 'user_id':
b'd4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4',
'user_domain_id': '997b3e91271140feb1635eefba7c65a1', 'system_scope': None,
'project_id': None, 'project_domain_id': None, 'roles': [], 'is_admin_project':
True, 'service_user_id': None, 'service_user_domain_id': None,
'service_project_id': None, 'service_project_domain_id': None, 'service_roles':
[]}
(keystone.server.flask.application): 2019-06-10 19:47:02,700 DEBUG
Dispatching request to legacy mapper: /v3/users
(keystone.server.flask.application): 2019-06-10 19:47:02,700 DEBUG
SCRIPT_NAME: `/v3`, PATH_INFO:
`/users/d4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4/projects`
(routes.middleware): 2019-06-10 19:47:02,700 DEBUG Matched GET
/users/d4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4/projects
(routes.middleware): 2019-06-10 19:47:02,700 DEBUG Route path:
'/users/{user_id}/projects', defaults: {'action': 'list_user_projects',
'controller': }
(routes.middleware): 2019-06-10 19:47:02,700 DEBUG Match dict: {'user_id':
'd4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4', 'action':
'list_user_projects', 'controller':
}
(keystone.common.wsgi): 2019-06-10 19:47:02,700 INFO GET
https://keystone.mysite:5000/v3/users/d4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4/projects
(keystone.common.controller): 2019-06-10 19:47:02,700 DEBUG RBAC: Adding
query filter params ()
(keystone.common.authorization): 2019-06-10 19:47:02,700 DEBUG RBAC:
Authorizing
identity:list_user_projects(user_id=d4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4)
(keystone.policy.backends.rules): 2019-06-10 19:47:02,701 DEBUG enforce
identity:list_user_projects: {'trust_id': None, 'trustor_id': None,
'trustee_id': None, 'domain_id': None, 'domain_name': None, 'group_ids': [],
'token': , 'user_id':
b'd4fb94cfa3ce0f7829d76fe44697488e7765d88e29f5a896f57d43caadb0fad4',
'user_domain_id': '997b3e91271140feb1635eefba7c65a1', 'system_scope': None,
'project_id': None, 'project_domain_id': None, 'roles': [], 'is_admin_project':
True, 'service_user_id': None, 'service_user_domain_id': None,
'service_project_id': None, 'service_project_domain_id': None, 'service_roles':
[]}
(keystone.common.wsgi): 2019-06-10 19:47:02,702 WARNING You are not
authorized to perform the requested action: identity:list_user_projects.
It actually appears elsewhere in the keystone.log that there is a string
which has encapsulated bytecode data in it (or vice versa).
(keystone.common.wsgi): 2019-06-10 19:46:59,019 INFO POST
[Yahoo-eng-team] [Bug 1844607] [NEW] log error when create neutron port with wrong subnet
Public bug reported:
With Neutron Newton version
There are two networks named share_net and test1 in my env, each with
one subnet. When I create port in share_net, but specify subnet_id of
the test1's subnet, not the subnet of share_net. Create port failed, but
log is "Failed to create port on network
8fd6c0d1-e499-4e29-9786-dadb377f9939, because fixed_ips included invalid
subnet d213e64e-045e-4941-a4bd-ffc049ad792c."
Here we can see network 8fd6c0d1-e499-4e29-9786-dadb377f9939 is test1,
subnet d213e64e-045e-4941-a4bd-ffc049ad792c is the subnet of test1. The
log is confused, actually it should log network
311a12a8-6824-4348-b5b5-80068a0c3785 with invalid subnet d213e64e-
045e-4941-a4bd-ffc049ad792c.
()[root@busybox-openstack-85c44df77f-xk2rx /]# neutron net-list
+--++---+
| id | name
| subnets |
+--++---+
| 311a12a8-6824-4348-b5b5-80068a0c3785 | share_net
| ef7e9220-d478-48f7-819e-80143621f233 192.168.20.0/24 |
| 8fd6c0d1-e499-4e29-9786-dadb377f9939 | test1
| d213e64e-045e-4941-a4bd-ffc049ad792c 192.168.20.0/24 |
+--++---+
()[root@busybox-openstack-85c44df77f-xk2rx /]# neutron port-create
--name nic1 --fixed-ip subnet_id=d213e64e-045e-4941-a4bd-ffc049ad792c
311a12a8-6824-4348-b5b5-80068a0c3785
Invalid input for operation: Failed to create port on network
8fd6c0d1-e499-4e29-9786-dadb377f9939, because fixed_ips included invalid subnet
d213e64e-045e-4941-a4bd-ffc049ad792c.
Neutron server returns request_ids: ['req-e32df57b-0756-4b88-b042-a0b67ccd7fe7']
after inspect code, I found the function code is:
def _get_subnet_for_fixed_ip(self, context, fixed, subnets):
# Subnets are all the subnets belonging to the same network.
if not subnets:
msg = _('IP allocation requires subnets for network')
raise exc.InvalidInput(error_message=msg)
if 'subnet_id' in fixed:
def get_matching_subnet():
for subnet in subnets:
if subnet['id'] == fixed['subnet_id']:
return subnet
subnet = get_matching_subnet()
if not subnet:
subnet = self._get_subnet(context, fixed['subnet_id'])
msg = (_("Failed to create port on network %(network_id)s"
", because fixed_ips included invalid subnet "
"%(subnet_id)s") %
{'network_id': subnet['network_id'],
'subnet_id': fixed['subnet_id']})
raise exc.InvalidInput(error_message=msg)
this function, it use “'network_id': subnet['network_id'] ”, actually it should
use the network passed from api.
master branch also have this problem:
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#382
** Affects: neutron
Importance: Undecided
Assignee: zhengyong (zhengy23)
Status: New
** Changed in: neutron
Assignee: (unassigned) => zhengyong (zhengy23)
** Description changed:
With Neutron Newton version
There are two networks named share_net and test1 in my env, each with
one subnet. When I create port in share_net, but specify subnet_id of
the test1's subnet, not the subnet of share_net. Create port failed, but
log is "Failed to create port on network
8fd6c0d1-e499-4e29-9786-dadb377f9939, because fixed_ips included invalid
subnet d213e64e-045e-4941-a4bd-ffc049ad792c."
Here we can see network 8fd6c0d1-e499-4e29-9786-dadb377f9939 is test1,
subnet d213e64e-045e-4941-a4bd-ffc049ad792c is the subnet of test1. The
log is confused, actually it should log network
311a12a8-6824-4348-b5b5-80068a0c3785 with invalid subnet d213e64e-
045e-4941-a4bd-ffc049ad792c.
()[root@busybox-openstack-85c44df77f-xk2rx /]# neutron net-list
+--++---+
| id | name
| subnets |
+--++---+
| 311a12a8-6824-4348-b5b5-80068a0c3785 | share_net
| ef7e9220-d478-48f7-819e-80143621f233
[Yahoo-eng-team] [Bug 1844595] [NEW] openstackNova(Rocky)--chinese incorrect codes for db character error
Public bug reported:
Description
===
When search security-group, a message "Incorrect string value" is sent.
Environment
===
[root@controller1 ~]# lsb_release -a
LSB Version:
:core-4.1-mips64el:core-4.1-noarch:cxx-4.1-mips64el:cxx-4.1-noarch:desktop-4.1-mips64el:desktop-4.1-noarch:languages-4.1-mips64el:languages-4.1-noarch:printing-4.1-mips64el:printing-4.1-noarch
Distributor ID: Loongnix
Description:Loongnix release 1.0 (20190331)
Release:1.0
Codename: 20190331
Steps to reproduce & Expected result
==
execute a cli：
[root@controller1 ~]# openstack security group list
HttpException: 500: Server Error for url:
http://controller1:9696/v2.0/security-groups, {"NeutronError": {"message":
"\u8bf7\u6c42\u5931\u8d25\uff1a\u5728\u5904\u7406\u8bf7\u6c42\u65f6\uff0c\u53d1\u751f\u5185\u90e8\u670d\u52a1\u5668\u9519\u8bef\u3002",
"type": "HTTPInternalServerError", "detail": ""}}
2019-09-17 15:29:49.660 1845 ERROR neutron.api.v2.resource DBDataError:
(pymysql.err.InternalError) (1366, u"Incorrect string value:
'\\xE7\\xBC\\xBA\\xE7\\x9C\\x81...' for column 'description' at row 1") [SQL:
u'INSERT INTO standa rdattributes (resource_type, description, created_at,
updated_at) VALUES (%(resource_type)s, %(description)s, %(created_at)s,
%(updated_at)s)'] [parameters: {'created_at': datetime.datetime(2019, 9, 17, 7,
29, 49), 'description': u '\u7f3a\u7701\u5b89\u5168\u7ec4',
'resource_type': 'securitygroups', 'updated_at': datetime.datetime(2019, 9, 17,
7, 29, 49)}] (Background on this error at: http://sqlalche.me/e/2j85)
Logs & Configs
==
MariaDB [(none)]> show variables like 'character%';
+--+--+
| Variable_name| Value|
+--+--+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results| utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mariadb/charsets/ |
+--+--+
** 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/1844595
Title:
openstackNova(Rocky)--chinese incorrect codes for db character error
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
When search security-group, a message "Incorrect string value" is sent.
Environment
===
[root@controller1 ~]# lsb_release -a
LSB Version:
:core-4.1-mips64el:core-4.1-noarch:cxx-4.1-mips64el:cxx-4.1-noarch:desktop-4.1-mips64el:desktop-4.1-noarch:languages-4.1-mips64el:languages-4.1-noarch:printing-4.1-mips64el:printing-4.1-noarch
Distributor ID: Loongnix
Description: Loongnix release 1.0 (20190331)
Release: 1.0
Codename: 20190331
Steps to reproduce & Expected result
==
execute a cli：
[root@controller1 ~]# openstack security group list
HttpException: 500: Server Error for url:
http://controller1:9696/v2.0/security-groups, {"NeutronError": {"message":
"\u8bf7\u6c42\u5931\u8d25\uff1a\u5728\u5904\u7406\u8bf7\u6c42\u65f6\uff0c\u53d1\u751f\u5185\u90e8\u670d\u52a1\u5668\u9519\u8bef\u3002",
"type": "HTTPInternalServerError", "detail": ""}}
2019-09-17 15:29:49.660 1845 ERROR neutron.api.v2.resource DBDataError:
(pymysql.err.InternalError) (1366, u"Incorrect string value:
'\\xE7\\xBC\\xBA\\xE7\\x9C\\x81...' for column 'description' at row 1") [SQL:
u'INSERT INTO standa rdattributes (resource_type, description, created_at,
updated_at) VALUES (%(resource_type)s, %(description)s, %(created_at)s,
%(updated_at)s)'] [parameters: {'created_at': datetime.datetime(2019, 9, 17, 7,
29, 49), 'description': u '\u7f3a\u7701\u5b89\u5168\u7ec4',
'resource_type': 'securitygroups', 'updated_at': datetime.datetime(2019, 9, 17,
7, 29, 49)}] (Background on this error at: http://sqlalche.me/e/2j85)
Logs & Configs
==
MariaDB [(none)]> show variables like 'character%';
+--+--+
| Variable_name| Value|
+--+--+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results| utf8
[Yahoo-eng-team] [Bug 1814245] Re: _disconnect_volume incorrectly called for multiattach volumes during post_live_migration
** Also affects: nova/pike
Importance: Undecided
Status: New
** Changed in: nova/pike
Status: New => In Progress
** Changed in: nova/pike
Assignee: (unassigned) => Matt Riedemann (mriedem)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1814245
Title:
_disconnect_volume incorrectly called for multiattach volumes during
post_live_migration
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) pike series:
In Progress
Status in OpenStack Compute (nova) queens series:
Fix Committed
Status in OpenStack Compute (nova) rocky series:
Fix Committed
Bug description:
Description
===
Idc5cecffa9129d600c36e332c97f01f1e5ff1f9f introduced a simple check to
ensure disconnect_volume is only called when detaching a multi-attach
volume from the final instance using it on a given host.
That change however doesn't take LM into account and more specifically
the call to _disconect_volume during post_live_migration at the end of
the migration from the source. At this point the original instance has
already moved so the call to objects.InstanceList.get_uuids_by_host
will only return one local instance that is using the volume instead
of two, allowing disconnect_volume to be called.
Depending on the backend being used this call can succeed removing the
connection to the volume for the remaining instance or os-brick can
fail in situations where it needs to flush I/O etc from the in-use
connection.
Steps to reproduce
==
* Launch two instances attached to the same multiattach volume on the same
host.
* LM one of these instances to another host.
Expected result
===
No calls to disconnect_volume are made and the remaining instance on
the host is still able to access the multi-attach volume.
Actual result
=
A call to disconnect_volume is made and the remaining instance is
unable to access the volume *or* the LM fails due to os-brick failures
to disconnect the in-use volume on the host.
Environment
===
1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/
master
2. Which hypervisor did you use?
(For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
Libvirt + KVM
2. Which storage type did you use?
(For example: Ceph, LVM, GPFS, ...)
What's the version of that?
LVM/iSCSI with multipath enabled reproduces the os-brick failure.
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==
# nova show testvm2
[..]
| fault| {"message": "Unexpected error
while running command.
|
| | Command: multipath -f
360014054a424982306a4a659007f73b2
|
| | Exit code: 1
|
| | Stdout: u'Jan 28 16:09:29 |
360014054a424982306a4a659007f73b2: map in use\
|
| | Jan 28 16:09:29 | failed to
remove multipath map 360014054a424982306a4a", "code": 500, "details": "
|
| | File
\"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", line 202, in
decorated_function |
| | return function(self,
context, *args, **kwargs)
|
| | File
\"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", line 6299, in
_post_live_migration |
| | migrate_data)
|
| | File
\"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py\", line 7744, in
post_live_migration|
| |
self._disconnect_volume(context, connection_info, instance)
|
| | File
\"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py\", line 1287, in
_disconnect_volume |
| |
[Yahoo-eng-team] [Bug 1844583] [NEW] tox -e docs fails with "WARNING: RSVG converter command 'rsvg-convert' cannot be run. Check the rsvg_converter_bin setting"
Public bug reported: Since this change: https://github.com/openstack/nova/commit/16b9486bf7e91bfd5dc48297cee9f54b49156c93 Local docs builds fail if you don't have librsvg2-bin installed for the sphinxcontrib-svg2pdfconverter dependency (I'm on Ubuntu 18.04). We should include that in bindep.txt. ** Affects: nova Importance: Low Assignee: Matt Riedemann (mriedem) Status: Confirmed ** Tags: doc ** Changed in: nova Assignee: (unassigned) => Matt Riedemann (mriedem) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1844583 Title: tox -e docs fails with "WARNING: RSVG converter command 'rsvg-convert' cannot be run. Check the rsvg_converter_bin setting" Status in OpenStack Compute (nova): Confirmed Bug description: Since this change: https://github.com/openstack/nova/commit/16b9486bf7e91bfd5dc48297cee9f54b49156c93 Local docs builds fail if you don't have librsvg2-bin installed for the sphinxcontrib-svg2pdfconverter dependency (I'm on Ubuntu 18.04). We should include that in bindep.txt. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1844583/+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 1838554] Re: Specify keystone is OS user for fernet and credential setup
Reviewed: https://review.opendev.org/674725 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7fc7ef2a07b2d5721db613635873c08ac88b5258 Submitter: Zuul Branch:master commit 7fc7ef2a07b2d5721db613635873c08ac88b5258 Author: chenxing Date: Tue Aug 6 12:04:08 2019 +0800 Specify keystone is OS user for fernet and credential setup Change-Id: I40124c809d8b14a6c50edc0f758104ab09656250 Closes-Bug: #1838554 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1838554 Title: Specify keystone is OS user for fernet and credential setup Status in OpenStack Identity (keystone): Fix Released Bug description: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. I would suggest, that in chapter "Install and configure components" point 4 "Initialize Fernet key repositories" is clarified in a way that the reader knows the username "keystone" and the group name "keystone" are not free to be chosen, but specify the operating system's user and group "keystone". To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1838554/+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 1843889] Re: Windows: IPv6 tunnel endpoints
Reviewed: https://review.opendev.org/682031 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=484446984295d3122ead42e93288222d8b4e3ccb Submitter: Zuul Branch:master commit 484446984295d3122ead42e93288222d8b4e3ccb Author: Lucian Petrut Date: Fri Sep 13 14:42:18 2019 +0300 Windows: Fix local adapter ipv6 check ip_lib.IPDevice.device_has_ip doesn't include ipv6 addresses when checking if a local adapter is configured to use a certain address. This change fixes this issue, which will also allow using ipv6 tunnel endpoints. Co-authored-by: Alin Serdean Change-Id: Iff3d25a5701b96df9da75cf398fd19d29e5cfeda Closes-Bug: #1843889 ** 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/1843889 Title: Windows: IPv6 tunnel endpoints Status in neutron: Fix Released Bug description: ip_lib.IPDevice.device_has_ip doesn't include ipv6 addresses when checking if a local adapter is configured to use a certain address. This prevents IPv6 tunnel endpoints from being used on Windows. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1843889/+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 1844171] Re: Configuration parameter missing at "Configure the layer-3 agent"
Reviewed: https://review.opendev.org/682645 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1df7e4bc466a03aae6566354839fe2e1fde4aea2 Submitter: Zuul Branch:master commit 1df7e4bc466a03aae6566354839fe2e1fde4aea2 Author: YAMAMOTO Takashi Date: Tue Sep 17 22:17:20 2019 +0900 doc: Remove stale references to external_network_bridge This is a leftover of https://review.opendev.org/#/c/395568/ . Closes-Bug: #1844171 Change-Id: I99e45b78a5b56601f02c9e3c09b621c4d3b67de3 ** 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/1844171 Title: Configuration parameter missing at "Configure the layer-3 agent" Status in neutron: Fix Released Bug description: Link at which the bug exists: https://docs.openstack.org/neutron/stein/install/controller-install- option2-ubuntu.html This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: At the section mentioned in the summary, it is stated to configure the Linux bridge and external network bridge whereas, the code section below it only shows interface_driver. There is NO mention of external_network_bridge If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 14.0.3.dev63 on 2019-01-22 09:42:51 SHA: 91f12c096c1f36100a83faba28172ac6b134c8ea Source: https://opendev.org/openstack/neutron/src/doc/source/install/controller-install-option2-ubuntu.rst URL: https://docs.openstack.org/neutron/stein/install/controller-install-option2-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1844171/+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 1844531] [NEW] Tutorial: Creating an Horizon Plugin in horizon: How to find the Horizon folder?
Public bug reported: I do not know how to find the horizon folder, and think it should be included in the tutorial. In my opinion, it would be useful to include the default locations for the supported distros. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.1.1.dev12 on 2019-01-09 02:06:03 SHA: 2feb16764cb8f42cf424740a5f5875a35c0b7fb8 Source: https://git.openstack.org/cgit/openstack/horizon/tree/doc/source/contributor/tutorials/plugin.rst URL: https://docs.openstack.org/horizon/stein/contributor/tutorials/plugin.html ** Affects: horizon Importance: Undecided Status: New ** Tags: documentation -- 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/1844531 Title: Tutorial: Creating an Horizon Plugin in horizon: How to find the Horizon folder? Status in OpenStack Dashboard (Horizon): New Bug description: I do not know how to find the horizon folder, and think it should be included in the tutorial. In my opinion, it would be useful to include the default locations for the supported distros. This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [ ] This doc is inaccurate in this way: __ - [x] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.1.1.dev12 on 2019-01-09 02:06:03 SHA: 2feb16764cb8f42cf424740a5f5875a35c0b7fb8 Source: https://git.openstack.org/cgit/openstack/horizon/tree/doc/source/contributor/tutorials/plugin.rst URL: https://docs.openstack.org/horizon/stein/contributor/tutorials/plugin.html To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1844531/+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 1696476] Re: Identification of e24cloud platform as using Ec2 datasource
** Changed in: cloud-init Status: Expired => Triaged ** Changed in: cloud-init Importance: Undecided => Low -- 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/1696476 Title: Identification of e24cloud platform as using Ec2 datasource Status in cloud-init: Triaged Bug description: Hi, I'd like to ask you, to add identification for e24cloud platform (e24cloud.com) with Ec2 Datasource. It can be identified via system vendor field: # cat /sys/class/dmi/id/sys_vendor e24cloud # dmidecode --string=system-manufacturer e24cloud I'll be happy to test a patch. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1696476/+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 1844510] Re: openstackNova(Rocky)-launch instacne-NeutronAdminCredentialConfigurationInvalid
Double check the configuration for the [neutron] section in nova.conf
against this:
https://docs.openstack.org/neutron/rocky/install/controller-install-
ubuntu.html#configure-the-compute-service-to-use-the-networking-service
Note that the install guide is just a reference, the actual URLs have to
make sense for your deployment, e.g. I'm guessing the URL hostname for
auth isn't actually "controller". It also looks like you can drop the
/v3 suffix on the auth_url.
** Tags added: config neutron
** 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/1844510
Title:
openstackNova(Rocky)-launch instacne-
NeutronAdminCredentialConfigurationInvalid
Status in OpenStack Compute (nova):
Invalid
Bug description:
I try to launch new instance (from horizon as 'admin').
From empty list of instance, click 'launch instance'.
[root@controller1 ~]# uname -a
Linux controller1 3.10.84-21.fc21.loongson.18.mips64el #1 SMP PREEMPT Tue Apr
16 18:41:34 CST 2019 mips64 mips64 mips64 GNU/Linux
[root@controller1 ~]# less /var/log/nova/nova-api.log
2019-09-18 16:42:27.566 2320 ERROR nova.network.neutronv2.api
[req-4ff4645f-47be-4c66-bff1-2c8dbb4cca99 5af84d7c91ce4def8dad829fdd707e00
0c71a300399e4d759ef8b9dc6b00accf - default default] Neutron client was not able
to generate a valid
admin token, please verify Neutron admin credential located in nova.conf:
Unauthorized: 401-{u'error': {u'message': u'The request you have made requires
authentication.', u'code': 401, u'title': u'Unauthorized'}}
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi
[req-4ff4645f-47be-4c66-bff1-2c8dbb4cca99 5af84d7c91ce4def8dad829fdd707e00
0c71a300399e4d759ef8b9dc6b00accf - default default] Unexpected exception in API
method: NeutronAdminCre
dentialConfigurationInvalid: Networking client is experiencing an
unauthorized exception.
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi Traceback (most
recent call last):
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py", line 801, in
wrapped
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
f(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110,
in wrapper
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi return
func(*args, **kwargs)
2019-09-18 16:42:27.568 2320 ERROR nova.api.openstack.wsgi File
[Yahoo-eng-team] [Bug 1844157] Re: keystone-manage db_sync --check misbehaves, version 15.1.0
Reviewed: https://review.opendev.org/682447 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6bb14c0ff6c95bbce26ce8023ef621e408c111e6 Submitter: Zuul Branch:master commit 6bb14c0ff6c95bbce26ce8023ef621e408c111e6 Author: morgan fainberg Date: Mon Sep 16 11:15:25 2019 -0700 Use correct repo for initial version check Use the actual repo for the initial version check of the db version when performing `db_sync --check`. Previously we always used the Legacy Repo as the repo path was not populated in the `get_init_version` function. This allowed the case where the new expand/contract/migrate repos matched the legacy repo version number, the `db_sync --check` command would assume that everything was properly up to date regardless of the version for the expand/contract/migrate repositories. This was most noticable in the case of a db not under version control. Change-Id: Id5e6f74a5ed96fdf17e2c241466897974aa5a218 closes-bug: #1844157 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1844157 Title: keystone-manage db_sync --check misbehaves, version 15.1.0 Status in OpenStack Identity (keystone): Fix Released Bug description: We are seeing a difference in behaviour in keystone-manage between version 15.0.0 and 15.1.0. The newer version always has a return code of zero, which means that in openstack-ansible we never initialise the keystone db - that process is driven by parsing the return code. Here is an example of the return code being different between the different versions http://paste.openstack.org/show/776806/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1844157/+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 1843609] Re: Domain-specific domain ID resolution breaks with system-scoped tokens
Reviewed: https://review.opendev.org/681833 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8f43b9cab00c86a455b2a9700b434e98b2e9c2d8 Submitter: Zuul Branch:master commit 8f43b9cab00c86a455b2a9700b434e98b2e9c2d8 Author: Lance Bragstad Date: Thu Sep 12 16:46:26 2019 + Make system tokens work with domain-specific drivers When calling certain group or user APIs, keystone logic would attempt to figure out the domain to scope responses to. This was specific to enabling domain-specific driver support, where each domain is backed by a different identity store. This functionality is turned off by default. Since system-scoped tokens are not associated to a domain (unlike project-scoped tokens or domain-scoped tokens), the logic to determine a domain from a system-scoped token was breaking and returning an erroneous HTTP 401 Unauthorized when system users attempted to list users or groups. This commit adds support for domain detection with system-scoped tokens. Change-Id: I8f0f7a623a1741f461493d872849fae7ef3e8077 Closes-Bug: 1843609 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1843609 Title: Domain-specific domain ID resolution breaks with system-scoped tokens Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) queens series: In Progress Status in OpenStack Identity (keystone) rocky series: In Progress Status in OpenStack Identity (keystone) stein series: In Progress Status in OpenStack Identity (keystone) train series: Fix Released Bug description: System-scope was introduced in Queens [0] but recently we discovered a weird case where system users aren't able to do things they should be able to with system-scoped tokens when domain-specific drivers are enabled. For example, they are unable to list groups or users because the API logic for GET /v3/groups and GET /v3/users tries to resolve a domain ID from the request [1]. If domain-specific drivers are enabled and there isn't a domain ID associated to the request (either with a domain-scoped token or a project-scoped token) the API returns a 401, which makes no sense from the context of a system user [2]. You can recreate this locally by enabling domain-specific drivers in keystone.conf [3] and running the test_groups or test_users v3 protection tests using: $ tox -e py37 -- keystone.tests.unit.protection.v3.test_groups Observed failures: https://pasted.tech/pastes/b45c6b015b97c865018c4b3290f60e0456fe304a.raw This isn't blocking the gate because domain-specific drivers are off by default and the logic short-circuits [4]. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [1] https://opendev.org/openstack/keystone/src/branch/master/keystone/api/groups.py#L84 [2] https://opendev.org/openstack/keystone/src/branch/master/keystone/server/flask/common.py#L917-L943 [3] https://pasted.tech/pastes/e8ffce7a3377b960dd88de8c88e2ccfd173ec726.raw [4] https://opendev.org/openstack/keystone/src/branch/master/keystone/server/flask/common.py#L924-L926 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1843609/+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 1844516] [NEW] [neutron-tempest-plugin] SSH timeout exceptions when executing remote commands
Public bug reported: Those SSH timeout exceptions have been detected during the execution of the scenario QoS tests, in particular "test_qos_basic_and_update". Those SSH timeouts happened during the execution of the following commands: - "_kill_nc_process", killing any existing "nc" command being executed in the remote host. - creating the "nc" server in the remote host. Logs: [1]https://9a0240ca9f61a595b570-86672578d4e6ceb498f2d932b0da6815.ssl.cf1.rackcdn.com/633871/20/check/neutron-tempest-plugin-scenario-openvswitch/772f7a4/testr_results.html.gz [2]https://1fd93ff32a555bc48a73-5fe9d093373d887f2b09d5c4b981e1db.ssl.cf2.rackcdn.com/652099/34/check/neutron-tempest-plugin-scenario-openvswitch-rocky/4897a52/testr_results.html.gz [3]https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cf0/679510/1/check/neutron-tempest-plugin-scenario-openvswitch/cf055c6/testr_results.html.gz ** 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/1844516 Title: [neutron-tempest-plugin] SSH timeout exceptions when executing remote commands Status in neutron: New Bug description: Those SSH timeout exceptions have been detected during the execution of the scenario QoS tests, in particular "test_qos_basic_and_update". Those SSH timeouts happened during the execution of the following commands: - "_kill_nc_process", killing any existing "nc" command being executed in the remote host. - creating the "nc" server in the remote host. Logs: [1]https://9a0240ca9f61a595b570-86672578d4e6ceb498f2d932b0da6815.ssl.cf1.rackcdn.com/633871/20/check/neutron-tempest-plugin-scenario-openvswitch/772f7a4/testr_results.html.gz [2]https://1fd93ff32a555bc48a73-5fe9d093373d887f2b09d5c4b981e1db.ssl.cf2.rackcdn.com/652099/34/check/neutron-tempest-plugin-scenario-openvswitch-rocky/4897a52/testr_results.html.gz [3]https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cf0/679510/1/check/neutron-tempest-plugin-scenario-openvswitch/cf055c6/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1844516/+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 1782922] Re: LDAP: changing user_id_attribute bricks group mapping
Cosmic is EOL. will fix direction in Rocky cloud archive ** Changed in: keystone (Ubuntu Cosmic) Status: Triaged => Won't Fix -- 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/1782922 Title: LDAP: changing user_id_attribute bricks group mapping Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive queens series: Triaged Status in Ubuntu Cloud Archive rocky series: Triaged Status in Ubuntu Cloud Archive stein series: Triaged Status in Ubuntu Cloud Archive train series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystone package in Ubuntu: Fix Released Status in keystone source package in Bionic: Triaged Status in keystone source package in Cosmic: Won't Fix Status in keystone source package in Disco: Triaged Status in keystone source package in Eoan: Fix Released Bug description: Env Details: Openstack version: Queens (17.0.5) OS: CentOS 7.5 LDAP: Active Directory, Windows Server 2012R2 We changed the user_id_attribute to sAMAccountName when configuring keystone. [ user_id_attribute = "sAMAccountName" ; group_members_are_ids = False ]. Unfortunately this bricks the group mapping logic in keystone. The relevant code in keystone: `list_users_in_group` [1] -> gets all groups from the LDAP server, and then calls `_transform_group_member_ids`. `_transform_group_member_ids` tries to match the user ids (for posixGroups e.g.) or the DN. However DN matching does not match the full DN. It rather takes the first RDN of the DN and computes the keystone user id [2]. The first RDN in Active Directory is the "CN". While the user-create part honors the user_id_attribute and takes "sAMAccountName" in our configuration. The generated user-ids in keystone now do not match anymore and hence group mapping is broken. A fix could be looking up the user by the DN received from the 'member' attribute of a given group and compare the configured 'user_id_attribute' of the received ldap user id and the in keystone stored user id. A quick fix could also be to mention that behavior in the documentation. /e: related https://bugs.launchpad.net/keystone/+bug/1231488/comments/19 [1] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1285 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L126 [3] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1296 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1782922/+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 1782922] Re: LDAP: changing user_id_attribute bricks group mapping
For Ubuntu, a new package version including this fix has been uploaded to the following: * eoan (and train cloud archive) - https://launchpad.net/ubuntu/+source/keystone * disco unapproved queue - https://launchpad.net/ubuntu/disco/+queue?queue_state=1_text=keystone * rocky-staging (cosmic is EOL) - https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/rocky-staging/+packages?field.name_filter=keystone_filter=published_filter= * bionic unapproved queue - https://launchpad.net/ubuntu/bionic/+queue?queue_state=1_text=keystone ** Changed in: keystone (Ubuntu Eoan) Status: Triaged => 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/1782922 Title: LDAP: changing user_id_attribute bricks group mapping Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive queens series: Triaged Status in Ubuntu Cloud Archive rocky series: Triaged Status in Ubuntu Cloud Archive stein series: Triaged Status in Ubuntu Cloud Archive train series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystone package in Ubuntu: Fix Released Status in keystone source package in Bionic: Triaged Status in keystone source package in Cosmic: Won't Fix Status in keystone source package in Disco: Triaged Status in keystone source package in Eoan: Fix Released Bug description: Env Details: Openstack version: Queens (17.0.5) OS: CentOS 7.5 LDAP: Active Directory, Windows Server 2012R2 We changed the user_id_attribute to sAMAccountName when configuring keystone. [ user_id_attribute = "sAMAccountName" ; group_members_are_ids = False ]. Unfortunately this bricks the group mapping logic in keystone. The relevant code in keystone: `list_users_in_group` [1] -> gets all groups from the LDAP server, and then calls `_transform_group_member_ids`. `_transform_group_member_ids` tries to match the user ids (for posixGroups e.g.) or the DN. However DN matching does not match the full DN. It rather takes the first RDN of the DN and computes the keystone user id [2]. The first RDN in Active Directory is the "CN". While the user-create part honors the user_id_attribute and takes "sAMAccountName" in our configuration. The generated user-ids in keystone now do not match anymore and hence group mapping is broken. A fix could be looking up the user by the DN received from the 'member' attribute of a given group and compare the configured 'user_id_attribute' of the received ldap user id and the in keystone stored user id. A quick fix could also be to mention that behavior in the documentation. /e: related https://bugs.launchpad.net/keystone/+bug/1231488/comments/19 [1] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1285 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L126 [3] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1296 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1782922/+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 1844510] [NEW] NeutronAdminCredentialConfigurationInvalid
Public bug reported: I try to launch new instance (from horizon as 'admin'). >From empty list of instance, click 'launch instance'. ** 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/1844510 Title: NeutronAdminCredentialConfigurationInvalid Status in OpenStack Compute (nova): New Bug description: I try to launch new instance (from horizon as 'admin'). From empty list of instance, click 'launch instance'. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1844510/+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 1539722] Re: Image "container_format" incorrectly modified when editing image
Reviewed: https://review.opendev.org/664132
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=ba75bafc69c03f04b3c7d4f50e1cc9e3123743a3
Submitter: Zuul
Branch:master
commit ba75bafc69c03f04b3c7d4f50e1cc9e3123743a3
Author: 白子玉
Date: Sat Jun 8 15:14:51 2019 +0800
Specify proper container_format for 'vhd' disk_format
When editing an image, if the disk_fomrat is 'vhd',
the container_format was wrongly set to 'bare' before.
'ovf' is the correct container_format for 'vhd' disk images.
Closes-Bug: #1539722
Change-Id: Ic6b0c66af0d5c8db2d802d6eea2b97721d92b7eb
** Changed in: horizon
Status: Fix Committed => 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/1539722
Title:
Image "container_format" incorrectly modified when editing image
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
Hello,
When editing a Glance image in Horizon (for example, changing its
name), Horizon is incorrectly changing the container_format to "bare",
losing whatever the value previously was. This is affecting images
which have been taken from XenServer, as the container_format is
changed from "ovf" to "bare". The end-result of this, is that Cinder
does not run through the proper image conversion procedures (coalesce,
etc.) when creating a Volume from that Image. Instead it will just
dump the .gz file onto the volume, which is obviously unbootable.
We have traced the problem down to the file /usr/share/openstack-
dashboard/openstack_dashboard/dashboards/project/images/images/forms.py.
In the function "create_image_metadata", there is a section which
states:
if disk_format in ('ami', 'aki', 'ari',):
container_format = disk_format
elif disk_format == 'docker':
# To support docker containers we allow the user to specify
# 'docker' as the format. In that case we really want to use
# 'raw' as the disk format and 'docker' as the container format.
disk_format = 'raw'
container_format = 'docker'
else:
container_format = 'bare'
It's clear to see here how this is overriding the container_format from its
proper value. I believe an appropriate patch would be to add an an "elif
disk_format=='vhd' " section. For example, we have done the following which is
working for us:
if disk_format in ('ami', 'aki', 'ari',):
container_format = disk_format
elif disk_format == 'docker':
# To support docker containers we allow the user to specify
# 'docker' as the format. In that case we really want to use
# 'raw' as the disk format and 'docker' as the container format.
disk_format = 'raw'
container_format = 'docker'
elif disk_format == 'vhd':
container_format = 'ovf'
else:
container_format = 'bare'
I'm not enough of a developer to know if this is truly the correct patch, or
if this will break some other functionality for someone else. Could a real
developer please take a look at this, and patch as appropriate?
Thanks in advance,
Alex Oughton
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1539722/+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 1844500] [NEW] get_cmdline_from_pid may fail
Public bug reported:
Even though get_cmdline_from_pid() checks for the existence of the PID
before accessing the cmdline, the process may terminate just in between,
causing an IOError. So we need to catch that exception.
>From
>https://zuul.opendev.org/t/openstack/build/3a93ef0d0bbd40dc84758682dbc7b049:
ft1.40:
neutron.tests.functional.agent.test_firewall.FirewallTestCase.test_egress_udp_rule(OVS
Firewall Driver)_StringException: Traceback (most recent call last):
File "neutron/tests/base.py", line 180, in func
return f(self, *args, **kwargs)
File "neutron/tests/functional/agent/test_firewall.py", line 498, in
test_egress_udp_rule
self._test_rule(self.tester.EGRESS, self.tester.UDP)
File "neutron/tests/functional/agent/test_firewall.py", line 464, in
_test_rule
direction=direction)
File "neutron/tests/common/conn_testers.py", line 205, in assert_no_connection
self.assert_connection(direction, protocol, src_port, dst_port)
File "neutron/tests/common/conn_testers.py", line 49, in wrap
return f(self, direction, *args, **kwargs)
File "neutron/tests/common/conn_testers.py", line 200, in assert_connection
testing_method(direction, protocol, src_port, dst_port)
File "neutron/tests/common/conn_testers.py", line 161, in
_test_transport_connectivity
nc_tester.test_connectivity()
File "neutron/tests/common/net_helpers.py", line 526, in test_connectivity
self.client_process.writeline(testing_string)
File "neutron/tests/common/net_helpers.py", line 476, in client_process
self.establish_connection()
File "neutron/tests/common/net_helpers.py", line 503, in establish_connection
self._spawn_server_process()
File "neutron/tests/common/net_helpers.py", line 489, in _spawn_server_process
listen=True)
File "neutron/tests/common/net_helpers.py", line 554, in
_spawn_nc_in_namespace
proc = RootHelperProcess(cmd, namespace=namespace)
File "neutron/tests/common/net_helpers.py", line 300, in __init__
self._wait_for_child_process()
File "neutron/tests/common/net_helpers.py", line 333, in
_wait_for_child_process
"in %d seconds" % (self.cmd, timeout)))
File "neutron/common/utils.py", line 701, in wait_until_true
while not predicate():
File "neutron/tests/common/net_helpers.py", line 325, in child_is_running
self.pid, self.cmd, run_as_root=True)
File "neutron/agent/linux/utils.py", line 296, in get_root_helper_child_pid
if pid_invoked_with_cmdline(pid, expected_cmd):
File "neutron/agent/linux/utils.py", line 356, in pid_invoked_with_cmdline
cmd = get_cmdline_from_pid(pid)
File "neutron/agent/linux/utils.py", line 326, in get_cmdline_from_pid
with open('/proc/%s/cmdline' % pid, 'r') as f:
IOError: [Errno 2] No such file or directory: '/proc/2866/cmdline
** Affects: neutron
Importance: Undecided
Assignee: Dr. Jens Harbott (j-harbott)
Status: 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/1844500
Title:
get_cmdline_from_pid may fail
Status in neutron:
In Progress
Bug description:
Even though get_cmdline_from_pid() checks for the existence of the PID
before accessing the cmdline, the process may terminate just in
between, causing an IOError. So we need to catch that exception.
From
https://zuul.opendev.org/t/openstack/build/3a93ef0d0bbd40dc84758682dbc7b049:
ft1.40:
neutron.tests.functional.agent.test_firewall.FirewallTestCase.test_egress_udp_rule(OVS
Firewall Driver)_StringException: Traceback (most recent call last):
File "neutron/tests/base.py", line 180, in func
return f(self, *args, **kwargs)
File "neutron/tests/functional/agent/test_firewall.py", line 498, in
test_egress_udp_rule
self._test_rule(self.tester.EGRESS, self.tester.UDP)
File "neutron/tests/functional/agent/test_firewall.py", line 464, in
_test_rule
direction=direction)
File "neutron/tests/common/conn_testers.py", line 205, in
assert_no_connection
self.assert_connection(direction, protocol, src_port, dst_port)
File "neutron/tests/common/conn_testers.py", line 49, in wrap
return f(self, direction, *args, **kwargs)
File "neutron/tests/common/conn_testers.py", line 200, in assert_connection
testing_method(direction, protocol, src_port, dst_port)
File "neutron/tests/common/conn_testers.py", line 161, in
_test_transport_connectivity
nc_tester.test_connectivity()
File "neutron/tests/common/net_helpers.py", line 526, in test_connectivity
self.client_process.writeline(testing_string)
File "neutron/tests/common/net_helpers.py", line 476, in client_process
self.establish_connection()
File "neutron/tests/common/net_helpers.py", line 503, in
establish_connection
self._spawn_server_process()
File "neutron/tests/common/net_helpers.py", line 489, in
_spawn_server_process
[Yahoo-eng-team] [Bug 1782922] Re: LDAP: changing user_id_attribute bricks group mapping
** Changed in: cloud-archive/train Status: Triaged => 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/1782922 Title: LDAP: changing user_id_attribute bricks group mapping Status in Ubuntu Cloud Archive: Fix Committed Status in Ubuntu Cloud Archive queens series: Fix Committed Status in Ubuntu Cloud Archive rocky series: Fix Committed Status in Ubuntu Cloud Archive stein series: Fix Committed Status in Ubuntu Cloud Archive train series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystone package in Ubuntu: Triaged Status in keystone source package in Bionic: Triaged Status in keystone source package in Cosmic: Triaged Status in keystone source package in Disco: Triaged Status in keystone source package in Eoan: Triaged Bug description: Env Details: Openstack version: Queens (17.0.5) OS: CentOS 7.5 LDAP: Active Directory, Windows Server 2012R2 We changed the user_id_attribute to sAMAccountName when configuring keystone. [ user_id_attribute = "sAMAccountName" ; group_members_are_ids = False ]. Unfortunately this bricks the group mapping logic in keystone. The relevant code in keystone: `list_users_in_group` [1] -> gets all groups from the LDAP server, and then calls `_transform_group_member_ids`. `_transform_group_member_ids` tries to match the user ids (for posixGroups e.g.) or the DN. However DN matching does not match the full DN. It rather takes the first RDN of the DN and computes the keystone user id [2]. The first RDN in Active Directory is the "CN". While the user-create part honors the user_id_attribute and takes "sAMAccountName" in our configuration. The generated user-ids in keystone now do not match anymore and hence group mapping is broken. A fix could be looking up the user by the DN received from the 'member' attribute of a given group and compare the configured 'user_id_attribute' of the received ldap user id and the in keystone stored user id. A quick fix could also be to mention that behavior in the documentation. /e: related https://bugs.launchpad.net/keystone/+bug/1231488/comments/19 [1] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1285 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/core.py#L126 [3] https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap/common.py#L1296 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1782922/+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 1844479] [NEW] nova-api bug
Public bug reported: 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi InternalServerError: Request Failed: internal server error while processing your request. 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi Neutron server returns request_ids: ['req-c5bc199c-66e2-45c6-baa2-0d75d3a6df84'] 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi 2019-09-18 14:22:34.592 32942 INFO nova.api.openstack.wsgi [req-03cd8a2e-defb-432e-adb9-26d94730fe03 c2161d6eae004cbeb9ded0015e143278 80dcdc66b0b549a19d31cde810eb636a - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 实例通过ssh远程连接浮点ip， 删除安全组入tcp端口权限，导致程序异常； ** 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/1844479 Title: nova-api bug Status in OpenStack Compute (nova): New Bug description: 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi InternalServerError: Request Failed: internal server error while processing your request. 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi Neutron server returns request_ids: ['req-c5bc199c-66e2-45c6-baa2-0d75d3a6df84'] 2019-09-18 14:22:34.586 32942 ERROR nova.api.openstack.wsgi 2019-09-18 14:22:34.592 32942 INFO nova.api.openstack.wsgi [req-03cd8a2e-defb-432e-adb9-26d94730fe03 c2161d6eae004cbeb9ded0015e143278 80dcdc66b0b549a19d31cde810eb636a - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 实例通过ssh远程连接浮点ip， 删除安全组入tcp端口权限，导致程序异常； To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1844479/+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
