> 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?
Hrm, the approach that I've taken up to this point has been to add
configure support for features on an as-need basis. eg if we flush out
openstack support in Aeolus and QE or similar needs a way to
automatically test that, we could add support to configure. Similarly if
there is a need to automatically setup realms or other conductor
features via configure, that can be easily added (we currently support
setting up providers, provider accounts, hardware profiles, and
instances, in addition to buckets, images, and other entities external
to conductor)
> 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
Hrm believe there still is value in providing a utility which allows an
end-user to configure providers, accounts, instances, etc via a config
file and having that data propagate to conductor. Traditionally we put
this in configure as that was the mechanism which to configure aeolus
(both for minimal installations and full e2e installs, as QE and others
needed this functionality).
That being said, I'm fine w/ splitting this out of the aeolus-configure
command. Am now thinking that as part of configure suite we might want
to incorporate a DSL or similar for configuring Aeolus via the
filesystem. Or perhaps this would be best be part of the aeolus-cli
suite, as that component already uses the API to satisfy required
functionality.
Alternatively we can still continue using the Aeolus puppet recipe in
lieu of this DSL (making use of the API instead of the WUI), and just
invoke the advanced configuration (eg beyond the minimal install) via
another command that we ship (eg aeolus-install, aeolus-setup, or
whatever).
Thoughts?
-Mo