Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Sun, Apr 9, 2017 at 1:27 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
> > Le 9 avr. 2017 à 11:25, Yaniv Kaul  a écrit :
> >
>
> > However, I tend to agree with closing the bug - I'd create a library
> (module) *on top of the SDK* . The comment in the bug is quite clear about
> it:
> > "The objective of the SDK is to offer the same that the API offers,
> without the burden of the details of the HTTP and XML handling. Nothing
> less, and nothing more."
>
> Then don't call it a SDK, they are barely helper functions with bad design
> decisions, connection.vms_service().vm_service(id) is nothing else than
> redundancy and bring nothing else than noise.
>

http://www.ovirt.org/community/about/community-guidelines/#be-respectful

Y.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 9 avr. 2017 à 11:25, Yaniv Kaul  a écrit :
> 

> However, I tend to agree with closing the bug - I'd create a library (module) 
> *on top of the SDK* . The comment in the bug is quite clear about it:
> "The objective of the SDK is to offer the same that the API offers, without 
> the burden of the details of the HTTP and XML handling. Nothing less, and 
> nothing more."

Then don't call it a SDK, they are barely helper functions with bad design 
decisions, connection.vms_service().vm_service(id) is nothing else than 
redundancy and bring nothing else than noise. 




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Sun, Apr 9, 2017 at 12:14 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
> Le 6 avr. 2017 à 17:21, Ondra Machacek  a écrit :
>
>
>
> On Thu, Apr 6, 2017 at 5:00 PM, Fabrice Bacchella <
> fabrice.bacche...@orange.fr> wrote:
>
>> Ho my good, in ovirtsdk.services.py, for every service, there is a
>> different method with a different name that return a associated service, so
>> it's not possible to have a generic like:
>>
>> def  resolve(service, ...):
>> id = .
>> return service.service(id)
>>
>> because the generic call service is used by something that take a path
>> argument. But why not a service_by_id(self, id) ?
>>
>
> I am not fully sure I understand what you are missing, but feel free to
> open
> the bug on Python SDK in bugzilla, we will be happy to improve the SDK.
>
>
> I tried :
> https://bugzilla.redhat.com/show_bug.cgi?id=1439879
>
> I hit a wall. it seems that some of you are not willing to improve the SDK.
>

That's the beauty of open source.  You can help improving the SDK, instead
just complaining. Patches are welcome.

However, I tend to agree with closing the bug - I'd create a library
(module) *on top of the SDK* . The comment in the bug is quite clear about
it:
"The objective of the SDK is to offer the same that the API offers, without
the burden of the details of the HTTP and XML handling. Nothing less, and
nothing more."

So improving the SDK where we do not feel it should be improved, may not be
the best path.

Y.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Oved Ourfali]

Hi Fabrice,

I think you got proper explanation from Juan.
I think you should indeed consider whether to use the sdk or not, depending
on whether it fits your needs.

Regards,
Oved



On Apr 9, 2017 12:14, "Fabrice Bacchella" 
wrote:


Le 6 avr. 2017 à 17:21, Ondra Machacek  a écrit :



On Thu, Apr 6, 2017 at 5:00 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> Ho my good, in ovirtsdk.services.py, for every service, there is a
> different method with a different name that return a associated service, so
> it's not possible to have a generic like:
>
> def  resolve(service, ...):
> id = .
> return service.service(id)
>
> because the generic call service is used by something that take a path
> argument. But why not a service_by_id(self, id) ?
>

I am not fully sure I understand what you are missing, but feel free to open
the bug on Python SDK in bugzilla, we will be happy to improve the SDK.


I tried :
https://bugzilla.redhat.com/show_bug.cgi?id=1439879

I hit a wall. it seems that some of you are not willing to improve the SDK.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 17:21, Ondra Machacek  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 5:00 PM, Fabrice Bacchella 
> > wrote:
> Ho my good, in ovirtsdk.services.py , for every 
> service, there is a different method with a different name that return a 
> associated service, so it's not possible to have a generic like:
> 
> def  resolve(service, ...):
>   id = .
>   return service.service(id)
> 
> because the generic call service is used by something that take a path 
> argument. But why not a service_by_id(self, id) ?
> 
> I am not fully sure I understand what you are missing, but feel free to open
> the bug on Python SDK in bugzilla, we will be happy to improve the SDK.

