<div dir="ltr">Thanks Tim, we actually have the max length constraint as well (imposed because of Active Directory integration). We've gone back and forth about adding validation or generating names. We've chosen name generation for the time being because we felt that that would be better for the user than rejecting the create vm requests for all these various constraints <i>(webapp01 is already taken?? darn! How about craigjellick-webapp01? too long? shucks!)</i>. <div>
<br></div><div>Once we have deeper dns integration (ie your your vm name automatically becomes a valid FQDN dns entry), we may need to revisit our decision because users may really want more meaningful DNS entries than what our generated names can give them.<div>
<br></div><div>Belmiro, that additional hook in the network driver makes a lot of sense. We're using Neutron, so we'll have to investigate how it can be hooked in there and whether VM creation can fail gracefully if a conflict is discovered at that point in time.</div>
</div><div><br></div><div>Thanks for the info.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 3:12 AM, Belmiro Moreira <span dir="ltr"><<a href="mailto:moreira.belmiro.email.lists@gmail.com" target="_blank">moreira.belmiro.email.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Craig,<br>
in reality is what we are doing...<br>
to fail early we have some checks at API level. In the case of VM hostname uniqueness we check first if it exists already on DNS (the network is shared between between all the lab).<br>
Then we have some hooks in the nova network driver to interact with our network DB and register the new VM confirming the hostname uniqueness.<br>
<span class="HOEnZb"><font color="#888888"><br>
Belmiro<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Feb 2, 2014, at 1:29 , Craig J <<a href="mailto:craig.jellick@gmail.com">craig.jellick@gmail.com</a>> wrote:<br>
<br>
> Thanks Belmiro. I think long term we may end up doing something similar. Though our network infrastructure is fairly complex, so it would be more like a call to a network API (maybe just a DNS check?) rather than querying a DB directly.<br>

><br>
> Aryeh, to your point, OpenStack effectively _is_, the provisioning system. Our current use case is providing engineers with a self service portal for spinning up VMs on which they can do development work. So, the workflow is user -> UI -> nova API. But when a VM is spun up, we still want to integrate with existing systems such as Active Directory (via PBIS/Likewise). Long term, we have grander plans for making OpenStack the provisioning system for our integration and production environments and we'll probably need to build more ellaborate smarts into it.<br>

><br>
> At any rate, we aren't integrated fuly with DNS and some other systems yet and in taking an iterative approach, we are thinking that if we can have a quick and dirty way to guarantee name uniqueness with a relatively simple piece of code, we can address deeper integration later.<br>

><br>
><br>
><br>
> On Sat, Feb 1, 2014 at 3:31 PM, Aryeh Friedman <<a href="mailto:aryeh.friedman@gmail.com">aryeh.friedman@gmail.com</a>> wrote:<br>
><br>
><br>
> ---------- Forwarded message ----------<br>
> From: Aryeh Friedman <<a href="mailto:aryeh.friedman@gmail.com">aryeh.friedman@gmail.com</a>><br>
> Date: Sat, Feb 1, 2014 at 5:09 PM<br>
> Subject: Re: [Openstack] nova unique name generator middleware<br>
> To: Belmiro Moreira <<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.lists@gmail.com</a>><br>
><br>
><br>
> Since I am relatively new to the guts of OpenStack this might be an off base suggestion but why is this even OpenStack's problem vs. something that can be queried by whatever provisioning solution you choose?  Namely check the name at the provisioning front end and not  as a OpenStack layer per se?<br>

><br>
><br>
> On Sat, Feb 1, 2014 at 4:44 PM, Belmiro Moreira <<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.lists@gmail.com</a>> wrote:<br>
> Hi,<br>
> in our case we have a network DB were all VMs are registered.<br>
> We just check if the name provided by the user don’t conflict.<br>
><br>
> Belmiro<br>
><br>
> On Feb 1, 2014, at 20:19 , Craig J <<a href="mailto:craig.jellick@gmail.com">craig.jellick@gmail.com</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > In our OpenStack environment, we have the need to enforce unique names for each VM. Long story short, the names need to be unique because of some other systems that we are integrating with.<br>
> ><br>
> > 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.<br>

> ><br>
> > So, two questions:<br>
> > 1. Does anyone have a similar piece of middleware they'd care to share?<br>
> > 2. Are there any reasons this approach won't work? Any better approaches?<br>
> ><br>
> ><br>
> > Thanks in advance,<br>
> > Craig<br>
> > _______________________________________________<br>
> > Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> > Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> > Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
><br>
> --<br>
> Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br>
><br>
><br>
><br>
> --<br>
> Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br>
</div></div></blockquote></div><br></div>