On Sun, Apr 19, 2009 at 12:16 PM, Ignacio Martin Llorente <span dir="ltr">&lt;<a href="mailto:llorente@dacya.ucm.es">llorente@dacya.ucm.es</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I am not sure what is the state of this discussion, but I would like to support the addition of ENTRY and EXIT points to the diagram.<br>
</blockquote><div><br>Done. Attached, along with OmniGraffle source.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Moreover, if we do not assume that the submitted VMs have to run immediately or not at all,  I would like to suggest that we need a &quot;Pending&quot; state in the diagram. The new submitted VMs remain in this state until there are resources available. That could be the &quot;DEFINED&quot; state or the DMTF &quot;INITIAL&quot; state.</blockquote>
</div><br>&quot;Pending&quot; is ambiguous. &quot;Resuming&quot; is pending, so is &quot;suspending&quot;. There&#39;s various takes on &quot;defined&quot; and &quot;initial&quot; too... for example if you were to implement something like the Q-Layer^WSun Cloud API web interface on top of OCCI then you would likely start by creating and linking a bunch of objects, none of which would be useful until associated with actual resources - it would be like a shell/skeleton.<br>
<br>Perhaps this is something worth taking into consideration, though as I&#39;d rather not impose too much on implementors it probably belongs in the registry.<br><br>Sam<br><br>