Further discussion in #libcloud has lead us to think (but no decisions yet!) about instead of "drivers" being implementation details, but rather have them be running services that directly speak libcloud-API on one side, and the cloud-native API on the other.
In this case, Steve the Scripter would fire up the driver service he's using today, perhaps on localhost, and work with a cloudsh or other client that talks REST to the localhost-hosted service.
For the value-add of the previously discussed generic libcloud- service, which might do credential mapping and cloud multiplexing, it would be another cloud that speaks libcloud-API on the front, but also talks libcloud-API out the back ultimately to the real driver services.
In this case, libcloud-service would act more as a proxy/aggregator, and not directly drive the drivers.
One benefit is the RHEV-M driver would be able to run fully on the win32 machine, colocated with RHEV-M. It'd be a separate process from RHEV-M, but would not require a "driver" to be placed in libcloud- service AND a shim placed on the win32 machine. The full driver would be a single process running on the win32 box, aggregated by the libcloud-service.
If libcloud-service is a proxy, we *could* end up chaining them together, such as a libcloud-service for each department, which talks to its own local clouds AND also the libcloud-service for the corporation. The libcloud-service for the corporation would then also talk to its own clouds.
If each driver is really a service, and we stitch them together, we're SOA buzzword compliant. And each driver can be authored in the language most appropriate for that driver.
In previous discussion, if libcloud-service directly spoke to the drivers in-process, that severely restricts the implementation choices.
Here's some diagrams:
http://fnokd.com/~bob/libcloud-soa-1.png
The first represents Steve the Scripter who just wants a homogenous API he can script against regardless of which cloud he's really using. It would require 1 service running, possibly on localhost (but not required!).
The bottom half of that diagram shows a more complex configuration, where a proxying/aggregating value-add libcloud-service stands between Don the Developer and several clouds available simultaneously through the service.
Each driver may be on the same host, or may be exposed by the cloud provider natively, or distributed within the organization as appropriate (ie, RHEV-M's driver sitting directly on a win32 machine, everything else is scattered on linux boxen).
To make life easy for folks who are happy to use whatever language we've picked, we can also provide a libcloud-service-framework. This would be a template implementation of a driver, lacking the actual guts that do real work, but otherwise handling the HTTP and REST aspects.
http://fnokd.com/~bob/libcloud-framework-1.png
Folks could simply ignore it, though, and do their own implementation between libcloud-API and native-API. It's just an optional chunk to help driver implementors if they so choose.
-Bob
From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bob McWhirter
Further discussion in #libcloud has lead us to think (but no decisions yet!) about instead of "drivers" being implementation details, but rather have them be running services that directly speak libcloud-API on one side, and the cloud-native API on the other.
In this case, Steve the Scripter would fire up the driver service he's using today, perhaps on localhost, and work with a cloudsh or other client that talks REST to the localhost-hosted service.
For the value-add of the previously discussed generic libcloud- service, which might do credential mapping and cloud multiplexing, it would be another cloud that speaks libcloud-API on the front, but also talks libcloud-API out the back ultimately to the real driver services.
In this case, libcloud-service would act more as a proxy/aggregator, and not directly drive the drivers.
One benefit is the RHEV-M driver would be able to run fully on the win32 machine, colocated with RHEV-M. It'd be a separate process from RHEV-M, but would not require a "driver" to be placed in libcloud- service AND a shim placed on the win32 machine. The full driver would be a single process running on the win32 box, aggregated by the libcloud-service.
If libcloud-service is a proxy, we *could* end up chaining them together, such as a libcloud-service for each department, which talks to its own local clouds AND also the libcloud-service for the corporation. The libcloud-service for the corporation would then also talk to its own clouds.
If each driver is really a service, and we stitch them together, we're SOA buzzword compliant. And each driver can be authored in the language most appropriate for that driver.
In previous discussion, if libcloud-service directly spoke to the drivers in-process, that severely restricts the implementation choices.
Here's some diagrams:
http://fnokd.com/~bob/libcloud-soa-1.png
The first represents Steve the Scripter who just wants a homogenous API he can script against regardless of which cloud he's really using. It would require 1 service running, possibly on localhost (but not required!).
The bottom half of that diagram shows a more complex configuration, where a proxying/aggregating value-add libcloud-service stands between Don the Developer and several clouds available simultaneously through the service.
Each driver may be on the same host, or may be exposed by the cloud provider natively, or distributed within the organization as appropriate (ie, RHEV-M's driver sitting directly on a win32 machine, everything else is scattered on linux boxen).
To make life easy for folks who are happy to use whatever language we've picked, we can also provide a libcloud-service-framework. This would be a template implementation of a driver, lacking the actual guts that do real work, but otherwise handling the HTTP and REST aspects.
http://fnokd.com/~bob/libcloud-framework-1.png
Folks could simply ignore it, though, and do their own implementation between libcloud-API and native-API. It's just an optional chunk to help driver implementors if they so choose.
[IH] while this simplifies things, and allows to write each 'driver' based on most appropriate technology, with as few limitations as possible - it does reduce the chance of building a centralized logic of the abstraction/mapping/translation[1] between the APIs. I'm not "against" this approach, but it basically means "no need for a service" for the abstraction/translation part. We are just trying to define a "meta api", and anyone can connect to any cloud exposing our API. Again, this has its merits, but I'm not sure how appealing that would be (or different from simply telling everyone to implement/expose a DMTF interface for standardization).
[1] we are mixing in the discussion two things so far[2], so I'm specifying my comments are relevant to the abstraction part, not to the meta/multi cloud part. [2] yikes, nested comments... the I understand the scope discussed, we are discussing: - abstraction/translation api - a-la Libvirt. - meta/multi cloud orchestration - identity management between clouds, VM synchronization between clouds, etc. (this is where I think we have a lot of overlap with rhev-m)
Itamar Heim wrote:
From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bob McWhirter
Further discussion in #libcloud has lead us to think (but no decisions yet!) about instead of "drivers" being implementation details, but rather have them be running services that directly speak libcloud-API on one side, and the cloud-native API on the other.
In this case, Steve the Scripter would fire up the driver service he's using today, perhaps on localhost, and work with a cloudsh or other client that talks REST to the localhost-hosted service.
For the value-add of the previously discussed generic libcloud- service, which might do credential mapping and cloud multiplexing, it would be another cloud that speaks libcloud-API on the front, but also talks libcloud-API out the back ultimately to the real driver services.
In this case, libcloud-service would act more as a proxy/aggregator, and not directly drive the drivers.
One benefit is the RHEV-M driver would be able to run fully on the win32 machine, colocated with RHEV-M. It'd be a separate process from RHEV-M, but would not require a "driver" to be placed in libcloud- service AND a shim placed on the win32 machine. The full driver would be a single process running on the win32 box, aggregated by the libcloud-service.
If libcloud-service is a proxy, we *could* end up chaining them together, such as a libcloud-service for each department, which talks to its own local clouds AND also the libcloud-service for the corporation. The libcloud-service for the corporation would then also talk to its own clouds.
If each driver is really a service, and we stitch them together, we're SOA buzzword compliant. And each driver can be authored in the language most appropriate for that driver.
In previous discussion, if libcloud-service directly spoke to the drivers in-process, that severely restricts the implementation choices.
Here's some diagrams:
http://fnokd.com/~bob/libcloud-soa-1.png
The first represents Steve the Scripter who just wants a homogenous API he can script against regardless of which cloud he's really using. It would require 1 service running, possibly on localhost (but not required!).
The bottom half of that diagram shows a more complex configuration, where a proxying/aggregating value-add libcloud-service stands between Don the Developer and several clouds available simultaneously through the service.
Each driver may be on the same host, or may be exposed by the cloud provider natively, or distributed within the organization as appropriate (ie, RHEV-M's driver sitting directly on a win32 machine, everything else is scattered on linux boxen).
To make life easy for folks who are happy to use whatever language we've picked, we can also provide a libcloud-service-framework. This would be a template implementation of a driver, lacking the actual guts that do real work, but otherwise handling the HTTP and REST aspects.
http://fnokd.com/~bob/libcloud-framework-1.png
Folks could simply ignore it, though, and do their own implementation between libcloud-API and native-API. It's just an optional chunk to help driver implementors if they so choose.
[IH] while this simplifies things, and allows to write each 'driver' based on most appropriate technology, with as few limitations as possible - it does reduce the chance of building a centralized logic of the abstraction/mapping/translation[1] between the APIs. I'm not "against" this approach, but it basically means "no need for a service" for the abstraction/translation part. We are just trying to define a "meta api", and anyone can connect to any cloud exposing our API. Again, this has its merits, but I'm not sure how appealing that would be (or different from simply telling everyone to implement/expose a DMTF interface for standardization).
It would be possible for our implementation to support extended apis which provide enhanced functionality. To your point, this is no different then telling folks to expose a DMTF interface.. but there is huge value in that.
-- bk
+1
On 9 Jul 2009, at 16:30, Bob McWhirter wrote:
Further discussion in #libcloud has lead us to think (but no decisions yet!) about instead of "drivers" being implementation details, but rather have them be running services that directly speak libcloud-API on one side, and the cloud-native API on the other.
In this case, Steve the Scripter would fire up the driver service he's using today, perhaps on localhost, and work with a cloudsh or other client that talks REST to the localhost-hosted service.
For the value-add of the previously discussed generic libcloud- service, which might do credential mapping and cloud multiplexing, it would be another cloud that speaks libcloud-API on the front, but also talks libcloud-API out the back ultimately to the real driver services.
In this case, libcloud-service would act more as a proxy/aggregator, and not directly drive the drivers.
One benefit is the RHEV-M driver would be able to run fully on the win32 machine, colocated with RHEV-M. It'd be a separate process from RHEV-M, but would not require a "driver" to be placed in libcloud-service AND a shim placed on the win32 machine. The full driver would be a single process running on the win32 box, aggregated by the libcloud-service.
If libcloud-service is a proxy, we *could* end up chaining them together, such as a libcloud-service for each department, which talks to its own local clouds AND also the libcloud-service for the corporation. The libcloud-service for the corporation would then also talk to its own clouds.
If each driver is really a service, and we stitch them together, we're SOA buzzword compliant. And each driver can be authored in the language most appropriate for that driver.
In previous discussion, if libcloud-service directly spoke to the drivers in-process, that severely restricts the implementation choices.
Here's some diagrams:
http://fnokd.com/~bob/libcloud-soa-1.png
The first represents Steve the Scripter who just wants a homogenous API he can script against regardless of which cloud he's really using. It would require 1 service running, possibly on localhost (but not required!).
The bottom half of that diagram shows a more complex configuration, where a proxying/aggregating value-add libcloud-service stands between Don the Developer and several clouds available simultaneously through the service.
Each driver may be on the same host, or may be exposed by the cloud provider natively, or distributed within the organization as appropriate (ie, RHEV-M's driver sitting directly on a win32 machine, everything else is scattered on linux boxen).
To make life easy for folks who are happy to use whatever language we've picked, we can also provide a libcloud-service-framework. This would be a template implementation of a driver, lacking the actual guts that do real work, but otherwise handling the HTTP and REST aspects.
http://fnokd.com/~bob/libcloud-framework-1.png
Folks could simply ignore it, though, and do their own implementation between libcloud-API and native-API. It's just an optional chunk to help driver implementors if they so choose.
-Bob
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
--- Mark Little mlittle@redhat.com
JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
deltacloud-devel@lists.fedorahosted.org
-
Bob McWhirter -
Bryan Kearney -
iheim＠redhat.com -
Mark Little