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
