Sorry for the back and forth, I'm interfacing with individuals who consume our CloudStack environment. I'm being told that the issues actually aren't related to API parameters, but behavior of the API calls:
1) As a user, listing network ACLs now shows ALL ACLs, not just the ones you own. An example test that was shown to me created a new user, listed ACLs, then created two ACLs and listed again. Previously, the result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand new user sees all ACLs. 2) Test case used to succeed by failing when duplicate or overlapping ACLs were created. Now, they're allowed. I have yet to duplicate this and see if it causes problems for virtual routers. I'll try to confirm/duplicate and create JIRA issues for these if I don't get a response back from someone explaining/validating the new behavior. On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > Marcus, if any of the CS API command(s) return the error for > parameter/parameter combination that used to work before, then it means APIs > are incompatible, and it has to be fixed. > Thank you for looking into it. > > -Alena. > > From: Marcus Sorensen <shadow...@gmail.com> > Reply-To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> > Date: Monday, November 11, 2013 1:10 PM > To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> > > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs > > Ok, I'll dig deeper into it. Our api's ACL tests are breaking against 4.2. > > On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala > <kishan.kav...@citrix.com> wrote: > > Marcus, > aclid is optional when creating a networlACL. In 4.1, networkId is > mandatory for creating ACL. So, when networkId is specified instead of aclid > in 4.2, CS gets the aclList associated with the network and adds acl to it. > So, API doesn't break if the aclid is not specified. > > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Saturday, 9 November 2013 1:13 AM > To: dev@cloudstack.apache.org > Cc: Kishan Kavala > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs > > Yes, that would certainly maintain api compatibility if one creates an ACL > without specifying aclid, it creates a new list and applies it to the given > network. > > On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi > <animesh.chaturv...@citrix.com> wrote: >> Actually use this link to the message in that thread >> http://s.apache.org/QKI >> >> >> >>> -----Original Message----- >>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >>> Sent: Friday, November 08, 2013 11:24 AM >>> To: dev@cloudstack.apache.org >>> Cc: Kishan Kavala >>> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs >>> >>> >>> I will let Kishan comment but found this thread >>> http://markmail.org/thread/fxzki6ftqacyrylk >>> >>> >>> > -----Original Message----- >>> > From: Marcus Sorensen [mailto:shadow...@gmail.com] >>> > Sent: Friday, November 08, 2013 9:13 AM >>> > To: dev@cloudstack.apache.org >>> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs >>> > >>> > So I take the silence to simply be a collective "oops". I guess >>> > this just should serve as a reminder to not break API compatibility >>> > without a discussion. Perhaps our tests will surface this better in >>> > the future (although I need to look, I wonder if any ACL tests were >>> > also simply changed to accomodate the new behavior). >>> > >>> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen >>> > <shadow...@gmail.com> >>> > wrote: >>> > > Maybe this has been discussed already, but we seem to have run >>> > > into an api incompatibility. In 4.1, you could create ad-hoc ACL >>> > > rules that applied to a network. In 4.2, you have to first create >>> > > an 'ACL list', then add those rules to the list, then apply the >>> > > list to a network. Or so it seems. This means that applications >>> > > that are coded to the cloudstack API and utilize createNetworkACL >>> > > will break, because the flow has changed. >>> > > >>> > > Am I correct on this? And if so, shouldn't we have deployed 4.2 >>> > > as 5.0, since the stated versioning is based on API compatibility? > >
