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