Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2
Just to clarify. Wido, the issue you are experiencing is only with basic networks and also exists in 4.9 right? The issue becomes noticeable when you have a lot of networks. Is that a fair statement? On May 9, 2017 5:39 PM, "Wido den Hollander" wrote: > +0 > > I don't want to VOTE -1 due to a bug we are facing, but for us 4.10 would > be a problem due to the VR performance. > > A PR is open for this, but I also don't want to delay 4.10 any longer: > https://github.com/apache/cloudstack/pull/2089 > > Technically the VR works, it is just that deployment is utterly slow. > > Wido > > > Op 9 mei 2017 om 7:31 schreef Rajani Karuturi : > > > > > > Hi All, > > > > I've created a 4.10.0.0 release, with the following artifacts up for a > vote: > > > > Git Branch and Commit SH: > > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h= > fadc80d50f9e95012c9ff3644b60b600c6f65204 > > Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204 > > Branch: 4.10.0.0-RC20170509T1030 > > > > Source release (checksums and signatures are available at the same > > location): > > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/ > > > > PGP release keys (signed using CBB44821): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > Vote will be open for 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) > > > > ~Rajani > > http://cloudplatform.accelerite.com/ >
Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2
+0 I don't want to VOTE -1 due to a bug we are facing, but for us 4.10 would be a problem due to the VR performance. A PR is open for this, but I also don't want to delay 4.10 any longer: https://github.com/apache/cloudstack/pull/2089 Technically the VR works, it is just that deployment is utterly slow. Wido > Op 9 mei 2017 om 7:31 schreef Rajani Karuturi : > > > Hi All, > > I've created a 4.10.0.0 release, with the following artifacts up for a vote: > > Git Branch and Commit SH: > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=commit;h=fadc80d50f9e95012c9ff3644b60b600c6f65204 > Commit:fadc80d50f9e95012c9ff3644b60b600c6f65204 > Branch: 4.10.0.0-RC20170509T1030 > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/ > > PGP release keys (signed using CBB44821): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > Vote will be open for 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) > > ~Rajani > http://cloudplatform.accelerite.com/
Re: [PROPOSAL] Separate creation and backup operations for a volume snapshot
Harika Punna wrote: > > Currently, Volume Snapshots in Cloudstack take considerable amount of > time to complete as snapshot involves creation on primary and backup on > secondary. I would like to introduce an optional parameter in > CreateSnapshotCmd API to separate these operations. > > > More details in the FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Separate+creation+and+backup+operations+for+a+volume+snapshot > > > Thanks, > Harika. Hello Harika. There was a related discussion around a global configuration parameter snapshot.backup.rightafter See the thread here: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 And here is the PR where this was merged into 4.9: https://github.com/apache/cloudstack/pull/1697 This is distinct from what you propose, and I like the idea of being able to specify whether or not to back up at snapshot creation time, versus only having a global configuration parameter. Also one remaining issue with the current implementation of snapshots and backups is that if the snapshot.backup.rightafter parameter is set to false, on doing certain operations with snapshots (create template from snapshot iirc, perhaps some others) it will then need to take the backup to secondary at that time, and it will be very slow. I think at some point you have to take that hit, so maybe there is no way around this. But that brings me to a followup point: since the PR was merged above, ACS will backup on-demand any snapshots that need to be on secondary that only exist on primary. it would be nice to also have an optional cleanup thread and an expiration of backups to secondary. Or maybe API endpoints that would allow some external management of backups. What do you think? Nathan Johnson R&D Engineer Education Networks of America
Re: [PROPOSAL] branch on first RC and open up master for features
As far as I remember only 4.4 and the commercial 3.x series were releases that way. On 09/05/17 08:25, "Erik Weber" wrote: On Mon, May 8, 2017 at 10:40 AM, Daan Hoogland wrote: > LS, > > In a lot of occasions, we have seen new features that are waiting for releases with blocker bugs and while these bugs certainly must be solved, users that are not hindered by those bugs directly are stopped by them. Therefore, I propose we will fork on the first RC branches for future releases, so that development is not stopped for it. If the release process takes too long and to nice features get merged in between we can always decide to re-branch before releasing. I might be misunderstanding, but isn't your proposal more or less how we used to do releases back in the day? -- Erik daan.hoogl...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
