[occi-wg] On repainting the bikeshed at the 11th hour...

[Gary Mazz]

Sam  +2

It is much simpler to map a strongly hierarchal structure to a flat 
representation than the converse.

Moving towards a JSON ONLY solution may alienate and exclude 
interoperability with other well established and standardized management 
schemes. IMHO, this would be very poor approach for this occi effort. In 
fact, using a JSON scheme would prove challenging to clearly represent 
relationships in a unix /dev tree or the /proc file system. For example, 
representing the different views capable in SNIA storage models with 
JSON would be extremely difficult, if not at all.

Rendering a model, whether in XML or JSON should not be the issue. 
Providing an accurately rendered representation reflecting the interests 
of the users, including system managers, is very important. Today, most 
computer systems are organized and represented though management schemes 
that are at least hierarchical if not network models ie: recursion 
though symbolic and hard links. Most storage systems, along with TINA, 
and DMTF's CIM,  are complex systems represented though standardized 
management schemes that are complex network models. As the cloud matures 
and as we adopt collaborative practices, do we actually believe cloud 
systems and architectures will reduce complexity ? I don't believe so.

It is far easier to represent hierarchical and network (not networking) 
information with XML than JSON. It also requires less time and effort, 
we don't have to flatten existing models and delay adoption.

I personally believe there will be many opportunities to represent the 
complex in flatter renderings (mappings) like JSON, flat text or ASN.1,  
SNMP MIBS or enterprise 6bit paper tape. Each entity involved with 
clouds will have their own business models and processes. Roles and 
existing operational models will determine the informations required 
from clouds, one size will not fit all. We cannot treat clouds as a 
university mid-term project or the 20year fiasco of linux. IMHO, again, 
moving to a JSON only solution would radically defeature capabilities 
and significantly limit the value proposition of deployments.

IMHO, Sam is on target,
Mark:  Go work as an IT tech in a very large data center, your opinion 
will change.

cheers,
Gary Mazz

