You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Boris Schrijver <bo...@pcextreme.nl> on 2015/12/16 08:34:14 UTC
Re: [VOTE] Apache CloudStack 4.7.0
Hi all,
Hereby my vote for the ACS 4.7.0 RC 1
Details:
Vote: +1
Besides the integration tests (which all ran fine) I've also tested the
following:
- S3 Integration (Secondary Storage) with NFS Staging store
- Ceph RBD storage (Primary Storage)
- Basic networking with security groups
--
Met vriendelijke groet / Kind regards,
Boris Schrijver
PCextreme B.V.
http://www.pcextreme.nl/contact
Tel direct: +31 (0) 118 700 215
> On December 16, 2015 at 12:34 AM Remi Bergsma <RB...@schubergphilis.com>
> wrote:
>
>
> +1 (binding)
>
> This vote is based on testing on a real cloud.
>
> At Schuberg Philis we built a new cloud based on ACS 4.7.0RC1 (upgraded from
> 4.6). It runs XenServer 6.5 clusters, a CentOS 7 management cluster, Galera DB
> (also on CentOS 7), HA proxies (CentOS 7), NFS storage and Nicira/NSX for
> networking/SDN. Capacity to start with is about 12TB ram and 500+ cores.
> Secondary storage is an S3 compatible solution (Cloudian) with NFS staging
> store. Configured LDAP for authentication.
>
> Before a go-live we always do thorough testing and try to break the setup
> emulating crashes and problems.
>
> We successful executed these CloudStack related tests:
>
> * crashed a hypervisor which was poolmaster and saw recovery in about 5
> min (tested with/without returning of the hypervisor)
> * crashed a hypervisor which was NOT poolmaster and saw recovery in about
> 5 min (tested with/without returning of the hypervisor)
> * crashed overbooked hypervisor in a cluster with too many VMs to run on
> the remaining hypervisors. Saw it recovered fully when crashed hypervisor
> returned. (this you don’t want to happen, but at least the recovery was
> automatic)
> * crashed one of the app servers; the other one continued and took over.
> No user impact.
> * crashed the main Galera DB node, the two remaining nodes survived and
> kept working. No CloudStack impact.
> * did performance tests and walked into the default 200mbps limit on
> tiers. When we removed it (aka configured it properly) we could use full
> 10gbps.
> * crashed the NFS staging store, could not deploy VM from template that
> was not already on primary storage. Recovered automatically when NFS returned
> and VM was started.
> * many functional tests, also covered In the integration tests (spin many
> VMs, migrate, make port forwardings etc).
> * executed patch round (live migrating vms around), rebooting all
> hypervisors without user impact.
>
> Conclusion:
> It’s pretty solid, even with one management server and a degraded database we
> could still continue and operate existing VMs and start new ones. When the
> nodes returned recovery was automatic.
> We feel confident running production with Apache CloudStack 4.7 and will start
> doing so later today!
>
> Regards,
> Remi
>
> PS:
> The integration tests we run in the dev/test environments were also successful
> (the same I executed on the PRs that were merged).
>
>
>
> From: Remi Bergsma
> <RB...@schubergphilis.com>>
> Date: Sunday 13 December 2015 21:27
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> <de...@cloudstack.apache.org>>
> Subject: [VOTE] Apache CloudStack 4.7.0
>
> Hi all,
>
> Since our 4.6.0 release (on Nov 13th, exactly 1 month ago), we have merged
> 100+ pull requests [1] with lots of bug fixes, refactoring and of course new
> features. Time for a new release!
>
>
> I've created a 4.7.0 release candidate, with the following artifacts up for a
> vote:
>
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=4.7.0-RC20151213T2109
>
> Commit: 2f26a859a971a9852ed9f6f34fe35e52fe6028a9
>
> Source release (checksums and signatures are available at the same location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.7.0/
>
> PGP release keys (signed using A47DDC4F):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for at least 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to indicate
> "(binding)" with their vote?
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> [1] git log --pretty=oneline --abbrev-commit origin/4.6..4.7.0-RC20151213T2109
> | grep "Merge pull request"
>
Re: [VOTE] Apache CloudStack 4.7.0
Posted by Stephan Seitz <s....@secretresearchfacility.com>.
Hi devs,
could someone please test VR in advanced networking? In detail: adding
>=10 public IPs and adding >=5 firewall and portforwarding rules to
each of the IPs.
I've noticed that each single call into the VR updates and verifies the
whole set of rules. I don't know if this was introduced around 4.5 or
if I just hit an edgecase recently. Using more than a few IPs/rules is
not only really time consuming, in case of a network/VR restart it also
leads to a VR shutdown (maybe some watchdog kicks in after a timeout).
Thanks, and sorry that I don't have enough ressources this year to
check this on my own.
Stephan
Am Mittwoch, den 16.12.2015, 08:34 +0100 schrieb Boris Schrijver:
> Hi all,
>
> Hereby my vote for the ACS 4.7.0 RC 1
>
> Details:
>
> Vote: +1
>
> Besides the integration tests (which all ran fine) I've also tested
> the
> following:
>
> - S3 Integration (Secondary Storage) with NFS Staging store
> - Ceph RBD storage (Primary Storage)
> - Basic networking with security groups
>
> --
>
> Met vriendelijke groet / Kind regards,
>
> Boris Schrijver
>
> PCextreme B.V.
>
> http://www.pcextreme.nl/contact
> Tel direct: +31 (0) 118 700 215
>
> > On December 16, 2015 at 12:34 AM Remi Bergsma <
> > RBergsma@schubergphilis.com>
> > wrote:
> >
> >
> > +1 (binding)
> >
> > This vote is based on testing on a real cloud.
> >
> > At Schuberg Philis we built a new cloud based on ACS 4.7.0RC1
> > (upgraded from
> > 4.6). It runs XenServer 6.5 clusters, a CentOS 7 management
> > cluster, Galera DB
> > (also on CentOS 7), HA proxies (CentOS 7), NFS storage and
> > Nicira/NSX for
> > networking/SDN. Capacity to start with is about 12TB ram and 500+
> > cores.
> > Secondary storage is an S3 compatible solution (Cloudian) with NFS
> > staging
> > store. Configured LDAP for authentication.
> >
> > Before a go-live we always do thorough testing and try to break the
> > setup
> > emulating crashes and problems.
> >
> > We successful executed these CloudStack related tests:
> >
> > * crashed a hypervisor which was poolmaster and saw recovery in
> > about 5
> > min (tested with/without returning of the hypervisor)
> > * crashed a hypervisor which was NOT poolmaster and saw
> > recovery in about
> > 5 min (tested with/without returning of the hypervisor)
> > * crashed overbooked hypervisor in a cluster with too many VMs
> > to run on
> > the remaining hypervisors. Saw it recovered fully when crashed
> > hypervisor
> > returned. (this you don’t want to happen, but at least the recovery
> > was
> > automatic)
> > * crashed one of the app servers; the other one continued and
> > took over.
> > No user impact.
> > * crashed the main Galera DB node, the two remaining nodes
> > survived and
> > kept working. No CloudStack impact.
> > * did performance tests and walked into the default 200mbps
> > limit on
> > tiers. When we removed it (aka configured it properly) we could use
> > full
> > 10gbps.
> > * crashed the NFS staging store, could not deploy VM from
> > template that
> > was not already on primary storage. Recovered automatically when
> > NFS returned
> > and VM was started.
> > * many functional tests, also covered In the integration tests
> > (spin many
> > VMs, migrate, make port forwardings etc).
> > * executed patch round (live migrating vms around), rebooting
> > all
> > hypervisors without user impact.
> >
> > Conclusion:
> > It’s pretty solid, even with one management server and a degraded
> > database we
> > could still continue and operate existing VMs and start new ones.
> > When the
> > nodes returned recovery was automatic.
> > We feel confident running production with Apache CloudStack 4.7 and
> > will start
> > doing so later today!
> >
> > Regards,
> > Remi
> >
> > PS:
> > The integration tests we run in the dev/test environments were also
> > successful
> > (the same I executed on the PRs that were merged).
> >
> >
> >
> > From: Remi Bergsma
> > <RB...@schubergphilis.com>>
> > Date: Sunday 13 December 2015 21:27
> > To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
> > <de...@cloudstack.apache.org>>
> > Subject: [VOTE] Apache CloudStack 4.7.0
> >
> > Hi all,
> >
> > Since our 4.6.0 release (on Nov 13th, exactly 1 month ago), we have
> > merged
> > 100+ pull requests [1] with lots of bug fixes, refactoring and of
> > course new
> > features. Time for a new release!
> >
> >
> > I've created a 4.7.0 release candidate, with the following
> > artifacts up for a
> > vote:
> >
> > Git Branch and Commit SH:
> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog
> > ;h=4.7.0-RC20151213T2109
> >
> > Commit: 2f26a859a971a9852ed9f6f34fe35e52fe6028a9
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.7.0/
> >
> > PGP release keys (signed using A47DDC4F):
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> > Vote will be open for at least 72 hours.
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> > indicate
> > "(binding)" with their vote?
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> >
> > [1] git log --pretty=oneline --abbrev-commit origin/4.6..4.7.0
> > -RC20151213T2109
> > > grep "Merge pull request"
> >
Re: [VOTE] Apache CloudStack 4.7.0
Posted by Wido den Hollander <wi...@widodh.nl>.
Vote: +1
See more below
On 16-12-15 08:34, Boris Schrijver wrote:
> Hi all,
>
> Hereby my vote for the ACS 4.7.0 RC 1
>
> Details:
>
> Vote: +1
>
> Besides the integration tests (which all ran fine) I've also tested the
> following:
>
> - S3 Integration (Secondary Storage) with NFS Staging store
> - Ceph RBD storage (Primary Storage)
There is a known issue with 4.7.0:
https://issues.apache.org/jira/browse/CLOUDSTACK-8302
This issue however also exists in ALL previous versions and there is a
outstanding PR for this: https://github.com/apache/cloudstack/pull/1230
Since this issue has been there for a long time I don't consider it as a
blocker.
Wido
> - Basic networking with security groups
>
> --
>
> Met vriendelijke groet / Kind regards,
>
> Boris Schrijver
>
> PCextreme B.V.
>
> http://www.pcextreme.nl/contact
> Tel direct: +31 (0) 118 700 215
>
>> On December 16, 2015 at 12:34 AM Remi Bergsma <RB...@schubergphilis.com>
>> wrote:
>>
>>
>> +1 (binding)
>>
>> This vote is based on testing on a real cloud.
>>
>> At Schuberg Philis we built a new cloud based on ACS 4.7.0RC1 (upgraded from
>> 4.6). It runs XenServer 6.5 clusters, a CentOS 7 management cluster, Galera DB
>> (also on CentOS 7), HA proxies (CentOS 7), NFS storage and Nicira/NSX for
>> networking/SDN. Capacity to start with is about 12TB ram and 500+ cores.
>> Secondary storage is an S3 compatible solution (Cloudian) with NFS staging
>> store. Configured LDAP for authentication.
>>
>> Before a go-live we always do thorough testing and try to break the setup
>> emulating crashes and problems.
>>
>> We successful executed these CloudStack related tests:
>>
>> * crashed a hypervisor which was poolmaster and saw recovery in about 5
>> min (tested with/without returning of the hypervisor)
>> * crashed a hypervisor which was NOT poolmaster and saw recovery in about
>> 5 min (tested with/without returning of the hypervisor)
>> * crashed overbooked hypervisor in a cluster with too many VMs to run on
>> the remaining hypervisors. Saw it recovered fully when crashed hypervisor
>> returned. (this you don’t want to happen, but at least the recovery was
>> automatic)
>> * crashed one of the app servers; the other one continued and took over.
>> No user impact.
>> * crashed the main Galera DB node, the two remaining nodes survived and
>> kept working. No CloudStack impact.
>> * did performance tests and walked into the default 200mbps limit on
>> tiers. When we removed it (aka configured it properly) we could use full
>> 10gbps.
>> * crashed the NFS staging store, could not deploy VM from template that
>> was not already on primary storage. Recovered automatically when NFS returned
>> and VM was started.
>> * many functional tests, also covered In the integration tests (spin many
>> VMs, migrate, make port forwardings etc).
>> * executed patch round (live migrating vms around), rebooting all
>> hypervisors without user impact.
>>
>> Conclusion:
>> It’s pretty solid, even with one management server and a degraded database we
>> could still continue and operate existing VMs and start new ones. When the
>> nodes returned recovery was automatic.
>> We feel confident running production with Apache CloudStack 4.7 and will start
>> doing so later today!
>>
>> Regards,
>> Remi
>>
>> PS:
>> The integration tests we run in the dev/test environments were also successful
>> (the same I executed on the PRs that were merged).
>>
>>
>>
>> From: Remi Bergsma
>> <RB...@schubergphilis.com>>
>> Date: Sunday 13 December 2015 21:27
>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>> <de...@cloudstack.apache.org>>
>> Subject: [VOTE] Apache CloudStack 4.7.0
>>
>> Hi all,
>>
>> Since our 4.6.0 release (on Nov 13th, exactly 1 month ago), we have merged
>> 100+ pull requests [1] with lots of bug fixes, refactoring and of course new
>> features. Time for a new release!
>>
>>
>> I've created a 4.7.0 release candidate, with the following artifacts up for a
>> vote:
>>
>> Git Branch and Commit SH:
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=4.7.0-RC20151213T2109
>>
>> Commit: 2f26a859a971a9852ed9f6f34fe35e52fe6028a9
>>
>> Source release (checksums and signatures are available at the same location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.7.0/
>>
>> PGP release keys (signed using A47DDC4F):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>
>> Vote will be open for at least 72 hours.
>>
>> For sanity in tallying the vote, can PMC members please be sure to indicate
>> "(binding)" with their vote?
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>>
>> [1] git log --pretty=oneline --abbrev-commit origin/4.6..4.7.0-RC20151213T2109
>> | grep "Merge pull request"
>>