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 arvind@creatrixitsoft.com
 designates 65.55.90.234 as permitted sender)
Message-ID: <SNT141-ds17A7C3210C5059B2E36AC1A2C60@phx.gbl>
From: "Arvind Creatrix IT Soft" <arvind@creatrixitsoft.com>
To: <dev@deltacloud.apache.org>
References: <515EC593.90807@redhat.com>
 <1365200562.23209.66.camel@avon.watzmann.net> <5162BBBC.20605@redhat.com>
 <1365464759.23209.94.camel@avon.watzmann.net> <1365515918.4034.1.camel@iotop>
In-Reply-To: <1365515918.4034.1.camel@iotop>
Subject: Re: deltacloud as a lib and broker
Date: Tue, 9 Apr 2013 21:11:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0294_01CE3566.D7FC8530"
Importance: Normal

------=_NextPart_000_0294_01CE3566.D7FC8530
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi

With ref to the discussion- I was already planning to work on creating =
an API over the core Delta Cloud code as I need it in a number of my =
projects.

I suggest the following means to do this, in as painless a manner as =
possible--

(1) Use Rails and RABL--> https://github.com/nesquena/rabl to generate =
the API
(2) Use the VersionCake gem for versioning( =
https://github.com/bwillis/versioncake)=20
(3) Controllers are set up in an hierarchy where you have one =
BaseController which contains this authentication logic (as a =
before_filter) and then the other controllers inherit from that. If you =
have any other helpers, they would go in this controller too.=20
(4) For authorization, use CanCan.(https://github.com/ryanb/cancan)  =
It's README and Wiki are great sources of information on how to use it.=20

Finally, here is some helpful text from the RABL docs-->

Once you have installed RABL (explained above), you can construct a RABL =
view template and then render the template from your Sinatra, Padrino or =
Rails applications from the controller (or route) very easily. Using =
Padrino as an example, assuming you have aPost model filled with blog =
posts, you can render an API representation (both JSON and XML) by =
creating a route:

# app/app.rb
get "/posts", :provides =3D> [:json, :xml] do
  @user =3D current_user
  @posts =3D Post.order("id DESC")
  render "posts/index"
end
Then we can create the following RABL template to express the API output =
of @posts:

# app/views/posts/index.rabl
collection @posts
attributes :id, :title, :subject
child(:user) { attributes :full_name }
node(:read) { |post| post.read_by?(@user) }
Which would output the following JSON or XML when visiting =
http://localhost:3000/posts.json

[{  "post" :
  {
    "id" : 5, title: "...", subject: "...",
    "user" : { full_name : "..." },
    "read" : true
  }
}]
This is an easy way to create a API library that has its own versioning- =
and at the same time it basically just uses the core code in the Delta =
Cloud library itself.

Yours sincerely,
Arvind,
Creatrix IT Soft.
-----Original Message-----=20
From: Jozef Zigmund=20
Sent: Tuesday, April 9, 2013 7:28 PM=20
To: dev@deltacloud.apache.org=20
Cc: Martin Povolny ; aeolus-devel=20
Subject: Re: deltacloud as a lib and broker=20

On Mon, 2013-04-08 at 16:45 -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.
> > >
> >=20
> > I'm not familiar with DC plans (which sound really interesting) but =
even=20
> > 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=20
> > with REST API, adds stateful features
>=20
> 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
>=20
>         dc =3D Deltacloud::new(some_backend, some_provider, =
credentials)
>         inst =3D 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)
>        =20
> As you can see, the above isn't very Rubyish; it would be nicer to =
write
>=20
>         dc =3D Deltacloud::new(some_backend, some_provider, =
credentials)
>         inst =3D dc.create_instance(...)
>         if inst.initial_state =3D=3D 'STOPPED'
>           inst.poll_for { |inst| inst.stopped? }
>           inst.start
>         end
>         inst.poll_for { |inst| inst.started? }
>         .. do stuff with your running instance ..
>         inst.stop
>=20
> What I am mostly after is a feel for who's going to do the following
> around a DC library:
>=20
>       * 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
>=20
> Ok .. who's raising their hand ? ;)
>=20

I'm in to help with it.

> David
>=20
>=20


------=_NextPart_000_0294_01CE3566.D7FC8530--