Hi,<br><br>We have created a ticket for this feature. You can follow the development and add comments in our development portal:<br><br><a href="http://dev.opennebula.org/issues/966">http://dev.opennebula.org/issues/966</a><br>
<br>Regards.<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">2011/11/4 Thomas Higdon <span dir="ltr"><<a href="mailto:thigdon@akamai.com">thigdon@akamai.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Nov 04, 2011 at 07:00:21AM -0500, Carlos Martín Sánchez wrote:<br>
> Hi Chris,<br>
><br>
> I think adding the owner is a good idea. However, the examples you provide rely<br>
> on the '/' separator, and currently that's a valid character for both user and<br>
> resource names.<br>
><br>
> This is our suggested syntax to implement this:<br>
><br>
> DISK = [ IMAGE = "Ubuntu",<br>
> IMAGE_UNAME = "oneadmin" ]<br>
><br>
> DISK = [ IMAGE = "Ubuntu",<br>
> IMAGE_UID = 7 ]<br>
><br>
> DISK = [ IMAGE = "Ubuntu" ]<br>
><br>
> DISK = [ IMAGE_ID = 23 ]<br>
><br>
> 1: use the Image named ubuntu, owned by the user named oneadmin.<br>
> 2: use the ubuntu Image owned by user with ID 7.<br>
> 3: use the ubuntu Image owned by the user instantiating the VM.<br>
> 4: use image with ID 23<br>
<br>
</div>This has fleshed out the exact idea I was suggesting. Looks good to me.<br>
<div class="HOEnZb"><div class="h5"><br>
> 2011/11/3 Thomas Higdon <<a href="mailto:thigdon@akamai.com">thigdon@akamai.com</a>><br>
><br>
> Another more radical suggestion is to do away with the template<br>
> management system entirely, and switch to a system where the templates<br>
> are derived directly from files that exist on the filesystem. This has a<br>
> number of advantages I can see (if you're interested I'll explain<br>
> further), but it might be more change than you're willing to go through<br>
> at this point.<br>
><br>
><br>
> Regards.<br>
> --<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">cmartin@opennebula.org</a> | @OpenNebula<br>
><br>
><br>
> 2011/11/3 Chris Johnston <<a href="mailto:chjohnston@rim.com">chjohnston@rim.com</a>><br>
><br>
> This issue has caused myself much frustration as well. Personally I prefer<br>
> the suggestion of using both the owner and the resource name for specifying<br>
> a resource. That should work for just about any use case and allows names<br>
> to be used at any level with no confusion as to what resource is really<br>
> being referenced. For example...<br>
><br>
> IMAGE = "oneadmin/generic"<br>
> IMAGE = "dev01/virtapp"<br>
> IMAGE = "user01/virtapp"<br>
> IMAGE = "user01/custom"<br>
><br>
> ...and the same for NETWORK. It does add some overhead but it's a lot<br>
> simpler than maintaining lists of IDs and constantly updating scripts.<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a> [mailto:<br>
> <a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a>] On Behalf Of Thomas Higdon<br>
> Sent: Thursday, November 03, 2011 12:36 PM<br>
> To: Carlos Martín Sánchez<br>
> Cc: <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
> Subject: Re: [one-users] use of IMAGE_ID and its ilk in 3.0<br>
><br>
> Hi, it's good to know the ONE developers are so open to feedback about<br>
> the way the system works. ONE seems great from what I've used so far.<br>
><br>
> The solution that you would propose would work fine for me, mostly<br>
> because it looks like that for a single user, the templating system<br>
> would work the same as it did for 2.2, which was ok with me.<br>
><br>
> I'm a little leery of the idea of ever forcing users to use IMAGE_ID or<br>
> NETWORK_ID parameters. In my mind, forcing users to specify these in<br>
> static template strings/files is equivalent to some Unix command-line<br>
> tool asking a user to specify the inode number of a file rather than its<br>
> name.<br>
><br>
> Here's a suggestion. Your database is basically a key-value store. In<br>
> 2.2, the only key you allowed is the name (in 3.0 it's only ID). I'd<br>
> suggest that you allow more freedom in the specification of keys. You<br>
> might ask users to specify a name for resources that they own. If they<br>
> are asking for resources that they don't own, then they must also<br>
> specify which user owns that resource, or perhaps which group. If<br>
> there's ambiguity, then error on that.<br>
><br>
> Another suggestion I would make is to remove the NAME attribute from all<br>
> templates (or make it optional) and allow users to specify a name on the<br>
> command-line, defaulting to something reasonable, as is done now for<br>
> template instantiation. That way, users who don't care what the name is<br>
> don't need to specify it, and users who do care don't need to edit a<br>
> text file to instantiate multiple instances of the same resource. I see<br>
> this as being useful in a scenario where I want to create <x> read/write<br>
> 250GB disks for <x> VMs, but not necessarily create <x> template files,<br>
> or edit one file <x> times.<br>
><br>
> At the end of the day, desirable behavior for me is to be able to create<br>
> a set of static template files for networks, images and VMs, and be able<br>
> to instantiate all of them in the proper order and have it just work.<br>
> ONE 3.0 does not allow me to do that.<br>
><br>
> Another more radical suggestion is to do away with the template<br>
> management system entirely, and switch to a system where the templates<br>
> are derived directly from files that exist on the filesystem. This has a<br>
> number of advantages I can see (if you're interested I'll explain<br>
> further), but it might be more change than you're willing to go through<br>
> at this point.<br>
><br>
> On Thu, Nov 03, 2011 at 08:55:30AM -0500, Carlos Martín Sánchez wrote:<br>
> > Hi Thomas,<br>
> ><br>
> > Some users requested to let new resources use repeated names, see for<br>
> instance<br>
> > this thread [1]. This makes sense in deployments with a large number of<br>
> users,<br>
> > or in a multi-tenant scenario, where you don't want users having to try a<br>
> > resource creation several times until they find a free name.<br>
> ><br>
> > We implemented this allowing repeated names, but only if they are not<br>
> owned by<br>
> > the same user. It was done this way so users can reference resources by<br>
> name in<br>
> > CLI commands, e.g. 'oneimage show my_img'.<br>
> ><br>
> > Since we released OpenNebula 3.0, some of you have complained about this<br>
> > change, so let me try to explain why we decided to drop the NAME<br>
> reference from<br>
> > VM templates:<br>
> ><br>
> ><br>
> > Lets say you want to use the VNet named "blue". In the worst case<br>
> scenario, you<br>
> > will have one "blue" network owned by you, several "blue" networks owned<br>
> by<br>
> > other people in your group, and several other "blue" networks owned by<br>
> people<br>
> > from other groups. You may, or may not, have rights to use the latter<br>
> "blue"<br>
> > networks outside your group.<br>
> ><br>
> > How does OpenNebula decide which "blue" network do you want to use? At<br>
> first<br>
> > sight, you could try to arrange them by priority: your VNet has comes<br>
> first,<br>
> > then VNets from your group, and then VNets from other groups. This<br>
> presents a<br>
> > lot of problems:<br>
> ><br>
> > You can have at most one "blue" network, but what happens if you are<br>
> > 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<br>
> with<br>
> > addresses in the 192.169.10.0 network. But you own another "blue" VNet<br>
> with<br>
> > base address 192.168.30.0. The user will expect his VNets to have greater<br>
> > priority, but then the VM will be created in a different VNet than the<br>
> one<br>
> > intended by "boss_user".<br>
> ><br>
> > If you don't own any "blue" network, you may create a template that uses<br>
> a<br>
> > public one owned by other user in your group. If it is the only "blue"<br>
> network<br>
> > in the group, then you template will work fine, until somebody else<br>
> decides to<br>
> > publish another "blue" network in the same group. From that moment,<br>
> OpenNebula<br>
> > would have to guess, or just refuse to instantiate that template that was<br>
> > working fine before.<br>
> ><br>
> ><br>
> > In the end, we could implement a priority and do our best to document it,<br>
> but<br>
> > we though that would cause a lot of confusion. The easiest solution was<br>
> to<br>
> > force the usage of IDs, what didn't look to us like a really limiting<br>
> > requirement.<br>
> ><br>
> ><br>
> ><br>
> > After reading your feedback, we are considering to bring back the NAME<br>
> > reference in VM templates for version 3.2.<br>
> > We think the most robust and easier to understand behaviour is the<br>
> following<br>
> > one:<br>
> ><br>
> > * Allow to use NAME to reference only resources owned by the user<br>
> instantiating<br>
> > the VM.<br>
> > * If the template is intended to be shared with other users, then it must<br>
> use<br>
> > the IMAGE_ID and NETWORK_ID attributes.<br>
> ><br>
> ><br>
> > To all community members intersested in this issue, please share your<br>
> thoughts.<br>
> > What do you think about this? Would it be enough for your use-cases?<br>
> Would you<br>
> > address this issue differently?<br>
> ><br>
> ><br>
> > Regards.<br>
> ><br>
> > [1] <a href="http://lists.opennebula.org/pipermail/users-opennebula.org/" target="_blank">http://lists.opennebula.org/pipermail/users-opennebula.org/</a><br>
> 2010-October/<br>
> > 002924.html<br>
> ><br>
> > --<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">cmartin@opennebula.org</a> | @OpenNebula<br>
> ><br>
> ><br>
> > On Tue, Nov 1, 2011 at 6:12 PM, Thomas Higdon <<a href="mailto:thigdon@akamai.com">thigdon@akamai.com</a>> wrote:<br>
> ><br>
> > In 2.2, in a VM template, I could specify an image for a disk that<br>
> was<br>
> > in the image repository by using IMAGE = <name>. This behavior<br>
> 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<br>
> 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<br>
> behavior,<br>
> > I must instantiate the image, note the ID returned, and then rewrite<br>
> my<br>
> > VM template to use that ID in its DISK attribute, then instantiate<br>
> 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<br>
> will<br>
> > allow the old behavior? Why was this change made?<br>
> > _______________________________________________<br>
> > Users mailing list<br>
> > <a href="mailto:Users@lists.opennebula.org">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>
> ><br>
> ><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opennebula.org">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>
><br>
> ---------------------------------------------------------------------<br>
> This transmission (including any attachments) may contain confidential<br>
> information, privileged material (including material protected by the<br>
> solicitor-client or other applicable privileges), or constitute non-public<br>
> information. Any use of this information by anyone other than the intended<br>
> recipient is prohibited. If you have received this transmission in error,<br>
> please immediately reply to the sender and delete this information from<br>
> your system. Use, dissemination, distribution, or reproduction of this<br>
> transmission by unintended recipients is not authorized and may be<br>
> unlawful.<br>
><br>
><br>
</div></div></blockquote></div><br>