On 06/02/2011 07:46 AM, Chris Lalancette wrote:
On 06/02/11 - 10:27:18AM, David Lutterkort wrote:
On Wed, 2011-06-01 at 12:18 -0400, Chris Lalancette wrote:
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
From the API side, I see this as the only practical option - anything
else would add some sort of application logic to the API. It would also
require some name remapping scheme: Deltacloud says the instance is
called 'frobnez' when the cloud provider calls it 'i-123476'. That means
there's yet another piece of data that admins need to hang on to, with
devastating consequences if they don't.
In practical terms, we already have a feature 'user_name' for instances
that indicates that the clouds supports user-supplied names. We could
just enhance the XML to include the maximum size, e.g.
<api driver="..." version="...">
<link href="http://localhost:3001/api/instances";
rel="instances">
<feature name="user_name">
<param name="name">
<constraint name="max_length"
value="20"/>
<constraint name="pattern"
value="[a-zA-Z0-9]+"/>
</param>
</feature>
</link>
</api>
(The pattern stuff as an example of something we don't need right now,
but might want to add at some point)
Right. OK, so the consensus here seems to be that the feature thing is the
way to go. I'll start working on that.
Thanks,
Chris,
I found another wrinkle in the instance name requirements. The
powershell api doesn't like pound signs and validates the instance name
using this regular expression: ^[a-zA-Z\d.\-_]*$
I posted a screenshot of the error I ran into here:
https://www.aeolusproject.org/redmine/issues/1705
