deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lalancette <clala...@redhat.com>
Subject Length of instance names in Deltacloud
Date Wed, 01 Jun 2011 16:18:17 GMT
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?

-- 
Chris Lalancette

[1] Aeolus uses deltacloud and condor to abstract away cloud differences, for
those who don't know.

Mime
View raw message