Hi all, I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found? I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge. On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people: * People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers. * End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete. So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people. I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps. So, what have we not done yet? We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that. Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?" I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here? A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop. C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people. D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings. What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work? alexis
Alexis (and all), <snip lots of useful and relevant bits>
I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here?
A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop.
C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people.
D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings.
What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work?
I have continued to watch the OCCI list with interest, and will make a concerted effort to review the current proposals to come back with comments in the next few days. My apologies for myself or my team not having interacted more already, but current work commitments within the company have prevented this so far. We made an open pledge some months back that we would willingly adopt a new API standard based on what made most commercial sense, and I certainly think OCCI has come a long way towards this. Regards, Tony Lucas Chief Executive Officer XCalibre/FlexiScale. http://www.flexiscale.com
Hi Tony, On Tue, May 26, 2009 at 11:43 PM, Tony Lucas <tony@xcalibre.co.uk> wrote:
Alexis (and all),
I have continued to watch the OCCI list with interest, and will make a concerted effort to review the current proposals to come back with comments in the next few days. My apologies for myself or my team not having interacted more already, but current work commitments within the company have prevented this so far.
We made an open pledge some months back that we would willingly adopt a new API standard based on what made most commercial sense, and I certainly think OCCI has come a long way towards this.
It was great to meet you in Prague and discuss our respective goals... I was happy to know that you guys were monitoring our progress and I really hope we can deliver something useful for you sooner rather than later. I think the main selling points for cloud providers like yourselves are: - Interoperability for the parts we care about while still allowing you room to innovate/differentiate (if we make it too tight the commoditisation takes over)... that translates to customers being able to migrate to you easily (which is a double edged sword in that if you fail to deliver they can leave you easier too) and perhaps more importantly more tools like desktop management clients and autonomic scaling (e.g. RightScale). - Access to enterprise users who are currently kicking the tyres with PoCs and pilots, but who will likely end up with a more "enterprise" solution like VMware provided by a traditional hosting provider. If we meet their needs then you'll gain access to a segment that you might not have otherwise been able to reach. As usual open to 1 (or 2) on 1 calls with you/your staff for gathering requirements and feedback but it'll have to wait until next week unless you happen to be in Lisbon. Cheers, Sam
Alexis Richardson wrote:
On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people:
To get input from others, and people who cannot keep up with the volume on the email list, it would be really helpful if there were some kind of summary/pointers of the OCCI "state of play" on the main OCCI docuwiki web page. I've caught up on about a months worth of OCCI mailing list today since the OGF sessions were slow, and looked at RESTful proposals, state model, spreadsheet side-by-side comparison, etc. but I don't think others have 4-6 hours free to trawl the mailing list to find the relevant links and build up a coherent picture of what OCCI is currently "about". It has been said many times this past month, but certainly the very first goal of OCCI should be to settle on something totally trivial that can be implemented, and then produce a few implementations that do that. From my perspective the absolute most trivial thing would be to instantiate a virtual host, get a handle to it, and then destroy it. It sounds like this has already been done, but as someone has suggested, capturing this in a use case, describing how OCCI specifies such a scenario, then pointing to some implementations which actually do it would be a great first step. Assuming such a trivial process would be uninteresting and pointless is forgetting the problem with assumptions. Has this been done? If so, highlight it on the OCCI website landing page. If not, get it done.
Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?"
I've probably missed something. Why aren't you including EC2? Ian
On Wed, May 27, 2009 at 2:05 AM, Ian Stokes-Rees <ijstokes@spmetric.com>wrote:
To get input from others, and people who cannot keep up with the volume on the email list, it would be really helpful if there were some kind of summary/pointers of the OCCI "state of play" on the main OCCI docuwiki web page.
I've proposed (and even set up) a blog but it hasn't [yet] taken off. I'm guessing this is the best way for those not actively involved in the list to keep up with current events.
It has been said many times this past month, but certainly the very first goal of OCCI should be to settle on something totally trivial that can be implemented, and then produce a few implementations that do that. From my perspective the absolute most trivial thing would be to instantiate a virtual host, get a handle to it, and then destroy it. It sounds like this has already been done<snip>
Yes, with the status quo it goes something like this: - POST a web form to http://example.com/compute (e.g. cpu=2&memory=2048) - Follow redirect to new resource URL and GET resource as simple key-value in preferred format (text, json, xml) - Modify as required and PUT resource back where you got it. - DELETE resource when you're done with it. I'm pretty sure it's not going to get any simpler nor any more RESTful than that... and it's pretty much implementable already. Note that you don't need to know anything more than how to submit a web form and pretty much every user agent that exists today can do that.
Because we want to make use of prior art, at this point I am going to
quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?"
I've probably missed something. Why aren't you including EC2?
Ironically for the same IP issues that affect both Sun and GoGrid APIs - the absence of any patent protection whatsoever. Sure we "want to make use of prior art" as Alexis says, but only when it's safe to do so. As Mike Linksvayer (VP of Creative Commons) pointed out<http://www.tbray.org/ongoing/When/200x/2009/03/16/Sun-Cloud#c1237388431.205827>to Tim Bray: Putting a spec under a liberal CC license is a no-brainer and Sun did the
right thing in doing that. But that act's impact without a bunch of other stuff in place shouldn't be overhyped.
Surely GoGrid's patent-free, right? Not according to their launch press release<http://www.servepath.com/servepath/press-releases/gogrid-launch.php> : GoGrid features several new patent-pending technologies offering a new
approach to scalability and management of multi-server environments
I'm not going to waste my time running through Intellectual Property 101 again if people aren't going to listen anyway but I would ask that those pointing at potentially problematic APIs desist. It's just not worth the risk and the problem is not so difficult that we need to resort to copying others' work anyway, especially given how far we've come already. Replicating the Sun Cloud API and adding two tablespoons of GoGrid and a pinch of OGF's rigid state model isn't going to work and is a huge step backwards from where we are now anyway. Sam
On May 26, 2009, at 5:48 PM, Sam Johnston wrote:
<XXX, doesn't matter what> isn't going to work and is a huge step backwards from where we are now anyway.
Where are you now anyway? Facing a glaring lack of consensus on pretty well everything. I'd be careful about characterizing anything as a step back. All technical issues aside, and speaking as an outsider, I'd advise members of this group to rally around whatever your co-chairs propose, because they're trying to get you from nowhere to somewhere. -Tim
On Wed, May 27, 2009 at 3:04 AM, Tim Bray <Tim.Bray@sun.com> wrote:
On May 26, 2009, at 5:48 PM, Sam Johnston wrote:
<XXX, doesn't matter what> isn't going to work and is a huge step
backwards from where we are now anyway.
Where are you now anyway? Facing a glaring lack of consensus on pretty well everything. I'd be careful about characterizing anything as a step back.
Actually the only thing we *don't* have consensus on is whether or not to follow the leaders (Google, Microsoft, IBM) in adopting Atom, and I've already given up on the idea of using it across the board anyway (for better or worse). It's now 3am where I am and I've been on and off the phone all night with Andy getting ourselves in sync (we are, after all, doing the lion's share of the work). We've come to the conclusion that a simple key-value format originally proposed by ElasticHosts is feasible if supported by HTTP (for individual resources) and/or Atom (for collections of resources) for the meta-model. This is basically illustrated in the wiki<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign>and is a significant simplification/improvement on what I had previously proposed - at least all the extra discussion has been useful. As it's key-value (links, categories, etc. are delegated to the underlying protocol(s)) we have a further optimisation of being able to use HTML forms directly - so a client need not even understand the OCCI representation(s) if it knows how to submit a form. It really doesn't get any easier than that and we get the ability to submit e.g. OVF/OVA files for free - I'm guessing (hoping) the ElasticHosts guys will be happy when they get back from their long weekend as it was their feedback that primarily drove the revision. All technical issues aside, and speaking as an outsider, I'd advise members
of this group to rally around whatever your co-chairs propose, because they're trying to get you from nowhere to somewhere. -Tim
Having worked on this project full time and then some since March I take some amount of offense to your claim that we are "nowhere", especially considering that the proposal you're supporting "as an outsider" to get "somewhere" is the adoption and rubber stamping of your own API (not forgetting that one of the two co-chairs who "strongly supports this course of action" happens to be another Sun employee). If that ends up being the case even in light of the unresolved patent problems first raised over 2 months ago then I'll be out of here quicker than you can say "vendor capture". Sam
On Tue, May 26, 2009 at 6:43 PM, Sam Johnston <samj@samj.net> wrote:
Having worked on this project full time and then some since March I take some amount of offense to your claim that we are "nowhere", especially considering that the proposal you're supporting "as an outsider" to get "somewhere" is the adoption and rubber stamping of your own API (not forgetting that one of the two co-chairs who "strongly supports this course of action" happens to be another Sun employee). If that ends up being the case even in light of the unresolved patent problems first raised over 2 months ago then I'll be out of here quicker than you can say "vendor capture".
Sam
i am not now and never have been an employee of sun and i support the adoption of the sun api as the basis for further work. i care nothing for politics. it is simply a clean, simple solution to the problem at hand and the very fact that it requires more development makes it perfect for our purposes. i have urged you repeatedly in private communications to take a less combative approach and now i am asking you in public. you are doing little but giving others reason to ignore your views, regardless of their merit. i see no reason to question tim's motives and many reasons to agree with the api he has helped develop at sun. please take a step back and see that none of us is in charge here and we all want the best outcome. the only way we can succeed is together. we will be right sometimes and wrong sometimes (and sometimes we will be right and do the wrong thing), and that is the nature of standards bodies. b
On Wed, May 27, 2009 at 4:31 AM, Benjamin Black <b@b3k.us> wrote:
On Tue, May 26, 2009 at 6:43 PM, Sam Johnston <samj@samj.net> wrote:
Having worked on this project full time and then some since March I take some amount of offense to your claim that we are "nowhere", especially considering that the proposal you're supporting "as an outsider" to get "somewhere" is the adoption and rubber stamping of your own API (not forgetting that one of the two co-chairs who "strongly supports this course of action" happens to be another Sun employee). If that ends up being the case even in light of the unresolved patent problems first raised over 2 months ago then I'll be out of here quicker than you can say "vendor capture".
i am not now and never have been an employee of sun and i support the adoption of the sun api as the basis for further work. i care nothing for politics. it is simply a clean, simple solution to the problem at hand and the very fact that it requires more development makes it perfect for our purposes.
This is an intriguing response given I wasn't referring to you... but it's early and maybe that's not what you meant. If you're looking for a clean, simple solution then I refer you to the wiki where now hundreds of multi-vendor man hours have been spent developing same with what I consider fairly impressive (read "clean, simple") results based on what is out there today. I guess I missed the memo where running into the usual contention over programmers' preferred formats means we've failed and need to start from scratch. I also missed the part where adopting one vendor's WiP API over any other is somehow fair to other vendors, somehow different from what DMTF are doing with VMware's vCloud API and somehow sensible when we know that Sun have patents like #863157 and #925437 floating around in the problem space - I'd rather just tread carefully than burning more time engaging OGF and/or Sun's lawyers. A number of us have been closely examining multiple vendors' existing APIs and gleaning from them what is applicable to us - I don't see the need to move this effort in the direction of any one vendor over any other and more specifically I don't see things like fixed classifications schems around Virtual [Private] Data Centers and Clusters are appropriate when there are generic, flexible alternatives. I've also spent more time looking at state machine modeling and discussing it with Roger@Fujitsu in London... while I previously agreed with Tim's case for "actuators" the feedback from the REST crowd left doubt in my mind and I think we may have found a somewhat more flexible approach which provided for audit, canceling unactioned requests, etc. i have urged you repeatedly in private communications to take a less
combative approach and now i am asking you in public. you are doing little but giving others reason to ignore your views, regardless of their merit. i see no reason to question tim's motives and many reasons to agree with the api he has helped develop at sun. please take a step back and see that none of us is in charge here and we all want the best outcome. the only way we can succeed is together. we will be right sometimes and wrong sometimes (and sometimes we will be right and do the wrong thing), and that is the nature of standards bodies.
Ok so you told me to "please listen" because the author of various specs was speaking. I did, and I agree with the vast majority of what Tim has to say. You also suggested my message was lost in my delivery, which is probably true - DJB was right about DNS <http://www.doxpara.com/?p=1162> and probably is with DNSSEC vs DNScurve <http://dnscurve.org/dnssec.html> too, but inferior alternatives are still being adopted for a similar reason. That said, we're working on problems with subtle but important differences - Tim needed to expose the specific functionality of Sun's technology while we need to be more generic, flexible and extensible. We'll pick the eyes out (e.g. take the best parts) of Sun's and GoGrid's and ElasticHosts' and whatever other applicable APIs we can find but if the perfect API existed already none of us would be here. Sam
Sam, On Wed, May 27, 2009 at 10:33 AM, Sam Johnston <samj@samj.net> wrote
I guess I missed the memo where running into the usual contention over programmers' preferred formats means we've failed and need to start from scratch.
My proposal is not that we start from scratch, it is that we are missing a chunk of definitions for how to interact with the cloud. Taking the Sun/GG API and, as you put it, picking their eyes out (eek!) is a good way to fill that gap. As I say, I am looking for GROUP feedback here please.
I also missed the part where adopting one vendor's WiP API over any other is somehow fair to other vendors,
The word "adopting" does not mean the same as "taking as a starting point" which is what was used. It is precisely BECAUSE it is WiP that it is useful for our purposes which include "taking what has been done and making it better and common". I would like to hear what the other vendors think *from them*.
That said, we're working on problems with subtle but important differences - Tim needed to expose the specific functionality of Sun's technology while we need to be more generic, flexible and extensible. We'll pick the eyes out (e.g. take the best parts) of Sun's and GoGrid's and ElasticHosts' and whatever other applicable APIs we can find but if the perfect API existed already none of us would be here.
Please DO just that. Make those APIs better. Tell us what needs to be done to them to make them better. Explain the subtle but important differences with reference to the work on the wiki to illustrate specific requirements. alexis
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Alexis Richardson wrote:
Sam,
On Wed, May 27, 2009 at 10:33 AM, Sam Johnston <samj@samj.net> wrote
I guess I missed the memo where running into the usual contention over programmers' preferred formats means we've failed and need to start from scratch.
My proposal is not that we start from scratch, it is that we are missing a chunk of definitions for how to interact with the cloud. Taking the Sun/GG API and, as you put it, picking their eyes out (eek!) is a good way to fill that gap.
As I say, I am looking for GROUP feedback here please.
I'll kick in my 2cents. The behavioral models, how we will interact with the various cloud implementations is not a trivial task. It will require a "do diligence" phase for each implementation. I don't think its feasible for this group in capacity or current levels of sponsorship can achieve that goal in any reasonable amount of time. I would suggest that we engage each of the implementation teams. At a minimum, supply them with a list of questions and issues we feel is relevant to provide interoperability. I would like to have them help build the attribute matrix. If they don't participate, we do what we can and get a minimal set of features. We could also consult with the operators and end users. Interview them, find out the specific behavioral/interaction concerns for interoperability. I fully expect each will have widely varying requirements and expectations. Since they don't have it today, it may be a wish list. We can at least assess the commonalities and classify the users. -g
I also missed the part where adopting one vendor's WiP API over any other is somehow fair to other vendors,
The word "adopting" does not mean the same as "taking as a starting point" which is what was used. It is precisely BECAUSE it is WiP that it is useful for our purposes which include "taking what has been done and making it better and common".
I would like to hear what the other vendors think *from them*.
I'm not happy with the idea (ego ?), but there needs to be a hard concerted effort to get a wip document completed. The matrix on the wiki is a good starting point for an API. The life cycle portion is also a good starting point to discover behavioral gaps. A challenge with this strategy is our expectations may be too high for the outcome of the review process. Reviewers commonly critique what is "in" the doc, not what is missing from the doc. We will need to submit some structured questions with each api to solicit responses pertaining to administration, management and diagnostic support. Thats all i can think of on minimal sleep. -g
That said, we're working on problems with subtle but important differences - Tim needed to expose the specific functionality of Sun's technology while we need to be more generic, flexible and extensible. We'll pick the eyes out (e.g. take the best parts) of Sun's and GoGrid's and ElasticHosts' and whatever other applicable APIs we can find but if the perfect API existed already none of us would be here.
Please DO just that. Make those APIs better. Tell us what needs to be done to them to make them better. Explain the subtle but important differences with reference to the work on the wiki to illustrate specific requirements.
alexis
This is a little concerning. We need to first establish the attributes for each of the apis and aggregate/synthesize an api. Place that document in the hands of the reviewers. gauge the 2Ms (too much, too little). -gary
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Sam, The problem is that we don't have something concrete on the wiki that has the following properties: 1. (a) is agreed on OR (b) is a clear proposal 2. has consensus meaning support from multiple parties willing to implement and use - we don't want 'outsiders' we want convergence I am trying to PROPOSE a concrete course of action. I really truly appreciate the work you are putting in, especially the drive to work with EH and Andy from SLA@SOI. But I don't see that work necessarily conflicting with what I am proposing. As as aside, with all due respect: It does not help when you say, one week, "it really doesn't get any simpler than this" and then simplify it and again say "it really doesn't get any simpler than this". Please try to understand that we don't have full unimpeded access to all your thought processes, and consensus will arise from your clarifying them. Instead of chucking around phrases like 'vendor capture' and 'rubber stamping', why don't you tell us what Sun, GoGrid, etc, don't do to meet your requirement. Then we can make a better open document that meets the needs of multiple providers and users, and has their consensual buy in and support. We have the pieces of the puzzle right in front of us. If you object to my proposal then propose an alternative! alexis On Wed, May 27, 2009 at 2:43 AM, Sam Johnston <samj@samj.net> wrote:
On Wed, May 27, 2009 at 3:04 AM, Tim Bray <Tim.Bray@sun.com> wrote:
On May 26, 2009, at 5:48 PM, Sam Johnston wrote:
<XXX, doesn't matter what> isn't going to work and is a huge step backwards from where we are now anyway.
Where are you now anyway? Facing a glaring lack of consensus on pretty well everything. I'd be careful about characterizing anything as a step back.
Actually the only thing we don't have consensus on is whether or not to follow the leaders (Google, Microsoft, IBM) in adopting Atom, and I've already given up on the idea of using it across the board anyway (for better or worse).
It's now 3am where I am and I've been on and off the phone all night with Andy getting ourselves in sync (we are, after all, doing the lion's share of the work). We've come to the conclusion that a simple key-value format originally proposed by ElasticHosts is feasible if supported by HTTP (for individual resources) and/or Atom (for collections of resources) for the meta-model. This is basically illustrated in the wiki and is a significant simplification/improvement on what I had previously proposed - at least all the extra discussion has been useful.
As it's key-value (links, categories, etc. are delegated to the underlying protocol(s)) we have a further optimisation of being able to use HTML forms directly - so a client need not even understand the OCCI representation(s) if it knows how to submit a form. It really doesn't get any easier than that and we get the ability to submit e.g. OVF/OVA files for free - I'm guessing (hoping) the ElasticHosts guys will be happy when they get back from their long weekend as it was their feedback that primarily drove the revision.
All technical issues aside, and speaking as an outsider, I'd advise members of this group to rally around whatever your co-chairs propose, because they're trying to get you from nowhere to somewhere. -Tim
Having worked on this project full time and then some since March I take some amount of offense to your claim that we are "nowhere", especially considering that the proposal you're supporting "as an outsider" to get "somewhere" is the adoption and rubber stamping of your own API (not forgetting that one of the two co-chairs who "strongly supports this course of action" happens to be another Sun employee). If that ends up being the case even in light of the unresolved patent problems first raised over 2 months ago then I'll be out of here quicker than you can say "vendor capture".
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Ian, On Wed, May 27, 2009 at 1:05 AM, Ian Stokes-Rees <ijstokes@spmetric.com> wrote:
Alexis Richardson wrote:
On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people:
To get input from others, and people who cannot keep up with the volume on the email list, it would be really helpful if there were some kind of summary/pointers of the OCCI "state of play" on the main OCCI docuwiki web page. I've caught up on about a months worth of OCCI mailing list today since the OGF sessions were slow, and looked at RESTful proposals, state model, spreadsheet side-by-side comparison, etc. but I don't think others have 4-6 hours free to trawl the mailing list to find the relevant links and build up a coherent picture of what OCCI is currently "about".
That is correct. To all ---- The conversation on the list is good but nothing should be deemed obvious unless it is in a form that makes it so. PLEASE use the wiki to articulate specific proposals, in a form where they can be commented on (on the list) and improved (on the wiki).
It has been said many times this past month, but certainly the very first goal of OCCI should be to settle on something totally trivial that can be implemented, and then produce a few implementations that do that. From my perspective the absolute most trivial thing would be to instantiate a virtual host, get a handle to it, and then destroy it. It sounds like this has already been done, but as someone has suggested, capturing this in a use case, describing how OCCI specifies such a scenario, then pointing to some implementations which actually do it would be a great first step. Assuming such a trivial process would be uninteresting and pointless is forgetting the problem with assumptions. Has this been done? If so, highlight it on the OCCI website landing page. If not, get it done.
This is an excellent statement of the difference between list and wiki. It should not be necessary to ask a question on the list, to get an answer about something that has already been either (a) agreed, or (b) proposed clearly.
Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?"
I've probably missed something. Why aren't you including EC2?
EC2 is there in the matrix of existing APIs as a reference point and it is legitimate to say "wait but EC2 has this functionality and OCCI does not, so what requirement does EC2 meet (if any) that OCCI needs to meet". The notion of taking API X as a 'starting point' is based on it being: * open (licensing) * concrete (unambiguous, discussable, implementable) * modifiable (a licensing issue) * extensible (eg to add functionality or integration points) Sun and GG (and EH) meet those criteria. Given the Sun documents we could take the GG and EH work and "make something better". We could also take the OCCI work and make something better still. This process works when multiple users and implementers support it. That's what I am looking for. The keyword is multiple. Anything else is just hot air. a
Alexis Richardson wrote:
The notion of taking API X as a 'starting point' is based on it being:
* open (licensing) * concrete (unambiguous, discussable, implementable) * modifiable (a licensing issue) * extensible (eg to add functionality or integration points)
Sun and GG (and EH) meet those criteria. Given the Sun documents we could take the GG and EH work and "make something better". We could also take the OCCI work and make something better still.
This process works when multiple users and implementers support it. That's what I am looking for. The keyword is multiple. Anything else is just hot air.
This works as a process, and we would support it starting from any of the Sun, GG or EH APIs. In all cases there would be some work to do - for example on storage, EH does not yet support non-persistent "scratch" drives for an instance, GG does not support multiple drives on a server, and I'm not sure if Sun supports persistent drives which survive a server being stopped. If we go this route, we must to take Sam and Gary's concerns regarding patents seriously. It is not sufficient for the API _specification_ to be under Creative Commons if all implementers will still have to pay patent royalties to a vendor when they implement it. "Reasonable and Non-Discriminatory" licensing is also not sufficient - as Sam and Gary have said there would need to be a "Royalty-Free" patent pledge stating that the future OCCI API will not require any licence or payment. The patent situation is currently unclear. Fortunately however, we have representation from all three of Sun, GG and EH on this list, so OGF can extract the necessary royalty-free patent pledges! Tim / Thijs - can you arrange for Sun to make a royalty-free patent pledge regarding the Sun Cloud APIs, so that OCCI could consider building from them? Randy - if you are still the right person at GoGrid (http://cloudscaling.com/blog/administrivia/my-gogrid-status) then can you arrange for GoGrid to make a royalty-free patent pledge if OCCI were to build from your APIs? myself (ElasticHosts) - I'm happy to commit here and now. If OCCI wants to build from the EH APIs then we will immediately license them under Create Commons or any similar license. We have no patents covering our APIs, and I'm willing to sign any royalty-free patent pledge that OCCI gives me. Cheers, Richard.
Thanks Richard. Just to explain what the patent issue is in more detail, the concern that Sam raised is articulated in this blog post: http://creativecommons.org/weblog/entry/13654 I would be very interested in what the OGF policy is here. On Wed, May 27, 2009 at 12:58 PM, Richard Davies <richard.davies@elastichosts.com> wrote:
Alexis Richardson wrote:
The notion of taking API X as a 'starting point' is based on it being:
* open (licensing) * concrete (unambiguous, discussable, implementable) * modifiable (a licensing issue) * extensible (eg to add functionality or integration points)
Sun and GG (and EH) meet those criteria. Given the Sun documents we could take the GG and EH work and "make something better". We could also take the OCCI work and make something better still.
This process works when multiple users and implementers support it. That's what I am looking for. The keyword is multiple. Anything else is just hot air.
This works as a process, and we would support it starting from any of the Sun, GG or EH APIs.
In all cases there would be some work to do - for example on storage, EH does not yet support non-persistent "scratch" drives for an instance, GG does not support multiple drives on a server, and I'm not sure if Sun supports persistent drives which survive a server being stopped.
If we go this route, we must to take Sam and Gary's concerns regarding patents seriously. It is not sufficient for the API _specification_ to be under Creative Commons if all implementers will still have to pay patent royalties to a vendor when they implement it. "Reasonable and Non-Discriminatory" licensing is also not sufficient - as Sam and Gary have said there would need to be a "Royalty-Free" patent pledge stating that the future OCCI API will not require any licence or payment.
The patent situation is currently unclear. Fortunately however, we have representation from all three of Sun, GG and EH on this list, so OGF can extract the necessary royalty-free patent pledges!
Tim / Thijs - can you arrange for Sun to make a royalty-free patent pledge regarding the Sun Cloud APIs, so that OCCI could consider building from them?
Randy - if you are still the right person at GoGrid (http://cloudscaling.com/blog/administrivia/my-gogrid-status) then can you arrange for GoGrid to make a royalty-free patent pledge if OCCI were to build from your APIs?
myself (ElasticHosts) - I'm happy to commit here and now. If OCCI wants to build from the EH APIs then we will immediately license them under Create Commons or any similar license. We have no patents covering our APIs, and I'm willing to sign any royalty-free patent pledge that OCCI gives me.
Cheers,
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Quoting [Alexis Richardson] (May 27 2009):
Date: Wed, 27 May 2009 13:12:29 +0100 From: Alexis Richardson <alexis.richardson@gmail.com> To: Richard Davies <richard.davies@elastichosts.com> Cc: occi-wg@ogf.org Subject: Re: [occi-wg] moving forward
Thanks Richard.
Just to explain what the patent issue is in more detail, the concern that Sam raised is articulated in this blog post: http://creativecommons.org/weblog/entry/13654
I would be very interested in what the OGF policy is here.
OGF's policy is described at http://www.ogf.org/About/abt_policies.php. Please let me know if you have more specific questions - I'm happy to farward those to the responsible OGF folx.
myself (ElasticHosts) - I'm happy to commit here and now. If OCCI wants to build from the EH APIs then we will immediately license them under Create Commons or any similar license. We have no patents covering our APIs, and I'm willing to sign any royalty-free patent pledge that OCCI gives me.
Richard, example IPR notices are at http://www.ogf.org/About/abt_policies_ipr.php. Could you draft a similar statement and send it to office@ogf.org? Cheers, Andre.
Cheers,
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
Andre Merzky wrote:
I would be very interested in what the OGF policy is here.
OGF's policy is described at http://www.ogf.org/About/abt_policies.php. Please let me know if you have more specific questions - I'm happy to forward those to the responsible OGF folks.
As I understand this document and your previous mail, the OGF position is that it requires at a minimum pledges of RAND (Reasonable and Non-Discriminatory) patent licensing: http://www.ogf.org/pipermail/occi-wg/2009-May/000778.html I strongly support Gary Mazz's reply at the time: http://www.ogf.org/pipermail/occi-wg/2009-May/000779.html We should make absolutely sure that OCCI either has no patent entanglement or that all relevant intellectual property is available RF (Royalty-Free). This is what we'd need to clarify with Sun or GoGrid before I'd be willing to base OCCI from one of their APIs. With a royalty-free patent pledge, I'd be happy to base it on either of them.
myself (ElasticHosts) - I'm happy to commit here and now. If OCCI wants to build from the EH APIs then we will immediately license them under Create Commons or any similar license. We have no patents covering our APIs, and I'm willing to sign any royalty-free patent pledge that OCCI gives me.
Richard,
example IPR notices are at http://www.ogf.org/About/abt_policies_ipr.php. Could you draft a similar statement and send it to office@ogf.org?
Absolutely - I will do that now and will cc: this list. I look forward to Sun and GoGrid following suit! Cheers, Richard.
Quoting [Richard Davies] (May 27 2009):
Andre Merzky wrote:
I would be very interested in what the OGF policy is here.
OGF's policy is described at http://www.ogf.org/About/abt_policies.php. Please let me know if you have more specific questions - I'm happy to forward those to the responsible OGF folks.
As I understand this document and your previous mail, the OGF position is that it requires at a minimum pledges of RAND (Reasonable and Non-Discriminatory) patent licensing: http://www.ogf.org/pipermail/occi-wg/2009-May/000778.html
I strongly support Gary Mazz's reply at the time: http://www.ogf.org/pipermail/occi-wg/2009-May/000779.html
We should make absolutely sure that OCCI either has no patent entanglement or that all relevant intellectual property is available RF (Royalty-Free).
This is what we'd need to clarify with Sun or GoGrid before I'd be willing to base OCCI from one of their APIs. With a royalty-free patent pledge, I'd be happy to base it on either of them.
I agree. OGF's requirement of RAND is a minimum - I don't think that precludes RF statements at all. If the OCCI group feels that RF is a requirement (and it seems like this), then the group should try to recieve those RF statements (as you do). Still, they should be posted on the official OGF page.
myself (ElasticHosts) - I'm happy to commit here and now. If OCCI wants to build from the EH APIs then we will immediately license them under Create Commons or any similar license. We have no patents covering our APIs, and I'm willing to sign any royalty-free patent pledge that OCCI gives me.
Richard,
example IPR notices are at http://www.ogf.org/About/abt_policies_ipr.php. Could you draft a similar statement and send it to office@ogf.org?
Absolutely - I will do that now and will cc: this list. I look forward to Sun and GoGrid following suit!
Great, thanks! Best, Andre.
Cheers,
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Nothing is ever easy.
Submitted by Richard Davies, CEO, ElasticHosts ElasticHosts is pleased to announce that any patent claims held by ElasticHosts which are necessary to implement the "Open Cloud Computing Interface" (OCCI) as designed by the OGF Open Cloud Computing Interface Working Group will be licensed on a royalty-free basis. ElasticHosts strongly supports the creation of open and royalty-free standards for cloud computing, which we believe will be essential for the success of this key technology.
Richard, On Wed, May 27, 2009 at 2:43 PM, Richard Davies < richard.davies@elastichosts.com> wrote:
Submitted by Richard Davies, CEO, ElasticHosts
ElasticHosts is pleased to announce that any patent claims held by ElasticHosts which are necessary to implement the "Open Cloud Computing Interface" (OCCI) as designed by the OGF Open Cloud Computing Interface Working Group will be licensed on a royalty-free basis.
ElasticHosts strongly supports the creation of open and royalty-free standards for cloud computing, which we believe will be essential for the success of this key technology.
Thanks for taking the issue seriously - I note that your statement has already been published on ogf.org and that there is precedent for Sun having done the same for a previous API. Here's hoping we'll see something from both Sun and GoGrid in due course. FWIW the OGF IPR policy is drawn into the membership agreement so member companies are covered across the board... Sun's not a member but Oracle is ;) Sam
Sun is a member of OGF. Just like Oracle. All the best, -Thijs On Wed, 2009-05-27 at 18:04 +0200, Sam Johnston wrote:
Richard,
On Wed, May 27, 2009 at 2:43 PM, Richard Davies <richard.davies@elastichosts.com> wrote: Submitted by Richard Davies, CEO, ElasticHosts
ElasticHosts is pleased to announce that any patent claims held by ElasticHosts which are necessary to implement the "Open Cloud Computing Interface" (OCCI) as designed by the OGF Open Cloud Computing Interface Working Group will be licensed on a royalty-free basis.
ElasticHosts strongly supports the creation of open and royalty-free standards for cloud computing, which we believe will be essential for the success of this key technology.
Thanks for taking the issue seriously - I note that your statement has already been published on ogf.org and that there is precedent for Sun having done the same for a previous API. Here's hoping we'll see something from both Sun and GoGrid in due course.
FWIW the OGF IPR policy is drawn into the membership agreement so member companies are covered across the board... Sun's not a member but Oracle is ;)
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
On Wed, May 27, 2009 at 6:06 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
Sun is a member of OGF. Just like Oracle.
Well y'all should get yourselves on the list<http://www.ogf.org/Members/members_members.php> . Sam
I'll ping Joel *g* :-) Thanks for the pointer... On Wed, 2009-05-27 at 18:13 +0200, Sam Johnston wrote:
On Wed, May 27, 2009 at 6:06 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote: Sun is a member of OGF. Just like Oracle.
Well y'all should get yourselves on the list.
Sam
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
On May 27, 2009, at 9:04 AM, Sam Johnston wrote:
Here's hoping we'll see something from both Sun and GoGrid in due course.
Normally, this is the kind of thing that Sun's been very good at. There's some correspondence going around, internally. At this point, however, anything that represents a nontrivial corporate commitment is probably needs routing through the Sun-Oracle integration team; those guys are all about distilling sanity out of Oracle's 80k headcount as combined with Sun's 30k, and are possibly the most overworked group on the planet right now. So, probably count on delays. Hey, if someone from Oracle wanted to speak up pre-emptively...
FWIW the OGF IPR policy is drawn into the membership agreement so member companies are covered across the board...
Does our having signed up to this make any difference? Thijs? Alexis? And I hate to end on a cynical note, but in practice this whole patent- coverage exercise probably doesn't mean a damn thing. Anyone with exposure to the dismal universe of software patents would probably agree with my guess that there are tons of 'em out there covering every little aspect of anything we might do, many held by people who aren't OGF members or haven't even heard of "Cloud Computing" at this point. Yes, it's nice when people who are *in the process* do non- asserts, and I support that. But typically those people aren't the problem. But there is good news, too. Unlike the situation in the hardware world, I'm not aware of anyone ever having successfully set up a patent-based tollbooth on a software-only Internet protocol deployment. FWIW, my own position: RAND is 100% unacceptable because it rules out open-source solutions. Protocols which require any kind of licensing whatsoever cannot be used on the Internet. -Tim
FWIW the OGF IPR policy is drawn into the membership agreement so member companies are covered across the board...
Does our having signed up to this make any difference? Thijs? Alexis?
Well not really (but do not nail me on this statement) In the history of OGF this doesn't have to happen a lot. And until we are not pushing Sun Cloud APi into the OGF group we are fine without an signed statement. Everything which is posted or stated in concalls already falls under the OGF IPR by the way... Cheers, -Thijs
On Wed, May 27, 2009 at 7:17 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
FWIW the OGF IPR policy is drawn into the membership agreement so member companies are covered across the board...
Does our having signed up to this make any difference? Thijs? Alexis?
Well not really (but do not nail me on this statement) In the history of OGF this doesn't have to happen a lot. And until we are not pushing Sun Cloud APi into the OGF group we are fine without an signed statement.
As you say, if we're not importing any APIs wholesale we should be fine - most of what we'd incorporate passes the obviousness test<http://en.wikipedia.org/wiki/Inventive_step_and_non-obviousness>anyway... it's just when people start talking about commercial APIs as "starting points" that I break out into a cold sweat. Very happy to see some good progress made with this today... we've got a solid start and plenty of places to pull in refinements. Sam
As you say, if we're not importing any APIs wholesale we should be fine - most of what we'd incorporate passes the obviousness test anyway... it's just when people start talking about commercial APIs as "starting points" that I break out into a cold sweat.
Starting point does not mean we copy Sun Cloud API or anything like that...There are more ways then that! And I'm sure that is what Alexis meant in his proposal on howto move on... Cheers, -Thijs
Correct. On Wed, May 27, 2009 at 8:16 PM, Thijs Metsch <Thijs.Metsch@sun.com> wrote:
As you say, if we're not importing any APIs wholesale we should be fine - most of what we'd incorporate passes the obviousness test anyway... it's just when people start talking about commercial APIs as "starting points" that I break out into a cold sweat.
Starting point does not mean we copy Sun Cloud API or anything like that...There are more ways then that! And I'm sure that is what Alexis meant in his proposal on howto move on...
Cheers,
-Thijs
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi all, I strongly support this course of action. One short comment on the side. If we decide to go for one or another rendering that doesn't mean we cannot have a look at other renderings in future. But for now we should follow the purposed process. In future we can for sure add extensions and some more renderings of formats if somebody wants it. Remember that this group wants to deliver fast. But after we delivered the API 1.0 or so we are not done and can work on extensions and other renderings. We can and probably change the charter accordingly and put in a timeline describing where we want to go in the future after our first API. All the best, -Thijs On Tue, 2009-05-26 at 22:31 +0100, Alexis Richardson wrote:
Hi all,
I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found?
I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge.
On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people:
* People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers.
* End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete.
So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people.
I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps.
So, what have we not done yet?
We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that.
Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?"
I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here?
A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop.
C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people.
D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings.
What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work?
alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
The Process - Will it work? In a word, yes but let us make what we have worked on in the wiki [1] as the base for our comparison, compare/contrast. On aspects of patents, IANAL etc but can we split that discussion into its own thread? Regarding comparisons - I think that it is a very useful exercise to do such a comparison (I’m biased - I suggested it! :-D). However to Alexis' course suggestion I would like to add one amendment and place emphasis on taking what we, OCCI-WG, have in the wiki [1] and then compare/contrast it with others and see which is weak where and then provide recommendations to OCCI and/or the API provider. That way everyone gets something out of it and encourages participation. Indeed on reviewing APIs for SLA@SOI [2][3], I might suggest that OCCI would need to manage long running tasks (such as provisioning of VMs) in a fashion not all too similar to how GoGrid do it. Also, reviewing the other models will help us form a common set of attributes for our nouns and help take as many different providers needs into consideration. Another example is SUN's API. It has a fixed static hierarchy of groupings (Cloud, VirtualDataCenter, Cluster) - those grouping may not suit every provider. So OCCI can make that more generic and provide a means to make group/collection management to suit all providers. Sun do support the use of tags something that we can consider in the our design. These are not proposals right now but a flavour of how we can proceed with the Process so let's not diverge this thread. Sam and I and have clarified what we feel is a good starting point from the aspect of model and protocol - HTTP, RESTful (this will help in define the "WHAT" operations do) and always striving to adopt best practices, initially XML for representation (yes, attached to a schema). But wait, yes there are complimenting JSON and TXT renderings but as Thijs mentioned we can add/subtract in the future. Details of this can be found here [1]. With respect to Atom there are 2 points to deal with: 1) OCCI Model Independence OCCI is not tightly coupled to Atom in any way. This relationship was unclear to me but by discussion with Sam this is now rectified. An OCCI model can exist without the dependency on Atom and a model-instance can be generated without referring to external schemas like Atom. 2) OCCI and the use and management of collections. In reference to Atom: Currently there is no real standard approach in dealing with collections of item when it comes to web APIs - it's left up to application logic directed by each individual service provider. Atom provides a suggestion to this as part of its standard and, one could argue by association, a standard in itself. With this in mind it makes sense to provide a standardised means to interact and manage collections in a way that is common to all service providers and so we should as part of our API design use Atom's specifications on this. As OCCI we can either mandate this or recommend this but bear in mind that it's a means to further interoperability. An interesting parallel on this was told by Alexis to me: One of the reasons that the adoption of OODBs hasn't been rapid is the problem whereby you need to create your own lookup scheme and collection management. For RMDBs this is a freebie and a standard (if you ignore extensions etc), however with OODBs there are a number of competing proposed suggested standards - and of course the "roll-your-own" variety. Finally to echo Tim's point - let's get a consolidated direction & consensus on this to somewhere. I feel we're not far off. I myself am available to chat to anyone (skype:andy.edmonds) or if you want my mobile, message me off-list. Andy [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign [2] http://forge.ogf.org/sf/go/doc15610 [3] http://forge.ogf.org/sf/go/doc15612 -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexis Richardson Sent: 26 May 2009 22:31 To: occi-wg@ogf.org Subject: [occi-wg] moving forward Hi all, I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found? I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge. On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people: * People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers. * End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete. So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people. I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps. So, what have we not done yet? We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that. Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?" I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here? A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop. C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people. D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings. What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work? alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
What about versioning the API? This is surprisingly hard to get right, but (for many, just as surprisingly) awfully important -- I have seen numerous enterprisey distributed system efforts fail for just (and entirely) this reason. There is no mention in any of the three APIs being talked about here (GoGrid, EH, or Sun) of versioning that I can find? Nor do I recal it being discussed as a first class design goal on this list yet? On the wiki there is no mention of it in the API Design section. Although I confess that I have never used it in anger, there is a fascinating proposal for attacking versioning in a RESTful way here: http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ (with some caveats here: http://barelyenough.org/blog/2008/05/versioning-rest-web-services-tricks-and... ). The REST gurus in this group may well know an even better way to solve the problem. I'd be interested in hearing others' views on this. Mark Masterson Enterprise architect, troublemaker CSC Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss Masterson | Public blog: Process Perfection (http://jroller.com/MasterMark/) | mmasterson@csc.com | www.csc.com. CSC • This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered in England No: 0963578
FWIW (and, apologies for coming late to the party -- day job and all that), I strongly support this approach. It's worth mentioning that I agree with and support the clarifications that Sam, Andy and others have made. I don't understand this approach to mean "adopting" or even "using" any particular existing API -- it's about picking the best ideas and making OCCI a synthesis of them. And it may also be worth mentioning that I know nothing of patents, so I'm content to defer debates about their inherent evils to people who do. In general, I'm encouraged with the progress I've seen here over the last few days. I really like the RESTful work that is now emerging on the wiki. Mark Masterson Enterprise architect, troublemaker CSC Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss Masterson | Public blog: Process Perfection (http://jroller.com/MasterMark/) | mmasterson@csc.com | www.csc.com. CSC • This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered in England No: 0963578 Alexis Richardson <alexis.richardso n@gmail.com> To Sent by: "occi-wg@ogf.org" <occi-wg@ogf.org> occi-wg-bounces@o cc gf.org Subject [occi-wg] moving forward 26/05/09 17:31 Hi all, I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found? I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge. On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people: * People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers. * End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete. So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people. I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps. So, what have we not done yet? We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that. Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?" I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here? A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop. C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people. D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings. What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work? alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Sun, May 31, 2009 at 4:47 PM, Mark Masterson <mmasterson@csc.com> wrote:
FWIW (and, apologies for coming late to the party -- day job and all that), I strongly support this approach.
Better late than never :)
It's worth mentioning that I agree with and support the clarifications that Sam, Andy and others have made. I don't understand this approach to mean "adopting" or even "using" any particular existing API -- it's about picking the best ideas and making OCCI a synthesis of them.
Agreed - since the very beginning (actually technically *before* the beginning) I've been talking about OCCI as a "consensus" of existing APIs... which doesn't mean it should necessarily end up closer to one over another as *all* of the existing APIs have limitations which stem from being designed by a single entity for a single implementation.
And it may also be worth mentioning that I know nothing of patents, so I'm content to defer debates about their inherent evils to people who do.
Patents are like government licenses to set up toll bridges... you can charge whatever you like for the toll and even decide not to let certain cars past based on make, model, colour or just because you feel like it. Enter RAND - this requirement limits the toll to something "reasonable" (e.g. $3 rather than $300) and "non-discriminatory" (e.g. you have to let all cars past for the same price). That works nicely for things like advanced video codecs (for which the costs should be reasonably recoverable) but it limits implementations to commercial products (e.g. Adobe Flash) while excluding open source altogether (e.g. Mozilla Firefox)... unless an exception is introduced based on OSI approved licensing etc. That's why specs like the Ogg Theora video codec <http://yro.slashdot.org/article.pl?sid=07/12/11/1339251> have a good chance of success even if technically inferior to commercial offerings like H.264 (which is not to say that I believe that to be the case). Although OGF policy may permit us to adopt RAND, we most certainly should avoid it at all costs. The only thing we should avoid more than that (by way of membership agreements, patent pledges, etc.) is infringing patents to which even RAND does not apply and for which licensing (if any is even offered) is determined by litigation. Ideally of course we wouldn't go near any patents but that's impossible to guarantee so we just need to be as careful as possible - the risk is low but the potential cost for our users is extreme. In general, I'm encouraged with the progress I've
seen here over the last few days. I really like the RESTful work that is now emerging on the wiki.
Agreed, this approach should be both extremely simple and extremely scalable. Sam
Mark Masterson Enterprise architect, troublemaker CSC
Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss Masterson | Public blog: Process Perfection (http://jroller.com/MasterMark/) | mmasterson@csc.com | www.csc.com.
CSC • This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered in England No: 0963578
Alexis Richardson <alexis.richardso n@gmail.com> To Sent by: "occi-wg@ogf.org" <occi-wg@ogf.org> occi-wg-bounces@o cc gf.org Subject [occi-wg] moving forward 26/05/09 17:31
Hi all,
I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found?
I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge.
On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people:
* People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers.
* End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete.
So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people.
I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps.
So, what have we not done yet?
We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that.
Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?"
I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here?
A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop.
C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people.
D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings.
What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work?
alexis _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (12)
-
Alexis Richardson -
Andre Merzky -
Benjamin Black -
Edmonds, AndrewX -
Gary Mazz -
Ian Stokes-Rees -
Mark Masterson -
Richard Davies -
Sam Johnston -
Thijs Metsch -
Tim Bray -
Tony Lucas