yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #64440
[Bug 1694537] Re: Instance creation fails with SSL, keystone v3
The root cause for this is HAProxy timing out and terminating the TCP
session. The hint in the error was the EOF:
SSLError: SSL exception connecting to https://keystone-<CUSTOMER_DOMAIN>.net:5000/v3/auth/tokens: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",)
Bumping up the haproxy-*-timeout values for the API charms resolved the issue for CLI driven instance create commands.
There is still some question if instance creation via horizon has a remaining bug or timeout.
I am marking the nova-compute and nova-cloud-controller projects as invalid for this bug. If a horizon bug still remains we can add the openstack-dashboard project to this bug.
** Changed in: nova
Status: Incomplete => Invalid
** Changed in: charm-nova-cloud-controller
Status: Incomplete => 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/1694537
Title:
Instance creation fails with SSL, keystone v3
Status in OpenStack nova-cloud-controller charm:
Invalid
Status in OpenStack Compute (nova):
Invalid
Bug description:
OS version is Ocata, with SSL enabled across the entire cloud.
Using the Keystone-LDAP charm to allow AD user authentication to the
OS deployment. AD admin users can login, and have limited admin
access.
If an AD user is added to a project on either the AD domain or the
admin_default domain as an admin, they are able to request an instance
but the instance creation errors out with:
http://paste.ubuntu.com/24727101/
There is an associated error in nova-cloud-controller's apache2 nova-
placement error log: http://paste.ubuntu.com/24727106/
Creating an instance with a local administrator on the admin_domain
domain on a project in the admin domain works without issue. However
it does not work while logged in as a local administrator (who has
admin rights added) on a project created in the AD domain.
The root of the issue seems to be communication between the nova
scheduler and the nova placement api, specifically where if a token
originates from the AD domain it has insufficient privileges to
perform administrative action between services.
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1694537/+subscriptions
References