Bug 1099818

Summary: [Python/Java SDK]Network labels get_labels().get() accept diffarent parameters for Python and Java SDK
Product: Red Hat Enterprise Virtualization Manager Reporter: Meni Yakove <myakove>
Component: ovirt-engine-sdk-javaAssignee: Juan Hernández <juan.hernandez>
Status: CLOSED ERRATA QA Contact: Meni Yakove <myakove>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.4.0CC: aberezin, gklein, iheim, iliam, juan.hernandez, juwu, masayag, myakove, nyechiel, oramraz, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: AutomationBlocker, ZStream
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: rhevm-sdk-java-3.5.0.0-1.el6_5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1101425 (view as bug list) Environment:
Last Closed: 2015-02-11 18:11:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1101425, 1142923, 1156165    

Description Meni Yakove 2014-05-21 09:30:32 UTC
Description of problem:
In Python SDK:
net.get_labels().get() accept ['id', 'name']
In Java SDK:
net.get_labels().get() accept ['id']

Comment 1 Juan Hernández 2014-05-21 09:52:14 UTC
This is currently a limitation of the Java SDK, it doesn't support getting entities by name, not only for network labels, but for all collections.

How does it block automation?

Comment 2 Moti Asayag 2014-05-21 11:25:47 UTC
(In reply to Juan Hernández from comment #1)
> This is currently a limitation of the Java SDK, it doesn't support getting
> entities by name, not only for network labels, but for all collections.
> 
> How does it block automation?

I doesn't suppose to block any use-case regarding labels, since labels are identified by id only.

Is there an option to omit the name from the label under the network in python sdk ?

Comment 3 Juan Hernández 2014-05-21 11:43:08 UTC
I see now that we have another issue here: the generator of the Java SDK assumes that identifiers of entities are UUIDs, and the "get" method receives a Java UUID class as the parameter:

  public NetworkLabel get(UUID id) throws ClientProtocolException {
    ... 
  }

But network labels don't use UUIDs as identifiers, they use arbitrary strings. This means that there is no way to get a network label by id in the Java SDK.

Comment 4 Ilia Meerovich 2014-05-21 12:01:36 UTC
Juan,

1. It breaks convention (all other get methods accepts only id).
   I can adjust ART java sdk backend to handle it but I think that it not a good 
   idea to break convention...
2. It is automation blocker. 
   - Our tests are api agnostic. So in such case Network  
     team cannot test label feature with java sdk.

Comment 5 Juan Hernández 2014-05-21 12:05:10 UTC
Looking at this deeper I see that we actually have support to get elements by name, in the base CollectionDecorator class:

  public Z get(String name) throws ClientProtocolException {
    ...
  }

So this should work for any collection where the elements have names. It won't work for labels however, as they don't have names, only ids.

Comment 6 Juan Hernández 2014-05-21 12:21:59 UTC
So, to summarize, the solution to this issue should be to have a method that allows retrieving a network label from the corresponding collection specifying the identifier as a string, not as a UUID. This should be done not only for network labes, but for all collections, as any entity could have an id that isn't a string. We can't override the "get" method for this, as the meaning of "get" that receives a string is "get by name", so we will need to add a new method:

  NetworkLabel getById(String id) {
  }

Is this acceptable?

Comment 7 Moti Asayag 2014-05-21 13:36:13 UTC
(In reply to Juan Hernández from comment #6)
> So, to summarize, the solution to this issue should be to have a method that
> allows retrieving a network label from the corresponding collection
> specifying the identifier as a string, not as a UUID. This should be done
> not only for network labes, but for all collections, as any entity could
> have an id that isn't a string. We can't override the "get" method for this,
> as the meaning of "get" that receives a string is "get by name", so we will
> need to add a new method:
> 
>   NetworkLabel getById(String id) {
>   }
> 
> Is this acceptable?

Shouldn't it be added to org.ovirt.engine.sdk.entities.Label as:

Label getById(String id) {
...
}

For the sake of NetworkLabel, HostNICLabel and DataCenterNetworkLabel which faces the same issue ?

Comment 8 Ilia Meerovich 2014-05-21 13:44:30 UTC
(In reply to Juan Hernández from comment #6)
> So, to summarize, the solution to this issue should be to have a method that
> allows retrieving a network label from the corresponding collection
> specifying the identifier as a string, not as a UUID. This should be done
> not only for network labes, but for all collections, as any entity could
> have an id that isn't a string. We can't override the "get" method for this,
> as the meaning of "get" that receives a string is "get by name", so we will
> need to add a new method:
> 
>   NetworkLabel getById(String id) {
>   }
> 
> Is this acceptable?

Do you suggest to add:
get_by_id method to all collections in python sdk
getById method to all collections in java sdk

So 'get' that exists now will be actually get_by_name (without renaming it due to backward compatibility)

Comment 9 Juan Hernández 2014-05-21 13:52:31 UTC
No, no change in the Python SDK as it already has a single "get" method that can take both the "name" and "id" parameters.

In the Java SDK we currently have two methods:

  NetworkLabel get(String name)  <-- This means "get by name"
  NetworkLabel get(UUID id)  <-- This means "get by id"

We can't remove any of these methods, and we can't add a new "get" method that receives a string and that means "get by name", as that isn't possible in Java. The alternative I propose is to add this:

  NetworkLabel getById(String id)

Only in the Java SDK.

Comment 10 Juan Hernández 2014-05-22 16:01:56 UTC
This bug is now fixed in upstream releases 3.4.1.2, and packages are available here:

  http://jhernand.fedorapeople.org/rpms/ovirt-engine-sdk-java/3.4.1.2-1

The downstream fix for 3.5 will be done when we have downstream 3.5 branches and we do the rebase from upstream.

Comment 12 Juan Hernández 2014-07-03 15:15:03 UTC
This fix is contained in rhevm-sdk-java-3.5.0.0-1.el6_5, already available in brew.

Comment 14 Julie 2014-11-19 01:12:28 UTC
Hi Juan,
If this bug requires doc text for errata release, please provide draft text in the following format:
Cause: 
Consequence: 
Fix: 
Result: 
The documentation team will review, edit, and approve the text. 
If this bug does not require doc text, please set the 'requires_doc_text' flag to -.

Please do so for all your bugs in the advisory.

Cheers,
Julie

Comment 16 errata-xmlrpc 2015-02-11 18:11:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0184.html