Howdy guys--
First, congrats to everyone for doing awesome with Deltacloud and the launch. Jeremy, the website looks fantastic. Kim and the Video team also made us all look good.
I'd like us to consider what the "end-game" of Deltacloud as an API looks like. Where do we draw the line of what is and is not Deltacloud, from an API viewpoint?
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and storage.
Basically, for things like Amazon's Simple Queueing Service (SQS) and SimpleDB. Implementation of these things using JBoss technologies falls under the scope of my JBoss Cloud project. JBoss Cloud (as you may or may not know) aims to make JBoss middleware "cloud-ready". So far that's meant getting JBoss AS up in a PaaS configuration "in the cloud" with clustering and such. Furthering that, I aim to get HonetQ (our messaging service) and Infinispan (our data-grid project) up as RESTful, cloud-ready services. To directly respond to SQS and SimpleDB.
I'm going to be working with REST-* on those efforts.
Where does that leave Deltacloud? I think it leaves Deltacloud Just Fine. Deltacloud addresses the IaaS level of abstraction, which is at least a level lower than REST-* seems to want to address.
Deltacloud Framework can certainly aim to tie it all together, also. We can have drivers that work with my HonetQ-REST impl of REST- Messaging, and a driver to map to Amazon's SQS (or another provider's "native" queue cloud-service).
Portall, likewise, can continue to overlay policy and other value-add on top of the "bare" protocols.
Leaving us with
Deltacloud-API -- defining IaaS-level interactions REST-* (Messaging, Transactions, Storage) -- defining the "cloud services" offered as Services-as-a-Service defining how we'd like to see Messaging, Transaction, Storage, and whatever-else servicey things. This is potentially an open-ended porftolio of specs.
Deltacloud-Portal/Proxy -- consumes Deltacloud-API and REST-* standards, orchestrates the actual coordination of mixed on-premise/off-premise/private/public resources according to user-supplied policy.
Perhaps, if needed, Deltacloud-Messaging could extend the basic REST- Messaging API defined through the REST-* community if an cloud- specific extensions are needed.
-Bob
On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote:
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and storage.
Very cool; the world will definitely be a better place with agreement on API's in those areas.
In the very big picture, I am hoping that we'll get to a place where we have API's for all the infrastructure building blocks that are event-driven (i.e., backed by messaging) rather than inherently request-based API's. With Qpid/QMF, we have a solid foundation for such API's. In a message-based world, there'll always be a need for bridging request-driven API's into the event-driven world (e.g., there's little we can do to make Amazon's API's go that way), but there are plenty of services that we can change to support event-driven interaction natively.
For application writers, life would be much easier, and we'd save each application from implementing its own caching/updating logic to track state etc. That logic would either reside in the services themselves, or in the poll/event bridges.
David
On Tue, Sep 8, 2009 at 7:20 PM, David Lutterkort lutter@redhat.com wrote:
On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote:
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and storage.
Very cool; the world will definitely be a better place with agreement on API's in those areas.
This all sounds very similar to my vision for OGF's OCCIhttp://www.occi-wg.org/ and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
FWIW REST-* sounds like something I could get behind but to be completely candid (as always) I'm disappointed to see similar governancehttp://www.jboss.org/reststar/community/governance.htmlshenanigans to those that undermined the WS-I http://en.wikipedia.org/wiki/Web_Services_Interoperability: "*Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year*". If it's not too late then please reconsider this position.
Sam
Sam Johnston wrote:
On Tue, Sep 8, 2009 at 7:20 PM, David Lutterkort <lutter@redhat.com mailto:lutter@redhat.com> wrote:
On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote: > I personally think that we might want to leverage the community > that'll also be building around REST-* (http://jboss.org/reststar). > There, the intent it to build RESTful APIs (but not necessarily > implementations) for things like messaging, transactions, and storage. Very cool; the world will definitely be a better place with agreement on API's in those areas.This all sounds very similar to my vision for OGF's OCCI http://www.occi-wg.org/ and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
I'm open to creating any new specifications. Would it make sense to have a REST-* Cloud API specification?
FWIW REST-* sounds like something I could get behind but to be completely candid (as always) I'm disappointed to see similar governance http://www.jboss.org/reststar/community/governance.html shenanigans to those that undermined the WS-I http://en.wikipedia.org/wiki/Web_Services_Interoperability: "/Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year/". If it's not too late then please reconsider this position.
What should it be changed to? So far the governance policies seem pretty liberal to me (since I wrote it). RHT as a permanent member of the board seems reasonable to me considering we started it and will be doing most of the work initially. Then again, if its a show stopper it will be removed.
Can we discuss your thoughts about governance more at:
http://groups.google.com/group/reststar-board
I'd like to have our discussion archived.
Thanks,
Bill
On Tue, Sep 8, 2009 at 8:35 PM, Bill Burke bburke@redhat.com wrote:
This all sounds very similar to my vision for OGF's OCCI <
http://www.occi-wg.org/%3E and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
I'm open to creating any new specifications. Would it make sense to have a REST-* Cloud API specification?
Does REST-* want to be an SSO? I would say emphatically "no" - it's better to contribute to open processes and evangelise the result. That's what I did with OCCI rather than trying to create something from scratch - OGF had a BoF group that had all the requisite infrastructure in place and just needed some direction.
You may well find that extending OCCI core (basically a RESTful framework for minting compatible APIs) gives you the best of both worlds - freedom to develop your own standards without weaving a patchwork quilt. Reconciling OCCI and DeltaCloud is also an option as if we don't align then we're likely to end up with ordinary standards that benefit some parties at the expense of others (see last week's Dilbert on that topic: http://www.dilbert.com/strips/comic/2009-09-02/).
FWIW REST-* sounds like something I could get behind but to be completely
candid (as always) I'm disappointed to see similar governance < http://www.jboss.org/reststar/community/governance.html%3E shenanigans to those that undermined the WS-I < http://en.wikipedia.org/wiki/Web_Services_Interoperability%3E: "/Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year/". If it's not too late then please reconsider this position.
What should it be changed to? So far the governance policies seem pretty liberal to me (since I wrote it). RHT as a permanent member of the board seems reasonable to me considering we started it and will be doing most of the work initially. Then again, if its a show stopper it will be removed.
IMO any type of preferential treatment undermines the goal of being open and unnecessarily breeds mistrust - I for one am not only unlikely to support such an initiative but very likely to be critical of it. It not only discourages active participation of the "founding fathers" and others but jeopardises the entire initiative should they lose interest - just look at what it did for WS-I (there was a great InfoWorld article on the subject which has recently vanished).
The best approach is to build a large, committed membership base and justify to them at every opportunity why it is you deserve to be leading them. If someone more capable comes along then that is presumably better for your initiative anyway, and if you have a large enough base you have good stability/security.
Can we discuss your thoughts about governance more at:
http://groups.google.com/group/reststar-board
I'd like to have our discussion archived.
I joined the list before (that makes three of us) and am copying it now - let's follow up over there.
Sam
Bill's on vacation this week so he may have a different perspective, but I don't have a problem with the statement as it's made, i.e., Red Hat having a permanent position on the board. I've been involved with standards for 20+ years through OMG, OASIS, W3C, WS-I, GGF, JCP and others. What's proposed in the whole effort around REST-* is far less Evil Empire and far more Benign Coordinator. If we have problems with the approach in the future of course we can re-examine it, but at this stage I think it's fine.
Mark.
On 8 Sep 2009, at 18:46, Sam Johnston wrote:
On Tue, Sep 8, 2009 at 7:20 PM, David Lutterkort lutter@redhat.com wrote: On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote:
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and
storage.
Very cool; the world will definitely be a better place with agreement on API's in those areas.
This all sounds very similar to my vision for OGF's OCCI and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
FWIW REST-* sounds like something I could get behind but to be completely candid (as always) I'm disappointed to see similar governance shenanigans to those that undermined the WS-I: "Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year". If it's not too late then please reconsider this position.
Sam
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
--- 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).
On Wed, Sep 9, 2009 at 11:43 AM, Mark Little mlittle@redhat.com wrote:
Bill's on vacation this week so he may have a different perspective, but I don't have a problem with the statement as it's made, i.e., Red Hat having a permanent position on the board. I've been involved with standards for 20+ years through OMG, OASIS, W3C, WS-I, GGF, JCP and others. What's proposed in the whole effort around REST-* is far less Evil Empire and far more Benign Coordinator. If we have problems with the approach in the future of course we can re-examine it, but at this stage I think it's fine.
Ok so let me put it another way: you don't see a problem with a provider of services covered by standards bestowing themselves a privileged position in the standards setting organisation? I certainly do. This isn't (or at least need not be) the DMTF or WS-I or indeed any traditional organisation complete with arcane rules, preferential votes, founding fathers, etc. In any case I'm sure the others all consider themselves "benign coordinators" too. The most successful standards these days by far (think OpenID, OAuth, WHAT WG's take on HTML5) come from loose-knit communities of equals.
At the end of the day it's your show and you can run it how you like, but with policies like this it will likely remain your show as I can't imagine others in the cloud space (like Canonical) signing up for it. VMware may be able to lead its competitors by the nose but with an effective monopoly in the [on-premises] virtualisation space that's hardly surprising - I don't see anyone else having that kind of control in the cloud space.
Sam
On 8 Sep 2009, at 18:46, Sam Johnston wrote:
On Tue, Sep 8, 2009 at 7:20 PM, David Lutterkort lutter@redhat.comwrote:
On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote:
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and storage.
Very cool; the world will definitely be a better place with agreement on API's in those areas.
This all sounds very similar to my vision for OGF's OCCIhttp://www.occi-wg.org/ and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
FWIW REST-* sounds like something I could get behind but to be completely candid (as always) I'm disappointed to see similar governancehttp://www.jboss.org/reststar/community/governance.htmlshenanigans to those that undermined the WS-I http://en.wikipedia.org/wiki/Web_Services_Interoperability: "*Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year*". If it's not too late then please reconsider this position.
Sam
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
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).
On 9 Sep 2009, at 11:22, Sam Johnston wrote:
On Wed, Sep 9, 2009 at 11:43 AM, Mark Little mlittle@redhat.com wrote: Bill's on vacation this week so he may have a different perspective, but I don't have a problem with the statement as it's made, i.e., Red Hat having a permanent position on the board. I've been involved with standards for 20+ years through OMG, OASIS, W3C, WS-I, GGF, JCP and others. What's proposed in the whole effort around REST-* is far less Evil Empire and far more Benign Coordinator. If we have problems with the approach in the future of course we can re-examine it, but at this stage I think it's fine.
Ok so let me put it another way: you don't see a problem with a provider of services covered by standards bestowing themselves a privileged position in the standards setting organisation? I certainly do.
This is where you're misunderstanding. At present REST-* isn't a standards body. It's not funded by member organizations, for instance. It's not Eclipse. It's not W3C. It's a community in the same way that Apache or JBoss.org is a community. When/if the REST-* community decides to take whatever we work on to an independent standards body then all of that changes and I'd expect us to be on the same footing as everyone else.
This isn't (or at least need not be) the DMTF or WS-I or indeed any traditional organisation complete with arcane rules, preferential votes, founding fathers, etc. In any case I'm sure the others all consider themselves "benign coordinators" too. The most successful standards these days by far (think OpenID, OAuth, WHAT WG's take on HTML5) come from loose-knit communities of equals.
At the end of the day it's your show and you can run it how you like, but with policies like this it will likely remain your show as I can't imagine others in the cloud space (like Canonical) signing up for it.
This isn't specifically about Cloud. Believe it or not but REST existed before Cloud came along. This is a community effort around REST usage wherever that may occur. What gives you the impression REST- * is Cloud specific?
VMware may be able to lead its competitors by the nose but with an effective monopoly in the [on-premises] virtualisation space that's hardly surprising - I don't see anyone else having that kind of control in the cloud space.
As the community grows, if there are problems in the way in which it is managed then I would fully expect us to look at them and revisit any decisions. As I said above, this is a community effort. It's meant to be open. We don't want to fall into the same situation as, say, Sun with the JCP.
Mark.
Sam
On 8 Sep 2009, at 18:46, Sam Johnston wrote:
On Tue, Sep 8, 2009 at 7:20 PM, David Lutterkort lutter@redhat.com wrote: On Mon, 2009-09-07 at 18:28 -0400, Bob McWhirter wrote:
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar). There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and
storage.
Very cool; the world will definitely be a better place with agreement on API's in those areas.
This all sounds very similar to my vision for OGF's OCCI and is exactly why I've split off core from infrastructure concerns - it definitely sounds like we should be collaborating more in future.
FWIW REST-* sounds like something I could get behind but to be completely candid (as always) I'm disappointed to see similar governance shenanigans to those that undermined the WS-I: "Red Hat, as the founder of REST-*, gets a permanent seat on the board. All other board members must be elected by the overall membership once a year". If it's not too late then please reconsider this position.
Sam
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
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).
--- 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).
Mark Little wrote:
On 9 Sep 2009, at 11:22, Sam Johnston wrote:
This isn't (or at least need not be) the DMTF or WS-I or indeed any traditional organisation complete with arcane rules, preferential votes, founding fathers, etc. In any case I'm sure the others all consider themselves "benign coordinators" too. The most successful standards these days by far (think OpenID, OAuth, WHAT WG's take on HTML5) come from loose-knit communities of equals.
CORBA, WS-*, Java EE were/are much more popular and widely used than OpenID and OAuth. And they all had a lot of these "arcane rules" you are talking about...
Granted, I don't want a lot of arcane rules, but quite honestly the JCP was a pretty good organization. Except for some of the closed expert-group processes of the JCP and licensing issues, the structure was pretty conducive to creating solid specifications. Even having Sun as a semi-dictator helped a lot to resolve some of the more political specifications (like JPA for instance).
At the end of the day it's your show and you can run it how you like, but with policies like this it will likely remain your show as I can't imagine others in the cloud space (like Canonical) signing up for it.
This isn't specifically about Cloud. Believe it or not but REST existed before Cloud came along. This is a community effort around REST usage wherever that may occur. What gives you the impression REST-* is Cloud specific?
The cloud needs REST, REST does not need the cloud.
VMware may be able to lead its competitors by the nose but with an effective monopoly in the [on-premises] virtualisation space that's hardly surprising - I don't see anyone else having that kind of control in the cloud space.
As the community grows, if there are problems in the way in which it is managed then I would fully expect us to look at them and revisit any decisions. As I said above, this is a community effort. It's meant to be open. We don't want to fall into the same situation as, say, Sun with the JCP.
The end goal is to provide solid specifications. Any changes to the governance model to facilitate this would be met with open arms.
From: deltacloud-devel-bounces@lists.fedorahosted.org
[mailto:deltacloud-
devel-bounces@lists.fedorahosted.org] On Behalf Of David Lutterkort
...
Very cool; the world will definitely be a better place with agreement on API's in those areas.
In the very big picture, I am hoping that we'll get to a place where we have API's for all the infrastructure building blocks that are event-driven (i.e., backed by messaging) rather than inherently request-based API's. With Qpid/QMF, we have a solid foundation for such API's. In a message-based world, there'll always be a need for bridging request-driven API's into the event-driven world (e.g., there's little we can do to make Amazon's API's go that way), but there are plenty of services that we can change to support event-driven interaction natively.
For application writers, life would be much easier, and we'd save each application from implementing its own caching/updating logic to track state etc. That logic would either reside in the services themselves, or in the poll/event bridges.
[IH] I agree on the QMF side - we need to provide the more powerful two-way (which allows event driven) api. One could still use the web service to poll for the state, but the solution should support sending events as well (so we should plan an API that supports both one-way and two-way modes in the one-way mode there should be an easy way to poll for the queue of events for example.
On 7 Sep 2009, at 23:28, Bob McWhirter wrote:
Howdy guys--
First, congrats to everyone for doing awesome with Deltacloud and the launch. Jeremy, the website looks fantastic. Kim and the Video team also made us all look good.
I'd like us to consider what the "end-game" of Deltacloud as an API looks like. Where do we draw the line of what is and is not Deltacloud, from an API viewpoint?
I personally think that we might want to leverage the community that'll also be building around REST-* (http://jboss.org/reststar).
+1
That is precisely one of the areas where we can and should push standardization. It's the goal of REST-*.
There, the intent it to build RESTful APIs (but not necessarily implementations) for things like messaging, transactions, and storage.
Basically, for things like Amazon's Simple Queueing Service (SQS) and SimpleDB. Implementation of these things using JBoss technologies falls under the scope of my JBoss Cloud project. JBoss Cloud (as you may or may not know) aims to make JBoss middleware "cloud-ready". So far that's meant getting JBoss AS up in a PaaS configuration "in the cloud" with clustering and such. Furthering that, I aim to get HonetQ (our messaging service) and Infinispan (our data-grid project) up as RESTful, cloud-ready services. To directly respond to SQS and SimpleDB.
I'm going to be working with REST-* on those efforts.
Where does that leave Deltacloud? I think it leaves Deltacloud Just Fine. Deltacloud addresses the IaaS level of abstraction, which is at least a level lower than REST-* seems to want to address.
Deltacloud Framework can certainly aim to tie it all together, also. We can have drivers that work with my HonetQ-REST impl of REST- Messaging, and a driver to map to Amazon's SQS (or another provider's "native" queue cloud-service).
Portall, likewise, can continue to overlay policy and other value-add on top of the "bare" protocols.
Leaving us with
Deltacloud-API -- defining IaaS-level interactions REST-* (Messaging, Transactions, Storage) -- defining the "cloud services" offered as Services-as-a-Service defining how we'd like to see Messaging, Transaction, Storage, and whatever-else servicey things. This is potentially an open-ended porftolio of specs.
Deltacloud-Portal/Proxy -- consumes Deltacloud-API and REST-* standards, orchestrates the actual coordination of mixed on-premise/off-premise/private/public resources according to user-supplied policy.
Perhaps, if needed, Deltacloud-Messaging could extend the basic REST- Messaging API defined through the REST-* community if an cloud- specific extensions are needed.
-Bob
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
--- 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
-
Bill Burke -
Bob McWhirter -
David Lutterkort -
iheim＠redhat.com -
Mark Little -
Sam Johnston