[occi-wg] Is OCCI the HTTP of Cloud Computing?

Tino Vazquez tinova79 at gmail.com
Mon May 11 11:03:47 CDT 2009


Hi Randy,

First of all, excuse me for the delayed answer. This thread somehow
ended up in my Trash folder, not really sure why (?).

Comments interspersed,


On Sun, May 10, 2009 at 12:10 AM, Randy Bias <randyb at gogrid.com> wrote:
> First off, we've got to be careful about saying 'copy the image'.  You
> probably mean 'copy the instance'.  Where an image is an on-disk
> representation of an unpowered VM and an instance is a running version of
> that same on-disk representation or a running copy.
>
> So for 'cloning' do you mean:
>
>    - An image in a library is turned into an instance?
>    - A running instance is copied?
>    - If a running instance is copied do you have a new image or a new
> instance?
>    - If you have a new instance, is it powered on automatically?
>    - Does a new cloned instance have the exact same hardware profile
>      as the original cloned instance?  RAM, CPU, disk?
>    - Does a cloned instance also duplicate the RAM?


I really mean copy the image, as it is a suggestion for an attribute
of the "Drive" object. AFAIK, the clone attribute has been already
suggested for the "Server" object (BTW, wouldn't it be better to call
it VirtualMachine instead of Server?). So, as I see it

   Drive object -> clone attribute. Set to yes: "Copy the on-disk
representation of one drive of a VM"
                                                    Set to no: "Use
the original on-disk representation of one drive of a VM"

As I see it , one VM can have more than one drive, it is not its
complete representation (I mean, it can be, but it doesn't have to). I
suggested it because I can see the benefits of declaring the base
system drive of a VM as cloneable (so it can be used by different VMs)
but each VM having their data partition set as not clonable and each
VM use their own one (not sure if we should introduce the concept of
"shareable", it is quite  a dangerous field). And other combination
also.

The cloning attribute for "Servers" has to be correctly defined, and I
suggest using your questions as a starting point to unequivocally  do
so. It just got me thinking, VMWare uses the concept of Template aside
from the VirtualMachine, with the purpose of making clones. How do you
feel about this?

>
> In other words, am I making a PURE 100% duplicated running instance (there
> are use cases for this), a new reference image, or am I 'scaling' an
> instance (either horizontally with more copies or vertically with a bigger
> copy)?

In this case, I guess I was talking about a new reference image.

>
> I've seen clone used by customers, clouds, and various IT departments and
> I've almost never seen the same definition.  It's about as bad as 'cloud'
> when it comes to being defined.

I understand you concern. I think that the purpose of this working
group is to precisely define these concepts, as good as we can do i. I
really think that the "clone" attribute for drives is a good
complement for the "persistent" one.

>
> When our customers ask for cloning they also usually mean very different
> things.

Precisely, we have to give them meaning as what we find more reasonable.

>
> I'd rather have a few different verbs here that specified different behavior
> and that's potentially a rat's nest because not every cloud supports all of
> these behaviors.

That is true, I suggest using it as a extension. We will therefore
avoid further ill-defined "clone"  attributes for different clouds.
That is, IMHO, what standards are for.

>
>
> --Randy

Thanks, I think this is a rather productive discussion.

- Tino

>
>
> On 5/7/09 12:44 AM, "Tino Vazquez" <tinova at fdi.ucm.es> wrote:
>
>> Hi Randy,
>>
>> By "clone" I mean "copy the image" if set to yes or "use the original"
>> if set to no. What other meaning do you have in mind?
>>
>> Also, for me "stop" means stop the VM and dump the state onto a file.
>> "suspend" would be stop it but keep the state in memory.
>>
>> BTW, there is something in state machine diagram [1]  that I still
>> don't understand. The entry point (after start) I take it as the
>> "defined" or "pending" state. If that is correct, then we have our VMs
>> going always from the initial state to "suspended". Is that what we
>> want?
>>
>> Regards,
>>
>> -Tino
>>
>> [1]
>>
> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateMode>
> l
>>
>> --
>> Constantino Vázquez, Grid Technology Engineer/Researcher:
>> http://www.dsa-research.org/tinova
>> DSA Research Group: http://dsa-research.org
>> Globus GridWay Metascheduler: http://www.GridWay.org
>> OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
>>
>>
>>
>> On Thu, May 7, 2009 at 1:29 AM, Randy Bias <randyb at gogrid.com> wrote:
>>> dange
>
>
> --
> Randy Bias, VP Technology Strategy, GoGrid
> randyb at gogrid.com, (415) 939-8507 [mobile]
> BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
>
>



More information about the occi-wg mailing list