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?
