Kishan, weren't we supposed to create a default ACL container (list) and assign the rule to it, if no ACL list is passed to the call? Shouldn't be hard to fix
From: Animesh Chaturvedi <animesh.chaturv...@citrix.com<mailto:animesh.chaturv...@citrix.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Friday, November 8, 2013 11:23 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Cc: Kishan Kavala <kishan.kav...@citrix.com<mailto:kishan.kav...@citrix.com>> 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<mailto: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<mailto: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?
