Feature #653

Resources can only be referenced by their ID

Added by Ruben S. Montero over 8 years ago. Updated over 8 years ago.

Status:ClosedStart date:05/19/2011
Priority:NormalDue date:
Assignee:Ruben S. Montero% Done:

0%

Category:Core & System
Target version:Release 3.0
Resolution:fixed Pull request:

Description

As the use-cases of OpenNebula scales in the number of users, it has become very difficult to maintain a double reference schema for resources. Usually name's collide and it is necessary to introduce a policy to pick just one resource (image, network or template). This is confusing and tends to produce errors in cross reference when the pools changes.

Next release will only allow to reference the objects by ID

Associated revisions

Revision 82982a7a
Added by Ruben S. Montero over 8 years ago

feature #653, #488: Images can only be referenced by ID in DISKs. Names can now be repeated, even for the same user

Revision 88317546
Added by Ruben S. Montero over 8 years ago

feature #653, #488: Networks can only be referenced by ID in NICs. Names can now be repeated, even for the same user

History

#1 Updated by jordan pittier over 8 years ago

This is not backward compatible. There should be a big warning somewhere in the documentation and/or the "changelog"/release note.

#2 Updated by Tino Vázquez over 8 years ago

We certainly warn about this, so to avoid confusion.

We are conscious that this may cause issues, we would like to hear what kind of problems do you foresee, in case we are missing something. AFAWK, templates would need to be rewritten if they relied on images and network names. Which problems do you see coming from this?

#3 Updated by jordan pittier over 8 years ago

It's not that I foresee some specific problems, but more that when problems happen (and they do :p) I find it hard to track their origin.

Two days ago, I spent 2 hours wondering why a context variable wasn't set at all in context.sh although I though it was in my template VM. Turned out I was refering (in the context section of the Template) my "Network" by its name and not by its ID (which is now mandatory, I use "master" branch). Nowhere in any logs file was mentionned that I was doing something wrong.

Thanks to nice support from IRC, I solved it. I guess all I am saying is maybe be more "verbose" (log ou output to STDOUT) when something goes wrong.

#4 Updated by Shi Jin over 8 years ago

My comment on this is that the use of NETWORK_ID is probably suitable for a production environment but during a development phase, the use of NETWORK NAME is much more convenient. For example, while I am playing with the network template setup by frequently deleting and creating new VNET under the same name with different parameters. We have to change the VM template for every VNET update since the NETWORK_ID changes while its name can remain the same.
This is not a big issue since once the VNET is tuned to work, it should remain for a long time in a production environment.

By the way, is it possible to specify an already deleted VNET ID in a VNET template?

Thanks.
Shi

#5 Updated by Justin Cinkelj over 8 years ago

Also, when creating new VNET with 'onevnet', its ID is not returned. So it is required to search for it.

- I think opennebula takes care of having unique names for resources of a single user.
- But multiple resources would still be found if searching with 'onevnet -f name=myname list m', as m includes all public VNETs
- Should 'one* create' commands return ID to simplify usage?

#6 Updated by Javi Fontan over 8 years ago

Justin Cinkelj wrote:

- Should 'one* create' commands return ID to simplify usage?

You can add -v argument to create commands to return the ID.

#7 Updated by Ruben S. Montero over 8 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

Also available in: Atom PDF