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 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
