RFC: Minor API change proposal for aeolus-cli

Mo Morsi mmorsi at redhat.com
Wed Dec 14 13:45:20 UTC 2011


Thanks for the response Matt, I feel this thread is generating some good 
discussion. Comments inline


On 12/13/2011 04:58 PM, Matt Wagner wrote:
> On Tue, Dec 13, 2011 at 07:16:47AM -0500, Mo Morsi wrote:
>> 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 think Aeolus is fundamentally a collection of "top-heavy... web
> interfaces that need to be configured / setup independently."

Exactly, this is something I'd like to see change. "a collection of 
top-heavy web interfaces" doesn't sound like a good selling point.

Since we're competing against several other open source cloud management 
frameworks, I just would like to make sure we develop the highest 
quality product possible.


> It doesn't
> make a ton of sense to run Image Warehouse or Conductor (for example) by
> itself.

I agree w/ your sentiment about conductor but not iwhd. Like 
imagefactory and deltacloud, IWHD provides value in its own right. It is 
a small tool that does one job very well, eg providing a generic 
key/value data store.

Conductor doesn't make sense on its own, as it is the aggregate of 
components plus providing some functionality ontop of that. Which is why 
I'm apprehensive of too many components depending on conductor.

  Rather the relationship should be inverted, conductor should depend on 
simpler underlying components, so that those components can still be 
used in the simplest manner independently, with the conductor package 
being an optional add on for those who want it.



>
> I also think that aeolus-cli is, fundamentally, just a wrapper for
> Conductor's API.
>
> I do think the idea of having a variety of individual utilities is a
> good one, but I don't think that they should be shoehorned into
> aeolus-cli. As you say, part of the UNIX philosophy is small,
> independent tools, as opposed to one large Swiss Army knife that reaches
> out to various services. We can keep aeolus-cli as the command-line that
> talks to Conductor. Factory has its own CLI tool (AFAICT). Some people
> have suggested in the past that it would be nifty if Deltacloud had one.
>

I actually like this proposal alot, we can keep aeolus-cli as is, but 
develop additional command line interfaces, independant of conductor. 
This way, if people want to manage the various components in their own 
right, without bringing the conductor web interface into the mix, they 
are more than able to, while conductor and the aeolus-cli wrapper is 
still available for anyone to go that route.

Of course, this brings up the issue w/ keeping conductor in sync w/ 
changes to the cloud made outside of it, but again this is a problem 
that needs to be solved anyways, as the end-user can manage the cloud 
via the native cloud APIs and web interfaces.

This shouldn't provide a barrier to developing some of these alternative 
tools. If it does, the entire project as a whole suffers as we're 
impeding overall progress until a single conductor-specific problem is 
resolved.

   -Mo





More information about the aeolus-devel mailing list