cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: api incompatibility between 4.1 and 4.2 in ACLs
Date Mon, 11 Nov 2013 23:34:00 GMT
On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
<Alena.Prokharchyk@citrix.com> wrote:
> On 11/11/13 2:59 PM, "Marcus Sorensen" <shadowsor@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.Prokharchyk@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 <shadowsor@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.Kavala@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:shadowsor@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.chaturvedi@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.chaturvedi@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:shadowsor@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
>>>>> > <shadowsor@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?
>>>
>>>
>>
>
>

Mime
View raw message