[occi-wg] [ogf-board] Fwd: Cloud Standards Integration - Request for comments

Edmonds, AndrewX andrewx.edmonds at intel.com
Fri Jun 24 09:16:52 CDT 2011


Hi Craig - thanks for the inputs, much appreciated! I'll answer inline...

/snip

The Scenario example is a simple MapReduce service consisting of
a Portal, a Hadoop Master and a Hadoop Slave -- along with two storage
volumes.  These are connected in a simple network topology.

AE: Correct

While an OVF package can represent a multi-VM configuration, this is
not emphasized in the Service Migration and Redeployment discussion.
In fact, the acronym OVA (Open Virtualization Appliance or Application)
is used but not defined.  Presumably OVA is intended to denote entire
applications that can consist of many resources.

AE: An OVA is OVF + VM image data packaged using say something like tar. I
think the reference to OVA should in fact be removed as it is the function
of CDMI to manage data i.e. VM images.

OCCI's Resource Templates do not seem intended to capture entire
"virtual application configurations" -- rather they are intended to
capture individual resource configurations.  (Is that correct?)

AE: You could possibly construct the entire configuration, however the
initial intent behind the Resource Templates are what you state - capture
individual resource configurations. In the current work within SLA at SOI we
expose 3 types of compute resource templates: small, medium and large (so
surprise there :-)). However, to model a service deployment of 1+ compute
resources we have a custom extension (Service) that ties multiple compute
resources along with their SLOs.

Step 4 of Service Migration states that the service provider
instantiates the resources and attaches the related data.  Nothing is
said about network topology support or necessary/expected bandwidth.
Compute resources can be qualified by clock speed or RAM, storage
resources can be qualified by size, but network resources have no such
qualifications.

AE: This is more related to a decision of document brevity. Yes virtual
network switches can be requested via OCCI and qualified by a number of
attributes as listed in Section 3.2 of the infrastructure specification.

What I'm getting at is the ability to migrate/instantiate large,
complex applications or even "virtual data centers" out of a physical
data center/cloud.  Aside from issues of scale, can this be done at
all?

AE: This is an excellent question. On paper it is very much possible,
however to truly prove this real experiments need to be conducted. I believe
the outcome of such an activity will result in many learning and interesting
paths of R&D.

Presumably this would be facilitated by managing things like virtual
switches.  What would it take to do this (in OVF)?  What would this
have to look like to be compatible with the VLAN management work being
done using OpenFlow and IF-MAP in the OCC Virtual Network Testbed?
(This will be hard to answer since I don't think there's anything
written up yet.)

AE: I believe there will be support for the definition of network entities
in OVF2.0. With regard to SDN frameworks and protocols (e.g. OpenFlow and
Open vSwitch), these are things that run more in the domain and under the
control of the service provider. You can compare it with hypervisor
management suites and how those are exposed to clients - they're indirectly
via further abstracted interfaces. If you look at the OCCI deployment
"architecture" (http://bit.ly/ivU60E) you'll see that such SDN frameworks
and protocols fit in the box of resource management frameworks.

What's the uptake of OCCI/OVF/CDMI in OpenStack?
AE:
 - OCCI: there is initial support provided by Thijs and I aim to contribute
further to it in the coming months.
 - OVF: there is some support for OVF in the glance image service of open
stack
 - CDMI: there is a blueprint open for exposing it out of Swift. At the DMTF
APTS meeting there were a number of people expressing interest in this,
including myself.

These standards will be of importance in a large EU project, FI-ware
(fi-ware.eu) and so I expect to see contributions from that project.

HTH,
Andy

--Craig

Minor editorial comments:

AE: These will be sorted out :-) Thanks!

1) CMWG needs a citation.
2) The first reference to OVF occurs in the second paragraph of the
Introduction but the citation [4] isn't given until two paragraphs later.
3) OVA is used by not defined.


On 6/23/11 7:50 AM, Sill, Alan wrote:
> FYI - As discussed on today's board meeting call. Please review this
document, feel free to circulate it within OGF groups, and any feedback
should be directed to Thijs and the occi-wg.
>
> Alan
>
>
>
> Begin forwarded message:
>
> From: "Thijs Metsch"<tmetsch at platform.com<mailto:tmetsch at platform.com>>
> To:
"occi-wg at ogf.org<mailto:occi-wg at ogf.org>"<occi-wg at ogf.org<mailto:occi-wg at ogf
.org>>
> Subject: [occi-wg] Cloud Standards Integration - Request for comments
>
> Dear all,
>
> The DMTF APTS meeting in Boulder, CO last month has been a great a
> success [1]. And as one of the outcomes some of the OCCI-wg members
> wrote a document which describe how today's Cloud standards (CDMI, OVF
> and OCCI) can be used together to create a open Cloud. This document is
> now finally ready (Sorry for the delay) and by this email I would ask
> for your comments and thoughts on this documents.
>
> Many thanks,
>
> -Thijs
>
> [1]<http://occi-wg.org/2011/05/25/occi-at-dmtf-apts/>
http://occi-wg.org/2011/05/25/occi-at-dmtf-apts/
>
>
>
> _______________________________________________
> ogf-board mailing list
> ogf-board at ogf.org
> http://www.ogf.org/mailman/listinfo/ogf-board
_______________________________________________
occi-wg mailing list
occi-wg at ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20110624/bf59d2ba/attachment.bin 
-------------- next part --------------
-------------------------------------------------------------
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