RFC: Minor API change proposal for aeolus-cli

Mo Morsi mmorsi at redhat.com
Tue Dec 13 12:16:47 UTC 2011


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.

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.

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