Resources can only be referenced by their ID
|Assignee:||Ruben S. Montero||% Done:|
|Category:||Core & System|
|Target version:||Release 3.0|
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
#2 Updated by Tino Vázquez over 9 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 9 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 9 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?
#5 Updated by Justin Cinkelj over 9 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?