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?
