Description of problem: The class ovirtsdk.infrastructure.brokers.VersionCaps is unusable. I'm using it with api.capabilities.get(id='332e3633-2e36-332e-3633-2e36332e3633'). I'm testing it with the following code: capa = api.capabilities.get(id='332e3633-2e36-332e-3633-2e36332e3633') for k in dir(capa): v = getattr(capa, k) if k.startswith("get_"): try: print "%s %s" %(k, v()) except: print "%s BROKEN" % (k) The result is: get_actions None get_architecture_capabilities BROKEN get_authentication_methods BROKEN get_boot_devices BROKEN get_boot_protocols BROKEN get_brick_states BROKEN get_build None get_class_obj_ BROKEN get_comment None get_configuration_types BROKEN get_content_types BROKEN get_cpu_modes BROKEN get_cpus BROKEN get_creation_states BROKEN get_creation_status None get_current BROKEN get_custom_properties BROKEN get_data_center_states BROKEN get_description None get_disk_formats BROKEN get_disk_interfaces BROKEN get_disk_states BROKEN get_disk_storage_types BROKEN get_display_disconnect_actions BROKEN get_display_types BROKEN get_error_handling BROKEN get_extensiontype_ None get_external_statuses BROKEN get_features BROKEN get_fence_types BROKEN get_full_version None get_gluster_volume_states BROKEN get_gluster_volume_types BROKEN get_graphics_types BROKEN get_hook_states BROKEN get_host_nic_states BROKEN get_host_non_operational_details BROKEN get_host_protocols BROKEN get_host_states BROKEN get_href /api/capabilities/332e3633-2e36-332e-3633-2e36332e3633 get_id 332e3633-2e36-332e-3633-2e36332e3633 get_inheritable_booleans BROKEN get_ip_versions BROKEN get_kdump_states BROKEN get_link [] get_major 3 get_message_broker_types BROKEN get_minor 6 get_name None get_network_plugin_types BROKEN get_network_states BROKEN get_nfs_versions BROKEN get_nic_interfaces BROKEN get_os_types BROKEN get_path_ BROKEN get_path_list_ BROKEN get_payload_encodings BROKEN get_permits BROKEN get_pm_proxy_types BROKEN get_power_management_states BROKEN get_power_managers BROKEN get_qos_types BROKEN get_quota_mode_types BROKEN get_reported_device_types BROKEN get_revision None get_rng_sources BROKEN get_scheduling_policies BROKEN get_scheduling_policy_unit_types BROKEN get_selinux_modes BROKEN get_serial_number_policies BROKEN get_sgio_options BROKEN get_snapshot_statuses BROKEN get_spm_states BROKEN get_sso_methods BROKEN get_stages BROKEN get_step_types BROKEN get_storage_domain_states BROKEN get_storage_domain_types BROKEN get_storage_formats BROKEN get_storage_types BROKEN get_template_states BROKEN get_transport_types BROKEN get_usages BROKEN get_vm_affinities BROKEN get_vm_device_types BROKEN get_vm_pause_details BROKEN get_vm_pool_types BROKEN get_vm_states BROKEN get_vm_types BROKEN get_watchdog_actions BROKEN get_watchdog_models BROKEN A lot of getter, but almost all of them are unusable. Why are they here ?
There is a problem with the way we decide what is the Python type returned by capabilties.get(id=...), we assume that it is "Version" when it should be "VersionCaps". This doesn't happen with the capabilities.list() method, so you can use it as a workaround: # Retrieve the capabilities for all versions, and select the one # that we need: capa = None for version in api.capabilities.list(): if version.get_major() == 3 and version.get_minor() == 6: capa = version break # Use the capabilities selected in the previous step: for k in dir(capa): v = getattr(capa, k) if k.startswith("get_"): try: print "%s %s" %(k, v()) except: print "%s BROKEN" % (k) Note that you will still be getting some BROKEN lines, because some "get_" generateDS.py built-in methods like "get_class_obj_" can't be invoked with "v()", as they require additional arguments. As there is a workaround, and the capabilities resource will be replaced by enumerated types in version 4 of the SDK, I'm in favor of closing as WONTFIX. Is that OK?
I don't agree. You still have a api.capabilities.get that is broken. Do you expect every developper using this API to find this bug and read the work around ?
Yes, I do expect developers using the SDK to search and report in bugzilla when they have an issue, like you did. That is why I took the time to investigate the issue and to provide a workaround. The question now is if it is worth to invest additional time to do the fix, when there is a workaround and the capabilities won't exist in the future. I'm my opinion it isn't worth. As this seems important for you I will dedicate additional time to evaluate how much effort is needed, then I will make a decision.