[VOTE] Apache Cloudstack 4.10.0.0 - RC2

[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: Re: [PROPOSAL] branch on first RC and open up master for features

[Will Stevens]

Thank you for getting this through your lab too Haijiao.  :)

*Will Stevens*
CTO



On Mon, May 8, 2017 at 10:50 PM, Haijiao <18602198...@163.com> wrote:

> Hi, Rajani, Will and Community
>
>
> Yes, we just finished the test in our lab.  We confirmed the latest PR
> 2062# has fixed the known issues about VPN disconnection due to any network
> change including VPN account add/delete.
>
>
> I will update the result in PR 2062# and I think it can be merged now.
>
>
> Thanks for your effort,  good job !
>
>
>
>
> 在2017年05月09 10时04分, "Rajani Karuturi"写道:
>
> It's waiting on test update from haijiao
>
> ~Rajani
>
> Sent from phone.
>
> On 8 May 2017 8:05 p.m., "Will Stevens"  wrote:
>
> > https://github.com/apache/cloudstack/pull/2062 should be ready to
> merge, I
> > think I had that one ready a couple weeks ago.
> >
> > *Will Stevens*
> > CTO
> >
> > 
> >
> > On Mon, May 8, 2017 at 9:53 AM, Simon Weller  wrote:
> >
> > > The only PR that is currently showing in blocker status is :
> > > https://github.com/apache/cloudstack/pull/2062
> > >
> > > Are there others that should be tagged?
> > >
> > >
> > > - Si
> > >
> > >
> > > 
> > > From: Rohit Yadav 
> > > Sent: Monday, May 8, 2017 6:43 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> > features
> > >
> > > Rajani,
> > >
> > >
> > > Can we have a list of outstanding blockers/issues?
> > >
> > >
> > > I also saw some enhancement PRs merged, which I think we should be
> > > avoiding and instead have our resources spent on fixing the release
> > > blockers, thanks.
> > >
> > >
> > > Regards.
> > >
> > > 
> > > From: Rajani Karuturi 
> > > Sent: 08 May 2017 16:20:01
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> > features
> > >
> > > I disagree. The release process is taking long because we dont
> > > have enough people working on the release. Sometimes, even the
> > > blockers don't get enough attention. There is no point in adding
> > > features on already broken/blocked master which is not
> > > releasable. "un-freezing" master for new features shouldn't be
> > > the goal in my opinion. We should move towards faster
> > > releases/release cycles.
> > >
> > > Thanks,
> > >
> > > ~ Rajani
> > >
> > > http://cloudplatform.accelerite.com/
> > >
> > > On May 8, 2017 at 2:11 PM, Daan Hoogland
> > > (daan.hoogl...@shapeblue.com) 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.
> > >
> > > Thoughts..?
> > > Daan
> > >
> > > daan.hoogl...@shapeblue.com
> > > www.shapeblue.com ( http://www.shapeblue.com
> )
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
>

Re:Re: [PROPOSAL] branch on first RC and open up master for features

[Haijiao]

Hi, Rajani, Will and Community


Yes, we just finished the test in our lab.  We confirmed the latest PR 2062# 
has fixed the known issues about VPN disconnection due to any network change 
including VPN account add/delete.


I will update the result in PR 2062# and I think it can be merged now.


Thanks for your effort,  good job !




在2017年05月09 10时04分, "Rajani Karuturi"写道:

It's waiting on test update from haijiao

~Rajani

Sent from phone.

On 8 May 2017 8:05 p.m., "Will Stevens"  wrote:

