Bug 1797659 - [API]Have a generic way to initialize a VM in run-once
Summary: [API]Have a generic way to initialize a VM in run-once
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.3.9-1
: 4.3.9.4
Assignee: Liran Rotenberg
QA Contact: Beni Pelled
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-03 15:18 UTC by Liran Rotenberg
Modified: 2020-04-06 06:53 UTC (History)
4 users (show)

Fixed In Version: ovirt-engine-4.3.9.4
Clone Of:
Environment:
Last Closed: 2020-04-06 06:53:11 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.3+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 106726 0 master ABANDONED core: let engine decide the init type 2020-09-03 07:23:08 UTC
oVirt gerrit 106833 0 master MERGED restapi: introduce generic initialize 2020-09-03 07:23:09 UTC
oVirt gerrit 106834 0 master MERGED restapi+backend: Support generic vm initialization 2020-09-03 07:23:09 UTC
oVirt gerrit 107369 0 model_4.3 MERGED restapi: introduce generic initialize 2020-09-03 07:23:09 UTC
oVirt gerrit 107436 0 ovirt-engine-4.3 MERGED restapi+backend: Support generic vm initialization 2020-09-03 07:23:08 UTC

Internal Links: 1813948

Description Liran Rotenberg 2020-02-03 15:18:34 UTC
Description of problem:
When we have a VM and we start it with API, we can set Initialization type to it.
There are flags such as: useCloudInit, useSysprep, useIgnition that will tell the engine which initialization we wish to use.
But, in case we don't supply this flag we still wish the initialization will pass, and be determined by the OS type.

How reproducible:
100%

Steps to Reproduce:
1. Create a VM.
2. Start the VM wish REST-API(SDK) and set the Initialization in it.

Actual results:
VM doesn't have payload, no initialization in action.

Expected results:
The VM should have the initialization with it.

Additional info:
For example to SDK using ignition(python script):
connection = sdk.Connection(
    url='https://<engine-fqdn>/ovirt-engine/api',
    username=<user>,
    password=<password,
    insecure=True,
    debug=True
)

vms_service = connection.system_service().vms_service()


ignition='''
{
  "ignition": { "version": "3.0.0" },
  "passwd": {
    "users": [
      {
        "name": "core",
        "passwordHash": "$y$j9T$skCa2x5kFis7p58gYjz3C1$ykelHfCckRToZKAVYK7GDdLOCi3pcF2WMioI.vmYkj5"
      }
    ]
  }
}
'''
vm = vms_service.list(search='name=<vm_name>')[0]

vm_service = vms_service.vm_service(vm.id)
vm_service.start(
    vm=types.Vm(
        initialization=types.Initialization(
            custom_script=ignition,
        )
    )
)
connection.close()

Comment 1 Liran Rotenberg 2020-02-09 16:51:42 UTC
Changing the bug title. We will have now a generic flag in API. The flag will let the engine decide the initialization type depending on the operation system of the VM.
In case the user will run-once with this flag, the VM will have the desired payload.

Comment 5 Beni Pelled 2020-03-25 07:29:03 UTC
Verified with:
- ovirt-engine-4.3.9.4-11.el7.noarch
- ovirt-engine-restapi-4.3.9.4-11.el7.noarch
- libvirt-4.5.0-33.el7.x86_64 (host)
- vdsm-4.30.43-1.el7ev.x86_64 (host)
- cloud-init-18.5-7.el8.noarch (vm)

Verification steps:

curl -k --location --request POST 'https://<ENGINE_FQDN>/ovirt-engine/api/vms/<VM_ID>/start' \
--header 'Content-Type: application/xml' \
--user '<USER>:<PASS>' \
--data-raw '<action>
  <use_initialization>true</use_initialization>
  <vm>
    <initialization>
        <host_name>test_hostname</host_name>
        <timezone>NZ</timezone>
        <user_name>test_user</user_name>
        <root_password>654321</root_password>
    </initialization>
  </vm>
</action>'

Result:
- The VM is up and running with the initialization parameters (Hostname, TZ, u/p)

Comment 6 Sandro Bonazzola 2020-04-06 06:53:11 UTC
This bugzilla is included in oVirt 4.3.9 release, published on March 20th 2020.

Since the problem described in this bug report should be
resolved in oVirt 4.3.9 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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