I tried :
https://bugzilla.redhat.com/show_bug.cgi?id=1439879 


I hit a wall. it seems that some of you are not willing to improve the SDK.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Thu, Apr 6, 2017 at 9:19 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
> Le 6 avr. 2017 à 20:06, Yaniv Kaul  a écrit :
>
>
>
> On Thu, Apr 6, 2017 at 5:30 PM, Fabrice Bacchella <
> fabrice.bacche...@orange.fr> wrote:
>
>>
>> > Le 6 avr. 2017 à 16:12, Yaniv Kaul  a écrit :
>>
>> > Seriously though - perhaps you could borrow code from our Ansible
>> module? See[1].
>> >
>>
>> If the code already exists, why it's not already in the sdk instead of
>> having to dig throw external code ?
>
>
> It's a good question, which I've asked as well in the past. The reason is
> that it's above the SDK, not part of the SDK.
> But that doesn't matter - we really ought to have a module/library on top
> of the SDK,  that can be shared.
> For example, between ovirt-system-tests, Ansible, oVirtBackup[1] and
> several others who write on top of our SDK.
> We just never got to generalise it enough and split it. You are welcome to
> begin this work - I believe it has value.
> (It's also a good Google Summer of Code project - I'll see if I can update
> that page on ovirt.org).
>
>
> I have already started it for sdk3, I will need to restart if almost from
> scratch to sdk4: https://github.com/fbacchella/ovirtcmd and need to right
> a lot of very basic code.
>

Well, if you are talking about a CLI, I've started one for SDK4[1]. It
exactly suffers from what I describe above - due to lack of a library on
top of the SDK I'm quite wastefully re-writing what others (for example,
the Ansible module) have probably done already.
But other than that, and the fact I stopped the effort, it's a very cool
CLI, I encourage you to check it out and perhaps pick it and do a better
job than me.

Y.
[1] https://github.com/mykaul/ovirt4cli
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 20:06, Yaniv Kaul  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 5:30 PM, Fabrice Bacchella 
> > wrote:
> 
> > Le 6 avr. 2017 à 16:12, Yaniv Kaul  > > a écrit :
> 
> > Seriously though - perhaps you could borrow code from our Ansible module? 
> > See[1].
> >
> 
> If the code already exists, why it's not already in the sdk instead of having 
> to dig throw external code ?
> 
> It's a good question, which I've asked as well in the past. The reason is 
> that it's above the SDK, not part of the SDK.
> But that doesn't matter - we really ought to have a module/library on top of 
> the SDK,  that can be shared.
> For example, between ovirt-system-tests, Ansible, oVirtBackup[1] and several 
> others who write on top of our SDK.
> We just never got to generalise it enough and split it. You are welcome to 
> begin this work - I believe it has value.
> (It's also a good Google Summer of Code project - I'll see if I can update 
> that page on ovirt.org ).

I have already started it for sdk3, I will need to restart if almost from 
scratch to sdk4: https://github.com/fbacchella/ovirtcmd 
 and need to right a lot of very basic 
code.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 17:21, Ondra Machacek  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 5:00 PM, Fabrice Bacchella 
> > wrote:
> Ho my good, in ovirtsdk.services.py , for every 
> service, there is a different method with a different name that return a 
> associated service, so it's not possible to have a generic like:
> 
> def  resolve(service, ...):
>   id = .
>   return service.service(id)
> 
> because the generic call service is used by something that take a path 
> argument. But why not a service_by_id(self, id) ?
> 
> I am not fully sure I understand what you are missing, but feel free to open
> the bug on Python SDK in bugzilla, we will be happy to improve the SDK.
>  

Done, with a first idea for what might be needed:

