[one-users] use of IMAGE_ID and its ilk in 3.0
Carlos Martín Sánchez
cmartin at opennebula.org
Mon Nov 7 06:22:29 PST 2011
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>
More information about the Users
mailing list