Description of problem: In Python SDK: net.get_labels().get() accept ['id', 'name'] In Java SDK: net.get_labels().get() accept ['id']
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