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-java | Assignee: | Juan Hernández <juan.hernandez> | |
| Status: | CLOSED ERRATA | QA Contact: | Meni Yakove <myakove> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 3.4.0 | CC: | 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
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? (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 ? 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.
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.
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.
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?
(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 ? (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) 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. 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. This fix is contained in rhevm-sdk-java-3.5.0.0-1.el6_5, already available in brew. 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 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 |