[occi-wg] moving forward

Sam Johnston samj at samj.net
Mon Jun 1 06:06:54 CDT 2009 

On Sun, May 31, 2009 at 4:47 PM, Mark Masterson <mmasterson at 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 at 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 at gmail.com>                                               To
>             Sent by:                  "occi-wg at ogf.org" <occi-wg at ogf.org>
>             occi-wg-bounces at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090601/3e29f1c5/attachment.html

More information about the occi-wg mailing list