[one-users] use of IMAGE_ID and its ilk in 3.0
Ruben S. Montero
rubensm at dacya.ucm.es
Wed Nov 23 00:59:39 PST 2011
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 <cmartin at opennebula.org>:
> 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 | cmartin at opennebula.org | @OpenNebula
>
>
> 2011/11/4 Thomas Higdon <thigdon at akamai.com>
>>
>> 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 <thigdon at akamai.com>
>> >
>> > 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 | cmartin at opennebula.org | @OpenNebula
>> >
>> >
>> > 2011/11/3 Chris Johnston <chjohnston at rim.com>
>> >
>> > 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: users-bounces at lists.opennebula.org [mailto:
>> > users-bounces at lists.opennebula.org] On Behalf Of Thomas Higdon
>> > Sent: Thursday, November 03, 2011 12:36 PM
>> > To: Carlos Martín Sánchez
>> > Cc: users at lists.opennebula.org
>> > 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 | cmartin at opennebula.org | @OpenNebula
>> > >
>> > >
>> > > On Tue, Nov 1, 2011 at 6:12 PM, Thomas Higdon <thigdon at akamai.com>
>> > 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
>> > > Users at lists.opennebula.org
>> > > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>> > >
>> > >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opennebula.org
>> > 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
> Users at lists.opennebula.org
> 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
More information about the Users
mailing list