On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk <alena.prokharc...@citrix.com> wrote: > On 11/11/13 2:59 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > >>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. > > Its a bug if the ACLs belong to some other user in the domain as the > regular user can see only his own resources. Can you please elaborate who > owns 24 and 26 ACLs, and who makes the call (the type of the user - domain > admin, root admin, regular user)
Test creates a domain, creates a new user in the domain, lists ACLs as that user. ACLs from other domains and accounts are seen (all ACLs, as far as I can tell). > >> >>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. > > > Not a bug. If it was the other way around - duplicated rules were allowed, > and now we block it - then it would have been a bug because your DB might > already have duplicated records prior to update. > With the new way ACLs are implemented, you can set the priority for the > rule. Once the rule with the highest priority is hit, the rest of the > rules are not being processed. You can read the FS to understand how the > feature works. Kishan, can you point Marcus to the spec. Yes, please. This sounds as though someone may create a rule for 22-80, and another for 80-443, and only one of the rules will work (the one with priority). That would cause confusion as far as understanding why a rule isn't working. I'll see if I can dig it up on my own as well. > > >> >>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? >>> >>> >> > >