https://bugzilla.redhat.com/show_bug.cgi?id=1439879 




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Thu, Apr 6, 2017 at 5:30 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
> > Le 6 avr. 2017 à 16:12, Yaniv Kaul  a écrit :
>
> > Seriously though - perhaps you could borrow code from our Ansible
> module? See[1].
> >
>
> If the code already exists, why it's not already in the sdk instead of
> having to dig throw external code ?


It's a good question, which I've asked as well in the past. The reason is
that it's above the SDK, not part of the SDK.
But that doesn't matter - we really ought to have a module/library on top
of the SDK,  that can be shared.
For example, between ovirt-system-tests, Ansible, oVirtBackup[1] and
several others who write on top of our SDK.
We just never got to generalise it enough and split it. You are welcome to
begin this work - I believe it has value.
(It's also a good Google Summer of Code project - I'll see if I can update
that page on ovirt.org).

Y.

[1] https://github.com/wefixit-AT/oVirtBackup
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Ondra Machacek]

On Thu, Apr 6, 2017 at 5:00 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> Ho my good, in ovirtsdk.services.py, for every service, there is a
> different method with a different name that return a associated service, so
> it's not possible to have a generic like:
>
> def  resolve(service, ...):
> id = .
> return service.service(id)
>
> because the generic call service is used by something that take a path
> argument. But why not a service_by_id(self, id) ?
>

I am not fully sure I understand what you are missing, but feel free to open
the bug on Python SDK in bugzilla, we will be happy to improve the SDK.


>
> grep 'def .*_service.self, id.:' site-packages/ovirtsdk4/services.py
> def vm_service(self, id):
> def group_service(self, id):
> def host_service(self, id):
> def vm_service(self, id):
> def label_service(self, id):
> def label_service(self, id):
> def profile_service(self, id):
> def profile_service(self, id):
> def network_service(self, id):
> def permission_service(self, id):
> def role_service(self, id):
> def tag_service(self, id):
> def profile_service(self, id):
> def storage_domain_service(self, id):
> def balance_service(self, id):
> def bookmark_service(self, id):
> def level_service(self, id):
> def cluster_service(self, id):
> def profile_service(self, id):
> def data_center_service(self, id):
> def attachment_service(self, id):
> def disk_profile_service(self, id):
> def snapshot_service(self, id):
> def disk_service(self, id):
> def group_service(self, id):
> def user_service(self, id):
> def domain_service(self, id):
> def event_service(self, id):
> def resource_service(self, id):
> def host_service(self, id):
> def group_service(self, id):
> def provider_service(self, id):
> def host_service(self, id):
> def certificate_service(self, id):
> def agent_service(self, id):
> def file_service(self, id):
> def filter_service(self, id):
> def brick_service(self, id):
> def hook_service(self, id):
> def volume_service(self, id):
> def group_service(self, id):
> def device_service(self, id):
> def hook_service(self, id):
> def nic_service(self, id):
> def node_service(self, id):
> def storage_service(self, id):
> def host_service(self, id):
> def icon_service(self, id):
> def image_transfer_service(self, id):
> def image_service(self, id):
> def console_service(self, id):
> def nic_service(self, id):
> def watchdog_service(self, id):
> def instance_type_service(self, id):
> def iscsi_bond_service(self, id):
> def job_service(self, id):
> def katello_erratum_service(self, id):
> def mac_pool_service(self, id):
> def attachment_service(self, id):
> def network_filter_service(self, id):
> def label_service(self, id):
> def network_service(self, id):
> def provider_service(self, id):
> def image_service(self, id):
> def provider_service(self, id):
> def network_service(self, id):
> def subnet_service(self, id):
> def key_service(self, id):
> def provider_service(self, id):
> def type_service(self, id):
> def operating_system_service(self, id):
> def permit_service(self, id):
> def qos_service(self, id):
> def limit_service(self, id):
> def limit_service(self, id):
> def quota_service(self, id):
> def role_service(self, id):
> def policy_service(self, id):
> def unit_service(self, id):
> def cdrom_service(self, id):
> def disk_service(self, id):
> def nic_service(self, id):
> def snapshot_service(self, id):
> def key_service(self, id):
> def statistic_service(self, id):
> def step_service(self, id):
> def disk_service(self, id):
> def connection_service(self, id):
> def template_service(self, id):
> def attachment_service(self, id):
> def vm_service(self, id):
> def storage_domain_service(self, id):
> def storage_connection_extension_service(self, id):
> def storage_connection_service(self, id):
> def permission_service(self, id):
> def tag_service(self, id):
> def cdrom_service(self, id):
> def attachment_service(self, id):
> def disk_service(self, id):
> def console_service(self, id):
> def nic_service(self, id):
> def watchdog_service(self, id):
> def template_service(self, id):
> def unmanaged_network_service(self, id):
> def user_service(self, id):
> def network_service(self, id):
> def application_service(self, id):
> def cdrom_service(self, id):
> def disk_service(self, id):
> def console_service(self, id):
> def device_service(self, id):
> def nic_service(self, id):
> def node_service(self, id):
> def pool_service(self, id):
> def reported_device_service(self, id):
> def session_service(self, id):
> def 

