On 11/11/13 3:34 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
>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). Sounds like a security bug to me. Kishan, can you take a look pls? > >> >>> >>>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? >>>> >>>> >>> >> >> >
