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 <[email protected]> wrote: > Actually use this link to the message in that thread http://s.apache.org/QKI > > > >> -----Original Message----- >> From: Animesh Chaturvedi [mailto:[email protected]] >> Sent: Friday, November 08, 2013 11:24 AM >> To: [email protected] >> 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:[email protected]] >> > Sent: Friday, November 08, 2013 9:13 AM >> > To: [email protected] >> > 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 <[email protected]> >> > 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?
