RFC: Minor API change proposal for aeolus-cli

Martyn Taylor mtaylor at redhat.com
Tue Dec 13 14:48:53 UTC 2011


On 12/13/2011 02:26 PM, Mo Morsi wrote:
> On 12/13/2011 08:36 AM, wes hayutin wrote:
>>
>> 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.
>
> ++ absolutely agree.
>
> By separating the API from the web ui, we are now allowing developers 
> / end-users who want to use a different interface to do so w/out going 
> through any hurdles.
>
> Deltacloud provides a consistent / simple API which we can make use of 
> in both cases. This way as business requirements change the graphical 
> interface, the underlying mechanisms can remain rock solid.
>
>
>
>>
>>
>> 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.
>
> Also agree, both the web ui and cli can invoke deltacloud to 
> communicate w/ the cloud providers in the same manner.
>
> An issue arises though with keeping these components in sync, as well 
> as in sync w/ the cloud provider should changes be made via the EC2 
> management console for example.
>
> To keep it lightweight, the CLI can query the cloud provider on 
> demand, to request cloud information as it is made available. This way 
> the CLI would not require any underlying storage mechanism.
>
> To make sure requests are satisfied in a timely manner in the web ui, 
> it can incorporate a cache in the database, which gets updated 
> periodically via a separate daemon that uses Deltacloud in the exact 
> same manner the CLI does.
>
>   -Mo
Conductor offers value on top of that offered by deltacloud, factory and 
all the other components we use.  If we bypass Conductor and use these 
services directly we are losing that Value Add.  The CLI is simply an 
interface to conductor and nothing more/less.  A user/the CLI has no 
knowledge of Deltacloud, Imagefactory or any of the underlying 
infrastructure.

This is a little bit like saying, when booking my holiday to France, I 
want to talk directly to the hotel, airline and insurance and bypass my 
travel agent, to make things more light weight.  Conductor is the 
central hub (The Travel Agent) that brings all these things together in 
one managable place, and makes sure they are in sync, with the addition 
of adding the value of Deployables, Pools, etc... the CLI is just a 
window into this hub.

>
>




More information about the aeolus-devel mailing list