Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model
Hi, On Fri, 2009-04-17 at 13:46 +0100, Chris Webb wrote:
of VMs within a cloud for load-balancing is something that should surely be completely user-transparent. Is this intended for some other purpose?)
I think it might be useful to know the exact state at sometime. Maybe we an split is up: It only get in migration state when the users triggered the operation. It stays in running when it is a load-balacing operation.
Also, I don't follow what your 'installed' and 'starting' states are for. Surely our virtual machine is either running or not: we can't distinguish from outside whether a guest OS has fully started or not, even if we believe such a distinction is well-defined.
I tried to summarize the states in the wiki page :-) Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
Thijs Metsch <Thijs.Metsch@Sun.COM> writes:
Also, I don't follow what your 'installed' and 'starting' states are for.
I tried to summarize the states in the wiki page :-)
...but not these two... Cheers, Chris.
true :-/ may fault...Will add them. @all: feel free to change if you want to. This was just a suggestion from my side... -Thijs On Fri, 2009-04-17 at 14:02 +0100, Chris Webb wrote:
Thijs Metsch <Thijs.Metsch@Sun.COM> writes:
Also, I don't follow what your 'installed' and 'starting' states are for.
I tried to summarize the states in the wiki page :-)
...but not these two...
Cheers,
Chris. -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
Hi
I think it might be useful to know the exact state at sometime. Maybe we an split is up: It only get in migration state when the users triggered the operation. It stays in running when it is a load-balacing operation.
The user cannot request a migration, there is no reason for that. Migration can only be triggered by the local/internal scheduler of VM placement. And in such a case, as long as the user receives the contracted capacity, the migration is transparent. Ignacio
Ignacio Martin Llorente <llorente@dacya.ucm.es> writes:
The user cannot request a migration, there is no reason for that. Migration can only be triggered by the local/internal scheduler of VM placement. And in such a case, as long as the user receives the contracted capacity, the migration is transparent.
I agree. Cheers, Chris.
Quoting [Ignacio Martin Llorente] (Apr 17 2009):
Hi
I think it might be useful to know the exact state at sometime. Maybe we an split is up: It only get in migration state when the users triggered the operation. It stays in running when it is a load-balacing operation.
The user cannot request a migration, there is no reason for that. Migration can only be triggered by the local/internal scheduler of VM placement. And in such a case, as long as the user receives the contracted capacity, the migration is transparent.
True. But can we mandate that migration is always transparent? For systems where this is not the case, a 'Migrating' state (or some other state which describes degraded performance, like 'Snapshot', 'Backup', or whatever) may be useful, or even essential. Andre. -- Nothing is ever easy.
True. But can we mandate that migration is always transparent?
I think so, we are defining an API for cloud infrastructures and not an API for VM Managers (local tools for orchestration or "private clouds")
For systems where this is not the case, a 'Migrating' state (or some other state which describes degraded performance, like 'Snapshot', 'Backup', or whatever) may be useful, or even essential.
Not a state, but the provider could provide such information? Ignacio
Andre.
-- Nothing is ever easy.
participants (4)
-
Andre Merzky -
Chris Webb -
Ignacio Martin Llorente -
Thijs Metsch