[occi-wg] Events ?
Gary Mazz
garymazzaferro at gmail.com
Wed May 20 04:05:39 CDT 2009
Hi Andy,
I think the hierarchy is important. I took issue (confusion) with the
"cluster" term and lack of definition for the execution container (vm)
where the resources are attached. The names in the hierarchy are
arbitrary, but we are probably better off defining a scheme and some
basic/standard logical entities like clouds, federations, domains,
worlds, applications and services. How they are organized should be up
to the user's management scheme. We just need to define a way create and
reconcile the hierarchy.
-gary
Edmonds, AndrewX wrote:
> I had a related offline comment by Andre - " Minor comment: the hierarchy you added on top of Compute seems arbitrary (to me). Can that be done generically, e.g. a group entity which has 1:n mapping to itself, and Compute resources?"
> With that I modified things to be more generic/flexible - see attached.
>
> Andy
>
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Gary Mazz
> Sent: 20 May 2009 09:14
> To: Sam Johnston
> Cc: occi-wg at ogf.org; Roger Menday
> Subject: Re: [occi-wg] Events ?
>
>
> Sam Johnston wrote:
>
>> Gary,
>>
>> The UML doesn't reflect the reality of the AtomPub meta-model, which
>> is in fact far more flexible. I don't care if you call your logical
>> collections "groups", "clusters", "virtual data centers" or "gaggles".
>>
> I assumed its more flexible, but I wasn't sure of the terminology and
> division of responsibilities. The DMTF model included virtual metal like
> network adapters and HBAs. Others define disk drives and disk files. I
> don't see any managing QOS for virtual metal. The problem with all this
> vmetal is it exposes the underlying fabric or a vitalized view of the
> underlying fabric. ie switches, gateways, routers, paths, storage
> multipathing, disk arrays and luns. It can be a can o' worms. We still
> need to figure out how to handle an IP address in one cloud provider on
> one net segment and migrating to another provider on another net segment.
>
>> The categories have terms ("win2k3"), labels ("Windows 2003 Server")
>> and schemes ("http://purl.org/occi/category#os") and the very first
>> category we would be looking to define is of course the resource types
>> (what Google call "kinds") - that is, "compute", "storage", "network"
>> (and according to NIST's draft definition, in future "application" and
>> "service" - though I'm not sure about that).
>>
> In part, I'm trying to itemize the terms/properties.
>
>> Hierarchical grouping is something to talk about - do we use something
>> like a '/' separator ala /myvdc/myvrack, have pointers to "parent"
>> objects, or something else.
>>
> Agreed, I personally would like to see different views of the system.
> The end user should see /Domain/Federation/Cloud/containers/resources .
> The cloud provider should see
> /Cloud/Federation/Domain/containers/resources or
> /Cloud/Domain/Federation/containers/resources. Privacy laws and business
> practices may restrict one cloud provider from viewing a domain's other
> cloud providers and their resources. The roles are also different. The
> Domain would be interested in a view of its multiple cloud providers.
> The cloud providers would be interested in the Domains and their
> utilization.
>
>> Ok have a flight to catch to London - see [some of] you there.
>>
> Safe trip...
>
> -gary
>
>> Sam
>>
>> On Wed, May 20, 2009 at 5:38 AM, Gary Mazz <garymazzaferro at gmail.com
>> <mailto:garymazzaferro at gmail.com>> wrote:
>>
>> Yes, thanks.. I'm looking at it and using it as a guide to the
>> other specs.
>>
>> I'll explain why I'm confused and it look like I'm pursuing more
>> than the scope
>>
>> In the occi system model, the IaaS fits between the PaaS and
>> fabric. Looking at the occi UML it shows the compute resource as
>> aggregated dependency of cluster<ag>>domain<ag>>cloud. The
>> example defines "groups" as racks, pools, data center, etc., real
>> physical assets. Based on the example, I think of clusters as
>> organization of physical compute resources. If the intent was to
>> keep domain and cloud logical elements, it may be better to get
>> rid of the cluster as a class and convert it to a property
>> defining a quality of service for the user. Some may disagree, but
>> I don't believe the user cares if there is a cluster configured
>> for round robin, random distribution, active all or primary/spare
>> failover. I'm assuming they'll care about workload capacity and
>> service availability. (and costs).
>>
>> Currently cluster<ag>>domain<ag>>cloud looks more like a fabric
>> than a logical components. Fabrics need a different set of
>> capabilities, like events.
>>
>> -gary
>>
>>
>> Alexis Richardson wrote:
>>
>> Gary
>>
>> Have you seen the interface comparison spreadsheet?
>>
>> http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ
>>
>> This is our core focus for interop. To achieve commonality
>> right here
>> right now. No invention just interop.
>>
>> a
>>
>>
>> On Tue, May 19, 2009 at 9:51 PM, Gary Mazz
>> <garymazzaferro at gmail.com <mailto:garymazzaferro at gmail.com>>
>> wrote:
>>
>>
>> Well since this is a interoperability interface, I'm
>> assuming there will be
>> gateways to other technologies like fabrics. Events, event
>> delivery and
>> event management are important patterns and are supported
>> by others. I
>> don't believe we'll be able to get away without supporting
>> them for very
>> long. One of the big drawbacks to snmp and cimoms are the
>> lack of event
>> support and an infrastructure to support event message
>> persistence.
>>
>> I'm also not sure where we are drawing the line in terms of
>> interoperability. There was a general consensus that occi
>> should be focusing
>> on integration points in the cloud, but I didn't see a
>> clear definition of
>> an integration point. (I was out of the loop for a while)
>> In the occi model
>> the platform can be considered a container (loosely, a vm)
>> with
>> infrastructure resources provisioned. The container life
>> cycle and resource
>> provisioning are "management" integration points, although
>> there are no
>> verbs published yet.
>> Will portions of occi interface be permitted to permeate
>> the container
>> boundary ? It is still unclear the level of interaction,
>> if any, between
>> the occi and the container contents. Maybe I missed the
>> definition.
>>
>> -gary
>>
>>
>>
>>
>>
>> Alexis Richardson wrote:
>>
>>
>> Indeed and XMPP and HTTP should not be overlooked either.
>>
>>
>> On Tue, May 19, 2009 at 7:49 PM, Sam Johnston
>> <samj at samj.net <mailto:samj at samj.net>> wrote:
>>
>>
>>
>> On Tue, May 19, 2009 at 7:13 PM, Alexis Richardson
>> <alexis.richardson at gmail.com
>> <mailto:alexis.richardson at gmail.com>> wrote:
>>
>>
>>
>> Interesting point.
>>
>> Speaking as someone who is professionally
>> involved in messaging and
>> events my STRONG advice would be to completely
>> leave them for now.
>> Implementation of the planned draft will
>> naturally bring up use cases
>> suited to the various eventing technologies
>> and protocols, none of
>> which are fully baked by the way. This will
>> be good fodder for future
>> work but currently is **** not in scope ****.
>>
>>
>>
>> Agreed, and I don't know AMQP well enough to say
>> how it could fit here.
>>
>> The use case we need to take away from it is that
>> OCCI messages aren't
>> necessarily going to be ephemeral - they may well
>> be long lived, queued,
>> serialised, saved to file, etc.
>>
>> Sam
>>
>>
>>
>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org <mailto: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
> -------------------------------------------------------------
> 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.
>
>
> ------------------------------------------------------------------------
>
More information about the occi-wg
mailing list