> https://github.com/apache/cloudstack/pull/2062 should be ready to merge, I
> think I had that one ready a couple weeks ago.
>
> *Will Stevens*
> CTO
>
> 
>
> On Mon, May 8, 2017 at 9:53 AM, Simon Weller  wrote:
>
> > The only PR that is currently showing in blocker status is :
> > https://github.com/apache/cloudstack/pull/2062
> >
> > Are there others that should be tagged?
> >
> >
> > - Si
> >
> >
> > 
> > From: Rohit Yadav 
> > Sent: Monday, May 8, 2017 6:43 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> features
> >
> > Rajani,
> >
> >
> > Can we have a list of outstanding blockers/issues?
> >
> >
> > I also saw some enhancement PRs merged, which I think we should be
> > avoiding and instead have our resources spent on fixing the release
> > blockers, thanks.
> >
> >
> > Regards.
> >
> > 
> > From: Rajani Karuturi 
> > Sent: 08 May 2017 16:20:01
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> features
> >
> > I disagree. The release process is taking long because we dont
> > have enough people working on the release. Sometimes, even the
> > blockers don't get enough attention. There is no point in adding
> > features on already broken/blocked master which is not
> > releasable. "un-freezing" master for new features shouldn't be
> > the goal in my opinion. We should move towards faster
> > releases/release cycles.
> >
> > Thanks,
> >
> > ~ Rajani
> >
> > http://cloudplatform.accelerite.com/
> >
> > On May 8, 2017 at 2:11 PM, Daan Hoogland
> > (daan.hoogl...@shapeblue.com) 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.
> >
> > Thoughts..?
> > Daan
> >
> > daan.hoogl...@shapeblue.com
> > www.shapeblue.com ( http://www.shapeblue.com )
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>

Re: [PROPOSAL] branch on first RC and open up master for features

[Rajani Karuturi]

Yes. That's the only blocker. Once it's merged, I will create rc2

~Rajani

Sent from phone.

On 8 May 2017 7:24 p.m., "Simon Weller"  wrote:

> The only PR that is currently showing in blocker status is :
> https://github.com/apache/cloudstack/pull/2062
>
> Are there others that should be tagged?
>
>
> - Si
>
>
> 
> From: Rohit Yadav 
> Sent: Monday, May 8, 2017 6:43 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] branch on first RC and open up master for features
>
> Rajani,
>
>
> Can we have a list of outstanding blockers/issues?
>
>
> I also saw some enhancement PRs merged, which I think we should be
> avoiding and instead have our resources spent on fixing the release
> blockers, thanks.
>
>
> Regards.
>
> 
> From: Rajani Karuturi 
> Sent: 08 May 2017 16:20:01
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] branch on first RC and open up master for features
>
> I disagree. The release process is taking long because we dont
> have enough people working on the release. Sometimes, even the
> blockers don't get enough attention. There is no point in adding
> features on already broken/blocked master which is not
> releasable. "un-freezing" master for new features shouldn't be
> the goal in my opinion. We should move towards faster
> releases/release cycles.
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 8, 2017 at 2:11 PM, Daan Hoogland
> (daan.hoogl...@shapeblue.com) 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.
>
> Thoughts..?
> Daan
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: [PROPOSAL] branch on first RC and open up master for features

[Rajani Karuturi]

It's waiting on test update from haijiao

~Rajani

Sent from phone.

On 8 May 2017 8:05 p.m., "Will Stevens"  wrote:

> https://github.com/apache/cloudstack/pull/2062 should be ready to merge, I
> think I had that one ready a couple weeks ago.
>
> *Will Stevens*
> CTO
>
> 
>
> On Mon, May 8, 2017 at 9:53 AM, Simon Weller  wrote:
>
> > The only PR that is currently showing in blocker status is :
> > https://github.com/apache/cloudstack/pull/2062
> >
> > Are there others that should be tagged?
> >
> >
> > - Si
> >
> >
> > 
> > From: Rohit Yadav 
> > Sent: Monday, May 8, 2017 6:43 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> features
> >
> > Rajani,
> >
> >
> > Can we have a list of outstanding blockers/issues?
> >
> >
> > I also saw some enhancement PRs merged, which I think we should be
> > avoiding and instead have our resources spent on fixing the release
> > blockers, thanks.
> >
> >
> > Regards.
> >
> > 
> > From: Rajani Karuturi 
> > Sent: 08 May 2017 16:20:01
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] branch on first RC and open up master for
> features
> >
> > I disagree. The release process is taking long because we dont
> > have enough people working on the release. Sometimes, even the
> > blockers don't get enough attention. There is no point in adding
> > features on already broken/blocked master which is not
> > releasable. "un-freezing" master for new features shouldn't be
> > the goal in my opinion. We should move towards faster
> > releases/release cycles.
> >
> > Thanks,
> >
> > ~ Rajani
> >
> > http://cloudplatform.accelerite.com/
> >
> > On May 8, 2017 at 2:11 PM, Daan Hoogland
> > (daan.hoogl...@shapeblue.com) 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.
> >
> > Thoughts..?
> > Daan
> >
> > daan.hoogl...@shapeblue.com
> > www.shapeblue.com ( http://www.shapeblue.com )
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>

Re: [PROPOSAL] branch on first RC and open up master for features

[Rajani Karuturi]

All the PRs are tagged with milestone 4.10.0.0 and label Blocker

~Rajani

Sent from phone.

On 8 May 2017 5:14 p.m., "Rohit Yadav"  wrote:

> Rajani,
>
>
> Can we have a list of outstanding blockers/issues?
>
>
> I also saw some enhancement PRs merged, which I think we should be
> avoiding and instead have our resources spent on fixing the release
> blockers, thanks.
>
>
> Regards.
>
> 
> From: Rajani Karuturi 
> Sent: 08 May 2017 16:20:01
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] branch on first RC and open up master for features
>
> I disagree. The release process is taking long because we dont
> have enough people working on the release. Sometimes, even the
> blockers don't get enough attention. There is no point in adding
> features on already broken/blocked master which is not
> releasable. "un-freezing" master for new features shouldn't be
> the goal in my opinion. We should move towards faster
> releases/release cycles.
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 8, 2017 at 2:11 PM, Daan Hoogland
> (daan.hoogl...@shapeblue.com) 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.
>
> Thoughts..?
> Daan
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: GSoC'17

