[Openstack] nova unique name generator middleware
Joel Cooklin
joel.cooklin at gmail.com
Mon Feb 3 02:26:46 UTC 2014
+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 :
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140202/bafca7e4/attachment.html>
More information about the Openstack
mailing list