On 05/12/13 4:17 pm, "David Nalley" wrote:
>
>While in a perfect world we wouldn't have any schema changes two
>things jump out at me in this case.
>
>1. We have precedent in doing schema changes in bugfix (both 4.0.1 and
>4.1.1 had some schema changes)
>2. We already have some schema changes in 4
On Wed, Dec 4, 2013 at 11:09 PM, Marcus Sorensen wrote:
> Yes, a schema fix in point release is kind of messy. If it has to be
> that way then perhaps we just flag it in the known issues so people
> can skip 4.2.x if they utilize the acls api calls.
>
> 5214 doesn't really require a schema change
>>
>>enance release we will like to avoid schema
>> changes as much as possible.
>
>it sounds like a pretty big issue IMHO, if not even a security risk.
Schema changes are bit messy in a maintenance release as it will require
changes to upgrade script etc.
We can put the fix in 4.3 and document t
Yes, a schema fix in point release is kind of messy. If it has to be
that way then perhaps we just flag it in the known issues so people
can skip 4.2.x if they utilize the acls api calls.
5214 doesn't really require a schema change, just a fix to how the
schema is upgraded. Adding 'IF NOT EXISTS'
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
wro
On Dec 4, 2013, at 4:33 AM, Abhinandan Prateek
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 releas
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 tem
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 hund
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 wrote:
> On Tue, Dec 3, 2013 at 7:48 AM, sebgoa wrote:
>>
>> Can you be more specific ? what fixes required a re-vote ?
>
> There was
On Tue, Dec 3, 2013 at 7:48 AM, sebgoa 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.
I'm going to vote -1 on this one. I think
https://issues.apache.org/jira/browse/CLOUDSTACK-5145 should be
addressed as cloudstack is leaking data from users to other users who
don't own the data. The data isn't extremely sensitive, it only gives
away vpc ids that you don't own and acl information (
On Dec 3, 2013, at 1:24 PM, Abhinandan Prateek
wrote:
> Hi All,
>
>There were some issues found in the 4.2.1 RC that was earlier approved by
> voters.
> As a result the RC has to be re-spun. There is not much of a difference
> between this and the one approved earlier apart from some add
Hi All,
There were some issues found in the 4.2.1 RC that was earlier approved by
voters.
As a result the RC has to be re-spun. There is not much of a difference between
this and the one approved earlier apart from some additional fixes.
The current vote is to approve the current RC buil
13 matches
Mail list logo
