RFC: Minor API change proposal for aeolus-cli
wes hayutin
whayutin at redhat.com
Tue Dec 13 13:36:44 UTC 2011
On Tue, 2011-12-13 at 07:16 -0500, Mo Morsi wrote:
> On 12/12/2011 03:57 PM, Jason Guiditta wrote:
> >
> > and change it to:
> > aeolus-cli image build {other args}
> >
> > This would present a more general construct of:
> > aeolus-cli {top-level-command} {subcommand} {options}
> >
> > The reasoning is that while _at this moment_ aeolus-cli is purely an
> > interface to managing images, over time it should/will grown into a
> > full suite of commands for managing anything that conductor can do
> > (calling the conductor api, of course).
>
> +1 to this
>
> Here's another question (slightly off-topic, but related). To what
> extent can we decouple the CLI from the centralized management services?
> eg. conductor, deltacloud, imagefactory, etc
>
> I ask because it seems somewhat top-heavy to have a command line tool
> depend on several centralized web interfaces that needs to be configured
> / setup independently. Until we are able to mitigate this, I fear that
> this will always been seen as a negative aspect of Aeolus, as the Unix
> philosophy has always been small/independent/simple tools that do one
> job well.
If you look at the problem at a slightly different angle, I think you
come up an implementation that IMHO the best.
You create a application that has an api. Then you create a webui that
calls that api, and you also create a CLI that calls the api.
>
> I see a few solutions to getting around this. As far as I understand,
> Imagefactory can be used directly, we can simply run the command via an
> internal pipe to build images, no central services needed.
>
> For something like deltacloud, we can easily spin up an internal
> instance in the cli process, and just communicate w/ it locally via the
> normal REST interface.
>
> For things which are much heavier, like conductor (as it requires a db,
> and more external pre-configuration), we can develop a separate daemon
> as part of the conductor suite that queries the cloud providers for
> updates. Then we don't have to worry about aeolus-cli to conductor
> communication as that just falls into place.
hrm.. I'd rather see the webui and cli make the *same exact* calls.
I'd imagine this implementation to be more prone to bugs.
>
> We will need to do this anyways as the end user can start/stop/manage
> instances via the cloud provider's interface anyways, and we will want
> to manage those instances via conductor. This way, the top-heavy web ui
> depends on the simpler underlying services, and not the other way around.
>
>
> Thoughts?
> -Mo
>
More information about the aeolus-devel
mailing list