Bug 862038
Summary: | Unable to add new providers if using LDAP authentication | ||
---|---|---|---|
Product: | [Retired] CloudForms Cloud Engine | Reporter: | james labocki <jlabocki> |
Component: | aeolus-configure | Assignee: | John Eckersberg <jeckersb> |
Status: | CLOSED WONTFIX | QA Contact: | Rehana <aeolus-qa-list> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.1.0 | CC: | 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
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. 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? 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. |