deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <>
Subject Re: deltacloud as a lib and broker
Date Wed, 10 Apr 2013 15:53:31 GMT
On 04/10/2013 02:53 PM, Martin Povolny wrote:
> Hi all!
> On Mon, Apr 08, 2013 at 04:45:59PM -0700, David Lutterkort wrote:
>> On Mon, 2013-04-08 at 14:44 +0200, Jan Provaznik wrote:
>>>> There are some other downsides to using DC in process (as a library): it
>>>> also significantly changes where DC can go architecturally. So far, the
>>>> classic DC API has worked very hard to be stateless - CIMI isn't, and it
>>>> wouldn't be unreasonable to introduce state into the classic DC API.
>>>> That would be much more awkward if DC becomes a library.
>>> I'm not familiar with DC plans (which sound really interesting) but even
>>> with stateful DC the lib could make sense:
>>> 1) the DC lib - can be used by anyone who doesn't need any stateful feature
>>> 2) DC/CIMI stateful service - built *on top* of the lib, wraps the lib
>>> with REST API, adds stateful features
>> I think this is the right way to slice things up: make the DC service(s)
>> wrappers around the DC library. The library essentially deals with
>> adapting the internal driver API to something stable, and probably will
>> make the API look a little more Rubyish. For example, right now code to
>> start and stop an instance would look something like
> I think that Jan's original idea was to expose sort-of-cleaned-up driver
> API as the universal library API.
> That is mainly work through the controller methods that implement the
> API calls and
>    * identify and fix the places where there is any other code then such
>      that parses and passes the inputs, outputs and error state between
>      the REST remote call and the drivers.
>    * unify the driver interface where differences exist
> Then just provide some class that basically delegates everything to a driver.
>>          dc = Deltacloud::new(some_backend, some_provider, credentials)
>>          inst = dc.create_instance(...)
>>          unless starts_automatically(dc)  # needs to look at
>>          instance_states
>>            wait_for_state(dc, inst, "STOPPED")
>>            dc.start_instance(credentials,
>>          end
>>          wait_for_state(dc, inst, "STARTED")
>>          .. do stuff with your running instance ..
>>          dc.stop_instance(dc, inst)
>> As you can see, the above isn't very Rubyish; it would be nicer to write
>>          dc = Deltacloud::new(some_backend, some_provider, credentials)
>>          inst = dc.create_instance(...)
>>          if inst.initial_state == 'STOPPED'
>>            inst.poll_for { |inst| inst.stopped? }
>>            inst.start
>>          end
>>          inst.poll_for { |inst| inst.started? }
>>          .. do stuff with your running instance ..
>>          inst.stop
>> What I am mostly after is a feel for who's going to do the following
>> around a DC library:
>>        * Come up with a library API that is safe to use - that includes
>>          keeping the API stable and making sure we only expose reasonable
>>          parts of the driver API. We don't want an automatic "It's in the
>>          drivers, therefore it's part of the API"
>>        * Write enough tests to convince us that the library API still
>>          works
>>        * Document that API
> As I read it, what you suggest is implementing a Ruby-style API on top
> of the cleaned-up driver API.
> Having such layer on top of that is not what Jan suggested, but it would
> surely be convenient from consumer point of view.
> Also it would allow more changes in the driver API if the Ruby-style API
> would be what is advertised as "the thing" to the community. The
> Ruby-style API could then be the "air bag" that keeps the backward
> compatibility even if the driver API changes.
> I personally like the idea as it is surely more Ruby-dev (community)
> friendly. But it is then a thing of a wider scope.
> We should probably take a look at other libraries out there (both
> provider-specific and sort-of-universal, such as the Fog) to see the
> programming idioms that people might be already used to.
I maybe a little late to the discussion here but, in my opinion, looking 
beyond just the broker here, I feel we have a good opportunity to stand 
out from the crowd by implementing more of the CIMI specifcation whilst 
also bringing out new features like the brokering tool.

Creating the brokering tool and integrating with tools like HEAT will 
allow us to extend CIMI support to things like, System and Monitoring.  
For this reason, I think it would be appropriate to deploy services 
along side DC rather than using a library under the covers or by 
wrapping it.  This architecture will better allow us to fit together 
many of these tools we provide to offer up a more complete multi cloud, 
CIMI implementation.  This could be realised by mounting DC, and using 
the client libraries to consume it, which maybe what you meant by 
wrapping the service?

Is proving a more comprehensive CIMI implementation something that we 
are interested in and should be considered when designing these tools?  
Or maybe its out of the scope?

>> Ok .. who's raising their hand ? ;)
>> David

View raw message