Re: [ovirt-users] SKD4

[Barak Korren]

On 6 April 2017 at 18:00, Fabrice Bacchella  wrote:
> Ho my good, in ovirtsdk.services.py, for every service, there is a different
> method with a different name that return a associated service, so it's not
> possible to have a generic like:
>
> def  resolve(service, ...):
> id = .
> return service.service(id)
>
> because the generic call service is used by something that take a path
> argument. But why not a service_by_id(self, id) ?
>
I think you can use getattr to get a generic call like you want:

With your example code:

def resolve(service, ...):
id = .
return getattr(services, service + '_service')(id)




-- 
Barak Korren
bkor...@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

Ho my good, in ovirtsdk.services.py, for every service, there is a different 
method with a different name that return a associated service, so it's not 
possible to have a generic like:

def  resolve(service, ...):
id = .
return service.service(id)

because the generic call service is used by something that take a path 
argument. But why not a service_by_id(self, id) ?

grep 'def .*_service.self, id.:' site-packages/ovirtsdk4/services.py
def vm_service(self, id):
def group_service(self, id):
def host_service(self, id):
def vm_service(self, id):
def label_service(self, id):
def label_service(self, id):
def profile_service(self, id):
def profile_service(self, id):
def network_service(self, id):
def permission_service(self, id):
def role_service(self, id):
def tag_service(self, id):
def profile_service(self, id):
def storage_domain_service(self, id):
def balance_service(self, id):
def bookmark_service(self, id):
def level_service(self, id):
def cluster_service(self, id):
def profile_service(self, id):
def data_center_service(self, id):
def attachment_service(self, id):
def disk_profile_service(self, id):
def snapshot_service(self, id):
def disk_service(self, id):
def group_service(self, id):
def user_service(self, id):
def domain_service(self, id):
def event_service(self, id):
def resource_service(self, id):
def host_service(self, id):
def group_service(self, id):
def provider_service(self, id):
def host_service(self, id):
def certificate_service(self, id):
def agent_service(self, id):
def file_service(self, id):
def filter_service(self, id):
def brick_service(self, id):
def hook_service(self, id):
def volume_service(self, id):
def group_service(self, id):
def device_service(self, id):
def hook_service(self, id):
def nic_service(self, id):
def node_service(self, id):
def storage_service(self, id):
def host_service(self, id):
def icon_service(self, id):
def image_transfer_service(self, id):
def image_service(self, id):
def console_service(self, id):
def nic_service(self, id):
def watchdog_service(self, id):
def instance_type_service(self, id):
def iscsi_bond_service(self, id):
def job_service(self, id):
def katello_erratum_service(self, id):
def mac_pool_service(self, id):
def attachment_service(self, id):
def network_filter_service(self, id):
def label_service(self, id):
def network_service(self, id):
def provider_service(self, id):
def image_service(self, id):
def provider_service(self, id):
def network_service(self, id):
def subnet_service(self, id):
def key_service(self, id):
def provider_service(self, id):
def type_service(self, id):
def operating_system_service(self, id):
def permit_service(self, id):
def qos_service(self, id):
def limit_service(self, id):
def limit_service(self, id):
def quota_service(self, id):
def role_service(self, id):
def policy_service(self, id):
def unit_service(self, id):
def cdrom_service(self, id):
def disk_service(self, id):
def nic_service(self, id):
def snapshot_service(self, id):
def key_service(self, id):
def statistic_service(self, id):
def step_service(self, id):
def disk_service(self, id):
def connection_service(self, id):
def template_service(self, id):
def attachment_service(self, id):
def vm_service(self, id):
def storage_domain_service(self, id):
def storage_connection_extension_service(self, id):
def storage_connection_service(self, id):
def permission_service(self, id):
def tag_service(self, id):
def cdrom_service(self, id):
def attachment_service(self, id):
def disk_service(self, id):
def console_service(self, id):
def nic_service(self, id):
def watchdog_service(self, id):
def template_service(self, id):
def unmanaged_network_service(self, id):
def user_service(self, id):
def network_service(self, id):
def application_service(self, id):
def cdrom_service(self, id):
def disk_service(self, id):
def console_service(self, id):
def device_service(self, id):
def nic_service(self, id):
def node_service(self, id):
def pool_service(self, id):
def reported_device_service(self, id):
def session_service(self, id):
def watchdog_service(self, id):
def vm_service(self, id):
def profile_service(self, id):
def weight_service(self, id):
def katello_erratum_service(self, id):