[Syed Ahmed]

Point taken Sverrir,

The current focus is to put the NoVNC implementation along side the
existing ajax based implementation so that it doesn't break existing
functionality. RDP will still be supported via the traditional way and
maybe we can add RDP using other third party libs like
http://cedrozor.github.io/myrtille/ in the future.

Thanks,
-Syed


On Mon, May 8, 2017 at 1:14 AM, Daan Hoogland 
wrote:

> Have fun Sachin,
>
> May you come up with the most flexible, extensible, pluggable,
> configurable addition to our project ever ;)
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> On 05/05/17 17:49, "sachin patil"  wrote:
>
> Hello all,
>
>I have been selected for GSoC'17 and would be working on
> CloudStack-9778  >(
>  Adding a new NoVNC console ).
>
> The aim of this feature is to make it possible to connect to VM
> consoles
> using  VNC client called NoVNC in browsers.
>
> NoVNC console is better than our current customized console. Additional
> features that NoVNC provides over the current customized console
> include a
> copy/paste functionality, scrollback. NoVNC uses websockets that
> provides a
> more reliable and secure connections.
>
> My proposal can be found here
> https://docs.google.com/document/d/1IqJiZ_
> sJZktAoPjdQePoinBNZzPboR1jCkUXBpqanjo/edit
>
> I have been selected for this project with my mentors Rohit Yadav and
> Syed
> Ahmed.
>
> Would like to know about your thoughts/ideas on this project.
>
> Regards,
> Sachin Patil
>
>
>

Re: Very slow Virtual Router provisioning with 4.9.2.0

[Wido den Hollander]

Hi,

To conclude, after doing a lot of work in debugging we were able to reduce the 
deployment of our VRs from ~2 hours to ~5 MINUTES.

Two PRs are open for this against the 4.9 branch:

- https://github.com/apache/cloudstack/pull/2077
- https://github.com/apache/cloudstack/pull/2089

The problem was that in Basic Networking each VR would get ALL DHCP information 
instead of just the information for that POD (PR 2077).

The other issue is that for each entry dnsmasq and Apache would be restarted 
combined with some other things. By delaying this to the end of the provision 
of the router we save a lot of time.

Both PRs are running in production on our cloud in Basic Networking with a few 
thousands Instances behind it. No problems found so far.

Wido

> Op 2 mei 2017 om 19:57 schreef Wido den Hollander :
> 
> 
> Hi,
> 
> Last night I upgraded a CloudStack 4.5.2 setup to 4.9.2.0. All went well, but 
> the VR provisioning is terribly slow which causes all kinds of problems.
> 
> The vr_cfg.sh and update_config.py scripts start to run. Restart dnsmasq, add 
> metadata, etc.
> 
> But for just 1800 hosts this can take up to 2 hours and that causes timeouts 
> in the management server and other problems.
> 
> 2 hours is just very, very slow. So I am starting to wonder if something is 
> wrong here.
> 
> Did anybody else see this?
> 
> Running Basic Networking with CloudStack 4.9.2.0
> 
> Wido

Re: [PROPOSAL] branch on first RC and open up master for features

[Will Stevens]

https://github.com/apache/cloudstack/pull/2062 should be ready to merge, I
think I had that one ready a couple weeks ago.

*Will Stevens*
CTO



On Mon, May 8, 2017 at 9:53 AM, Simon Weller  wrote:

