On 05/12/13 4:17 pm, David Nalley da...@gnsa.us 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
On Wed, Dec 4, 2013 at 11:09 PM, Marcus Sorensen shadow...@gmail.com 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
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
On Dec 4, 2013, at 4: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
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
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 this as
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
On Dec 3, 2013, at 1:24 PM, Abhinandan Prateek abhinandan.prat...@citrix.com
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
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 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
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
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
12 matches
Mail list logo
