RFC: All provider config to reside in Conductor

Michael Orazi morazi at redhat.com
Thu Apr 5 21:12:11 UTC 2012



----- Original Message -----
> Thanks for the feedback. Comments below.
> 
> On 04/05/2012 05: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_config_to_reside_in_Conductor
> >>
> >>
> >> 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?
> >
> For RHEV, we do ask the user to enter credentials twice. Once in
> rhevm_configure which is used to do the NFS export validation and
> then
> again in Conductor to create the provider account.
> 
> >> 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).
> >
> > /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.
> I like the goal of having the flexibility to setup the application
> either through Configure or graphically through Conductor and
> hopefully
> in the near future through an API.
> 
> But today we don't do the e2e setup that well given that we have
> provider account credentials in Configure (for RHEV and vSphere) and
> don't use them to create provider accounts in Conductor. At one point
> Configure was creating the provider accounts but that was removed
> because we weren't consistent and didn't support the same
> functionality
> for EC2.
> 
> How much of the e2e setup should Configure be doing? Should Configure
> be
> in the business of creating provider accounts for all providers?
> 
> If we were to support setting up provider and provider accounts
> through
> an API, then I think we would certainly need to move the provider
> account specific validation logic (like RHEV export) from Configure
> to
> Conductor.
> 

I'd vote that as soon as we have the API available, we should purge provider setup from configure.

My recollection is that we really only carried that because an API didn't exist yet.


> >> 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'm unsure where to draw the line with Configure myself.
> 
> Maybe we don't need to go as far as removing the creation of
> providers
> from Configure. But what we have today feels wierd, given we don't do
> full e2e setup through Configure. I feel like we are being asked to
> setup the application twice. Once when editing the _configure files
> and
> then again when we create provider accounts.
> 
> Should we also support configuration of realms through Configure?
> That
> feels like something that would be complicated to specify in yaml.
> Again
> where to place that line is blurry to me.
> 

I'd vote that we should ensure that conductor has proper API where we need it and view configure as a tool
to give the minimal working application set up for conductor and it's subcomponents.

Mike




More information about the aeolus-devel mailing list