OpenNebula

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

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?

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.

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

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?

Justin Cinkelj wrote:

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

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