Bug 1425295 - [v4 API] Template.DiskAttachments seems to be ignored when adding new Template
Summary: [v4 API] Template.DiskAttachments seems to be ignored when adding new Template
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.6
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ovirt-4.1.2
: ---
Assignee: Tal Nisan
QA Contact: Avihai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-21 06:28 UTC by Germano Veit Michel
Modified: 2020-05-14 15:47 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-06 05:30:36 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 75220 0 master MERGED Add create template example 2017-04-10 11:39:26 UTC
oVirt gerrit 75225 0 master MERGED Add create template example 2017-04-07 16:12:46 UTC
oVirt gerrit 75227 0 master MERGED Add create template example 2017-04-10 11:41:23 UTC
oVirt gerrit 75272 0 master MERGED Document template disk customization 2017-04-19 13:36:46 UTC
oVirt gerrit 75344 0 sdk_4.1 MERGED Add create template example 2017-04-07 16:21:09 UTC
oVirt gerrit 75404 0 sdk_4.1 MERGED Add create template example 2017-04-10 11:47:20 UTC
oVirt gerrit 75405 0 sdk_4.1 MERGED Add create template example 2017-04-10 11:49:18 UTC
oVirt gerrit 75654 0 model_4.1 MERGED Document template disk customization 2017-04-19 13:45:34 UTC

Description Germano Veit Michel 2017-02-21 06:28:51 UTC
Description of problem:

Using the python SDK4, I'm trying to set some parameters for a template creation. The goal is to have the template with QCOW2/Thin Disks irrespective of the base VM configuration. 
However, it looks like the DiskAttachments list is ignored on the Template instance passed to TemplatesService.add().

Example 1:

new_template = templates_service.add(
    types.Template(
        name = template_name,
        vm = types.Vm(
            name=vm.name,
        ),
        disk_attachments = []
    )
)

Results in this:

DEBUG:root:POST /ovirt-engine/api/templates HTTP/1.1

DEBUG:root:<template>
DEBUG:root:  <name>da_pipeline_template_210220171613</name>
DEBUG:root:  <vm>
DEBUG:root:    <name>Test</name>
DEBUG:root:  </vm>
DEBUG:root:  <disk_attachments/>       <--- empty
DEBUG:root:</template>

But the created template was created with the disks of VM 'Test'. Doesn't sound right.

Example 2 (what we actually want to do):

template_disks = []
disk_attachments_service = vm_service.disk_attachments_service()
for disk_attachment in disk_attachments_service.list():
    new_attachment = disk_attachment
    new_attachment.disk.sparse=True
    new_attachment.disk.format=types.DiskFormat.COW
    template_disks.append(new_attachment)

# Add Template    
print "3. Adding template %s based on VM %s" % (template_name,vm.name)
new_template = templates_service.add(
    types.Template(
        name = template_name,
        vm = types.Vm(
            name=vm.name,
        ),
        disk_attachments = template_disks
    )
)

Results in this:

DEBUG:root:POST /ovirt-engine/api/templates HTTP/1.1

DEBUG:root:  <name>da_pipeline_template_200220171706</name>
DEBUG:root:  <vm>
DEBUG:root:    <name>Test</name>
DEBUG:root:  </vm>
DEBUG:root:  <disk_attachments>
DEBUG:root:    <disk_attachment href="/ovirt-engine/api/vms/3a902fae-8d8b-4f42-afda-9297cc214682/diskattachments/559083c3-56af-4948-9247-d4921cc139cd" id="559083c3-56af-4948-9247-d4921cc139cd">
DEBUG:root:      <active>true</active>
DEBUG:root:      <bootable>true</bootable>
DEBUG:root:      <interface>virtio</interface>
DEBUG:root:      <disk href="/ovirt-engine/api/disks/559083c3-56af-4948-9247-d4921cc139cd" id="559083c3-56af-4948-9247-d4921cc139cd">
DEBUG:root:        <format>cow</format>
DEBUG:root:        <sparse>true</sparse>
DEBUG:root:      </disk>
DEBUG:root:      <vm href="/ovirt-engine/api/vms/3a902fae-8d8b-4f42-afda-9297cc214682" id="3a902fae-8d8b-4f42-afda-9297cc214682"/>
DEBUG:root:    </disk_attachment>
DEBUG:root:  </disk_attachments>
DEBUG:root:</template>

