Hi, there was a discussion in the last weeks about the proposal to reduce Conductor into a broker. Martin with Tomas wrote nice summary here: https://github.com/aeolusproject/conductor/wiki/BrokerProject
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.
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) - 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 - 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.
I think, this would also bring DC more audience. Obviously according to fog library popularity, ruby world wants a cloud lib and it's a pitty that the library is not Deltacloud. This lib would be also handy for the WingedMonkey project.
Jan
On 04/05/2013 08:37 AM, Jan Provazník wrote:
Hi, there was a discussion in the last weeks about the proposal to reduce Conductor into a broker. Martin with Tomas wrote nice summary here: https://github.com/aeolusproject/conductor/wiki/BrokerProject
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.
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)
- 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
- 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.
I think, this would also bring DC more audience. Obviously according to fog library popularity, ruby world wants a cloud lib and it's a pitty that the library is not Deltacloud. This lib would be also handy for the WingedMonkey project.
Jan
Option 3, being the closet to what we have now, may be the best path for getting a version 1 shipped.
It may also make external contribution to the individual pieces easier.
Option 2 seems to me to be a possible logical progression for second version.
Joe V.
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.
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.
This lib would be also handy for the WingedMonkey project.
AFAIK, they Rack-mount DC into their app.
David
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, 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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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
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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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.stopWhat 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 APIOk .. 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.
On 04/09/2013 01:45 AM, 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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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.stopWhat 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 APIOk .. who's raising their hand ? ;)
I'd like to participate too.
David
Jan
----- 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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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 APIOk .. who's raising their hand ? ;)
David
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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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.stopWhat 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 APIOk .. who's raising their hand ? ;)
I'm in to help with it.
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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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.stopWhat 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
On 04/10/2013 02:53 PM, Martin Povolny wrote:
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:
- the DC lib - can be used by anyone who doesn't need any stateful feature
- 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.stopWhat 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 APIAs 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.
I maybe a little late to the discussion here but, in my opinion, looking beyond just the broker here, I feel we have a good opportunity to stand out from the crowd by implementing more of the CIMI specifcation whilst also bringing out new features like the brokering tool.
Creating the brokering tool and integrating with tools like HEAT will allow us to extend CIMI support to things like, System and Monitoring. For this reason, I think it would be appropriate to deploy services along side DC rather than using a library under the covers or by wrapping it. This architecture will better allow us to fit together many of these tools we provide to offer up a more complete multi cloud, CIMI implementation. This could be realised by mounting DC, and using the client libraries to consume it, which maybe what you meant by wrapping the service?
Is proving a more comprehensive CIMI implementation something that we are interested in and should be considered when designing these tools? Or maybe its out of the scope?
Regards Martyn
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
On 04/10/2013 07:39 PM, David Lutterkort wrote:
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.
Yes, I meant tiny wrapper on top of drivers which abstracts from internal driver changes/differences. Michal's dc-client is probably nice example what methods (and with what parmas) I would expect from this API: https://github.com/mifo/deltacloud-client/tree/master/lib/deltacloud/client/...
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.
The example you mentioned in a prev mail (instance start + poll_for) looks like a handy feature to me, though more like an extension of this basic lib.
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
Jan
aeolus-devel@lists.fedorahosted.org
-
David Lutterkort -
Greg Blomquist -
Jan Provazník -
Joseph VLcek -
jzigmund＠redhat.com -
Martin Povolny -
Martyn Taylor