Hi Thomas,<br><br>Some users requested to let new resources use repeated names, see for instance this thread [1]. This makes sense in deployments with a large number of users, or in a multi-tenant scenario, where you don't want users having to try a resource creation several times until they find a free name.<br>
<br>We implemented this allowing repeated names, but only if they are not owned by the same user. It was done this way so users can reference resources by name in CLI commands, e.g. 'oneimage show my_img'.<br><br>
Since we released OpenNebula 3.0, some of you have complained about this change, so let me try to explain why we decided to drop the NAME reference from VM templates:<br><br><br>Lets say you want to use the VNet named "blue". In the worst case scenario, you will have one "blue" network owned by you, several "blue" networks owned by other people in your group, and several other "blue" networks owned by people from other groups. You may, or may not, have rights to use the latter "blue" networks outside your group.<br>
<br>How does OpenNebula decide which "blue" network do you want to use? At first sight, you could try to arrange them by priority: your VNet has comes first, then VNets from your group, and then VNets from other groups. This presents a lot of problems:<br>
<br> You can have at most one "blue" network, but what happens if you are instantiating a public template created by other user in your group?<br>Maybe the template was prepared by "boss_user", who owns a "blue" VNet with addresses in the 192.169.10.0 network. But you own another "blue" VNet with base address 192.168.30.0. The user will expect his VNets to have greater priority, but then the VM will be created in a different VNet than the one intended by "boss_user".<br>
<br>If you don't own any "blue" network, you may create a template that uses a public one owned by other user in your group. If it is the only "blue" network in the group, then you template will work fine, until somebody else decides to publish another "blue" network in the same group. From that moment, OpenNebula would have to guess, or just refuse to instantiate that template that was working fine before.<br>
<br><br>In the end, we could implement a priority and do our best to document it, but we though that would cause a lot of confusion. The easiest solution was to force the usage of IDs, what didn't look to us like a really limiting requirement.<br>
<br><br><br>After reading your feedback, we are considering to bring back the NAME reference in VM templates for version 3.2.<br>We think the most robust and easier to understand behaviour is the following one:<br><br>* Allow to use NAME to reference only resources owned by the user instantiating the VM.<br>
* If the template is intended to be shared with other users, then it must use the IMAGE_ID and NETWORK_ID attributes.<br><br><br>To all community members intersested in this issue, please share your thoughts.<br>What do you think about this? Would it be enough for your use-cases? Would you address this issue differently?<br>
<br><br>Regards.<br><br>[1] <a href="http://lists.opennebula.org/pipermail/users-opennebula.org/2010-October/002924.html" target="_blank">http://lists.opennebula.org/pipermail/users-opennebula.org/2010-October/002924.html</a><br>
<br clear="all"><span style="border-collapse:collapse;color:rgb(136, 136, 136);font-family:arial,sans-serif;font-size:13px">--<br>
Carlos Martín, MSc<br>Project Engineer<br>OpenNebula - The Open Source Toolkit for Data Center Virtualization<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42, 93, 176)" target="_blank"></a></span><br>
<br><br><div class="gmail_quote">On Tue, Nov 1, 2011 at 6:12 PM, Thomas Higdon <span dir="ltr"><<a href="mailto:thigdon@akamai.com" target="_blank">thigdon@akamai.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In 2.2, in a VM template, I could specify an image for a disk that was<br>
in the image repository by using IMAGE = <name>. This behavior appears<br>
to have been removed in 3.0, in favor of using IMAGE_ID = <id>, where<br>
<id> is an arbitrary number assigned by the opennebula system.<br>
<br>
This change in behavior seems kind of limiting. Before, I could create<br>
an image with a certain name, and then instantiate a VM template that<br>
had a disk that used that name. Now, in order to get that same behavior,<br>
I must instantiate the image, note the ID returned, and then rewrite my<br>
VM template to use that ID in its DISK attribute, then instantiate it.<br>
This is also true of virtual networks.<br>
<br>
Is there something I'm missing with respect to how VM templates are<br>
instantiated with respect to images? Is there any workaround that will<br>
allow the old behavior? Why was this change made?<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</blockquote></div><br>