deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arvind Creatrix IT Soft" <arv...@creatrixitsoft.com>
Subject Re: deltacloud as a lib and broker
Date Tue, 09 Apr 2013 15:41:46 GMT
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) 
(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. 
(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. 

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 => [:json, :xml] do
  @user = current_user
  @posts = 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----- 
From: Jozef Zigmund 
Sent: Tuesday, April 9, 2013 7:28 PM 
To: dev@deltacloud.apache.org 
Cc: Martin Povolny ; aeolus-devel 
Subject: Re: deltacloud as a lib and broker 

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.
> > >
> > 
> > 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'm in to help with it.

> David
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message