On 04/05/2012 08:11 AM, Mo Morsi wrote:
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.
Hrm? When a user sets up providers via configure, the configuration is
ultimately written to the conductor database. Configure simply provides
a mechanism which to setup providers and other data at installation time
so that the user does not have to provide this information via the wui
after the system has been setup.
eg for any given provider account the user should only have to provide
the config once, either via aeolus-configure or via the conductor wui.
In what circumstances does the user have to enter credentials multiple
times for a single provider?
So the issue isn't "configure vs. conductor" -- the issue is right
now
we have provider config specified in both imagefactory config files
_and_ in the conductor database. The purpose of this task is to move the
provider config bits that are in the imagefactory conf files into the
conductor provider object into the DB, and when initiating any factory
actions (build, push, etc) we'll provide the provider config via the API
call to factory that's currently read via rhev.json, etc.
The problem is that, today, in order to add a new RHEV provider, you
have to not only add it via the conductor UI but also add config bits to
the imagefactory conf files.
> 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.
Originally we added the provider (and other) config to configure to
allow an admin to completely setup aeolus e2e via configure, without
having to touch the WUI (of course any post-configure configuration is
still allowed as normal).
Yes, you can do it via configure, since configure writes to both the
conductor DB and the imagefactory conf files. What we're getting at here
is that you can't currently add a new provider "as normal" (i.e.
completely with the conductor UI) -- you have to make the UI action
_and_ augment the factory config files, which partly duplicates data and
partly adds different data in each place.
/me would still like to include this feature as possible, this way
QE
and other users requiring an automated mechanism which to configure the
application can use the configure yml files, while others wanting to do
it graphically can still use the conductor wui.
Sure -- if we remove the ability to add providers via -configure, we're
doing it wrong.
> 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.
+1 to having validation checks in conductor.
> 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.
As mentioned respectfully -1 to this, /me would like to see everything
that is configurable via the WUI to also be configurable via the
aeolus-configure node yml files if possible and vice-versa.
I think the above isn't quite correct. We're not so much moving provider
information out of configure as we're moving it out of imagefactory.
Part of this task needs to include not only enhancing the provider
metadata to include stuff needed by imagefactory, but also we've got to
provide API for provider creation so that configure can carry on just
like it does today, but instead of both creating the conductor provider
_and_ writing rhev.json, etc. for factory, we only need the single "add
provider to conductor" step in configure, so we won't have to write the
factory config file for the provider anymore.
Scott
-Mo