On 04/06/2013 12:22 AM, David Lutterkort wrote:

Hi Jan,

On Fri, 2013-04-05 at 14:37 +0200, Jan Provazník wrote:

...

During this discussion we touched (again) the "Deltacloud as a lib" topic, Michal asked me to send a mail here if we have a feature request. If you look at the possible solutions (the link above), having this lib would be helpful in all three options.

It's not the first time this has come up ;)

...

Although the broker could be implemented using DC as a separate service or as a rack mounted app, I think it's not an optimal solution: DC consumer is then dependent on this separate service, it adds another chunk into the chain that can fail and that a user has to take care of.

If it's rack mounted into an app which uses it, then it solves the problem with setting up separate daemon, but communication between app and DC is technically same as if it was separate service (so then TCP connection from the app to the mounted DC is done anyway). And it adds another problem - a user has to take care of restricting access to the mounted DC api which is then exposed in the same way as the main app.

From what I know there are two major reasons for having DC as a standalone service:

• taking care of another API (on lib level)

This entails a _lot_ of things; it's not just the mechanics of maintaining a little more code. That API needs to be documented, it needs to be tested, mechanisms have to be in place to evolve the API in a somewhat backwards-compatible manner etc.

...

• it can be used by other no-ruby projects then

I think that it wouldn't be so bad, because with DC as a lib:

• you wouldn't have to support ruby deltacloud-client

True, but that has been a very minor support burden so far.

...

• maybe the classic DC API wouldn't be needed then and consumers who

can't use DC lib directly would be satisfied with CIMI API (which you already have). But even if you keep classic DC API, it would be just simple wrapper around this lib which converts input/output into expected format.

That discussion is somewhat orthogonal to the library discussion.

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

Just curious, what is the reason to keep both stateful classic DC API and CIMI api in future? Backward compatibility?

Similarly, there are things we'd really need a background worker for; again, that becomes much more complicated if DC is a library.

As far as I can tell, the one big argument for DC as a library is that it's one less service to babysit _if_ you happen to write your app in Ruby. Maybe the right answer here is to figure out what concretely the big headaches around that are, and how to best address them.

The thing is that if I think about Aeolus-related components which we talked about recently and which were planned to be integrated somehow together (DC API, Broker, DC Tracker, Heat, a user interface app) and also if Broker should be standalone successful community project, then I wonder if there exists a reasonable solution.

...

This lib would be also handy for the WingedMonkey project.

AFAIK, they Rack-mount DC into their app.

Winged Monkey currently doesn't integrate DC API. From what I know from Brno guys one of the reasons is/was that Winged Moneky doesn't want to depend on an external service. True is there is a POC patch from Michal which uses rack-mount solution, anyway (at least Brno guys) would appreciate lib too.

David

On Mon, Apr 08, 2013 at 04:45:59PM -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 ? ;)

David

I'd be pleased to work on that given I get permission from my manager to put some fraction of my time to this. I see this as a quite well defined, framed task that can be considered a "have a rest after the lunch" project.

It is surely highly relevant to both the Tracker (wherever it lands), the Broker and also Winged Monkey colleagues would be happy to see this and use it in their project I would hope.

Having this could bring more contributors to DC once the Ruby community sees the potential of DC compared to Fog.

----- Original Message -----

From: "David Lutterkort" lutter@redhat.com To: dev@deltacloud.apache.org Cc: "Martin Povolny" mpovolny@redhat.com, "aeolus-devel" aeolus-devel@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

Hi all!

On Mon, Apr 08, 2013 at 04:45:59PM -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

I think that Jan's original idea was to expose sort-of-cleaned-up driver API as the universal library API.

That is mainly work through the controller methods that implement the API calls and

* identify and fix the places where there is any other code then such that parses and passes the inputs, outputs and error state between the REST remote call and the drivers. * unify the driver interface where differences exist

Then just provide some class that basically delegates everything to a driver.

    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

As I read it, what you suggest is implementing a Ruby-style API on top of the cleaned-up driver API.

Having such layer on top of that is not what Jan suggested, but it would surely be convenient from consumer point of view.

Also it would allow more changes in the driver API if the Ruby-style API would be what is advertised as "the thing" to the community. The Ruby-style API could then be the "air bag" that keeps the backward compatibility even if the driver API changes.

I personally like the idea as it is surely more Ruby-dev (community) friendly. But it is then a thing of a wider scope.

We should probably take a look at other libraries out there (both provider-specific and sort-of-universal, such as the Fog) to see the programming idioms that people might be already used to.

Ok .. who's raising their hand ? ;)

David

Hi Martin,

On Wed, 2013-04-10 at 15:53 +0200, Martin Povolny wrote:

I think that Jan's original idea was to expose sort-of-cleaned-up driver API as the universal library API.

That is mainly work through the controller methods that implement the API calls and

• identify and fix the places where there is any other code then such that parses and passes the inputs, outputs and error state between the REST remote call and the drivers.
• unify the driver interface where differences exist

Then just provide some class that basically delegates everything to a driver.

If by 'delegate' you mean 'wrap', i.e. have a tiny little bit of logic in between that allows us to adjust to changes in the driver API, then yes. Just as an example: we recently went through and made driver methods return empty arrays in a lot of places where they used to return nils. We need to have a place where we insulate library users from these sort of changes.

As I read it, what you suggest is implementing a Ruby-style API on top of the cleaned-up driver API.

Having such layer on top of that is not what Jan suggested, but it would surely be convenient from consumer point of view.

Also it would allow more changes in the driver API if the Ruby-style API would be what is advertised as "the thing" to the community. The Ruby-style API could then be the "air bag" that keeps the backward compatibility even if the driver API changes.

I personally like the idea as it is surely more Ruby-dev (community) friendly. But it is then a thing of a wider scope.

We should probably take a look at other libraries out there (both provider-specific and sort-of-universal, such as the Fog) to see the programming idioms that people might be already used to.

The reason I suggested the more Ruby-ish API is that I agree that we might be able to attract more people with the library API, but I don't think the current driver API is very attractive for that.

Geemus used to be very proud of the fact that Fog exposes a AR-inspired API - that's the kind of thing we should aim for here (not that I think AR is the right metaphor, but it's a good inspiration)

David