[occi-wg] Events ?
Gary Mazz
garymazzaferro at gmail.com
Fri May 22 16:52:55 CDT 2009
+1
-g
Sam Johnston wrote:
> Actually I'm with Gary on this one... what he said (and what I've said
> before) is "/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./". For me cloud->domain->cluster makes sense... for a
> hosting provider/enterprise something like datacenter->cage->rack
> makes more sense but this falls well into the realm of user
> preferences... no amount of defining each of the terms will give users
> the flexibility they need/want and many of them will have existing
> schemes that they will want to keep.
>
> Note that the proposed category scheme caters well for this in that
> you can have multiple vocabularies (schemes). The first and most
> obvious one is resource types (what Google call "kinds") including
> compute, storage and network. Others that we might want to define
> include things like operating systems (which could also be an enum
> attribute) and of course customers would be free to define their own.
> A category looks like this:
>
> <category scheme="http://purl.org/occi/cat#os" term="win2k3"
> label="Windows 2003 Server" />
>
>
> I had also catered for a user tag space ala:
>
> <category scheme="http://example.com/~/ <http://example.com/%7E/>"
> term="myboxen" />
>
>
> I need to read up on/think about hierarchical category schemes but am
> also tempted by a rel="parent" linking system.
>
> Sam
>
> 2009/5/20 Edmonds, AndrewX <andrewx.edmonds at intel.com
> <mailto:andrewx.edmonds at intel.com>>
>
> That a good point, Gary (can also see how Cluster could be
> interpreted differently). Might be useful if we list grouping
> entities on the registry wiki page.
>
> Andy
>
> -----Original Message-----
> From: Gary Mazz [mailto:garymazzaferro at gmail.com
> <mailto:garymazzaferro at gmail.com>]
> Sent: 20 May 2009 10:06
> To: Edmonds, AndrewX
> Cc: Sam Johnston; occi-wg at ogf.org <mailto:occi-wg at ogf.org>; Roger
> Menday; Andre Merzky
> Subject: Re: [occi-wg] Events ?
>
> 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>
> [mailto: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 <mailto: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>
> >> <mailto: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> <mailto: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>
> <mailto: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>
> >> <mailto: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>
> <mailto: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 <mailto: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.
> >
> >
> >
> ------------------------------------------------------------------------
> >
>
> -------------------------------------------------------------
> 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