Sam Johnston wrote:
> Including the list this time...
>
> On 5/7/09, Sam Johnston <samj at samj.net> wrote:
>   
>> So examples of the requisite extensibility include creating complex
>> storage and networking resources and importing the (large) existing
>> base of compute resources (in OVF or other legacy formats). It is
>> without doubt better to have the option and not use it than give it up
>> and find we need it.
>>
>> For the componentisation of implementations, it's highly unlikely that
>> the best architecture is to use the same platforms for everything from
>> controllers to monitoring to billing to security etc. in which case it
>> is extremely useful to be able to pass your messages around and build
>> them iteratively. JSON is great for [de]serialising objects in memory
>> but is actually more troublesome than XML for this particular use
>> case.
>>
>> I guess a lot of this comes down to the public vs private debate that
>> Ignacio captured nicely in a recent blog post. I prefer not to
>> differentiate and have my money on hybrid architectures. As a
>> potential client implementor I'd mych prefer not to have to implement
>> OCCi *and* vCloud^W OVF2.0 for things like that function people are
>> calling 'cloudbursting'.
>>
>> With XML we can be light for light users and as fat as need be for the
>> more demanding ones (like my enterprise clients who are primarily from
>> the CAC 40 - top 40 companies in France).
>>
>> FWIW I actually dislike XML as much as the next guy but I'm also very
>> practical and like to avoid cutting off my nose to spite my face.
>>
>> Sam on iPhone
>>
>> On 5/7/09, Mark Masterson <mmasterson at csc.com> wrote:
>>     
>>> Sam -- for the record, I find blanket assertions such as "an essential
>>> enterprise feature" to be problematic.  I'm about as enterprisey as
>>> anyone
>>> could possibly be, and you are definitely *not* speaking on my behalf
>>> here.
>>> I've no doubt that you are speaking for someone or something that relates
>>> to your experience, and an alternative phrasing such as "an essential
>>> feature for the enterprise customers I work with" would clearly
>>> articulate
>>> that.  But I"m here to tell you -- there's a large and valid population
>>> of
>>> folk who self-identify as "enterprise" who disagree with much of your
>>> reasoning.  Here are some examples:
>>>
>>> -- "The schema is a WiP for a start, and an essential enterprise
>>> feature".
>>>
>>> No, it is not.  In my world, we are busy trying to learn many lessons
>>> from
>>> the Web, only some of which fit within the scope of the term REST.  One
>>> of
>>> the most important lessons we are trying to internalise and apply is that
>>> a
>>> priori schemas are sometimes much more trouble than they are worth.  In
>>> that world, among other things, there are any number of examples of cases
>>> where I am trying to figure out how to *store my data* without an a
>>> priori
>>> schema, because that confers on me all sorts of advantages which seem to
>>> move me an inch or two towards the holy grail of disposable software.  I
>>> can assure you that, in those sorts of contexts, the idea of going to
>>> those
>>> lengths, only to move data to and from those schema-less data stores via
>>> "standard" mechanisms that impose one of its own can provoke gales of
>>> (slightly bitter) laughter.
>>>
>>> -- "Our success *requires* playing nice with OVF. And SNIA. And probably
>>> a
>>> bunch of other stuff in the future" followed then by "Our spec will be
>>> concise anyway given how we use XML in the lightest way possible".
>>>
>>> It worries me that you may not see the contradiction lurking in those two
>>> statements.  At best, these statements have a high probability of both
>>> being true only at a given point in time; one quite early in the life
>>> cycle
>>> of OCCI (which, of course, is where we are).  Over time, it is *very*
>>> unlikely (verging on the impossible, IMO) that both statements can
>>> *remain*
>>> true.  This is because the imperative underlying each of these statements
>>> is in direct conflict with the other -- "playing nice with others" is in
>>> direct conflict with "concise".  We all seem to be in agreement about the
>>> merits of concise -- the disagreement revolves around the degree of
>>> "playing nice with others", and / or preparing for playing nice with
>>> others.  I think there is a strong argument to be made for making a
>>> deliberate decision, at this point in the lifecycle, to *not* make
>>> playing
>>> nice with others a goal.  Explicitly -- IOW, making it a non-goal.
>>> Instead, focus on what I thought this group was chartered to do -- the
>>> simplest possible common representation of what's already out there,
>>> working.  The "others" be damned.
>>>
>>> -- "Cloud architectures are complex with many differs t extensions having
>>> to contribute to answers. JSON does not lend itself to this kind of thing
>>> so it's actually (a lot) more work for implementors"
>>>
>>> That sounds, to this "enterprise voice", like a feature, not a bug.
>>> Constraints are good.  I like constraints.  You have not yet convinced me
>>> that the "extensions" you refer to here are critical to the core of the
>>> aforementioned simplest possible common representation of what's already
>>> out there, working.  Instead, the impression I get is that these
>>> extensions
>>> (or even the possibility of having them) serves primarily the "play nice
>>> with others" (non) goal.  Since I don't think worrying about playing nice
>>> with others is a good idea, imposing a contstraint that makes it harder
>>> to
>>> do seems like a good idea to me.  Helps focus on the core goal --
>>> distractions fall away.  In my experience, that's a design approach that,
>>> in turn, produces *very* robust artefacts -- ones on which it is
>>> subsequently relatively easy to build more stuff (to play with other, for
>>> example).  Doing things the other way round (trying to anticipate and
>>> account for possible "extensions"), in my experience, too often leads to
>>> fragile, brittle designs.
>>>
>>> This argument, OTOH:
>>>
>>> -- "Agreed but that was before we had an almost complete spec, a rough
>>> reference implementation complete with mechanical transforms to the
>>> requested formats and the start of a HTML interface for good measure. For
>>> JSON we have nothing"
>>>
>>> ... is quite compelling, and in my view.  And that may outweigh all other
>>> concerns, given the desire to hold the date.  Dunno.
>>>
>>>
>>>
>>> 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
>>> _______________________________________________
>>> 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
>
>