Template variables should allow cross reference like CONTEXT does
|Assignee:||Ruben S. Montero||% Done:|
|Category:||Core & System|
|Target version:||Release 2.0|
This will potentially enable a wider a richer use of OpenNebula. For example, marrying the VNC port with the VM ID.
feature #189: Moved attribute parsing to VirtualMachine class (get rid of cross references). Added Requirements parsing and initial vnc_port generation
feature #189: Support to access NETWORK templates in VM CONTEXT (e.g. $NETWORK[DNS])
#1 Updated by Ruben S. Montero almost 11 years ago
- Target version set to Release 1.4.2
Looking at the attributes we do not need to use this cross parsing for all the variables (e.g. OS, DISK). Right now we have this for CONTEXT and for the REQUIREMENTS in a development branch. (For example you can do something like REQUIREMENTS = $NIC[MAC] = MACS, if you have a custom probe that generates a MACS attribute for the hosts you can do short of a MAC pinning, so only VMs with a given MAC runs in a given host)
My proposal: default generation values for port and listen in GRAPHICS. So if you do not put a port, OpenNebula will automatically assign 5900+$VMID, and if you do not put a listen OpenNebula will automatically HOSTNAME of the host where the VM is placed.
#5 Updated by Ruben S. Montero over 10 years ago
This ticket will include the following variable parsing/generation functionality for OpenNebula templates:
- Substitution of template variables in the REQUIREMENTS attribute
- Automatic generation of PORT as VMID + VNC_BASE_PORT. This should be enough to generate different ports for VMs so they do not collide
- Parsing of network attributes in CONTEXT. Network variables can be referenced as $NETWORK[...], see the mailing list for more info