from the reporter i understand this doesnt happen when just using the rest-api, only when using the sdk:

"
Additional info:
Same test, running on rest engine PASS on is26.
"

it seems this only affect sdk somehow, can you please re-check?

(In reply to Omer Frenkel from comment #1)
> from the reporter i understand this doesnt happen when just using the
> rest-api, only when using the sdk:
> 
> "
> Additional info:
> Same test, running on rest engine PASS on is26.
> "
> 
> it seems this only affect sdk somehow, can you please re-check?

it cannot be the case as sdk does not mandate any parameters, so either
reported use-case is incorrect or sdk does not have mentioned attributes yet
(which i believe the case), but then how can it fail regression tests ...

masayag\imeerovi info:
>
> It seems that the latest patch to api.xsd of cloud-init introduced
> 'CloudInit' element which contains an internal "network" element.
>
> The ART generateDS.py generates a data-structure which contains the
> entities map. Since the 'network' map is defined twice in the api.xsd
> (as a main entity and as the cloud-init entity), the entity is
> overridden in that map, cause the network to be mapped to the cloud-init
> network type.
>
> There are 2 possible solutions:
> 1. Modify the generateDS to create a type as the
> outerElementName-innerElementName (ART responsibility)

here is problematic stuff:

  <xs:complexType name="CloudInit">
    <xs:sequence>
      <xs:element ref="host" minOccurs="0"/>
      <xs:element name="network" minOccurs="0">
        <xs:complexType>
          <xs:sequence>
            <xs:element ref="nics" minOccurs="0"/>
            <xs:element ref="dns" minOccurs="0"/>
          xs:sequence>
        xs:complexType>
      xs:element>
      <xs:element ref="authorized_keys" minOccurs="0"/>
      <xs:element name="regenerate_ssh_keys" type="xs:boolean" minOccurs="0"/>
      <xs:element name="timezone" type="xs:string" minOccurs="0"/>
      <xs:element ref="users" minOccurs="0"/>
      <xs:element ref="files" minOccurs="0" maxOccurs="1"/>
    xs:sequence>
  xs:complexType>

It doesn't sounds good to define elements with the same name twice
so it looks that cloud init feature owner should fix it ....

> 2. Extract the inner type into a complex type which will require an
> explicit unique name. (cloud init feature owner responsibility)
>
> Or any other alternative that might fix this, as I'm not familiar
> on any restriction of element declaration within the api.xsd.
>
> Regards,
> Moti

More info:

Details for tha patch mentioned in comment #3:"
"restapi: cloud-init - rest api for start vm" http://gerrit.ovirt.org/#/c/15537/

This change fail REST tests, as well as SDK tests:
=================================================

REST fail on: 
------------
Network object has no attribute ID

SDK fail on:
-----------
Same here only on SDK (REST is OK)
2013-12-10 08:24:09,870 - MainThread - nics - ERROR - Element
'<ovirtsdk.infrastructure.brokers.VMNic object at 0x7dd8c50>' has no
attribute 'comment'
2013-12-10 08:24:09,871 - MainThread - nics - INFO - Property
'nic->name' has correct value: nic3
2013-12-10 08:24:09,871 - MainThread - nics - ERROR - Element
'<ovirtsdk.infrastructure.brokers.VMNic object at 0x7dd8c50>' has no
attribute 'boot_protocol'
2013-12-10 08:24:09,871 - MainThread - nics - ERROR - Element
'<ovirtsdk.infrastructure.brokers.VMNic object at 0x7dd8c50>' has no
attribute 'on_boot'
2013-12-10 08:24:09,871 - MainThread - nics - ERROR - Element
'<ovirtsdk.infrastructure.brokers.VMNic object at 0x7dd8c50>' has no
attribute 'vnic_profile'
2013-12-10 08:24:09,872 - MainThread - nics - ERROR - Element
'<ovirtsdk.xml.params.Network object at 0x7dd8e90>' has no attribute
'comment'
2013-12-10 08:24:09,872 - MainThread - nics - ERROR - Element
'<ovirtsdk.xml.params.Network object at 0x7dd8e90>' has no attribute
'profile_required'

This issue could be reproduced by any engine in ART since we are failing on validation. It occurs because tests are using (hard-coded) Network object from data_structures.py (generated from api.xsd by generateDS.py).

However ART validation of structure of api responce is done vs networkType object (cloudInit one). It happens because ART is using ClassesMapping in order to know which which object should be chosen.

So in this case, because of double declaration of Network entity, ClassesMapping becomes corrupted (generateDS overrides network mapping)

ART validation revealed that api has double declaration of Network object (one inside cloudInit and one in outer level).

(In reply to Ilanit Stein from comment #3)
we like the first option. The parser should handle same named entities if they are at different hierarchy level. There's nothing wrong with the XSD

For now either a quick hack to ART or disabling the test, I guess

(In reply to Michal Skrivanek from comment #6)
> (In reply to Ilanit Stein from comment #3)
> we like the first option. The parser should handle same named entities if
> they are at different hierarchy level. There's nothing wrong with the XSD
> 
> For now either a quick hack to ART or disabling the test, I guess

Michal,

xsd is wrong indeed, i've put Ori to help you out with this.

please also include this [1] fix, it's addresses issue in RSDL metadata.

[1] http://gerrit.ovirt.org/#/c/22249/

ok, bug is merged even though I think we didn't do the right, the only thing comforting me is we're going to deprecate it in next release:-)

Verified on is27. Both rest &sdk problems resolved.

Closing - RHEV 3.3 Released

Closing - RHEV 3.3 Released