incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomas Von Veschler <>
Subject Re: Length of instance names in Deltacloud
Date Wed, 01 Jun 2011 19:37:20 GMT
On 06/01/2011 06:18 PM, Chris Lalancette wrote:
> All,
>       We are having a bit of an issue with using condor with deltacloud[1].
> Essentially the issue boils down to the fact that maximum length of an instance
> name is a detail leaking through the deltacloud abstraction.  If I'm using
> gogrid as the backend cloud, then I, as a deltacloud client, currently need
> to know that the maximum length of an instance name is 20 characters.  This
> makes it so that the client application needs to have code like:
> if (gogrid)
>      name = 20characters
> elif (rhevm)
>      name = 50characters
> etc, which breaks the abstraction layer.  Ian Main, Richard Su, and myself have
> been trying to come up with some ideas of how to fix this situation, but we
> have run into a bit of a wall.  The solutions that we have toyed around with
> are:
> 1)  Make condor just generate a Least Common Denominator name.  Currently that
> seems to be gogrid with 20 characters.
> Pros: Brain-dead simple
> Cons: Requires apriori knowledge of the least common denominator.  Also, due to
> the way that condor uses names, it is not unique enough
> 2)  Use some sort of hash/digest on the name the user provides to fit it into
> the space.  For instance, if we used MD5 on the name, we could ensure that
> name never exceeded 32 characters, regardless of how long the input name was.
> Pros: Hides the details of cloud backends inside deltacloud itself.
> Consolidates the individual cloud restrictions into the individual deltacloud
> backend drivers
> Cons: A bit of a complex implementation, since you need to hash the name during
> instance creation, and unhash it during instance lookup.  Does something
> surprising that the user might not expect; if they look at their instances
> through another tool, the names will not be what they originally input
> 3)  Do a mechanism similar to 2), but require the client to pass a flag to
> create_instance and lookup_instance to enable it.
> Pros: Same as 2, plus the default behaviour remains unchanged.  Only clients
> that really want this functionality get it
> Cons: Still has a complex implementation.  Doesn't quite fix the general case
> 4)  Export the name length restriction through some sort of deltacloud feature.
> Then the client can look at the restriction, and generate a name conforming
> to the restriction.
> Pros: Requires very little change in deltacloud itself.  Pushes the problem out
> to the client
> Cons: Pushes the problem out to the client ;).  Sort of breaks the cloud
> abstraction by having to have the client be smarter
> Does anyone have any additional arguments for or against any of these options?
> Or have another idea of how we can stop the name length from leaking through
> the abstraction?

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.

What about:
1) Condor to create the instance with the name the user introduced in 
Aeolus (up to 20 chars)
2) Condor retrieves the instance ID after instance creation and uses it 
as JobID. Could add driver and/or realm for more uniqueness?


View raw message