Feature #1865
Merging vector attributes
Status: | Closed | Start date: | 04/05/2013 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Core & System | |||
Target version: | - | |||
Resolution: | duplicate | Pull request: |
Description
Hi,
Ref. feature #1697
The template merge function introduced in revision 60f0d4bf doesn't work as I expected. What it does is actually replace any attribute found in the template. Some attributes are actually vectors that may contains other attributes, and you don't necessarily want the other attributes from the vector to be crushed by the user supplied template.
Here is a typical example of my use case.
I'm enforcing the size of disk images for my VM by explicitly defining the SIZE attribute in my VM template. I prevent my user from modifying the size by setting DISK/SIZE as a restricted attribute. My VM template contains:
<DISK><SIZE>4096</SIZE></DISK>
I want my user to specify the image they want to use when instantiaing a new VM. A user may provide the following extra template to one.template.instantiate:
<DISK><IMAGE_ID>42</IMAGE_ID></DISK>
The current merge function will simply see my user is overriding the DISK attribute, erase the entire DISK vector from my template, and replace it with the user supplied DISK template.
What I expect is the IMAGE_ID attribute to be added to my existing DISK vector (preserving the DISK/SIZE attribute from my template).
My initial proposed version of the merge function in revision 3deeec21 handled the case of merging vector attributes.
I'm attaching a slightly revised patch (similar to 3deeec21) that applies on top of one-4.0 and preserve merging vector attributes. Note the patch as the same limitation when merging template that have multiple vectors of the same name (ex. multiple NIC vector attributes). Since there is no way to determine which vector to merge, the first vector attribute that matched is always used.
Thanks
Simon
Related issues
History
#1 Updated by Simon Boulet over 8 years ago
- File fix-4.0-template-merge.patch added
#2 Updated by Carlos Martín over 8 years ago
- Target version set to Release 4.2
Hi,
Thanks for the patch, we'll have to postpone this after the final 4.0 release, which is just around the corner.
Maybe we could try to support both the sub-attribute merge and the addition of new DISKs/NICs matching by DISK_ID... This attribute is now added by the core when a VM is instantiated, but I guess we could look for it in the source template.
By the way, the use case you describe does not work out of the box, I assume you are using custom drivers that make use of SIZE and IMAGE?
#3 Updated by Simon Boulet over 8 years ago
Carlos Martín wrote:
By the way, the use case you describe does not work out of the box, I assume you are using custom drivers that make use of SIZE and IMAGE?
Yes, custom drivers. It allows my users to use an existing image from a datastore (ex. a Debian image) but have the effective disk having a different size.
Looking forward at getting this into 4.2 (or a 4.0 revision later..), and let me know if you have any feedbacks.
Simon
#4 Updated by Ruben S. Montero about 8 years ago
- Category set to Core & System
#5 Updated by Ruben S. Montero about 8 years ago
- Target version deleted (
Release 4.2)
#6 Updated by Ruben S. Montero about 8 years ago
- Target version set to Release 4.2
#7 Updated by Simon Boulet about 8 years ago
I temporarily worked around this by setting the DISK size for the template in RAW/DISK_SIZE and using this in my driver, instead of trying to merge the user supplied DISK/IMAGE_ID with the DISK/SIZE attribute from the template.
#8 Updated by Ruben S. Montero almost 8 years ago
- Target version changed from Release 4.2 to Release 4.4
#9 Updated by Ruben S. Montero over 7 years ago
- Tracker changed from Bug to Feature
- Target version changed from Release 4.4 to Release 4.6
#10 Updated by Ruben S. Montero over 7 years ago
We are going a completely new approach for this using templates. So you can define a template, and a couple of variables that needs to be filled when the template is instantiated. We would be also able to provide defaults for it.
This would be an improved version, and core supported version of this tool:
#11 Updated by Ruben S. Montero over 7 years ago
- Status changed from New to Closed
- Target version deleted (
Release 4.6) - Resolution set to duplicate
#12 Updated by Ruben S. Montero over 7 years ago
- Related to Backlog #2590: General user inputs in templates added