Bug 862038

Summary: Unable to add new providers if using LDAP authentication
Product: [Retired] CloudForms Cloud Engine Reporter: james labocki <jlabocki>
Component: aeolus-configureAssignee: John Eckersberg <jeckersb>
Status: CLOSED WONTFIX QA Contact: Rehana <aeolus-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.1.0CC: jeckersb, morazi, pblaho
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-19 20:53:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description james labocki 2012-10-01 17:11:51 UTC
Description of problem:

After enabling LDAP authentication in Cloud Engine the following error is seen when trying to configure a new provider (vsphere). Also, the /etc/ldap_fluff.yml and /etc/aeolus-conductor/settings.yml are overwritten causing LDAP authentication to be disabled.

[root@rhc-07 ~]# aeolus-configure -p vsphere
Launching aeolus configuration recipe...
notice: /File[/etc/ldap_fluff.yml]/content: content changed '{md5}90518f63fc65aa5eb44403c26e85338e' to '{md5}109fb977032121710c47df851d8f0e72'
notice: /File[/usr/share/aeolus-conductor/config/settings.yml]/content: content changed '{md5}4286011ea83f881fca973252314b638d' to '{md5}0dff5fa8abb12afac191fec4d9c0acd6'
notice: /File[/usr/share/aeolus-conductor/config/initializers/secret_token.rb]/content: content changed '{md5}8881dcb82741176a6442802ce497f1d8' to '{md5}f8be640a64b1416cfc72a9488eee1791'
notice: /Stage[main]/Aeolus::Conductor/Aeolus::Rails::Create::Db[create_aeolus_database]/Exec[create_rails_database]/returns: executed successfully
notice: /Stage[main]/Aeolus::Conductor/Aeolus::Rails::Migrate::Db[migrate_aeolus_database]/Exec[migrate_rails_database]/returns: executed successfully
notice: /Stage[main]/Aeolus::Conductor/Aeolus::Conductor::Destroy_temp_admins[before]/Exec[destroy_temp_admin-before]/returns: executed successfully
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Temp_admin[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Exec[create_temp_admin]/returns: executed successfully
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Temp_admin[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Exec[grant_temp_admin_privs]/returns: executed successfully
err: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Login[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login]/post: change from  to https://localhost/conductor/user_session failed: An exception was raised when invoking web request: Invalid HTTP Return Code: 401,
                               was expecting one of 200
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Login[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Exec[decrement_login_counter]: Dependency Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login] has failures: true
warning: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Login[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Exec[decrement_login_counter]: Skipping because of failed dependencies
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Hwp[small-x86_64]/Web_request[hwp-small-x86_64]: Dependency Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login] has failures: true
warning: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Hwp[small-x86_64]/Web_request[hwp-small-x86_64]: Skipping because of failed dependencies
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Create_bucket[aeolus]/Exec[create-bucket-aeolus]/returns: executed successfully
notice: /Stage[main]/Aeolus::Deltacloud::Core/Exec[deltacloud-core-startup-wait]/returns: executed successfully
notice: /Stage[main]/Aeolus::Profiles::Vsphere/Aeolus::Profiles::Vsphere::Instance[default]/Aeolus::Conductor::Provider[vsphere-default]/Web_request[provider-vsphere-default]: Dependency Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login] has failures: true
warning: /Stage[main]/Aeolus::Profiles::Vsphere/Aeolus::Profiles::Vsphere::Instance[default]/Aeolus::Conductor::Provider[vsphere-default]/Web_request[provider-vsphere-default]: Skipping because of failed dependencies
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Logout[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-logout]: Dependency Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login] has failures: true
warning: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Logout[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-logout]: Skipping because of failed dependencies
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Destroy_temp_admins[after]/Exec[destroy_temp_admin-after]: Dependency Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login] has failures: true
warning: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Destroy_temp_admins[after]/Exec[destroy_temp_admin-after]: Skipping because of failed dependencies
notice: Finished catalog run in 29.48 seconds



Expected results:
Allow for successful configuration of a new provider using aeolus-configure after LDAP is being utilized and do not overwrite the files.

Comment 2 John Eckersberg 2012-10-01 19:03:59 UTC
A few thoughts on this...

(1) We rely on a rake task to add/remove the temp admin user, and use that user to make API calls in order to do things.  This is error prone, and when things break (like in this case) we get back useless error messages such as above:

err: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Conductor::Login[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e]/Web_request[temporary-administrative-user-bc5882e801d18d753b8d988ea91303383f7013aa34ab881e-conductor-login]/post: change from  to https://localhost/conductor/user_session failed: An exception was raised when invoking web request: Invalid HTTP Return Code: 401,
                               was expecting one of 200

We've already introduced the dependency on rake here, we might as well just use rake directly to do things from configure instead of going through the API.  For this case, it wouldn't matter what authentication method is being exposed on the API, we'd just fiddle objects as needed directly in a rake task.

(2) We lay down ldap_fluff.yml via configure as a template, but the template file does not have any logic in it.  If we are not going to put logic in and manage the file intelligently, we should just ship the default via RPM and mark it as %config so it gets handled the same as any other config file.

(3) We lay down settings.yml via configure as a template, but the only fields that we are managing in that file are the oauth keys for iwhd/imagefactory.  Thus any edits to other parts of the file are overwritten if configure is re-ran.  Instead of templating the entire file, maybe we could use Augeas to manipulate the oauth keys in-place, and leave the rest of the file alone.

Comment 3 james labocki 2012-10-01 20:09:57 UTC
Good comments John and thanks for the insight. One other thought. Why not have aeolus-configure simply configure a shell of aeolus-conductor and have all other configuration happen via CLI/WUI? This way LDAP configuration and provider setup would not be part of the initial run and users would not need to edit configuration files by hand?

Comment 4 Mike Orazi 2012-10-04 15:29:19 UTC
This seems pretty risky at this point of 1.1.  We can definitely consider it in 2.0, but I think we might want to put a release note in describing how to add the provider via the restful endpoints or the web ui as an alternative.