Which looks correct. But the result is not. format=cow and sparse=True are not honored. The template has the exact configuration of the base VM.

From these two examples, it looks like disk_attachments is completely ignored when creating a template, empty or not, configured or not, the result is always the same.

I assume this is a bug, or is there a catch somewhere? 

Version-Release number of selected component (if applicable):
rhevm-4.0.6.3-0.1.el7ev.noarch

How reproducible:
100%

Comment 1 Yaniv Lavi 2017-04-05 08:44:59 UTC
Can you have a look?

Comment 2 Juan Hernández 2017-04-05 11:14:12 UTC
The way to customize the disks of the template is to use the 'template.vm.disk_attachments.disk' attribute, not 'template.disk_attachments.disk'. For example, if you are using directly the API:

  POST /ovirt-engine/api/templates

  <template>
    <name>mytemplate</name>
    <vm id="0957c87d-c933-4d28-9ce4-635fa4d8c711">
      <disk_attachments>
        <disk_attachment>
          <disk id="db7594bd-102b-4a72-8c90-900f3609f0eb">
            <format>cow</format>
            <sparse>true</sparse>
          </disk>
        </disk_attachment>
      </disk_attachments>
    </vm>
  </template>

With the Python SDK it should be something like this:

---8<---
# Find the original virtual machine:
vms_service = system_service.vms_service()
vm = vms_service.list(search='name=myvm')[0]

# Get the identifiers of the disks attached to the virtual machine. We
# need this because we want to tell the server to create the disks of
# the template using a format different to the format used by the
# original disks.
attachments = connection.follow_link(vm.disk_attachments)
disk_ids = [
    attachment.disk.id
    for attachment in attachments
]

# Send the request to create the template. Note that the way to specify
# the original virtual machine, and the customizations, is to use the
# 'vm' attribute of the 'Template' type. In the customization we
# explicitly indicate that we want COW disks, regardless of what format
# the original disks had.
templates_service = system_service.templates_service()
template = templates_service.add(
    template=types.Template(
        name='mytemplate',
        vm=types.Vm(
            id=vm.id,
            disk_attachments=[
                types.DiskAttachment(
                    disk=types.Disk(
                        id=disk_id,
                        sparse=True,
                        format=types.DiskFormat.COW
                    )
                )
                for disk_id in disk_ids
            ]
        )
    )
)
--->8---

Please try that. If it works correctly I think you can close the bug as NOTABUG.

Comment 3 Germano Veit Michel 2017-04-06 05:30:36 UTC
So that the attachments must be set in template.vm.disk_attachments and not in template.disk_attachments. I would never have guessed it.

But it works, thanks a lot!

Comment 4 Juan Hernández 2017-04-06 08:02:44 UTC
I admit that is confusing. I am trying to clarify that in the specification of the API:

  Document template disk customization
  https://gerrit.ovirt.org/75272

I kindly invite you all to participate in the improvement of that documentation. when you have a question, and you find the answer somewhere other than the documentation, please consider updating it.

Comment 5 Germano Veit Michel 2017-04-07 00:41:56 UTC
Hi Juan,

Much appreciated your DOC improvement efforts! It's much better now and the examples are also very useful.

(In reply to Juan Hernández from comment #4)
> I kindly invite you all to participate in the improvement of that
> documentation. when you have a question, and you find the answer somewhere
> other than the documentation, please consider updating it.
Thanks, I will.

There is one more thing though, I think I found a bug related to this. Since it's not the exact same subject of this BZ (DOCs) I decided to open BZ#1439970.


Note You need to log in before you can comment on or make changes to this bug.