deltacloud as a lib and broker
Jan Provaznik
jprovazn at redhat.com
Tue Apr 9 10:56:44 UTC 2013
On 04/09/2013 01:45 AM, 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
>
> 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, inst.id)
> 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
>
> Ok .. who's raising their hand ? ;)
>
I'd like to participate too.
> David
>
>
Jan
More information about the aeolus-devel
mailing list