You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by Ian Main <im...@redhat.com> on 2010/12/07 05:10:19 UTC
'Name' usage in deltacloud drivers
Hi Guys..
So with our work on deltacloud aggregator, we've been trying to figure
out what to use for the instance name. I haven't actually looked at
the providers but I presume some of them require unique instance names.
In the web UI, the instance name can be entered before we know which
provider this instance is going to be started on. Therefore, the
various restrictions listed below are a real cause for concern.
The latest thinking is to generate a UUID and the append the instance
name given by the user, and then chop it to the maximum length of the
'name' field for the selected provider. Another idea is to use a pure
UUID for the name and store the user given name as some form of
metadata, tags, key/value pairs etc in the provider.
Either way we are going to require changes to the API. Probably the
easiest is to just support a notion of the maximum instance name
length for a given provider.
Here is my notes on what I managed to round up looking at the various
providers API docs:
EC2:
- key/value pair tags. Tags is probably the way to go here, tags are
more easily accessible in the AWS WUI.
- user data
- 'name' does not seem to ever show up in AWS console (bug?)
Gogrid:
- 20 character limit on 'name'
- there is an optional 'description' field to the server.add method that
could possibly be used to house the name. This is currently not set
in the gogrid driver.
Rackspace:
- rackspace uses 'metadata' in their server/instance create api call
which uses the key/value pair setup.
- No mention on 'name' restrictions.
RHEVM:
- Doesn't seem to have anything other than 'name'.
- Name has 64 char limit, no special characters. Although apparently '-'
and '_' work.
Rimuhosting:
- instance 'name' appears to require that it be a fqdn 'domain_name'.
The driver code has:
# really bad, but at least its a fqdn
Time.now.to_s + '.com'
in the case where the 'name' is not set by the user. It looks like it
requires a fqdn in the docs:
domain_name | xsd:string | The label you want to give the server. It
will need to be a fully qualified domain name.
- I see no provisions for any kind of key/value or user data etc.
Terramark:
- 'name' can be alphanumeric and '-', must begin with a letter, 15 char
limit.
- I don't see any kind of user data, key/value etc. Only thing might be
the 'group' designation which I'm not sure how that's really used.
Ian
Re: 'Name' usage in deltacloud drivers
Posted by Mohammed Morsi <mm...@redhat.com>.
On 12/14/2010 01:32 PM, David Lutterkort wrote:
> On Mon, 2010-12-06 at 20:10 -0800, Ian Main wrote:
>> Either way we are going to require changes to the API. Probably the
>> easiest is to just support a notion of the maximum instance name
>> length for a given provider.
> How would the following work for you:
>
> <link rel="instances" href="...">
> <feature name="user-name">
> <constraint name="length" value="20"/>
> <constraint name="pattern" value="[crazy regexp in some yet-to-be-specified syntax]"/>
> </feature>
> </link>
>
> In other words, we tell the client (a) that the cloud supports
> user-supplied names for instances (b) what the maximum length is and (c)
> the regexp pattern that the name must match (or would it more be more
> helpful to indicate that through words like 'hostname' or 'alphanum' ?)
Do any cloud providers support different encodings for names? eg If a
user wants to name their instances in a non-english language, would they
be able to do that? And would using 'alphanum' support this? Perhaps we
can have additional labels if so (utf-8, multibyte-encoding, etc)
One benefit of having a regex is we could be alot more fine grained in
terms of propagating the full support of cloud provider naming schemes
to the deltacloud end-user. We could still theoretically scan the
regex's themselves to determine if they consist of only alphanumeric
characters for error messages and such.
> Adding this requires a few gyrations in the API internals to add
> constraints to features.
>
>> Here is my notes on what I managed to round up looking at the various
>> providers API docs:
> Thanks for the research - what a mess.
>
Suppose that's a good thing for deltacloud, the messier the differences
between the cloud providers APIs and methodologies the more demand for a
single abstract cloud framework ;-)
-Mo
Re: 'Name' usage in deltacloud drivers
Posted by Ian Main <im...@redhat.com>.
On Wed, 2010-12-15 at 13:18 -0500, Mohammed Morsi wrote:
> On 12/14/2010 02:01 PM, Ian Main wrote:
> > On Tue, 2010-12-14 at 10:32 -0800, David Lutterkort wrote:
> >> On Mon, 2010-12-06 at 20:10 -0800, Ian Main wrote:
> >>> Either way we are going to require changes to the API. Probably the
> >>> easiest is to just support a notion of the maximum instance name
> >>> length for a given provider.
> >> How would the following work for you:
> >>
> >> <link rel="instances" href="...">
> >> <feature name="user-name">
> >> <constraint name="length" value="20"/>
> >> <constraint name="pattern" value="[crazy regexp in some yet-to-be-specified syntax]"/>
> >> </feature>
> >> </link>
> >>
> >> In other words, we tell the client (a) that the cloud supports
> >> user-supplied names for instances (b) what the maximum length is and (c)
> >> the regexp pattern that the name must match (or would it more be more
> >> helpful to indicate that through words like 'hostname' or 'alphanum' ?)
> > Yeah I'd be inclined to think 'hostname' or 'alphanum' would be better.
> > The client here is written in C++ so to apply the regexp I'd have to
> > drag in another library into condor and do the match to ensure
> > conformity. Even then I'm not sure how you'd use that information
> > (match/no match) to modify the name to conform. It would probably be
> > better just to say "if alphanum then sanitize_alphanum()".
>
> Would it be smart to automaticallly sanetize the names without
> consulting the user first? What if they go to start several instances
> all with the same name except for one character which is invalid and
> automatically removed?
I am going to prepend a UUID to the name and chop it to the max length.
Some clouds then will only have part of a UUID for a name but it will
still very likely be unique.
The only downside is it will be harder for the user to map between the
instances in the WUI and the instances in the native interface, but it
is a reasonable trade off imo.
Ian
> -Mo
Re: 'Name' usage in deltacloud drivers
Posted by Mohammed Morsi <mm...@redhat.com>.
On 12/14/2010 02:01 PM, Ian Main wrote:
> On Tue, 2010-12-14 at 10:32 -0800, David Lutterkort wrote:
>> On Mon, 2010-12-06 at 20:10 -0800, Ian Main wrote:
>>> Either way we are going to require changes to the API. Probably the
>>> easiest is to just support a notion of the maximum instance name
>>> length for a given provider.
>> How would the following work for you:
>>
>> <link rel="instances" href="...">
>> <feature name="user-name">
>> <constraint name="length" value="20"/>
>> <constraint name="pattern" value="[crazy regexp in some yet-to-be-specified syntax]"/>
>> </feature>
>> </link>
>>
>> In other words, we tell the client (a) that the cloud supports
>> user-supplied names for instances (b) what the maximum length is and (c)
>> the regexp pattern that the name must match (or would it more be more
>> helpful to indicate that through words like 'hostname' or 'alphanum' ?)
> Yeah I'd be inclined to think 'hostname' or 'alphanum' would be better.
> The client here is written in C++ so to apply the regexp I'd have to
> drag in another library into condor and do the match to ensure
> conformity. Even then I'm not sure how you'd use that information
> (match/no match) to modify the name to conform. It would probably be
> better just to say "if alphanum then sanitize_alphanum()".
Would it be smart to automaticallly sanetize the names without
consulting the user first? What if they go to start several instances
all with the same name except for one character which is invalid and
automatically removed?
-Mo
Re: 'Name' usage in deltacloud drivers
Posted by Ian Main <im...@redhat.com>.
On Tue, 2010-12-14 at 16:19 -0800, David Lutterkort wrote:
> On Tue, 2010-12-14 at 11:01 -0800, Ian Main wrote:
> > Perhaps the regex would be useful for user interface conformity in other
> > apps? For us the instance has to work on any back end so I can't see
> > enforcing it in the UI. I see no reason you couldn't add both.
>
> The main reason I suggested some sort of keyword for the pattern that
> the name most match is UI - an error message 'the name is invalid, it
> must match the regular expression /.../' is pretty unfriendly. A better
> error message is 'The name must be a valid domain name, i.e. consist
> only of alphanumeric characters, dashes, dots, ...'
>
> David
Well let's just go with the keyword then. I think you are right about
the error messages too.. hadn't thought of that.
Ian
Re: 'Name' usage in deltacloud drivers
Posted by David Lutterkort <lu...@redhat.com>.
On Tue, 2010-12-14 at 11:01 -0800, Ian Main wrote:
> Perhaps the regex would be useful for user interface conformity in other
> apps? For us the instance has to work on any back end so I can't see
> enforcing it in the UI. I see no reason you couldn't add both.
The main reason I suggested some sort of keyword for the pattern that
the name most match is UI - an error message 'the name is invalid, it
must match the regular expression /.../' is pretty unfriendly. A better
error message is 'The name must be a valid domain name, i.e. consist
only of alphanumeric characters, dashes, dots, ...'
David
Re: 'Name' usage in deltacloud drivers
Posted by Ian Main <im...@redhat.com>.
On Tue, 2010-12-14 at 10:32 -0800, David Lutterkort wrote:
> On Mon, 2010-12-06 at 20:10 -0800, Ian Main wrote:
> > Either way we are going to require changes to the API. Probably the
> > easiest is to just support a notion of the maximum instance name
> > length for a given provider.
>
> How would the following work for you:
>
> <link rel="instances" href="...">
> <feature name="user-name">
> <constraint name="length" value="20"/>
> <constraint name="pattern" value="[crazy regexp in some yet-to-be-specified syntax]"/>
> </feature>
> </link>
>
> In other words, we tell the client (a) that the cloud supports
> user-supplied names for instances (b) what the maximum length is and (c)
> the regexp pattern that the name must match (or would it more be more
> helpful to indicate that through words like 'hostname' or 'alphanum' ?)
Yeah I'd be inclined to think 'hostname' or 'alphanum' would be better.
The client here is written in C++ so to apply the regexp I'd have to
drag in another library into condor and do the match to ensure
conformity. Even then I'm not sure how you'd use that information
(match/no match) to modify the name to conform. It would probably be
better just to say "if alphanum then sanitize_alphanum()".
Perhaps the regex would be useful for user interface conformity in other
apps? For us the instance has to work on any back end so I can't see
enforcing it in the UI. I see no reason you couldn't add both.
Otherwise I think that would work fine... well, just to be clear this
would be queryable without having an instance created, correct? I'm
sorry I don't know the details of how that XML ends up being used.
> Adding this requires a few gyrations in the API internals to add
> constraints to features.
Thanks for the reply! :)
Ian
Re: 'Name' usage in deltacloud drivers
Posted by David Lutterkort <lu...@redhat.com>.
On Mon, 2010-12-06 at 20:10 -0800, Ian Main wrote:
> Either way we are going to require changes to the API. Probably the
> easiest is to just support a notion of the maximum instance name
> length for a given provider.
How would the following work for you:
<link rel="instances" href="...">
<feature name="user-name">
<constraint name="length" value="20"/>
<constraint name="pattern" value="[crazy regexp in some yet-to-be-specified syntax]"/>
</feature>
</link>
In other words, we tell the client (a) that the cloud supports
user-supplied names for instances (b) what the maximum length is and (c)
the regexp pattern that the name must match (or would it more be more
helpful to indicate that through words like 'hostname' or 'alphanum' ?)
Adding this requires a few gyrations in the API internals to add
constraints to features.
> Here is my notes on what I managed to round up looking at the various
> providers API docs:
Thanks for the research - what a mess.
David
Re: 'Name' usage in deltacloud drivers
Posted by Toby Crawley <tc...@redhat.com>.
On 12/06/2010 11:10 PM, Ian Main wrote:
>
> EC2:
>
> - key/value pair tags. Tags is probably the way to go here, tags are
> more easily accessible in the AWS WUI.
> - user data
> - 'name' does not seem to ever show up in AWS console (bug?)
>
I don't have any experience with the other drivers, but with ec2:
* the 'Name' key/value tag is exposed by default in the AWS web console, and is really the only useful option of the three
* tags cannot be set at instance creation time, but have to be applied after the instance has entered provisioning (pending) in ec2, making
it difficult to set the name at creation time. Michal implemented this in the ec2 driver with an create_tag call just after creating the
instance, and depending on the timing on the AWS side, sometimes the instance actually exists (and create_tag succeeds), and sometimes it
doesn't (and create_tag fails).
Toby