___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 16:12, Yaniv Kaul  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 4:49 PM, Fabrice Bacchella 
> > wrote:
> 
>> Le 6 avr. 2017 à 15:32, Yaniv Kaul > > a écrit :
>> 
>> 
>> 
>> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella 
>> > 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 ;-)

It's not about the number of LoC, it's about legibility, having code that says 
what's it's doing and doing what it says.___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 16:12, Yaniv Kaul  a écrit :

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

If the code already exists, why it's not already in the sdk instead of having 
to dig throw external code ?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Thu, Apr 6, 2017 at 5:02 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
> > Le 6 avr. 2017 à 15:47, Yaniv Kaul  a écrit :
> >
> >
>
> > Perhaps in your case. Here[1] is an example of the ovirt system tests,
> which were only partially converted (work in progress...) to v4 API.
>
> yes that really related to my use case.
>
> Another problem that I have with lack of documentation, that REST API
> documentation or samples don't provide.
>
> In python, what does vms_service.list(search='name=NotExistingVM') will
> return ? It's not stated in the REST documentation, but it's even worst in
> python.
>

You could file a bug for documentation, or better yet, contribute a patch
to it.
A patch to a basic example for negative cases would be very helpful as well.
An example of a patch[1] for the SDK examples from someone who found it is
lacking.

Let me know if I can help you with contributing the example. Start here[2]
TIA,
Y.

[1] https://gerrit.ovirt.org/#/c/75076/
[2] http://www.ovirt.org/develop/dev-process/working-with-gerrit/


> It could throw an exception, return None, or return an empty list ?
>
> If I'm using a sdk instead of direct HTTP call is not to be bothered my
> xml versus json representation, but instead find an answer to that kind of
> questions easily.
> In the sample I just find:
>
> vm = vms_service.list(search='name=myvm')[0]
>
> Not really helpfull.
>
> Is there any documentation about python exception thrown ? Or must I dig
> throw all the examples ?
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

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

>
> Le 6 avr. 2017 à 15:32, Yaniv Kaul  a écrit :
>
>
>
> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella <
> fabrice.bacche...@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
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 15:47, Yaniv Kaul  a écrit :
> 
> 

> Perhaps in your case. Here[1] is an example of the ovirt system tests, which 
> were only partially converted (work in progress...) to v4 API.

yes that really related to my use case.

Another problem that I have with lack of documentation, that REST API 
documentation or samples don't provide.

In python, what does vms_service.list(search='name=NotExistingVM') will return 
? It's not stated in the REST documentation, but it's even worst in python.

It could throw an exception, return None, or return an empty list ?

If I'm using a sdk instead of direct HTTP call is not to be bothered my xml 
versus json representation, but instead find an answer to that kind of 
questions easily.
In the sample I just find:

vm = vms_service.list(search='name=myvm')[0]

