Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1072819

Summary: Accept old payload file syntax for backwards compatibility
Product: [Retired] oVirt Reporter: Juan Hernández <juan.hernandez>
Component: ovirt-engine-apiAssignee: Ori Liel <oliel>
Status: CLOSED CANTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3CC: acathrow, gklein, iheim, kmorey, shrikant_ghare, s.kieske, yeylon
Target Milestone: ---   
Target Release: 3.4.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-07 08:30:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Juan Hernández 2014-03-05 09:21:48 UTC
In version 3.2 the syntax used to create the payload of a VM was the following:

  <payloads>
    <payload type="cdrom">
      <file name="/etc/hosts">
        <content>127.0.0.1 localhost myvm.example.com</content>
      </file>
    </payload>
  </payloads>

This generated a problem with the generateDS.py tool used to generate the Python SDK, so it was changed to the following:

  <payloads>
    <payload type="cdrom">
      <files>
        <file>
          <name>/etc/hosts</name>
          <content>127.0.0.1 localhost myvm.example.com</content>
        </file>
      </files>
    </payload>
  </payloads>

This broke backwards compatibility. The RESTAPI should be fixed so that in 3.3 it accepts both the old and the new syntax.

Comment 1 Juan Hernández 2014-03-05 09:27:21 UTC
This issue has been reported before in bug 1068803 and bug 1071948 and bug.

Comment 2 Juan Hernández 2014-03-05 09:28:18 UTC
*** Bug 1068803 has been marked as a duplicate of this bug. ***

Comment 3 Juan Hernández 2014-04-01 08:58:01 UTC
This fix won't be ready for 3.3.5, and there won't be a 3.3.6 release, so retargeting for 3.4.1.

Comment 4 Juan Hernández 2014-04-07 08:30:56 UTC
After studying this in detail and trying several alternatives we came to the conclusion that the solution is too complex and risky to implement.

Comment 5 Ori Liel 2014-04-07 09:20:56 UTC
We won't fix this, because the solution is very complex and time consuming: 

Background: 
----------

Python-sdk generation assumes name uniqueness for classes. The patch which introduced Payload: 
   
  http://gerrit.ovirt.org/#/c/3460


included this line in api.xsd: 

   <xs:element name="file" type="PayloadFile"/>

This declaration couples 'file' with 'PayloadFile', but elsewhere in our schema 'file' is coupled with 'File'. SDK generation did not know how to deal with this, and had problems. 

As a result, Payload structure was changed in:

  http://gerrit.ovirt.org/#/c/20162/

and SDK generation was fine again, but this solution was not backwards-compatible. 


This bug asks us to support both formats, the old and the new.  


Attempt at solution: 
---------------------

Achieving the above requires, as a first step, 'hiding' the duplicate name definition in the schema, as it harms SDK generation. Such hiding could be achieved by writing a proprietary JaxB plugin, which is activated by maven and influences entity generation. This part was done successfully. 

However, a full solution required another step: since in the old format, file-name was an attribute, and in the new format, file-name was an element, we would have to find some magic trick to make JaxB accept both. This would require another interceptor, a more complex one probably, and at this point we pulled the plug because the time that would be required was unreasonable.