Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Received-SPF: pass (athena.apache.org: domain of lutter@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <1365464759.23209.94.camel@avon.watzmann.net>
Subject: Re: deltacloud as a lib and broker
From: David Lutterkort <lutter@redhat.com>
To: dev@deltacloud.apache.org
Cc: Martin Povolny <mpovolny@redhat.com>,
        aeolus-devel
	 <aeolus-devel@fedorahosted.org>
Date: Mon, 08 Apr 2013 16:45:59 -0700
In-Reply-To: <5162BBBC.20605@redhat.com>
References: <515EC593.90807@redhat.com>
	 <1365200562.23209.66.camel@avon.watzmann.net> <5162BBBC.20605@redhat.com>
Organization: Red Hat Inc
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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

David