[one-users] use of IMAGE_ID and its ilk in 3.0

[Carlos Martín Sánchez]

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<http://twitter.com/opennebula><cmartin at opennebula.org>


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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20111107/6c1afc02/attachment-0003.htm>