> The only PR that is currently showing in blocker status is :
> https://github.com/apache/cloudstack/pull/2062
>
> Are there others that should be tagged?
>
>
> - Si
>
>
> 
> From: Rohit Yadav 
> Sent: Monday, May 8, 2017 6:43 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] branch on first RC and open up master for features
>
> Rajani,
>
>
> Can we have a list of outstanding blockers/issues?
>
>
> I also saw some enhancement PRs merged, which I think we should be
> avoiding and instead have our resources spent on fixing the release
> blockers, thanks.
>
>
> Regards.
>
> 
> From: Rajani Karuturi 
> Sent: 08 May 2017 16:20:01
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] branch on first RC and open up master for features
>
> I disagree. The release process is taking long because we dont
> have enough people working on the release. Sometimes, even the
> blockers don't get enough attention. There is no point in adding
> features on already broken/blocked master which is not
> releasable. "un-freezing" master for new features shouldn't be
> the goal in my opinion. We should move towards faster
> releases/release cycles.
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 8, 2017 at 2:11 PM, Daan Hoogland
> (daan.hoogl...@shapeblue.com) 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.
>
> Thoughts..?
> Daan
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: [PROPOSAL] branch on first RC and open up master for features

[Simon Weller]

The only PR that is currently showing in blocker status is : 
https://github.com/apache/cloudstack/pull/2062

Are there others that should be tagged?


- Si



From: Rohit Yadav 
Sent: Monday, May 8, 2017 6:43 AM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] branch on first RC and open up master for features

Rajani,


Can we have a list of outstanding blockers/issues?


I also saw some enhancement PRs merged, which I think we should be avoiding and 
instead have our resources spent on fixing the release blockers, thanks.


Regards.


From: Rajani Karuturi 
Sent: 08 May 2017 16:20:01
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] branch on first RC and open up master for features

I disagree. The release process is taking long because we dont
have enough people working on the release. Sometimes, even the
blockers don't get enough attention. There is no point in adding
features on already broken/blocked master which is not
releasable. "un-freezing" master for new features shouldn't be
the goal in my opinion. We should move towards faster
releases/release cycles.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 8, 2017 at 2:11 PM, Daan Hoogland
(daan.hoogl...@shapeblue.com) 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.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com
www.shapeblue.com ( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

Re: [PROPOSAL] branch on first RC and open up master for features

[Rohit Yadav]

Rajani,


Can we have a list of outstanding blockers/issues?


I also saw some enhancement PRs merged, which I think we should be avoiding and 
instead have our resources spent on fixing the release blockers, thanks.


Regards.


From: Rajani Karuturi 
Sent: 08 May 2017 16:20:01
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] branch on first RC and open up master for features

I disagree. The release process is taking long because we dont
have enough people working on the release. Sometimes, even the
blockers don't get enough attention. There is no point in adding
features on already broken/blocked master which is not
releasable. "un-freezing" master for new features shouldn't be
the goal in my opinion. We should move towards faster
releases/release cycles.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 8, 2017 at 2:11 PM, Daan Hoogland
(daan.hoogl...@shapeblue.com) 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.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com
www.shapeblue.com ( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [PROPOSAL] branch on first RC and open up master for features

[Rene Moser]

I am +1

Even though git is distributed, the github workflow (PRs) has some scale
limitations. Having a lots of small PRs can lead into a maintenance hell
for keeping them mergeable.

One way around it is to either have a "next"-branch or branch of master.
Either way, branching is required. Since we have a lot of integration
running on master, it is a far less expensive to branch of master
instead of having a "next" branch.

I would rather see devs working on bug fixing and features than merge
conflicts.

René

Re: [PROPOSAL] branch on first RC and open up master for features

[Daan Hoogland]

But these two points of attention are not mutually exclusive, are they?

On 08/05/17 12:50, "Rajani Karuturi"  wrote:

I disagree. The release process is taking long because we dont
have enough people working on the release. Sometimes, even the
blockers don't get enough attention. There is no point in adding
features on already broken/blocked master which is not
releasable. "un-freezing" master for new features shouldn't be
the goal in my opinion. We should move towards faster
releases/release cycles.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 8, 2017 at 2:11 PM, Daan Hoogland
(daan.hoogl...@shapeblue.com) 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.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com
www.shapeblue.com ( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue


daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [PROPOSAL] branch on first RC and open up master for features

[Rajani Karuturi]

I disagree. The release process is taking long because we dont
have enough people working on the release. Sometimes, even the
blockers don't get enough attention. There is no point in adding
features on already broken/blocked master which is not
releasable. "un-freezing" master for new features shouldn't be
the goal in my opinion. We should move towards faster
releases/release cycles.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 8, 2017 at 2:11 PM, Daan Hoogland
(daan.hoogl...@shapeblue.com) 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.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com
www.shapeblue.com ( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

[PROPOSAL] branch on first RC and open up master for features

[Daan Hoogland]

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.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

[PROPOSAL] Separate creation and backup operations for a volume snapshot

[Harika Punna]

Hi All,



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.




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.