Yes, that's right. I'm not sure I understand how the daos work and how
a join would work to do this sort of lookup. At first glance the
SearchBuilder join method seems to have some magic parameters, strings
like 'networkJoin' and 'tagSearch'.

On Wed, Dec 4, 2013 at 2:33 AM, Abhinandan Prateek
<abhinandan.prat...@citrix.com> wrote:
> Was trying to understand the issue. It seems there is no account
> information in network_acl or network_acl_item table.
> A proper fix will mean including that information and that means schema
> change. Since this is a maintenance release we will like to avoid schema
> changes as much as possible.
>
> A temporary fix (i.e. Till we fix schema in next big release) could mean
> fetching vpc list for a user from vpc table and then use the vpc ids to
> get the acls. *Marcus* you want to try out this fix ?
>
> -abhi
>
> On 04/12/13 3:28 am, "Marcus Sorensen" <shadow...@gmail.com> wrote:
>
>>Running the same API call on versions lower than 4.2.0 yields correct
>>results, since 4.2.0 the API call returns incorrect data. The API
>>itself is compatible, but for example if an application or user
>>consuming the API makes those calls it will get incorrect data. For
>>example, you now may get a hundred entries for port 22 open to
>>0.0.0.0/0 in your response, when only one of them is owned by you.
>>
>>On Tue, Dec 3, 2013 at 2:48 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>>wrote:
>>> H Marcus,
>>>
>>> It breaks behavior of the API, you say. Is this in comparison to 4.2
>>> or to prior versions?
>>>
>>> thanks,
>>> Daan
>>>
>>> On Tue, Dec 3, 2013 at 6:40 PM, Chip Childers <chipchild...@apache.org>
>>>wrote:
>>>> On Tue, Dec 3, 2013 at 7:48 AM, sebgoa <run...@gmail.com> wrote:
>>>>>
>>>>> Can you be more specific ? what fixes required a re-vote ?
>>>>
>>>> There was a security vulnerability reported in the release of
>>>> sufficient severity to cause the security team to request Abhi hold
>>>> off on publishing the release and to re-spin.
>

Reply via email to