Re: inconsistent listXXX API behaviors
Yiping, those differences are historically grown and then kept for backwards compatibility. The page Stephen mentions is a placeholder for changes to be executed when upping our major version number. If you have any additions please put them there. (you need to register and ask for access, but that is no biggy) On Mon, Jan 12, 2015 at 12:25 PM, Stephen Turner stephen.tur...@citrix.com wrote: There is a page on the wiki about inconsistencies in the list* APIs: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes. But I don't think it mentions this particular problem. -- Stephen Turner -Original Message- From: Yiping Zhang [mailto:yzh...@marketo.com] Sent: 09 January 2015 20:45 To: dev@cloudstack.apache.org Subject: inconsistent listXXX API behaviors Hi, all We have noticed some behavior differences among various listXXX API calls as shown bellow: When using listZones API with name=xxx argument, the returned zone's name must be an exact match for the given argument value. In this example, zone name must be exactly xxx for it to be returned by this call. When using listPods API with name=pod argument, all pods whose name ends with pod will be returned by this call. For example, pods with name as my_pod, my_2nd_pod and new_pod will all be returned. In other words, in these this API call, the name match is a sub string match, not exact string match, with given argument value. The API listClusters behaves the same way as listPods. Are the different behavior among these API calls intentional? If so what are the rationales for the differences ? If the different behavior is due to bugs in implementations, then there are over 100 listXXX type API calls whose behavior needs to be reviewed to see how many of them show buggy behaviors. Thanks Yiping -- Daan
RE: inconsistent listXXX API behaviors
There is a page on the wiki about inconsistencies in the list* APIs: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes. But I don't think it mentions this particular problem. -- Stephen Turner -Original Message- From: Yiping Zhang [mailto:yzh...@marketo.com] Sent: 09 January 2015 20:45 To: dev@cloudstack.apache.org Subject: inconsistent listXXX API behaviors Hi, all We have noticed some behavior differences among various listXXX API calls as shown bellow: When using listZones API with name=xxx argument, the returned zone's name must be an exact match for the given argument value. In this example, zone name must be exactly xxx for it to be returned by this call. When using listPods API with name=pod argument, all pods whose name ends with pod will be returned by this call. For example, pods with name as my_pod, my_2nd_pod and new_pod will all be returned. In other words, in these this API call, the name match is a sub string match, not exact string match, with given argument value. The API listClusters behaves the same way as listPods. Are the different behavior among these API calls intentional? If so what are the rationales for the differences ? If the different behavior is due to bugs in implementations, then there are over 100 listXXX type API calls whose behavior needs to be reviewed to see how many of them show buggy behaviors. Thanks Yiping
inconsistent listXXX API behaviors
Hi, all We have noticed some behavior differences among various listXXX API calls as shown bellow: When using listZones API with “name=xxx” argument, the returned zone’s name must be an exact match for the given argument value. In this example, zone name must be exactly “xxx” for it to be returned by this call. When using listPods API with “name=pod” argument, all pods whose name ends with “pod” will be returned by this call. For example, pods with name as “my_pod”, “my_2nd_pod” and “new_pod” will all be returned. In other words, in these this API call, the name match is a sub string match, not exact string match, with given argument value. The API listClusters behaves the same way as listPods. Are the different behavior among these API calls intentional? If so what are the rationales for the differences ? If the different behavior is due to bugs in implementations, then there are over 100 listXXX type API calls whose behavior needs to be reviewed to see how many of them show buggy behaviors. Thanks Yiping
