Afternoon all,

Currently traveling so my contributions have been limited this week (including missing the call as I was on a very busy fast train).

I personally don't see any reason to constrain implementors and reckon that a registry of attributes (e.g. cpu, mincpu, maxcpu, etc.) ought to suffice in terms of making requests. If someone wanted to use a more verbose representation (e.g. WS-I) then I would envisage catering for this need by embedding it as an opaque payload in the same way that we can carry OVF for clouds that support it.

For monitoring I envisage a very simple registry of the most common attributes (e.g. memory, cpu, etc.) as well as an equally simple facility to allocate namespaces (e.g. SNMP OIDs, Microsoft perfmon counters, etc.).

In both cases I seek a balance of simplicity and flexibility (primarily for enterprise/private cloud users), thus giving significant room for innovation (e.g. support of WS-Agreement) without sacrificing interoperability (implementations can simply ignore a lot of what they don't understand provided they understand the bare minimum of required terms).

Sam

On Fri, May 1, 2009 at 10:33 AM, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Yes I would also support the inclusion of Monitoring.
Although users can access monitoring data from within a VM these may not be accurate. It would be very useful if a provider would expose certain metrics about a VM or set of VMs that are obtained directly through the hypervisor. What this then might allow users to do it to confirm that what providers are giving them is in fact what they can see from metrics gathered from the VM. There was hints by guys in SAP (here [1]) about the formation of some working group/standard around this type of monitoring notion applied against IaaS.

Andy

[1] http://groups.google.com/group/cloudforum/browse_thread/thread/8ab6090fa0ec121c  <- see Steve Winkler's post

-----Original Message-----
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Luis Rodero-Merino
Sent: 30 April 2009 16:36
To: Ignacio Martin Llorente
Cc: occi-wg@ogf.org
Subject: Re: [occi-wg] Extraction of requirements

We would add

Identifications/References
Monitoring

The first would deal with the requirements regarding how elements are
to be identified/referenced (which elements have an id? nets, images
and VMs only? or also mems, disks...). Regarding 'Monitoring', we
think that's an important aspect that also should be included in this
specification.

Regards,
Luis

On Wed, Apr 29, 2009 at 6:33 PM, Ignacio Martin Llorente
<llorente@dacya.ucm.es> wrote:
> Hi,
>
> We are going to start with the evaluation of the submitted use cases.
> I am planing to create a table summarizing requirements for the
> different use cases with the following entries:
>
> A. Functional Requirements
> VM Description
> VM Management
> Network Management
> Image Management
>
> B. Non-functional Requirements
> Security
> Quality of Service
> Others
>
> Any suggestion?
>
> Ignacio
> --
> Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
> DSA Research Group:  web http://dsa-research.org and blog http://blog.dsa-research.org
> Globus GridWay Metascheduler: http://www.GridWay.org
> OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>



--
-----------------
Luis Rodero, PhD.
Junior Researcher @ Telefónica I+D
_______________________________________________
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.
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg