[Openstack] nova unique name generator middleware

John Griffith john.griffith at solidfire.com
Mon Feb 3 02:47:05 UTC 2014


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
>> >
>> >> -----Original Message-----
>> >> From: gustavo panizzo <gfa> [mailto:gfa at zumbi.com.ar]
>> >> Sent: 02 February 2014 05:27
>> >> To: Craig J; openstack at lists.openstack.org
>> >> Subject: Re: [Openstack] nova unique name generator middleware
>> >>
>> >> On 02/01/2014 04:19 PM, Craig J wrote:
>> >>
>> >>
>> >>> I think the best way to accomplish this is to write a custom piece of
>> >>> paste middleware and plug it into the nova api. I'm planning on
>> >>> basically overriding the name provide by the user with a name that we
>> >>> can guarantee to be unique.
>> >>
>> >> do you plan to rename the vm in case the name already exists or just
>> >> abort the creation? i would choose the second
>> >>
>> >>>
>> >>> So, two questions:
>> >>> 1. Does anyone have a similar piece of middleware they'd care to
>> >>> share?
>> >> i don't i would love to have it, i would share if i have it
>> >>
>> >>> 2. Are there any reasons this approach won't work? Any better
>> >>> approaches?
>> >> it think it should be done at tenant level, my use case is i want to
>> >> restrict vm names depending on the tenant them are in
>> >>
>> >> example:
>> >>
>> >> tenant foo, vm names allowes
>> >>
>> >> foo-mysql-n
>> >> foo-apache-n
>> >>
>> >> tenant bar
>> >>
>> >> foo-mongodb-n
>> >> foo-nginx
>> >>
>> >> this help a lot with orchestration, we are doing it manually now but i
>> >> would like to enforce it
>> >>
>> >>>
>> >>>
>> >>> Thanks in advance,
>> >>> Craig
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>
>> >>
>> >> --
>> >> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> > _______________________________________________
>> > 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
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>
>
> _______________________________________________
> 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
>
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?




More information about the Openstack mailing list