Not really helpfull.

Is there any documentation about python exception thrown ? Or must I dig throw 
all the examples ?


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 15:32, Yaniv Kaul  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella 
> > 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})



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

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

>
> Le 6 avr. 2017 à 15:32, Yaniv Kaul  a écrit :
>
>
>
> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella <
> fabrice.bacche...@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).
>
>
> Easy to write code that a well though sdk should have provided.
>

I'd like to believe our v4 SDKs are. They fix several inconsistencies we've
had with v3.


>
> Note that right now you can mix between v3 and v4, so you can migrate
> slowly, function by function.
>
>
> That's a possible but almost as complicated as rewrite everything in my
> case.
>

Perhaps in your case. Here[1] is an example of the ovirt system tests,
which were only partially converted (work in progress...) to v4 API.

HTH,
Y.

[1]
https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=blob;f=basic-suite-master/test-scenarios/002_bootstrap.py;h=c0e71df23f17335d59d9d37fcd4c833be6372c69;hb=HEAD#l109


>
>
> Another option that you can consider, if you are re-writing, is automation
> via Ansible.
> See https://github.com/ansible/ansible-modules-extras/tree/
> devel/cloud/ovirt
>
>
> A lot of people don't use ansible or use concurrent tools. So no that's
> not an option.
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

> Le 6 avr. 2017 à 15:32, Yaniv Kaul  a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella 
> > 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).

Easy to write code that a well though sdk should have provided.

> Note that right now you can mix between v3 and v4, so you can migrate slowly, 
> function by function.

That's a possible but almost as complicated as rewrite everything in my case.

> 
> 
> Another option that you can consider, if you are re-writing, is automation 
> via Ansible. 
> See https://github.com/ansible/ansible-modules-extras/tree/devel/cloud/ovirt 
>  

A lot of people don't use ansible or use concurrent tools. So no that's not an 
option.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella <
fabrice.bacche...@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).
Note that right now you can mix between v3 and v4, so you can migrate
slowly, function by function.

Another option that you can consider, if you are re-writing, is automation
via Ansible.
See https://github.com/ansible/ansible-modules-extras/tree/devel/cloud/ovirt


Y.


>
> Le 6 avr. 2017 à 14:23, Yaniv Kaul  a écrit :
>
> There is documentation online (and within the project).
> See http://ovirt.github.io/ovirt-engine-api-model/master/
>
> There are tens of examples in the RPM (and online).
> See https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples
>
> HTH,
> Y.
>
> On Thu, Apr 6, 2017 at 12:22 PM, Fabrice Bacchella <
> fabrice.bacche...@orange.fr> wrote:
>
>> I trying to migrate my python code from sdk3 to sdk4, is there any
>> migration doc, documentation help about that ? Even google is unable to
>> find anything relevant about that.
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Fabrice Bacchella]

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.


> Le 6 avr. 2017 à 14:23, Yaniv Kaul  a écrit :
> 
> There is documentation online (and within the project).
> See http://ovirt.github.io/ovirt-engine-api-model/master/ 
> 
> 
> There are tens of examples in the RPM (and online).
> See https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples 
> 
> 
> HTH,
> Y.
> 
> On Thu, Apr 6, 2017 at 12:22 PM, Fabrice Bacchella 
> > wrote:
> I trying to migrate my python code from sdk3 to sdk4, is there any migration 
> doc, documentation help about that ? Even google is unable to find anything 
> relevant about that.
> 
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] SKD4

[Yaniv Kaul]

There is documentation online (and within the project).
See http://ovirt.github.io/ovirt-engine-api-model/master/

There are tens of examples in the RPM (and online).
See https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples

HTH,
Y.

On Thu, Apr 6, 2017 at 12:22 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> I trying to migrate my python code from sdk3 to sdk4, is there any
> migration doc, documentation help about that ? Even google is unable to
> find anything relevant about that.
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] SKD4

[Fabrice Bacchella]

I trying to migrate my python code from sdk3 to sdk4, is there any migration 
doc, documentation help about that ? Even google is unable to find anything 
relevant about that.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users