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

[Chris Johnston]

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-boun...@lists.opennebula.org 
[mailto:users-boun...@lists.opennebula.org] On Behalf Of Thomas Higdon
Sent: Thursday, November 03, 2011 12:36 PM
To: Carlos Martín Sánchez
Cc: users@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  read/write
250GB disks for  VMs, but not necessarily create  template files,
or edit one file  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 diff

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

[Thomas Higdon]

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  read/write
250GB disks for  VMs, but not necessarily create  template files,
or edit one file  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

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

[Carlos Martín Sánchez]

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 | cmar...@opennebula.org |
@OpenNebula


On Tue, Nov 1, 2011 at 6:12 PM, Thomas Higdon  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 = . This behavior appears
> to have been removed in 3.0, in favor of using IMAGE_ID = , where
>  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@lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Opennebula Watch and MySQL

[Humberto N. Castejon Martinez]

Hi again,

I solved the problem. After all it seems it was a problem of missing
libraries/gems. I had manually installed the ruby gems named in the
documentation for Opennebula Watch, but it seems something was still
missing. i decided then to run sudo /usr/share/one/install_gems to install
all gems needed by all (optional) components. I got an error running that
script: it was complaining about the version of rubygems. Since I am
running Ubuntu 10.04.3 LTS, I had to run the following commands to update
rubygems:
gem install rubygems-update
cd /var/lib/gems/1.9.1/bin
sudo ./update_rubygems

I run again sudo /usr/share/one/install_gems and everything was ok.
thereafter I could start both the Watch service and Sunstone without
problems.

Cheers,
Humberto
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

[one-users] oneimage show does not work

[MENDOZA, John Robert T.]

Hi all,

I have recently upgraded our OpenNebula deployment from 2.2.1 to 3.0. 
I've successfully migrated the database (after much tinkering with the 
database migration codes.) and have started one daemon. My problem is, 
whenever I'm issuing the command oneimage show , it 
prints this error "[ImageInfo] Error getting image [some_image_id]." 
Also, in sunstone, whenever I'm selecting one image from the image pool, 
it outputs an error about the method "ImageInfo". Our current setup is:


OS: CentOS 5.6
Ruby: ruby 1.8.6 (2010-02-05 patchlevel 399) [x86_64-linux]
DB:  Sqlite

Is "oneimage show" broken?

Thanks,
Bert

___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org