deltacloud as a lib and broker

Greg Blomquist gblomqui at redhat.com
Tue Apr 9 13:17:34 UTC 2013



----- Original Message -----
> From: "David Lutterkort" <lutter at redhat.com>
> To: dev at deltacloud.apache.org
> Cc: "Martin Povolny" <mpovolny at redhat.com>, "aeolus-devel" <aeolus-devel at fedorahosted.org>
> Sent: Monday, April 8, 2013 7:45:59 PM
> Subject: Re: deltacloud as a lib and broker
> 
> 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


Or maybe even:

         dc = Deltacloud::new(some_backend, some_provider, credentials)
         inst = dc.create_instance(...)
         inst.start do |instance|
             ... do stuff with your running instance ...
         end # auto stops the instance, sort of like File.open() {|f| }


The start method could do a few things:
  1) encapsulate the logic for polling for a stopped state (in case the
     VM was just created).
  2) if a block if provided, it could auto-stop the instance after
     yielding (just an idea, but feels a little more ruby to me, and
     follows the pattern of resource cleanup like File.open
  3) if a block is _not_ provided, could leave the VM running for the 
     caller to control

> 
> 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 ? ;)
> 
> David
> 
> 
> 


More information about the aeolus-devel mailing list