incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomas Von Veschler <tvv...@redhat.com>
Subject Re: Length of instance names in Deltacloud
Date Thu, 02 Jun 2011 20:00:55 GMT
Thanks for the detailed explanation, really helps me understand better 
the internals. Some comments bellow:

On 06/01/2011 10:44 PM, Chris Lalancette wrote:
> On 06/01/11 - 09:37:20PM, Tomas Von Veschler wrote:
>> Hi Chris,
>>
>> One point that doesn't convince me too much is to use the condor id
>> as instance name. If for example using rhev, a sys admin will prefer
>> to have the VMs named like the user named it in Aelous, not really a
>> bunch of numbers/hash.
>
> Actually, I agree with you to a large extent.  However, I have not been able
> to convince upstream condor (where I have to get condor patches accepted) about
> this.  The reasoning is that the condor name is used as a unique
> handle to the instance.  Consider:
>
> 1)  Aeolus submits the job to condor.
> 2)  Condor generates the name (something like Condor_<hostname>_uniquejobid).
> 3)  Condor writes the name to the internal database; note that it does *not*
> have an ID yet, because we haven't submitted the job to deltacloudd yet.
> 4)  Condor submits the job to deltacloudd.
> 5)  Before it can get the status back from deltacloudd, condor crashes.
> 6)  On restart, condor can find the job again by looking up the unique name
> that it generated.  It can then start monitoring the job again.

I understand the problem now. A question, after it retrieves the job 
(=vm info?) in (6), does it switch to use VM IDs in advance or does it 
keep searching by name?

> It's not possible to do 6) if you use the user-generated name, because it is
> not necessarily unique enough.

But what about the triplet: provider_id # realm_id # vm_name ? For rhev 
that'd be unique. I mean Condor would have a way to reach the job again 
by decomposing the triplet.

To note: it's possible to change the name of a VM at the virt layer. 
That's why using vm ids sounds more robust than names to me.

Hope I'm not overcomplicating things, if we talk about managing 
hundreds+ VMs, the name of VMs at the virt layer is much less important 
than at an small rhev deployment (where btw probably won't use cloud 
anyway, or Aeolus target is also smaller virt deployments? I don't know :-)

Regards,
Tomas

Mime
View raw message