Paul,<div><br></div><div>Oh my... stackable resources eh? This actually makes a lot of sense when you look at my proposed roadmap (attached) in which case we could end up modelling an application running on a platform running on infrastructure. The meta-model supports this by way of links (e.g. &quot;up&quot;, &quot;down&quot;) but the concept of one person&#39;s workload being another&#39;s container wasn&#39;t something we&#39;d considered.</div>
<div><br></div><div>It may be safer then just to talk in terms of the resource names (currently compute, network, storage, but potentially also things like queues, databases, etc. in future).</div><div><ul><li><b>Template</b> applies to all types (e.g. &quot;compute template&quot;)</li>
<li><b>Reservation</b> could be used for allocated-but-unused resources (e.g. &quot;storage reservation&quot;)</li><li><b>Container</b> and <b>Workload</b> can still be used but depend on perspective (better than &quot;job&quot; anyway which implies batch).</li>
</ul><div>Getting a reference model into the document may be a good idea (actually Gary suggested it on the call today) but I fear that we&#39;ll find it restrictive so it would have to be &quot;suggested&quot; requirement level rather than &quot;recommended&quot; or &quot;required&quot; - as is the case for the state machine.</div>
<div><br></div></div><div>Sam<br><div><br><div class="gmail_quote">On Thu, Oct 29, 2009 at 1:19 AM, Strong, Paul <span dir="ltr">&lt;<a href=""></a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Sam,</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">This area is always fun.  IMHO the name should be less 
important than the definition of the thing that we name :o)  But that 
doesn&#39;t stop the debate.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">One potential problem I see with workload is that it is 
commonly used in reference to an application or service or to types of such 
things, as in transactional workloads, compute intensive workloads and so 
forth.   Is this a problem?  Probably not as long as define it 
properly and the context(s) within which to use it.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">However, as you say, in the grand scheme of things one 
person&#39;s workload can be another&#39;s container.  How do you intend to capture 
this, i.e. that a physical server hosts a hypervisor (a kind of operating 
system) that hosts a number of virtual servers that each host an operating 
system (which could itself be a hypervisor) which may host one or more JVMs, 
which host etc. etc.  The challenge we have is to create a model and set of 
terms which is simple and clear within the context of the current problem we are 
solving, which is extensible (enough) as the use case set grows and which 
is reasonably consistent with other models/definitions.  <span><font face="Arial" color="#0000ff" size="2">Attached is 
a diagram we found useful in the OGF reference model working group.  
It attempts to capture the various conceptual layers.  You can see this is 
old because N1 Grid Containers(c2003) = Solaris Containers (Zones plus Solaris 
cpu, mem and network IO controls).  
:o) </font></span></font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Anyway, in the OGF reference model we have chosen not to 
explicitly separate containers and workloads, or services and resources, but 
rather we have the notion of (managed) components that can have structural 
relationships (hosts, is composed of) and interaction relationships (network 
traffic flow, transaction flow) with other components.  These components 
are specialized into Servers (physical or logical), operating systems (which 
include hypervisors and traditional OSes) and so forth.  Avoiding 
giving the components names that imply relationships with other components 
has provided some conceptual flexibility :o)  One of our 
(eBay) internal tools uses this model as its basis and renders it as 
RDF, allowing us to model, capture and query various patterns and 
relationships within our infrastructure.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Actually this would be a good point to engage with the OGF 
Ref Model group.  They (inc me) would be very interested in using OCCI to 
help drive the ref model forward, to improve/correct it (ref 
model) and so forth.  Our goal is something that is not necessarily 
exhaustive, but rather something that is definitely useful :o)  We 
want to capture the lifecycle of the components (container, workload, whatever) 
as well as their structure/relationships.  </font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span><span></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Anyway</font> <font face="Arial" color="#0000ff" size="2">you get the idea I am sure.  It would perhaps be useful to hold a 
joint discussion or two with the ref model folks (mainly Dave Snelling &amp; I) 
to see whether we can help each other at all.</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Cheers</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Paul</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div><br>
<div lang="en-us" dir="ltr" align="left">
<font face="Tahoma" size="2"><b>From:</b> <a href="" target="_blank"></a> 
[mailto:<a href="" target="_blank"></a>] <b>On Behalf Of </b>Sam 
Johnston<br><b>Sent:</b> Wednesday, October 28, 2009 4:07 PM<br><b>To:</b> 
<a href="" target="_blank"></a><br><b>Subject:</b> [occi-wg] Terminology: containers, 
workloads,templates and instances<br></font><br></div><div><div></div><div class="h5">
<div></div>Evening all,
<div>I&#39;ve attached some notes Andy took from a call at the weekend as well as a 
diagram I whipped up today which I hope will help us to use common terminology 
and avoid the ambiguous term &quot;virtual machine&quot; (which can refer both to the host 
and the guest, or both together - as distinct from what we mean when we say 
&quot;java virtual machine&quot;). The proposed terminology is also generic and thus 
compatible with any work we do in the future at the platform and/or application 
layers (as deployed applications look just like virtual machines in that they 
can be started, stopped, etc.).</div>
  <li><b>Container</b> refers to the host of an individual workload (e.g. an 
  empty virtual machine [host], runtime, interpreter, etc.)
  </li><li><b>Workload</b> refers to a generic load that the user wishes to execute 
  in the cloud (e.g. virtual machine files [guest], RoR app, JAR/WAR, etc.) 
    <li><b>Template</b> refers to a COPYable workload that cannot be run (e.g. a 
    public AMI)
    </li><li><b>Instance</b> refers to a workload that is currently allocated and 
    consuming resources (e.g. a running or suspended virtual machine) 
<div>Some of you may recall similar terminology back when we were writing the 
charter but our model ended up going in a different direction. The reason it&#39;s 
come back up now is that we&#39;re getting down to the details (like running 
instances vs the [possibly immutable] template from which they were started) and 
not using common language causes confusion from time to time.</div>
<div>In terms of how we model these things for cloud infrastructure:</div>
  <li><b>Containers</b> are like reservations (though the resources may or may 
  not be actually reserved). If you create a blank server in VMware vCloud 
  express for example there&#39;s an entity that you will be billed for regardless 
  of whether you start it or even point it at an image. Similarly you can pay 
  Amazon for a &quot;reserved instance&quot; and then get cheaper hourly rates for it. 
  Think of it like a virtual dedicated server. These can be modeled via &quot;empty&quot; 
  compute resources - that is, ones which have metadata such as allocated cores 
  and memory, but no entity-body (e.g. OVF payload). 
  </li><li><b>Workloads</b> are whatever the user wants to run in your cloud. This 
  could be anything from a script to a complex, multi-VM OVF file (&quot;vApp&quot; in 
  VMware parlance). These are generally referred to as templates or instances: 
    <li><b>Templates</b> are resources that cannot be directly started (e.g. 
    don&#39;t advertise start, stop, restart, etc. actions), rather needing a COPY 
    to a new location as an &quot;instance&quot; first. Rather than having to reverse 
    engineer the available actions these are identified by a predetermined 
    &quot;template&quot; category. 
    </li><li><b>Instances</b> are resources that are allocated (e.g. can be started, 
    stopped, restarted, etc.). These are the default and can be identified by 
    the presence of an entity-body (e.g. OVF payload) and absence of the 
    &quot;template&quot; category. </li></ul></li></ul></div>
<div>We discussed this on the call today and it wasn&#39;t contentious but if you 
have feedback then fire away,</div>