FYI. This has been implemented and released as part of 3.2 pre-release 1. Cheers
Ruben 2011/11/7 Carlos Martín Sánchez <[email protected]>: > Hi, > > We have created a ticket for this feature. You can follow the development > and add comments in our development portal: > > http://dev.opennebula.org/issues/966 > > Regards. > -- > Carlos Martín, MSc > Project Engineer > OpenNebula - The Open Source Toolkit for Data Center Virtualization > www.OpenNebula.org | [email protected] | @OpenNebula > > > 2011/11/4 Thomas Higdon <[email protected]> >> >> On Fri, Nov 04, 2011 at 07:00:21AM -0500, Carlos Martín Sánchez wrote: >> > Hi Chris, >> > >> > I think adding the owner is a good idea. However, the examples you >> > provide rely >> > on the '/' separator, and currently that's a valid character for both >> > user and >> > resource names. >> > >> > This is our suggested syntax to implement this: >> > >> > DISK = [ IMAGE = "Ubuntu", >> > IMAGE_UNAME = "oneadmin" ] >> > >> > DISK = [ IMAGE = "Ubuntu", >> > IMAGE_UID = 7 ] >> > >> > DISK = [ IMAGE = "Ubuntu" ] >> > >> > DISK = [ IMAGE_ID = 23 ] >> > >> > 1: use the Image named ubuntu, owned by the user named oneadmin. >> > 2: use the ubuntu Image owned by user with ID 7. >> > 3: use the ubuntu Image owned by the user instantiating the VM. >> > 4: use image with ID 23 >> >> This has fleshed out the exact idea I was suggesting. Looks good to me. >> >> > 2011/11/3 Thomas Higdon <[email protected]> >> > >> > Another more radical suggestion is to do away with the template >> > management system entirely, and switch to a system where the >> > templates >> > are derived directly from files that exist on the filesystem. This >> > has a >> > number of advantages I can see (if you're interested I'll explain >> > further), but it might be more change than you're willing to go >> > through >> > at this point. >> > >> > >> > Regards. >> > -- >> > Carlos Martín, MSc >> > Project Engineer >> > OpenNebula - The Open Source Toolkit for Data Center Virtualization >> > www.OpenNebula.org | [email protected] | @OpenNebula >> > >> > >> > 2011/11/3 Chris Johnston <[email protected]> >> > >> > This issue has caused myself much frustration as well. Personally I >> > prefer >> > the suggestion of using both the owner and the resource name for >> > specifying >> > a resource. That should work for just about any use case and allows >> > names >> > to be used at any level with no confusion as to what resource is >> > really >> > being referenced. For example... >> > >> > IMAGE = "oneadmin/generic" >> > IMAGE = "dev01/virtapp" >> > IMAGE = "user01/virtapp" >> > IMAGE = "user01/custom" >> > >> > ...and the same for NETWORK. It does add some overhead but it's a >> > lot >> > simpler than maintaining lists of IDs and constantly updating >> > scripts. >> > >> > -----Original Message----- >> > From: [email protected] [mailto: >> > [email protected]] On Behalf Of Thomas Higdon >> > Sent: Thursday, November 03, 2011 12:36 PM >> > To: Carlos Martín Sánchez >> > Cc: [email protected] >> > Subject: Re: [one-users] use of IMAGE_ID and its ilk in 3.0 >> > >> > Hi, it's good to know the ONE developers are so open to feedback >> > about >> > the way the system works. ONE seems great from what I've used so >> > far. >> > >> > The solution that you would propose would work fine for me, mostly >> > because it looks like that for a single user, the templating system >> > would work the same as it did for 2.2, which was ok with me. >> > >> > I'm a little leery of the idea of ever forcing users to use IMAGE_ID >> > or >> > NETWORK_ID parameters. In my mind, forcing users to specify these in >> > static template strings/files is equivalent to some Unix >> > command-line >> > tool asking a user to specify the inode number of a file rather than >> > its >> > name. >> > >> > Here's a suggestion. Your database is basically a key-value store. >> > In >> > 2.2, the only key you allowed is the name (in 3.0 it's only ID). I'd >> > suggest that you allow more freedom in the specification of keys. >> > You >> > might ask users to specify a name for resources that they own. If >> > they >> > are asking for resources that they don't own, then they must also >> > specify which user owns that resource, or perhaps which group. If >> > there's ambiguity, then error on that. >> > >> > Another suggestion I would make is to remove the NAME attribute from >> > all >> > templates (or make it optional) and allow users to specify a name on >> > the >> > command-line, defaulting to something reasonable, as is done now for >> > template instantiation. That way, users who don't care what the name >> > is >> > don't need to specify it, and users who do care don't need to edit a >> > text file to instantiate multiple instances of the same resource. I >> > see >> > this as being useful in a scenario where I want to create <x> >> > read/write >> > 250GB disks for <x> VMs, but not necessarily create <x> template >> > files, >> > or edit one file <x> times. >> > >> > At the end of the day, desirable behavior for me is to be able to >> > create >> > a set of static template files for networks, images and VMs, and be >> > able >> > to instantiate all of them in the proper order and have it just >> > work. >> > ONE 3.0 does not allow me to do that. >> > >> > Another more radical suggestion is to do away with the template >> > management system entirely, and switch to a system where the >> > templates >> > are derived directly from files that exist on the filesystem. This >> > has a >> > number of advantages I can see (if you're interested I'll explain >> > further), but it might be more change than you're willing to go >> > through >> > at this point. >> > >> > On Thu, Nov 03, 2011 at 08:55:30AM -0500, Carlos Martín Sánchez >> > wrote: >> > > Hi Thomas, >> > > >> > > 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. >> > > >> > > 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'. >> > > >> > > 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: >> > > >> > > >> > > 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. >> > > >> > > 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: >> > > >> > > 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? >> > > 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". >> > > >> > > 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. >> > > >> > > >> > > 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. >> > > >> > > >> > > >> > > After reading your feedback, we are considering to bring back the >> > NAME >> > > reference in VM templates for version 3.2. >> > > We think the most robust and easier to understand behaviour is the >> > following >> > > one: >> > > >> > > * Allow to use NAME to reference only resources owned by the user >> > instantiating >> > > the VM. >> > > * If the template is intended to be shared with other users, then >> > it must >> > use >> > > the IMAGE_ID and NETWORK_ID attributes. >> > > >> > > >> > > To all community members intersested in this issue, please share >> > your >> > thoughts. >> > > What do you think about this? Would it be enough for your >> > use-cases? >> > Would you >> > > address this issue differently? >> > > >> > > >> > > Regards. >> > > >> > > [1] http://lists.opennebula.org/pipermail/users-opennebula.org/ >> > 2010-October/ >> > > 002924.html >> > > >> > > -- >> > > Carlos Martín, MSc >> > > Project Engineer >> > > OpenNebula - The Open Source Toolkit for Data Center >> > Virtualization >> > > www.OpenNebula.org | [email protected] | @OpenNebula >> > > >> > > >> > > On Tue, Nov 1, 2011 at 6:12 PM, Thomas Higdon <[email protected]> >> > wrote: >> > > >> > > In 2.2, in a VM template, I could specify an image for a disk >> > that >> > was >> > > in the image repository by using IMAGE = <name>. This behavior >> > appears >> > > to have been removed in 3.0, in favor of using IMAGE_ID = >> > <id>, where >> > > <id> is an arbitrary number assigned by the opennebula system. >> > > >> > > This change in behavior seems kind of limiting. Before, I >> > could >> > create >> > > an image with a certain name, and then instantiate a VM >> > template that >> > > had a disk that used that name. Now, in order to get that same >> > behavior, >> > > I must instantiate the image, note the ID returned, and then >> > rewrite >> > my >> > > VM template to use that ID in its DISK attribute, then >> > instantiate >> > it. >> > > This is also true of virtual networks. >> > > >> > > Is there something I'm missing with respect to how VM >> > templates are >> > > instantiated with respect to images? Is there any workaround >> > that >> > will >> > > allow the old behavior? Why was this change made? >> > > _______________________________________________ >> > > Users mailing list >> > > [email protected] >> > > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> > > >> > > >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> > >> > >> > --------------------------------------------------------------------- >> > This transmission (including any attachments) may contain >> > confidential >> > information, privileged material (including material protected by >> > the >> > solicitor-client or other applicable privileges), or constitute >> > non-public >> > information. Any use of this information by anyone other than the >> > intended >> > recipient is prohibited. If you have received this transmission in >> > error, >> > please immediately reply to the sender and delete this information >> > from >> > your system. Use, dissemination, distribution, or reproduction of >> > this >> > transmission by unintended recipients is not authorized and may be >> > unlawful. >> > >> > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > > -- Dr. Ruben Santiago Montero Associate Professor (Profesor Titular), Complutense University of Madrid URL: http://dsa-research.org/doku.php?id=people:ruben Weblog: http://blog.dsa-research.org/?author=7 _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
