Open Stack

There's currently a check in nova for max length. It's hard coded to 255.
Easy low-hanging fruit would be to make that number configurable and add a
configurable regex check on the server name.

The uniqueness check could be trickier: checking the nova db wouldn't be
sufficient in many cases as most people need to check some external
system(s). Maybe we could put together something pluggable with a nova-db
check as an example. Is a wsgi filter the most appropriate place for such a
pluggable validator or should it be deeper, at the same place where the
other server name validation occurs?



On Mon, Feb 3, 2014 at 6:46 AM, Joel Cooklin <joel.cooklin at gmail.com> wrote:

> >>Shouldn't "nova list" and some shell script magic do most of this?
>
> For our use case this won't work as well since several business units
> (tenants) make direct use of the APIs.  It's hard to enforce that they
> use our wrappers and the like.  It would be much more convenient in
> our case if we could enforce business logic via a plugin for all
> requests regardless of the client being used to access the API.
>
> On Sun, Feb 2, 2014 at 11:48 PM, Aryeh Friedman
> <aryeh.friedman at gmail.com> wrote:
> > Shouldn't "nova list" and some shell script magic do most of this?  The
> only
> > problem would be to make sure that two people didn't ask for a name at
> the
> > same time
> >
> >
> > On Mon, Feb 3, 2014 at 1:19 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
> >>
> >> > -----Original Message-----
> >> > From: John Griffith [mailto:john.griffith at solidfire.com]
> >> > Sent: 03 February 2014 03:47
> >> > To: Joel Cooklin
> >> > Cc: openstack at lists.openstack.org
> >> > Subject: Re: [Openstack] nova unique name generator middleware
> >> >
> >> > On Sun, Feb 2, 2014 at 7:26 PM, Joel Cooklin <joel.cooklin at gmail.com>
> >> > wrote:
> >> > > +1 intel use cases.  It would be nice to avoid our current custom
> >> > > patches.
> >> > >
> >> > >
> >> > > On Sunday, February 2, 2014, Joshua Harlow <harlowja at yahoo-inc.com>
> >> > > wrote:
> >> > >>
> >> > >> +1 yahoo use case(s) would also benefit from not having to patch
> the
> >> > >> +code
> >> > >> to achieve similar results.
> >> > >>
> >> > >> Sent from my really tiny device...
> >> > >>
> >> > >> > On Feb 2, 2014, at 12:12 AM, "Tim Bell" <Tim.Bell at cern.ch>
> wrote:
> >> > >> >
> >> > >> > It would be interesting to have a formal exit inside OpenStack
> nova
> >> > >> > at VM creation for this sort of check rather than having to patch
> >> > >> > the code.
> >> > >> >
> >> > >> > Other scenarios that I've seen is where there is a need to
> enforce
> >> > >> > limits as the server name is used for other purposes. Examples
> are
> >> > >> > characters in the server name or maximum length.
> >> > >> >
> >> > >> > Tim
> >> > >> >
> >> ...
> >> > >
> >> > Maybe just an auto-naming option added to nova's existing boot call;
> use
> >> > a prefix and the UUID of the instance would satisfy the
> >> > cases people are talking about here and not impact existing users?
> >> >
> >>
> >> We have a set of other use cases which are around the use of the server
> >> name to get a Kerberos/X.509 identity which imposes other restrictions
> on
> >> the name being chosen (such as maximum length and limited set of
> >> characters). The unique name is one scenario but there are others.
> >>
> >> Thus, we could start adding new options such as "max server name length"
> >> and "server name character set" or we find a way to do a plugin.
> >>
> >> Tim
> >>
> >> _______________________________________________
> >> Mailing list:
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >> Post to     : openstack at lists.openstack.org
> >> Unsubscribe :
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
> >
> >
> > --
> > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140203/c9cf48ec/attachment.html>