On 04/02/2012 07:13 PM, Richard Su wrote:
Hi all,
I welcome your comments on this feature.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/All_provider_c...
This contents of the wiki page is included below.
# Summary
Users should be asked to enter provider credentials and information
once. Currently users are asked to enter credentials in two places,
once in config files used by Configure and then again in Conductor
when creating a provider account. This can be confusing. We wil move
all provider creditials and information into a single place and that
will be Conductor.
Historically, Configure needed to know the provider credentials in
order to create private cloud definition files that are later used by
imagefactory (rhevm.json and vsphere.json). Credentials are no longer
needed in these private cloud definition files because of oauth. But
the private cloud definition files are still needed and the additional
provider parameters entered into Configure will need to be moved to
Conductor.
For RHEV, Configure also does additional validation to check the
export mount point is correctly specified, and if it is correct,
mounts it. This will need to be moved into Conductor as part of
validation checks Conductor performs when creating provider accounts.
Since all provider information will be moved out of Configure,
Configure will also stop creating providers in Configure for RHEV and
vSphere. Users will now create the providers and provider accounts.
EC2 is unaffected.
# Owner
Richard Su (rwsu)
and others who are interested
# Status
Planning phase.
# Screencast Demo
* Show Configure does not ask for credentials.
* Show Conductor asks for additional provider information used to
create private cloud definition files (rhevm.json and vsphere.json)
* Show provider validation logic performed by Configure has been moved
to Conductor.
# Tasks
This is being tracked as #2094.
* Remove credentials and provider information from Configure.
* Remove rhevm and vsphere profiles from Configure.
* In Conductor, add additional provider information needed by RHEV:
nfs server, nfs export, nfs mount point, and push timeout.
* In Conductor, add additional provider information needed by vSphere:
datastore and network name.
* Conductor creates rhevm.json and vsphere.json.
* RHEV export validation is moved to Conductor as part of provider
account validation before the account is created.
* Verify default configure profile works with RHEV and vSphere.
# Additional Details
The implementation needs to work with a head-less Conductor, that is a
Conductor environment where the user choses to only use the API and
not the UI. In this case, the API should ask for all information that
is needed to create the provider, provider account, json files and
that is need to perform provider specific validation.
It may also be worth investigating if we can eliminate the json files.
Imagefactory and/or Image Warehouse may be able to now just read the
information that used to reside in those files directly from Conductor.
+1 to removing the json files. Well I think the Factory team will want
to keep the ability to use the json files. However, I think conductor
should pass whatever json provider configuration as part of the API call
to factory to _override_ what's in factory json (if they exist at all)
Basically, as I see it, the Provider model (and 'new provider' UI)
should be expanded to include whatever data that's currently in
rhev/vsphere/whatever json files. This may require augmenting the
Provider Type model as well to take care of directing the
provider-type-specific behavior. Handling "headless" Conductor behavior
is a more general problem, not limited to this feature. Essentially we
need to move in the direction that all UI functionality should be
exposed via the API as well. It's one reason we're trying to move to a
model where both UI and API use the same RESTful actions via the same
controllers.
# Open Questions
Configure mounts the RHEV nfs export. Should Conductor now be
responsible for mounting it? Or should it simply check the mount exist
and ask the user to mount it if it doesn't? And perhaps provide a
command to perform the mount in a warning message.
I would think we'd mount it
when adding the provider via conductor. It's
actually still possible that, after this work is done, aeolus-configure
will still set up providers -- but it will do so via conductor API calls
rather than writing config directly to factory. Mounting the NFS call
seems to me like something that belongs to the 'create provider' action,
whether it's triggered via API call (with or without configure) or via
the UI 'new provider' form.
Scott