Description of problem: We have a new RHEVM 4.0 provider to add to our CFME 4.2 environment. When we try to provision, we get an error from attachcloudinitpayload complaining that it can't set the cloud-init for the new VM. Version-Release number of selected component (if applicable): 5.7.1.3-20170221135006_818f133 RHEV4 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The return error from RHEV suggest the CloudForms is making a incorrect api call when attaching the cloud-init data. Request syntactically incorrect. See the description below for the correct usage Looks to be due to https://bugzilla.redhat.com/show_bug.cgi?id=1337240
Is the customer using automation code that calls directly the methods of the RHV provider, or the methods of the 'ovirt' gem? This line in the automation logs suggests that: [----] I, [2017-04-04T12:17:16.661380 #28160:10e4740] INFO -- : Q-task_id([miq_provision_9000000000180]) <AEMethod attachcloudinitpayload> Attaching payload to VM: [ericb-betatest-1.beta.pt-virt.uspto.gov] There is no such 'Attaching payload VM' message in the CFME code base, so I believe it is code developed by the user. Can you please ask the user to share that code? Note that calling directly this provider code, or the 'ovirt' gem is bad practice: it may change from version to version without notice, backwards compatibility isn't guaranteed. However, in this particular case, it looks like the 'attach_payload' method of the 'ovirt' gem doesn't correctly detect the version of the server: for 4.0 it assumes that it is actually 3.0: https://github.com/ManageIQ/ovirt/blob/v0.14.0/lib/ovirt/vm.rb#L173-L223 If that is the problem, then I think that the user can workaround the problem replacing in their automation code the call to 'attach_payload' with 'attach_payload_3_3'. We should also fix that code to implement the version comparison so that it works correctly for 4.0. Let me take the opportunity to remind you that version 3 of the RHV API, used by the 'ovirt' gem, is deprecated since version 4 of RHV, and it will be completely removed in version 4.2 of RHV. I'd suggest the user to migrate their code to use the oVirt Ruby SDK, which we are committed to keep backwards compatible during the RHV 4 life cycle. It is documented here: https://github.com/oVirt/ovirt-engine-sdk-ruby/tree/master/sdk https://github.com/oVirt/ovirt-engine-sdk-ruby/tree/master/sdk/examples http://www.rubydoc.info/gems/ovirt-engine-sdk The gem is already included in CFME.
The proposed pull request to address this issue is the following: Fix handling of version 4.y in Vm.attach_payload https://github.com/ManageIQ/ovirt/pull/80
The proposed pull request has been merged to the 'ovirt' gem. Now we need to modify ManageIQ to use that new version: Use version 0.16.0 of the 'ovirt' gem https://github.com/ManageIQ/manageiq-gems-pending/pull/127
The pull request to use the new version of the 'ovirt' gem has been moved to th manageiq-providers-ovirt repository: Use version 0.16.0 of the 'ovirt' gem https://github.com/ManageIQ/manageiq-providers-ovirt/pull/20
Juan, How this bug should be verified please? Is cloud-init functionality testing, for RHV-4.1 is sufficient? Thanks.
Testing this rather complicate. You need to create an automation method in Ruby, and and from that method you need to use the `ovirt` gem to call the `Vm#attach_payload` method. The third attachment contains the code of the automation method that the customer used.
Verified using ovirt gem version 0.18.1 and RHV 4.1.9. Test script calling: vm.attach_payload({'floppy' => {'test.iso' => 'user_data_content'}}) Call succeeds and yields: ... <payloads> <payload> <files> <file> <name>test.iso</name> <content>user_data_content</content> </file> </files> <type>floppy</type> </payload> </payloads> ...