On Thu, Apr 6, 2017 at 4:49 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:

Le 6 avr. 2017 à 15:32, Yaniv Kaul <ykaul@redhat.com> a écrit :



On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Yes I'm starting to understand that thinking about migrating code is pointless.

The old skd3 code is just good to be thrown away. There is no hope thinking about "migrating code". And as it's just a thin layer around REST calls, it's up to us to try to make something usable around that. So I expect a lot of sweat and tears to adapt my existing code.

Well, yes and no. Yes, it's not smooth, but once you 'get' the idea behind the v4 API philosophy, it's quite easy to write to (at least in Python).

An example of code that I'm unhappy to write and that a good sdk should have provided:

searchfilter = "%s=%s" % (type, value)
vm = vms_service.list(search= searchfilter)[0]

instead of :
vms_service.list(search= {type: value})[0]

or even better:
vms_service.get(**{type: value})


Yes, I see what you mean. 100% more LoC are currently needed vs. your idea ;-)

Seriously though - perhaps you could borrow code from our Ansible module? See[1].

Y.

[1] https://github.com/ansible/ansible/blob/699df5824d36dab5cb46b3f7c63e8992bd778b27/lib/ansible/module_utils/ovirt.py#L220