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