Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Simon Weller]

Great, nice work!





From: Rohit Yadav <rohit.ya...@shapeblue.com>
Sent: Friday, July 7, 2017 1:04 AM
To: dev@cloudstack.apache.org
Subject: Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

Congratulations and well done!


From: Paul Angus <paul.an...@shapeblue.com>
Sent: 07 July 2017 00:15:30
To: dev@cloudstack.apache.org
Subject: RE: [RESULT][VOTE] Apache CloudStack 4.10.0.0

Well done!



Kind regards,

Paul Angus

paul.an...@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<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




-Original Message-
From: Wei ZHOU [mailto:ustcweiz...@gmail.com]
Sent: 06 July 2017 11:10
To: dev@cloudstack.apache.org
Subject: Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

nice!!

2017-07-06 11:56 GMT+02:00 Rajani Karuturi <raj...@apache.org>:

> Hi all,
>
> After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> 4 PMC + 2 non-PMC votes.
>
> +1 (PMC / binding)
> * Mike Tutkowski
> * Wido den Hollander
> * Daan Hoogland
> * Milamber
>
> +1 (non binding)
> * Kris Sterckx
> * Boris Stoyanov
>
> 0
> none
>
> -1
> none
>
> Thanks to everyone participating.
>
> I will now prepare the release announcement to go out after 24 hours
> to give the mirrors time to catch up.
>
> [1] http://markmail.org/thread/dafndhtflon4pshf
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Rohit Yadav]

Congratulations and well done!


From: Paul Angus <paul.an...@shapeblue.com>
Sent: 07 July 2017 00:15:30
To: dev@cloudstack.apache.org
Subject: RE: [RESULT][VOTE] Apache CloudStack 4.10.0.0

Well done!



Kind regards,

Paul Angus

paul.an...@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
  
 


-Original Message-
From: Wei ZHOU [mailto:ustcweiz...@gmail.com]
Sent: 06 July 2017 11:10
To: dev@cloudstack.apache.org
Subject: Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

nice!!

2017-07-06 11:56 GMT+02:00 Rajani Karuturi <raj...@apache.org>:

> Hi all,
>
> After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> 4 PMC + 2 non-PMC votes.
>
> +1 (PMC / binding)
> * Mike Tutkowski
> * Wido den Hollander
> * Daan Hoogland
> * Milamber
>
> +1 (non binding)
> * Kris Sterckx
> * Boris Stoyanov
>
> 0
> none
>
> -1
> none
>
> Thanks to everyone participating.
>
> I will now prepare the release announcement to go out after 24 hours
> to give the mirrors time to catch up.
>
> [1] http://markmail.org/thread/dafndhtflon4pshf
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Andrei Mikhailovsky]

Congratulations to everyone! Job well done!

Andrei

- Original Message -
> From: "Haijiao" <18602198...@163.com>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Thursday, 6 July, 2017 13:58:48
> Subject: Re:Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

> Finally 4.10 arrives.  True achievement of whole community !
> 
> 
> Thanks Rajani !
> 
> 
> 
> 
> 
> 
> 在2017年07月06 19时54分, "Wido den Hollander"<w...@widodh.nl>写道:
> 
> 
>> Op 6 juli 2017 om 12:09 schreef Wei ZHOU <ustcweiz...@gmail.com>:
>>
>>
>> nice!!
> 
> Indeed! Let's go for 4.11 :)
> 
> Wido
> 
>>
>> 2017-07-06 11:56 GMT+02:00 Rajani Karuturi <raj...@apache.org>:
>>
>> > Hi all,
>> >
>> > After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
>> > 4 PMC + 2 non-PMC votes.
>> >
>> > +1 (PMC / binding)
>> > * Mike Tutkowski
>> > * Wido den Hollander
>> > * Daan Hoogland
>> > * Milamber
>> >
>> > +1 (non binding)
>> > * Kris Sterckx
>> > * Boris Stoyanov
>> >
>> > 0
>> > none
>> >
>> > -1
>> > none
>> >
>> > Thanks to everyone participating.
>> >
>> > I will now prepare the release announcement to go out after 24 hours to
>> > give the mirrors time to catch up.
>> >
>> > [1] http://markmail.org/thread/dafndhtflon4pshf
>> >
>> > ~Rajani
>> > http://cloudplatform.accelerite.com/

RE: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Paul Angus]

Well done!



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Wei ZHOU [mailto:ustcweiz...@gmail.com] 
Sent: 06 July 2017 11:10
To: dev@cloudstack.apache.org
Subject: Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

nice!!

2017-07-06 11:56 GMT+02:00 Rajani Karuturi <raj...@apache.org>:

> Hi all,
>
> After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> 4 PMC + 2 non-PMC votes.
>
> +1 (PMC / binding)
> * Mike Tutkowski
> * Wido den Hollander
> * Daan Hoogland
> * Milamber
>
> +1 (non binding)
> * Kris Sterckx
> * Boris Stoyanov
>
> 0
> none
>
> -1
> none
>
> Thanks to everyone participating.
>
> I will now prepare the release announcement to go out after 24 hours 
> to give the mirrors time to catch up.
>
> [1] http://markmail.org/thread/dafndhtflon4pshf
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re:Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Haijiao]

Finally 4.10 arrives.  True achievement of whole community !


Thanks Rajani !






在2017年07月06 19时54分, "Wido den Hollander"写道:


> Op 6 juli 2017 om 12:09 schreef Wei ZHOU :
>
>
> nice!!

Indeed! Let's go for 4.11 :)

Wido

>
> 2017-07-06 11:56 GMT+02:00 Rajani Karuturi :
>
> > Hi all,
> >
> > After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> > 4 PMC + 2 non-PMC votes.
> >
> > +1 (PMC / binding)
> > * Mike Tutkowski
> > * Wido den Hollander
> > * Daan Hoogland
> > * Milamber
> >
> > +1 (non binding)
> > * Kris Sterckx
> > * Boris Stoyanov
> >
> > 0
> > none
> >
> > -1
> > none
> >
> > Thanks to everyone participating.
> >
> > I will now prepare the release announcement to go out after 24 hours to
> > give the mirrors time to catch up.
> >
> > [1] http://markmail.org/thread/dafndhtflon4pshf
> >
> > ~Rajani
> > http://cloudplatform.accelerite.com/
> >

Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Wido den Hollander]

> Op 6 juli 2017 om 12:09 schreef Wei ZHOU :
> 
> 
> nice!!

Indeed! Let's go for 4.11 :)

Wido

> 
> 2017-07-06 11:56 GMT+02:00 Rajani Karuturi :
> 
> > Hi all,
> >
> > After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> > 4 PMC + 2 non-PMC votes.
> >
> > +1 (PMC / binding)
> > * Mike Tutkowski
> > * Wido den Hollander
> > * Daan Hoogland
> > * Milamber
> >
> > +1 (non binding)
> > * Kris Sterckx
> > * Boris Stoyanov
> >
> > 0
> > none
> >
> > -1
> > none
> >
> > Thanks to everyone participating.
> >
> > I will now prepare the release announcement to go out after 24 hours to
> > give the mirrors time to catch up.
> >
> > [1] http://markmail.org/thread/dafndhtflon4pshf
> >
> > ~Rajani
> > http://cloudplatform.accelerite.com/
> >

Re: [RESULT][VOTE] Apache CloudStack 4.10.0.0

[Wei ZHOU]

nice!!

2017-07-06 11:56 GMT+02:00 Rajani Karuturi :

> Hi all,
>
> After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
> 4 PMC + 2 non-PMC votes.
>
> +1 (PMC / binding)
> * Mike Tutkowski
> * Wido den Hollander
> * Daan Hoogland
> * Milamber
>
> +1 (non binding)
> * Kris Sterckx
> * Boris Stoyanov
>
> 0
> none
>
> -1
> none
>
> Thanks to everyone participating.
>
> I will now prepare the release announcement to go out after 24 hours to
> give the mirrors time to catch up.
>
> [1] http://markmail.org/thread/dafndhtflon4pshf
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>

[RESULT][VOTE] Apache CloudStack 4.10.0.0

[Rajani Karuturi]

Hi all,

After 72 hours, the vote for CloudStack 4.10.0.0 [1] *passes* with
4 PMC + 2 non-PMC votes.

+1 (PMC / binding)
* Mike Tutkowski
* Wido den Hollander
* Daan Hoogland
* Milamber

+1 (non binding)
* Kris Sterckx
* Boris Stoyanov

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to
give the mirrors time to catch up.

[1] http://markmail.org/thread/dafndhtflon4pshf

~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Rajani Karuturi]

Thank you Mike, Wido, Kris, Boris, Daan and Milamber for voting.
I will send a results mail and will soon publish the release.

~Rajani
http://cloudplatform.accelerite.com/

On Thu, Jul 6, 2017 at 2:12 PM, Milamber  wrote:

> Hello
>
> +1 (binding)
>
> - Tested building .deb packages
> - Tested deployment with advanced network Ubuntu 16.04/KVM/NFS
>
> Milamber
>
>
> On 03/07/2017 05:52, Rajani Karuturi wrote:
>
>> Hi All,
>>
>> I've created 4.10.0.0 release with the following artifacts up for a vote:
>>
>> Git Branch and Commit SH:
>> https://github.com/apache/cloudstack/commit/9d2893d44a3c3a48
>> 29be0964cc991272c1d13e4d
>> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
>> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC2017070
>> 3T1006
>>
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>>
>> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/
>>
>> PRs merged since RC4: #2150 and #2089
>> PRs merged since RC5: revert of #2084
>> PRs merged since RC6: #2162
>>
>> 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)
>>
>> Thanks,
>> ~Rajani
>> http://cloudplatform.accelerite.com/
>>
>>
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Milamber]

Hello

+1 (binding)

- Tested building .deb packages
- Tested deployment with advanced network Ubuntu 16.04/KVM/NFS

Milamber

On 03/07/2017 05:52, Rajani Karuturi wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084
PRs merged since RC6: #2162

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Daan Hoogland]

we need another binding vote and I know Boris way of working. I don't
have time to test myself but given Boris vote I
+1 (binding)

On Thu, Jul 6, 2017 at 9:52 AM, Boris Stoyanov
 wrote:
> +1
>
> I’ve did upgrade testing with VMWare 5.5u3, advanced zone running on CentOS 
> 6.8 from:
> 4.5 -> 4.10 rc7
> 4.6 -> 4.10 rc7
> 4.9 -> 4.10 rc7
>
> All went smooth VRs got updated to the latests version and was able to add 
> new VMs to them.
>
> Thanks,
> Boris Stoyanov
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>> On Jul 5, 2017, at 4:30 PM, Kris Sterckx  
>> wrote:
>>
>> +1 from Nuage !
>>
>> Thanks
>>
>> Kris
>>
>> On 5 July 2017 at 15:11, Wido den Hollander  wrote:
>>
>>> +1 (binding)
>>>
>>> - Tested building DEB packages
>>> - Tested deployment with Basic Networking on Ubuntu 16.04
>>> - Tested IPv6 integration in Basic Networking
>>>
 Op 3 juli 2017 om 6:52 schreef Rajani Karuturi :


 Hi All,

 I've created 4.10.0.0 release with the following artifacts up for a vote:

 Git Branch and Commit SH:
 https://github.com/apache/cloudstack/commit/
>>> 9d2893d44a3c3a4829be0964cc991272c1d13e4d
 Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
 Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
>>> RC20170703T1006

 Source release (checksums and signatures are available at the same
 location):
 https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

 SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/

 PRs merged since RC4: #2150 and #2089
 PRs merged since RC5: revert of #2084
 PRs merged since RC6: #2162

 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)

 Thanks,
 ~Rajani
 http://cloudplatform.accelerite.com/
>>>
>



-- 
Daan

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Boris Stoyanov]

+1 

I’ve did upgrade testing with VMWare 5.5u3, advanced zone running on CentOS 6.8 
from: 
4.5 -> 4.10 rc7
4.6 -> 4.10 rc7
4.9 -> 4.10 rc7

All went smooth VRs got updated to the latests version and was able to add new 
VMs to them. 

Thanks,
Boris Stoyanov


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On Jul 5, 2017, at 4:30 PM, Kris Sterckx  
> wrote:
> 
> +1 from Nuage !
> 
> Thanks
> 
> Kris
> 
> On 5 July 2017 at 15:11, Wido den Hollander  wrote:
> 
>> +1 (binding)
>> 
>> - Tested building DEB packages
>> - Tested deployment with Basic Networking on Ubuntu 16.04
>> - Tested IPv6 integration in Basic Networking
>> 
>>> Op 3 juli 2017 om 6:52 schreef Rajani Karuturi :
>>> 
>>> 
>>> Hi All,
>>> 
>>> I've created 4.10.0.0 release with the following artifacts up for a vote:
>>> 
>>> Git Branch and Commit SH:
>>> https://github.com/apache/cloudstack/commit/
>> 9d2893d44a3c3a4829be0964cc991272c1d13e4d
>>> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
>>> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
>> RC20170703T1006
>>> 
>>> Source release (checksums and signatures are available at the same
>>> location):
>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>>> 
>>> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/
>>> 
>>> PRs merged since RC4: #2150 and #2089
>>> PRs merged since RC5: revert of #2084
>>> PRs merged since RC6: #2162
>>> 
>>> 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)
>>> 
>>> Thanks,
>>> ~Rajani
>>> http://cloudplatform.accelerite.com/
>> 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Kris Sterckx]

+1 from Nuage !

Thanks

Kris

On 5 July 2017 at 15:11, Wido den Hollander  wrote:

> +1 (binding)
>
> - Tested building DEB packages
> - Tested deployment with Basic Networking on Ubuntu 16.04
> - Tested IPv6 integration in Basic Networking
>
> > Op 3 juli 2017 om 6:52 schreef Rajani Karuturi :
> >
> >
> > Hi All,
> >
> > I've created 4.10.0.0 release with the following artifacts up for a vote:
> >
> > Git Branch and Commit SH:
> > https://github.com/apache/cloudstack/commit/
> 9d2893d44a3c3a4829be0964cc991272c1d13e4d
> > Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
> > Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
> RC20170703T1006
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> >
> > SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/
> >
> > PRs merged since RC4: #2150 and #2089
> > PRs merged since RC5: revert of #2084
> > PRs merged since RC6: #2162
> >
> > 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)
> >
> > Thanks,
> > ~Rajani
> > http://cloudplatform.accelerite.com/
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Wido den Hollander]

+1 (binding)

- Tested building DEB packages
- Tested deployment with Basic Networking on Ubuntu 16.04
- Tested IPv6 integration in Basic Networking

> Op 3 juli 2017 om 6:52 schreef Rajani Karuturi :
> 
> 
> Hi All,
> 
> I've created 4.10.0.0 release with the following artifacts up for a vote:
> 
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> 
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/
> 
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
> PRs merged since RC6: #2162
> 
> 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)
> 
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Wido den Hollander]

I will test today

> Op 5 jul. 2017 om 07:13 heeft Tutkowski, Mike  het 
> volgende geschreven:
> 
> For the sake of clarity, I should say +1 (binding).
> 
>> On Jul 4, 2017, at 11:07 PM, Rajani Karuturi  wrote:
>> 
>> Thanks Mike.
>> 
>> Is anyone else testing? We need atleast 3 binding votes to create
>> the Release.
>> 
>> Thanks,
>> 
>> ~ Rajani
>> 
>> http://cloudplatform.accelerite.com/
>> 
>> On July 3, 2017 at 11:03 AM, Tutkowski, Mike
>> (mike.tutkow...@netapp.com) wrote:
>> 
>> +1
>> 
>> I examined the changes for this RC when compared to the previous
>> one and my positive vote remains.
>> 
>> On Jul 2, 2017, at 10:53 PM, Rajani Karuturi 
>> wrote:
>> 
>> Hi All,
>> 
>> I've created 4.10.0.0 release with the following artifacts up
>> for a vote:
>> 
>> Git Branch and Commit SH:
>> https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
>> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
>> Branch:
>> https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006
>> 
>> Source release (checksums and signatures are available at the
>> same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>> 
>> SystemVm Templates:
>> http://download.cloudstack.org/systemvm/4.10/RC7/
>> 
>> PRs merged since RC4: #2150 and #2089
>> PRs merged since RC5: revert of #2084
>> PRs merged since RC6: #2162
>> 
>> 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)
>> 
>> Thanks,
>> ~Rajani
>> http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Tutkowski, Mike]

For the sake of clarity, I should say +1 (binding).

> On Jul 4, 2017, at 11:07 PM, Rajani Karuturi  wrote:
> 
> Thanks Mike.
> 
> Is anyone else testing? We need atleast 3 binding votes to create
> the Release.
> 
> Thanks,
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On July 3, 2017 at 11:03 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
> 
> +1
> 
> I examined the changes for this RC when compared to the previous
> one and my positive vote remains.
> 
> On Jul 2, 2017, at 10:53 PM, Rajani Karuturi 
> wrote:
> 
> Hi All,
> 
> I've created 4.10.0.0 release with the following artifacts up
> for a vote:
> 
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Branch:
> https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006
> 
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> 
> SystemVm Templates:
> http://download.cloudstack.org/systemvm/4.10/RC7/
> 
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
> PRs merged since RC6: #2162
> 
> 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)
> 
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Rajani Karuturi]

Thanks Mike.

Is anyone else testing? We need atleast 3 binding votes to create
the Release.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On July 3, 2017 at 11:03 AM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

+1

I examined the changes for this RC when compared to the previous
one and my positive vote remains.

On Jul 2, 2017, at 10:53 PM, Rajani Karuturi 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
Branch:
https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC7/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084
PRs merged since RC6: #2162

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Tutkowski, Mike]

+1

I examined the changes for this RC when compared to the previous one and my 
positive vote remains.

> On Jul 2, 2017, at 10:53 PM, Rajani Karuturi  wrote:
> 
> Hi All,
> 
> I've created 4.10.0.0 release with the following artifacts up for a vote:
> 
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> 
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/
> 
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
> PRs merged since RC6: #2162
> 
> 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)
> 
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/

[VOTE] Apache CloudStack 4.10.0.0 RC7

[Rajani Karuturi]

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/9d2893d44a3c3a4829be0964cc991272c1d13e4d
Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170703T1006

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084
PRs merged since RC6: #2162

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Rajani Karuturi]

Yes Mike. Will create new RC an publish in few hours.

~Rajani
http://cloudplatform.accelerite.com/

On Sat, Jul 1, 2017 at 12:06 AM, Tutkowski, Mike 
wrote:

> Hi Rajani,
>
> Just checking: Was it your intention to create a new RC on Monday?
>
> Thanks!
> Mike
>
> On 6/28/17, 3:28 AM, "Rajani Karuturi"  wrote:
>
> Thanks for confirming. I will keep this RC open for two more days
> for others to test before next RC.
>
> Agree on merging PRs part. That is our release principle in
> general.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 28, 2017 at 2:51 PM, Kris Sterckx
> (kris.ster...@nuagenetworks.net) wrote:
>
> Hi Rajani,
>
> Yes we qualified that fix. Can anyone else pls also confirm.
>
> To be very clear - this is a generic issue (with native VR based
> ACS), not
> tight to Nuage at all.
>
> We should not take in new PR's when we move from RC to RC to my
> view - this
> way always new issues will pop up.
>
> Best,
>
> Kris
>
> On 28 June 2017 at 06:49, Rajani Karuturi 
> wrote:
>
> Hi Kris,
>
> Can you please apply 2162 locally and see if you are OK with the
> changes? We shouldn't be spending one RC cycle for one issue.
>
> Ideally, we should have more CIs running on PRs from different
> usage perspectives(like managed storage, nuage, basic network,
> local storage, etc.). That would help uncover issues before they
> are merged.
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 27, 2017 at 8:14 PM, Kris Sterckx
> (kris.ster...@nuagenetworks.net) wrote:
>
> Hi all,
>
> I 'm sorry for voting -1 again.
>
> Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980
>
> Caused by : https://github.com/apache/cloudstack/pull/2089
>
> Fixed by : https://github.com/apache/cloudstack/pull/2162
>
> Kris
>
> - Nuage Networks
>
> On 26 June 2017 at 18:58, Tutkowski, Mike
>  wrote:
>
> +1 (binding)
>
> I am not concerned about the code changes that went into this RC
> since the
> previous RC, so I am still happy with the amount of automated
> and manual
> testing that I performed on a previous RC.
>
> On 6/25/17, 11:07 PM, "Rajani Karuturi" 
> wrote:
>
> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up
> for a
> vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/
> 0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
> RC20170626T1011
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates:
> http://download.cloudstack.org/systemvm/4.10/RC6/
>
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
>
> 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)
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Tutkowski, Mike]

Hi Rajani,

Just checking: Was it your intention to create a new RC on Monday?

Thanks!
Mike

On 6/28/17, 3:28 AM, "Rajani Karuturi"  wrote:

Thanks for confirming. I will keep this RC open for two more days
for others to test before next RC.

Agree on merging PRs part. That is our release principle in
general.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 2:51 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi Rajani,

Yes we qualified that fix. Can anyone else pls also confirm.

To be very clear - this is a generic issue (with native VR based
ACS), not
tight to Nuage at all.

We should not take in new PR's when we move from RC to RC to my
view - this
way always new issues will pop up.

Best,

Kris

On 28 June 2017 at 06:49, Rajani Karuturi 
wrote:

Hi Kris,

Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.

Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would help uncover issues before they
are merged.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 8:14 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162

Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike
 wrote:

+1 (binding)

I am not concerned about the code changes that went into this RC
since the
previous RC, so I am still happy with the amount of automated
and manual
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi" 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a
vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/
0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
RC20170626T1011

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Rajani Karuturi]

Thanks for confirming. I will keep this RC open for two more days
for others to test before next RC.

Agree on merging PRs part. That is our release principle in
general.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 2:51 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi Rajani,

Yes we qualified that fix. Can anyone else pls also confirm.

To be very clear - this is a generic issue (with native VR based
ACS), not
tight to Nuage at all.

We should not take in new PR's when we move from RC to RC to my
view - this
way always new issues will pop up.

Best,

Kris

On 28 June 2017 at 06:49, Rajani Karuturi 
wrote:

Hi Kris,

Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.

Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would help uncover issues before they
are merged.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 8:14 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162

Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike
 wrote:

+1 (binding)

I am not concerned about the code changes that went into this RC
since the
previous RC, so I am still happy with the amount of automated
and manual
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi" 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a
vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/
0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
RC20170626T1011

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Kris Sterckx]

Hi Rajani,

Yes we qualified that fix.  Can anyone else pls also confirm.

To be very clear - this is a generic issue (with native VR based ACS), not
tight to Nuage at all.

We should not take in new PR's when we move from RC to RC to my view - this
way always new issues will pop up.

Best,

Kris

On 28 June 2017 at 06:49, Rajani Karuturi  wrote:

> Hi Kris,
>
> Can you please apply 2162 locally and see if you are OK with the
> changes? We shouldn't be spending one RC cycle for one issue.
>
> Ideally, we should have more CIs running on PRs from different
> usage perspectives(like managed storage, nuage, basic network,
> local storage, etc.). That would help uncover issues before they
> are merged.
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 27, 2017 at 8:14 PM, Kris Sterckx
> (kris.ster...@nuagenetworks.net) wrote:
>
> Hi all,
>
> I 'm sorry for voting -1 again.
>
> Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980
>
> Caused by : https://github.com/apache/cloudstack/pull/2089
>
> Fixed by : https://github.com/apache/cloudstack/pull/2162
>
> Kris
>
> - Nuage Networks
>
> On 26 June 2017 at 18:58, Tutkowski, Mike
>  wrote:
>
> +1 (binding)
>
> I am not concerned about the code changes that went into this RC
> since the
> previous RC, so I am still happy with the amount of automated
> and manual
> testing that I performed on a previous RC.
>
> On 6/25/17, 11:07 PM, "Rajani Karuturi" 
> wrote:
>
> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up
> for a
> vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/
> 0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
> RC20170626T1011
>
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates:
> http://download.cloudstack.org/systemvm/4.10/RC6/
>
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
>
> 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)
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Wido den Hollander]

> Op 28 juni 2017 om 11:10 schreef Rajani Karuturi <raj...@apache.org>:
> 
> 
> Yes, those shouldn't have been merged.  We should have released
> faster and then merged.
> 
> Lets think of it as ours and us than theirs and those.
> 

True!

So let's see if we can get 4.10 out of the door and get 4.11 out there faster.

Merge what needs to be done, test, and go for 4.11 and 4.12

We might say that we don't merge everything for 4.11 and leave a few bits for 
4.12.

Wido

> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 28, 2017 at 12:19 PM, Paul Angus
> (paul.an...@shapeblue.com) wrote:
> 
> Those new PRs should not have been merged.
> 
> Those on the mailing list should respect the process and accept
> that they will have to wait until code is unfrozen.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
> 
> -Original Message-
> From: Rajani Karuturi [mailto:raj...@apache.org]
> Sent: 28 June 2017 07:45
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
> 
> Paul,
> 
> Which shows we are not actively following RCs. That PR was a
> blocker for RC3 and was well discussed. That PR is a perfect
> example that we are not working as community to release code.
> That is a fix for a blocker which stayed open for more than 45
> days.
> 
> If you see till RC2 it was only blockers that were merged. But,
> since it has taken a lot more time to fix blockers, more PRs were
> merged on request on the mailing list(and we don't have people
> even to object it). you can think of it as a combination of two
> releases due to the time it has taken.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 28, 2017 at 12:06 PM, Paul Angus
> (paul.an...@shapeblue.com) wrote:
> 
> Rajani,
> 
> I suspect that fatigue with the 4.10 release testing that we are
> seeing is due to the time it has taken to release it. And that is
> has been caused by new code going in, which have introduced new
> bugs.
> 
> This was demonstrated in the last -1 from Kris. This change was
> merged 10 days ago.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com ) 
> ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
> 
> -Original Message-
> From: Rajani Karuturi [mailto:raj...@apache.org]
> Sent: 28 June 2017 06:14
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
> 
> We can do a release every month as long as we have enough people
> actively participating in the release process.
> 
> We have people who wants to have their code/features checked in.
> We, very clearly do not have enough people working on
> releases/blockers. How many of us are testing/voting on releases
> or PRs? We have blockers in jira, with no one to fix. We have PRs
> open for release blockers for more than a month with no one to
> test.
> 
> I would ask everyone to start testing releases/PRs and voting on
> them actively.
> 
> We need people who can do the work. We already know what needs
> to be done as outlined in the release principles wiki after long
> discussions on this list.
> 
> Whether we create a branch off RC or continue on master wont
> change the current situation.
> 
> We, as community should commit to testing and releasing code.
> principles and theory wont help.
> 
> Thanks,
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 27, 2017 at 9:43 PM, Rafael Weingärtner
> (rafaelweingart...@gmail.com) wrote:
> 
> +1 to what Paul said.
> IMHO, as soon as we start a release candidate to close a
> version, all merges should stop (period); the only exceptions
> should be PRs that address specific problems in the RC.
> I always thought that we had a protocol for that [1]; maybe for
> this version, we have not followed it?
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen
> 
> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
> <paul.an...@shapeblue.com>
> wrote:
> 
> Hi All,
> 
> From my view point 'we' have been the architects of our own
> downfall. Once a code freeze is in place NO new features, NO
> enhancements should be going in. Once we're at an RC stage, NO
> new bug fixes other that for the blockers should be going in.
> that way the release gets out, and the next 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

Yes, those shouldn't have been merged.  We should have released
faster and then merged.

Lets think of it as ours and us than theirs and those.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 12:19 PM, Paul Angus
(paul.an...@shapeblue.com) wrote:

Those new PRs should not have been merged.

Those on the mailing list should respect the process and accept
that they will have to wait until code is unfrozen.

Kind regards,

Paul Angus

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

-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: 28 June 2017 07:45
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

Paul,

Which shows we are not actively following RCs. That PR was a
blocker for RC3 and was well discussed. That PR is a perfect
example that we are not working as community to release code.
That is a fix for a blocker which stayed open for more than 45
days.

If you see till RC2 it was only blockers that were merged. But,
since it has taken a lot more time to fix blockers, more PRs were
merged on request on the mailing list(and we don't have people
even to object it). you can think of it as a combination of two
releases due to the time it has taken.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 12:06 PM, Paul Angus
(paul.an...@shapeblue.com) wrote:

Rajani,

I suspect that fatigue with the 4.10 release testing that we are
seeing is due to the time it has taken to release it. And that is
has been caused by new code going in, which have introduced new
bugs.

This was demonstrated in the last -1 from Kris. This change was
merged 10 days ago.

Kind regards,

Paul Angus

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

-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: 28 June 2017 06:14
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

We can do a release every month as long as we have enough people
actively participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on
releases/blockers. How many of us are testing/voting on releases
or PRs? We have blockers in jira, with no one to fix. We have PRs
open for release blockers for more than a month with no one to
test.

I would ask everyone to start testing releases/PRs and voting on
them actively.

We need people who can do the work. We already know what needs
to be done as outlined in the release principles wiki after long
discussions on this list.

Whether we create a branch off RC or continue on master wont
change the current situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a
version, all merges should stop (period); the only exceptions
should be PRs that address specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for
this version, we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
<paul.an...@shapeblue.com>
wrote:

Hi All,

>From my view point 'we' have been the architects of our own
downfall. Once a code freeze is in place NO new features, NO
enhancements should be going in. Once we're at an RC stage, NO
new bug fixes other that for the blockers should be going in.
that way the release gets out, and the next one can get going.
If
4.10 had gone out in a timely fashion, then we'd probably be on
4.11 if not 4.12 by now, with all the new features AND all the
new fixes in.

People sliding new changes/bug fixes/enhancements in are not
making the product better, they're stopping progress. As we can
clearly see here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve
discussed in the past is that overall community participation in
the RC process has dropped off when such a new branch is created
(since the community as a whole

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

I don't think creating a branch will help in releasing faster. It
will only make it worse in my opinion.

If we can release faster, features will stay in the PR branch for
a short while and can be merged quickly.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 12:17 PM, Daan Hoogland
(daan.hoogl...@gmail.com) wrote:

I'm with Mike on this. fixes go into the rc branch, features
don't and
that's a clearer line then we have now. or we could just keep
rc'ing
untill one passes and keep working on stablising whichever
branch we
choose for that allowing both features and fixes.

On Wed, Jun 28, 2017 at 8:40 AM, Tutkowski, Mike
<mike.tutkow...@netapp.com> wrote:

Hi,

I personally still like the idea of a new branch being created
right around the time we cut our first RC.

Even if people want to commit changes to the new branch, they
should understand that that code won't be formally released until
the pending RC is validated and released.

That being the case, I would think those who choose to commit to
the new branch will have a vested interest in the RC going out,
as well.

In any event, in addition to the current automated regression
tests that are run, we still have a lot of tests that are not
hooked into the build that are being run ad hoc (managed storage
automated tests are an example). Additionally, we seem to have a
lot of manual tests being run.

Until we can deliver a framework in which we have a very high
percentage of the system covered by automated tests, there is
really no way we should consider monthly releases.

I think we are still shooting for releases every four months,
which seems fair given our current system.

If we enact some deadlines like a code freeze going forward,
that should help. With only blocker PRs going into subsequent
RCs, we should be able to avoid a lot of unnecessary spin.

I definitely want to point out that I appreciate everyone's time
and effort. In particular, I want to be clear that it is not my
intent to be critical of anyone who's been working in release
management. My only goal with this chain of e-mails is to see if
we can continue to improve the process.

Thanks, everyone!
Mike

On Jun 27, 2017, at 11:14 PM, Rajani Karuturi <raj...@apache.org>
wrote:

We can do a release every month as long as we have enough people
actively participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on
releases/blockers. How many of us are testing/voting on releases
or PRs? We have blockers in jira, with no one to fix. We have
PRs
open for release blockers for more than a month with no one to
test.

I would ask everyone to start testing releases/PRs and voting on
them actively.

We need people who can do the work. We already know what needs
to
be done as outlined in the release principles wiki after long
discussions on this list.

Whether we create a branch off RC or continue on master wont
change the current situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a
version, all
merges should stop (period); the only exceptions should be PRs
that address
specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for
this
version, we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
<paul.an...@shapeblue.com>
wrote:

Hi All,

>From my view point 'we' have been the architects of our own
downfall. Once
a code freeze is in place NO new features, NO enhancements
should be going
in. Once we're at an RC stage, NO new bug fixes other that for
the blockers
should be going in. that way the release gets out, and the next
one can get
going. If 4.10 had gone out in a timely fashion, then we'd
probably be on
4.11 if not 4.12 by now, with all the new features AND all the
new fixes in.

People sliding new changes/bug fixes/enhancements in are not
making the
product better, they're stopping progress. As we can clearly see
here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve
discussed
in the past is that overall community part

RE: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Paul Angus]

Those new PRs should not have been merged.

Those on the mailing list should respect the process and accept that they will 
have to wait until code is unfrozen.





Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org] 
Sent: 28 June 2017 07:45
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

Paul,

Which shows we are not actively following RCs. That PR was a blocker for RC3 
and was well discussed. That PR is a perfect example that we are not working as 
community to release code.
That is a fix for a blocker which stayed open for more than 45 days.

If you see till RC2 it was only blockers that were merged. But, since it has 
taken a lot more time to fix blockers, more PRs were merged on request on the 
mailing list(and we don't have people even to object it). you can think of it 
as a combination of two releases due to the time it has taken.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 12:06 PM, Paul Angus
(paul.an...@shapeblue.com) wrote:

Rajani,

I suspect that fatigue with the 4.10 release testing that we are seeing is due 
to the time it has taken to release it. And that is has been caused by new code 
going in, which have introduced new bugs.

This was demonstrated in the last -1 from Kris. This change was merged 10 days 
ago.

Kind regards,

Paul Angus

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

-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: 28 June 2017 06:14
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

We can do a release every month as long as we have enough people actively 
participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on releases/blockers. How 
many of us are testing/voting on releases or PRs? We have blockers in jira, 
with no one to fix. We have PRs open for release blockers for more than a month 
with no one to test.

I would ask everyone to start testing releases/PRs and voting on them actively.

We need people who can do the work. We already know what needs to be done as 
outlined in the release principles wiki after long discussions on this list.

Whether we create a branch off RC or continue on master wont change the current 
situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a version, all merges 
should stop (period); the only exceptions should be PRs that address specific 
problems in the RC.
I always thought that we had a protocol for that [1]; maybe for this version, 
we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:

Hi All,

From my view point 'we' have been the architects of our own downfall. Once a 
code freeze is in place NO new features, NO enhancements should be going in. 
Once we're at an RC stage, NO new bug fixes other that for the blockers should 
be going in.
that way the release gets out, and the next one can get going. If
4.10 had gone out in a timely fashion, then we'd probably be on
4.11 if not 4.12 by now, with all the new features AND all the new fixes in.

People sliding new changes/bug fixes/enhancements in are not making the product 
better, they're stopping progress. As we can clearly see here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve discussed in the 
past is that overall community participation in the RC process has dropped off 
when such a new branch is created (since the community as a whole tends to 
focus more on the new branch rather than on testing the RC and releasing it).

I believe we should do the following: As we approach the first RC, we need to 
limit the number of PRs going into the branch (in order to stabilize it). If we 
had a super duper array of automated regression tests that ran again

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Daan Hoogland]

I'm with Mike on this. fixes go into the rc branch, features don't and
that's a clearer line then we have now. or we could just keep rc'ing
untill one passes and keep working on stablising whichever branch we
choose for that allowing both features and fixes.

On Wed, Jun 28, 2017 at 8:40 AM, Tutkowski, Mike
<mike.tutkow...@netapp.com> wrote:
> Hi,
>
> I personally still like the idea of a new branch being created right around 
> the time we cut our first RC.
>
> Even if people want to commit changes to the new branch, they should 
> understand that that code won't be formally released until the pending RC is 
> validated and released.
>
> That being the case, I would think those who choose to commit to the new 
> branch will have a vested interest in the RC going out, as well.
>
> In any event, in addition to the current automated regression tests that are 
> run, we still have a lot of tests that are not hooked into the build that are 
> being run ad hoc (managed storage automated tests are an example). 
> Additionally, we seem to have a lot of manual tests being run.
>
> Until we can deliver a framework in which we have a very high percentage of 
> the system covered by automated tests, there is really no way we should 
> consider monthly releases.
>
> I think we are still shooting for releases every four months, which seems 
> fair given our current system.
>
> If we enact some deadlines like a code freeze going forward, that should 
> help. With only blocker PRs going into subsequent RCs, we should be able to 
> avoid a lot of unnecessary spin.
>
> I definitely want to point out that I appreciate everyone's time and effort. 
> In particular, I want to be clear that it is not my intent to be critical of 
> anyone who's been working in release management. My only goal with this chain 
> of e-mails is to see if we can continue to improve the process.
>
> Thanks, everyone!
> Mike
>
>> On Jun 27, 2017, at 11:14 PM, Rajani Karuturi <raj...@apache.org> wrote:
>>
>> We can do a release every month as long as we have enough people
>> actively participating in the release process.
>>
>> We have people who wants to have their code/features checked in.
>> We, very clearly do not have enough people working on
>> releases/blockers. How many of us are testing/voting on releases
>> or PRs? We have blockers in jira, with no one to fix. We have PRs
>> open for release blockers for more than a month with no one to
>> test.
>>
>> I would ask everyone to start testing releases/PRs and voting on
>> them actively.
>>
>> We need people who can do the work. We already know what needs to
>> be done as outlined in the release principles wiki after long
>> discussions on this list.
>>
>> Whether we create a branch off RC or continue on master wont
>> change the current situation.
>>
>> We, as community should commit to testing and releasing code.
>> principles and theory wont help.
>>
>> Thanks,
>>
>> ~ Rajani
>>
>> http://cloudplatform.accelerite.com/
>>
>> On June 27, 2017 at 9:43 PM, Rafael Weingärtner
>> (rafaelweingart...@gmail.com) wrote:
>>
>> +1 to what Paul said.
>> IMHO, as soon as we start a release candidate to close a
>> version, all
>> merges should stop (period); the only exceptions should be PRs
>> that address
>> specific problems in the RC.
>> I always thought that we had a protocol for that [1]; maybe for
>> this
>> version, we have not followed it?
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen
>>
>> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
>> <paul.an...@shapeblue.com>
>> wrote:
>>
>> Hi All,
>>
>> From my view point 'we' have been the architects of our own
>> downfall. Once
>> a code freeze is in place NO new features, NO enhancements
>> should be going
>> in. Once we're at an RC stage, NO new bug fixes other that for
>> the blockers
>> should be going in. that way the release gets out, and the next
>> one can get
>> going. If 4.10 had gone out in a timely fashion, then we'd
>> probably be on
>> 4.11 if not 4.12 by now, with all the new features AND all the
>> new fixes in.
>>
>> People sliding new changes/bug fixes/enhancements in are not
>> making the
>> product better, they're stopping progress. As we can clearly see
>> here.
>>
>> Kind regards,
>>
>> Paul Angus
>>
>> paul.an...@

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

Paul,

Which shows we are not actively following RCs. That PR was a
blocker for RC3 and was well discussed. That PR is a perfect
example that we are not working as community to release code.
That is a fix for a blocker which stayed open for more than 45
days.

If you see till RC2 it was only blockers that were merged. But,
since it has taken a lot more time to fix blockers, more PRs were
merged on request on the mailing list(and we don't have people
even to object it). you can think of it as a combination of two
releases due to the time it has taken.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 12:06 PM, Paul Angus
(paul.an...@shapeblue.com) wrote:

Rajani,

I suspect that fatigue with the 4.10 release testing that we are
seeing is due to the time it has taken to release it. And that is
has been caused by new code going in, which have introduced new
bugs.

This was demonstrated in the last -1 from Kris. This change was
merged 10 days ago.

Kind regards,

Paul Angus

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

-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: 28 June 2017 06:14
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

We can do a release every month as long as we have enough people
actively participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on
releases/blockers. How many of us are testing/voting on releases
or PRs? We have blockers in jira, with no one to fix. We have PRs
open for release blockers for more than a month with no one to
test.

I would ask everyone to start testing releases/PRs and voting on
them actively.

We need people who can do the work. We already know what needs
to be done as outlined in the release principles wiki after long
discussions on this list.

Whether we create a branch off RC or continue on master wont
change the current situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a
version, all merges should stop (period); the only exceptions
should be PRs that address specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for
this version, we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
<paul.an...@shapeblue.com>
wrote:

Hi All,

>From my view point 'we' have been the architects of our own
downfall. Once a code freeze is in place NO new features, NO
enhancements should be going in. Once we're at an RC stage, NO
new bug fixes other that for the blockers should be going in.
that way the release gets out, and the next one can get going. If
4.10 had gone out in a timely fashion, then we'd probably be on
4.11 if not 4.12 by now, with all the new features AND all the
new fixes in.

People sliding new changes/bug fixes/enhancements in are not
making the product better, they're stopping progress. As we can
clearly see here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve
discussed in the past is that overall community participation in
the RC process has dropped off when such a new branch is created
(since the community as a whole tends to focus more on the new
branch rather than on testing the RC and releasing it).

I believe we should do the following: As we approach the first
RC, we need to limit the number of PRs going into the branch (in
order to stabilize it). If we had a super duper array of
automated regression tests that ran against the code, then we
might be able to avoid this, but our automated test suite is not
extensive enough for us to do so.

As we approach the first RC, only blockers and trivial (ex. text
changes)
PRs should be permitted in. Once we cut the first RC, create a
new branch for ongoing dev work. In between RCs, we can only
allow in code related to blocker PRs (or trivial text changes, as
discussed before).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com>
wrote:

thi

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

Hi,

I personally still like the idea of a new branch being created right around the 
time we cut our first RC.

Even if people want to commit changes to the new branch, they should understand 
that that code won't be formally released until the pending RC is validated and 
released.

That being the case, I would think those who choose to commit to the new branch 
will have a vested interest in the RC going out, as well.

In any event, in addition to the current automated regression tests that are 
run, we still have a lot of tests that are not hooked into the build that are 
being run ad hoc (managed storage automated tests are an example). 
Additionally, we seem to have a lot of manual tests being run.

Until we can deliver a framework in which we have a very high percentage of the 
system covered by automated tests, there is really no way we should consider 
monthly releases.

I think we are still shooting for releases every four months, which seems fair 
given our current system.

If we enact some deadlines like a code freeze going forward, that should help. 
With only blocker PRs going into subsequent RCs, we should be able to avoid a 
lot of unnecessary spin.

I definitely want to point out that I appreciate everyone's time and effort. In 
particular, I want to be clear that it is not my intent to be critical of 
anyone who's been working in release management. My only goal with this chain 
of e-mails is to see if we can continue to improve the process.

Thanks, everyone!
Mike

> On Jun 27, 2017, at 11:14 PM, Rajani Karuturi <raj...@apache.org> wrote:
> 
> We can do a release every month as long as we have enough people
> actively participating in the release process.
> 
> We have people who wants to have their code/features checked in.
> We, very clearly do not have enough people working on
> releases/blockers. How many of us are testing/voting on releases
> or PRs? We have blockers in jira, with no one to fix. We have PRs
> open for release blockers for more than a month with no one to
> test.
> 
> I would ask everyone to start testing releases/PRs and voting on
> them actively.
> 
> We need people who can do the work. We already know what needs to
> be done as outlined in the release principles wiki after long
> discussions on this list.
> 
> Whether we create a branch off RC or continue on master wont
> change the current situation.
> 
> We, as community should commit to testing and releasing code.
> principles and theory wont help.
> 
> Thanks,
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 27, 2017 at 9:43 PM, Rafael Weingärtner
> (rafaelweingart...@gmail.com) wrote:
> 
> +1 to what Paul said.
> IMHO, as soon as we start a release candidate to close a
> version, all
> merges should stop (period); the only exceptions should be PRs
> that address
> specific problems in the RC.
> I always thought that we had a protocol for that [1]; maybe for
> this
> version, we have not followed it?
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen
> 
> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
> <paul.an...@shapeblue.com>
> wrote:
> 
> Hi All,
> 
> From my view point 'we' have been the architects of our own
> downfall. Once
> a code freeze is in place NO new features, NO enhancements
> should be going
> in. Once we're at an RC stage, NO new bug fixes other that for
> the blockers
> should be going in. that way the release gets out, and the next
> one can get
> going. If 4.10 had gone out in a timely fashion, then we'd
> probably be on
> 4.11 if not 4.12 by now, with all the new features AND all the
> new fixes in.
> 
> People sliding new changes/bug fixes/enhancements in are not
> making the
> product better, they're stopping progress. As we can clearly see
> here.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
> 
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
> Sent: 27 June 2017 01:25
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander <w...@widodh.nl>
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
> 
> I tend to agree with you here, Daan. I know the downside we’ve
> discussed
> in the past is that overall community participation in the RC
> process has
> dropped off when such a new branch is created (since the
> community as a
> whole tends to focus more on the new branch rather than on
> testing the RC
> and releasing it).
> 
> I believ

RE: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Paul Angus]

Rajani,

I suspect that fatigue with the 4.10 release testing that we are seeing is due 
to the time it has taken to release it.  And that is has been caused by new 
code going in, which have introduced new bugs.

This was demonstrated in the last -1 from Kris. This change was merged 10 days 
ago.



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org] 
Sent: 28 June 2017 06:14
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

We can do a release every month as long as we have enough people actively 
participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on releases/blockers. How 
many of us are testing/voting on releases or PRs? We have blockers in jira, 
with no one to fix. We have PRs open for release blockers for more than a month 
with no one to test.

I would ask everyone to start testing releases/PRs and voting on them actively.

We need people who can do the work. We already know what needs to be done as 
outlined in the release principles wiki after long discussions on this list.

Whether we create a branch off RC or continue on master wont change the current 
situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a version, all merges 
should stop (period); the only exceptions should be PRs that address specific 
problems in the RC.
I always thought that we had a protocol for that [1]; maybe for this version, 
we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:

Hi All,

From my view point 'we' have been the architects of our own downfall. Once a 
code freeze is in place NO new features, NO enhancements should be going in. 
Once we're at an RC stage, NO new bug fixes other that for the blockers should 
be going in. that way the release gets out, and the next one can get going. If 
4.10 had gone out in a timely fashion, then we'd probably be on
4.11 if not 4.12 by now, with all the new features AND all the new fixes in.

People sliding new changes/bug fixes/enhancements in are not making the product 
better, they're stopping progress. As we can clearly see here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve discussed in the 
past is that overall community participation in the RC process has dropped off 
when such a new branch is created (since the community as a whole tends to 
focus more on the new branch rather than on testing the RC and releasing it).

I believe we should do the following: As we approach the first RC, we need to 
limit the number of PRs going into the branch (in order to stabilize it). If we 
had a super duper array of automated regression tests that ran against the 
code, then we might be able to avoid this, but our automated test suite is not 
extensive enough for us to do so.

As we approach the first RC, only blockers and trivial (ex. text
changes)
PRs should be permitted in. Once we cut the first RC, create a new branch for 
ongoing dev work. In between RCs, we can only allow in code related to blocker 
PRs (or trivial text changes, as discussed before).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com>
wrote:

this is why i say we should branch on first RC, fix in release branch only and 
merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens < williamstev...@gmail.com> 
wrote:

I know it is hard to justify not merging PRs that seem ready but are

not

blockers in an RC, but it is a vicious circle which ultimately

results in a

longer RC process.

It is something i struggled with as a release manager as well.

On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org>

wrote:

Thanks Mike,

Will hold off next RC until we hear an update from you.

Regarding merging non-blockers, unfortunately, its a side-effect of taking more 
than three months in the RC phase :(

Than

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

We can do a release every month as long as we have enough people
actively participating in the release process.

We have people who wants to have their code/features checked in.
We, very clearly do not have enough people working on
releases/blockers. How many of us are testing/voting on releases
or PRs? We have blockers in jira, with no one to fix. We have PRs
open for release blockers for more than a month with no one to
test.

I would ask everyone to start testing releases/PRs and voting on
them actively.

We need people who can do the work. We already know what needs to
be done as outlined in the release principles wiki after long
discussions on this list.

Whether we create a branch off RC or continue on master wont
change the current situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a
version, all
merges should stop (period); the only exceptions should be PRs
that address
specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for
this
version, we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
<paul.an...@shapeblue.com>
wrote:

Hi All,

>From my view point 'we' have been the architects of our own
downfall. Once
a code freeze is in place NO new features, NO enhancements
should be going
in. Once we're at an RC stage, NO new bug fixes other that for
the blockers
should be going in. that way the release gets out, and the next
one can get
going. If 4.10 had gone out in a timely fashion, then we'd
probably be on
4.11 if not 4.12 by now, with all the new features AND all the
new fixes in.

People sliding new changes/bug fixes/enhancements in are not
making the
product better, they're stopping progress. As we can clearly see
here.

Kind regards,

Paul Angus

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

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve
discussed
in the past is that overall community participation in the RC
process has
dropped off when such a new branch is created (since the
community as a
whole tends to focus more on the new branch rather than on
testing the RC
and releasing it).

I believe we should do the following: As we approach the first
RC, we need
to limit the number of PRs going into the branch (in order to
stabilize
it). If we had a super duper array of automated regression tests
that ran
against the code, then we might be able to avoid this, but our
automated
test suite is not extensive enough for us to do so.

As we approach the first RC, only blockers and trivial (ex. text
changes)
PRs should be permitted in. Once we cut the first RC, create a
new branch
for ongoing dev work. In between RCs, we can only allow in code
related to
blocker PRs (or trivial text changes, as discussed before).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com>
wrote:

this is why i say we should branch on first RC, fix in release
branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
williamstev...@gmail.com> wrote:

I know it is hard to justify not merging PRs that seem ready but
are

not

blockers in an RC, but it is a vicious circle which ultimately

results in a

longer RC process.

It is something i struggled with as a release manager as well.

On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org>

wrote:

Thanks Mike,

Will hold off next RC until we hear an update from you.

Regarding merging non-blockers, unfortunately, its a side-effect
of taking more than three months in the RC phase :(

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 13, 2017 at 10:10 AM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi everyone,

I had a little time this evening and re-ran some VMware-related
tests around managed storage. I noticed a problem that I’d like
to investigate before we spin up the next RC. Let’s hold off on
the next RC until I can find out more (I should know more within
24 hours).

Thanks!
Mike

On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl>
wrote:

Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"

<mike.tutkow...@netapp.com>:

Hi,

I opened a PR against the most 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Rajani Karuturi]

Hi Kris,

Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.

Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would help uncover issues before they
are merged.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 8:14 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162

Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike
 wrote:

+1 (binding)

I am not concerned about the code changes that went into this RC
since the
previous RC, so I am still happy with the amount of automated
and manual
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi" 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a
vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/
0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
RC20170626T1011

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

I'm glad you guys (Paul and Rafael) agree with me. We should cut a branch once 
the first RC is built. Then we should only allow blockers in to fix RC issues.

This should speed up our releases in the future.

> On Jun 27, 2017, at 10:14 AM, Rafael Weingärtner 
> <rafaelweingart...@gmail.com> wrote:
> 
> +1 to what Paul said.
> IMHO, as soon as we start a release candidate to close a version, all
> merges should stop (period); the only exceptions should be PRs that address
> specific problems in the RC.
> I always thought that we had a protocol for that [1]; maybe for this
> version, we have not followed it?
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen
> 
> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus <paul.an...@shapeblue.com>
> wrote:
> 
>> Hi All,
>> 
>> From my view point 'we' have been the architects of our own downfall. Once
>> a code freeze is in place NO new features, NO enhancements should be going
>> in. Once we're at an RC stage, NO new bug fixes other that for the blockers
>> should be going in. that way the release gets out, and the next one can get
>> going.  If 4.10 had gone out in a timely fashion, then we'd probably be on
>> 4.11 if not 4.12 by now, with all the new features AND all the new fixes in.
>> 
>> People sliding new changes/bug fixes/enhancements in are not making the
>> product better, they're stopping progress.  As we can clearly see here.
>> 
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> 
>> -Original Message-----
>> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
>> Sent: 27 June 2017 01:25
>> To: dev@cloudstack.apache.org
>> Cc: Wido den Hollander <w...@widodh.nl>
>> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>> 
>> I tend to agree with you here, Daan. I know the downside we’ve discussed
>> in the past is that overall community participation in the RC process has
>> dropped off when such a new branch is created (since the community as a
>> whole tends to focus more on the new branch rather than on testing the RC
>> and releasing it).
>> 
>> I believe we should do the following: As we approach the first RC, we need
>> to limit the number of PRs going into the branch (in order to stabilize
>> it). If we had a super duper array of automated regression tests that ran
>> against the code, then we might be able to avoid this, but our automated
>> test suite is not extensive enough for us to do so.
>> 
>> As we approach the first RC, only blockers and trivial (ex. text changes)
>> PRs should be permitted in. Once we cut the first RC, create a new branch
>> for ongoing dev work. In between RCs, we can only allow in code related to
>> blocker PRs (or trivial text changes, as discussed before).
>> 
>> What do people think?
>> 
>> On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote:
>> 
>>this is why i say we should branch on first RC, fix in release branch
>>only and merge forward
>> 
>>On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
>> williamstev...@gmail.com> wrote:
>>> I know it is hard to justify not merging PRs that seem ready but are
>> not
>>> blockers in an RC, but it is a vicious circle which ultimately
>> results in a
>>> longer RC process.
>>> 
>>> It is something i struggled with as a release manager as well.
>>> 
>>> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org>
>> wrote:
>>> 
>>> Thanks Mike,
>>> 
>>> Will hold off next RC until we hear an update from you.
>>> 
>>> Regarding merging non-blockers, unfortunately, its a side-effect
>>> of taking more than three months in the RC phase :(
>>> 
>>> Thanks,
>>> 
>>> ~ Rajani
>>> 
>>> http://cloudplatform.accelerite.com/
>>> 
>>> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
>>> (mike.tutkow...@netapp.com) wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I had a little time this evening and re-ran some VMware-related
>>> tests around managed storage. I noticed a problem that I’d like
>>> to investigate before we spin up the next RC. Let’s hold off on
>>> the next RC

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rafael Weingärtner]

+1 to what Paul said.
IMHO, as soon as we start a release candidate to close a version, all
merges should stop (period); the only exceptions should be PRs that address
specific problems in the RC.
I always thought that we had a protocol for that [1]; maybe for this
version, we have not followed it?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:

> Hi All,
>
> From my view point 'we' have been the architects of our own downfall. Once
> a code freeze is in place NO new features, NO enhancements should be going
> in. Once we're at an RC stage, NO new bug fixes other that for the blockers
> should be going in. that way the release gets out, and the next one can get
> going.  If 4.10 had gone out in a timely fashion, then we'd probably be on
> 4.11 if not 4.12 by now, with all the new features AND all the new fixes in.
>
> People sliding new changes/bug fixes/enhancements in are not making the
> product better, they're stopping progress.  As we can clearly see here.
>
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
> Sent: 27 June 2017 01:25
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander <w...@widodh.nl>
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>
> I tend to agree with you here, Daan. I know the downside we’ve discussed
> in the past is that overall community participation in the RC process has
> dropped off when such a new branch is created (since the community as a
> whole tends to focus more on the new branch rather than on testing the RC
> and releasing it).
>
> I believe we should do the following: As we approach the first RC, we need
> to limit the number of PRs going into the branch (in order to stabilize
> it). If we had a super duper array of automated regression tests that ran
> against the code, then we might be able to avoid this, but our automated
> test suite is not extensive enough for us to do so.
>
> As we approach the first RC, only blockers and trivial (ex. text changes)
> PRs should be permitted in. Once we cut the first RC, create a new branch
> for ongoing dev work. In between RCs, we can only allow in code related to
> blocker PRs (or trivial text changes, as discussed before).
>
> What do people think?
>
> On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote:
>
> this is why i say we should branch on first RC, fix in release branch
> only and merge forward
>
> On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
> williamstev...@gmail.com> wrote:
> > I know it is hard to justify not merging PRs that seem ready but are
> not
> > blockers in an RC, but it is a vicious circle which ultimately
> results in a
> > longer RC process.
> >
> > It is something i struggled with as a release manager as well.
> >
> > On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org>
> wrote:
> >
> > Thanks Mike,
> >
> > Will hold off next RC until we hear an update from you.
> >
> > Regarding merging non-blockers, unfortunately, its a side-effect
> > of taking more than three months in the RC phase :(
> >
> > Thanks,
> >
> > ~ Rajani
> >
> > http://cloudplatform.accelerite.com/
> >
> > On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> > (mike.tutkow...@netapp.com) wrote:
> >
> > Hi everyone,
> >
> > I had a little time this evening and re-ran some VMware-related
> > tests around managed storage. I noticed a problem that I’d like
> > to investigate before we spin up the next RC. Let’s hold off on
> > the next RC until I can find out more (I should know more within
> > 24 hours).
> >
> > Thanks!
> > Mike
> >
> > On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl>
> > wrote:
> >
> >> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> > <mike.tutkow...@netapp.com>:
> >>
> >>
> >> Hi,
> >>
> >> I opened a PR against the most recent RC:
> > https://github.com/apache/cloudstack/pull/2141
> >>
> >

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Kris Sterckx]

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162


Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike  wrote:

> +1 (binding)
>
> I am not concerned about the code changes that went into this RC since the
> previous RC, so I am still happy with the amount of automated and manual
> testing that I performed on a previous RC.
>
> On 6/25/17, 11:07 PM, "Rajani Karuturi"  wrote:
>
> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up for a
> vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/
> 0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
> RC20170626T1011
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC6/
>
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
>
> 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)
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>
>
>

RE: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Paul Angus]

Hi All,

From my view point 'we' have been the architects of our own downfall. Once a 
code freeze is in place NO new features, NO enhancements should be going in. 
Once we're at an RC stage, NO new bug fixes other that for the blockers should 
be going in. that way the release gets out, and the next one can get going.  If 
4.10 had gone out in a timely fashion, then we'd probably be on 4.11 if not 
4.12 by now, with all the new features AND all the new fixes in.

People sliding new changes/bug fixes/enhancements in are not making the product 
better, they're stopping progress.  As we can clearly see here.


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander <w...@widodh.nl>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve discussed in the 
past is that overall community participation in the RC process has dropped off 
when such a new branch is created (since the community as a whole tends to 
focus more on the new branch rather than on testing the RC and releasing it).

I believe we should do the following: As we approach the first RC, we need to 
limit the number of PRs going into the branch (in order to stabilize it). If we 
had a super duper array of automated regression tests that ran against the 
code, then we might be able to avoid this, but our automated test suite is not 
extensive enough for us to do so.

As we approach the first RC, only blockers and trivial (ex. text changes) PRs 
should be permitted in. Once we cut the first RC, create a new branch for 
ongoing dev work. In between RCs, we can only allow in code related to blocker 
PRs (or trivial text changes, as discussed before).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote:

this is why i say we should branch on first RC, fix in release branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <williamstev...@gmail.com> 
wrote:
> I know it is hard to justify not merging PRs that seem ready but are not
> blockers in an RC, but it is a vicious circle which ultimately results in 
a
> longer RC process.
>
> It is something i struggled with as a release manager as well.
>
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org> wrote:
>
> Thanks Mike,
>
> Will hold off next RC until we hear an update from you.
>
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi everyone,
>
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I’d like
> to investigate before we spin up the next RC. Let’s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>
> Thanks!
> Mike
>
> On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl>
> wrote:
>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> <mike.tutkow...@netapp.com>:
>>
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
> it, I’m +1 on the new RC as long as this is the only commit added
> to it since the current RC.
>
> Thanks Mike!
>
> If this PR is good we should probably merge it asap and go for
> RC5.
>
> 4.10 should really be released by now.
>
> Wido
>
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
> <mike.tutkow...@netapp.com> wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
> snapshots on primary storage (which is a feature managed storage
> can support):

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

I tend to agree with you here, Daan. I know the downside we’ve discussed in the 
past is that overall community participation in the RC process has dropped off 
when such a new branch is created (since the community as a whole tends to 
focus more on the new branch rather than on testing the RC and releasing it).

I believe we should do the following: As we approach the first RC, we need to 
limit the number of PRs going into the branch (in order to stabilize it). If we 
had a super duper array of automated regression tests that ran against the 
code, then we might be able to avoid this, but our automated test suite is not 
extensive enough for us to do so.

As we approach the first RC, only blockers and trivial (ex. text changes) PRs 
should be permitted in. Once we cut the first RC, create a new branch for 
ongoing dev work. In between RCs, we can only allow in code related to blocker 
PRs (or trivial text changes, as discussed before).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland"  wrote:

this is why i say we should branch on first RC, fix in release branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens  
wrote:
> I know it is hard to justify not merging PRs that seem ready but are not
> blockers in an RC, but it is a vicious circle which ultimately results in 
a
> longer RC process.
>
> It is something i struggled with as a release manager as well.
>
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi"  wrote:
>
> Thanks Mike,
>
> Will hold off next RC until we hear an update from you.
>
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi everyone,
>
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I’d like
> to investigate before we spin up the next RC. Let’s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>
> Thanks!
> Mike
>
> On 6/12/17, 2:40 AM, "Wido den Hollander" 
> wrote:
>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> :
>>
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
> it, I’m +1 on the new RC as long as this is the only commit added
> to it since the current RC.
>
> Thanks Mike!
>
> If this PR is good we should probably merge it asap and go for
> RC5.
>
> 4.10 should really be released by now.
>
> Wido
>
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
> snapshots on primary storage (which is a feature managed storage
> can support):
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>>
>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>>
>> At a high level, what it does is remove a row from the
> cloud.snapshot_store_ref table when a volume is deleted that has
> one or more volume snapshots.
>>
>> This is fine for non-managed (traditional) storage; however,
> managed storage can store volume snapshots on primary storage, so
> removing this row breaks that functionality.
>>
>> I can fix the problem that this commit introduced by looking
> at the primary storage that supports the volume snapshot and
> checking the following: 1) Is this managed storage? 2) If yes, is
> the snapshot in question stored on that primary storage?
>>
>> The problem is I will be out of the office for a couple weeks
> and will not be able to address this until I return.
>>
>> We could revert the commit, but I still will not have time to
> run the managed-storage regression test suite until I return.
>>
>> On a side note, it looks like this commit was introduced since
> the most recent RC. I would argue that it was not a blocker and
> should not have been placed into the new RC. We (as a community)
> tend to have a lot of code go in between RCs and that just
> increases the chances of 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Tutkowski, Mike]

+1 (binding)

I am not concerned about the code changes that went into this RC since the 
previous RC, so I am still happy with the amount of automated and manual 
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi"  wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:

https://github.com/apache/cloudstack/commit/0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170626T1011

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

[VOTE] Apache CloudStack 4.10.0.0 RC6

[Rajani Karuturi]

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170626T1011

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Rajani Karuturi]

Agree. Will create rc6 soon.

~Rajani

Sent from phone.

On 23 Jun 2017 3:17 p.m., "Wido den Hollander"  wrote:

>
> > Op 22 juni 2017 om 21:38 schreef Kris Sterckx <
> kris.ster...@nuagenetworks.net>:
> >
> >
> > Sorry , i meant  PR/2084  >
> >
>
> Ok, so revert and RC6 then?
>
> Wido
>
> > On 22 June 2017 at 21:25, Kris Sterckx 
> > wrote:
> >
> > > Hi all
> > >
> > >
> > > Thanks to Daan for driving the work at PR/2155
> > >  , but i believe it
> needs
> > > more soak time.
> > >
> > > We found today this PR is breaking VR-provided Guest DNS for SDN
> providers
> > > also.
> > >
> > > As Daan also suggested, i would recommend taking it out 4.10 and give
> it
> > > some more cycles in 4.11.
> > >
> > > We will support qualifying it.
> > >
> > > thanks,
> > >
> > > Kris
> > >
> > > - Nuage Networks
> > >
> > > On 21 June 2017 at 16:45, Kris Sterckx  >
> > > wrote:
> > >
> > >> Hi  Wido, Daan, all
> > >>
> > >>
> > >> We have just pushed a workaround
> > >>
> > >> https://github.com/apache/cloudstack/pull/2155
> > >>
> > >> This works for us.
> > >>
> > >> The CsPassword class seems like not needed at all ?  The important
> part
> > >> for us is that  iptables_change = True  is set also in case of
> password
> > >> handling.  That was missing.
> > >>
> > >> Daan, we left a TODO for you to look into deeper though. We worked at
> > >> getting the databag handling fixed inside the class but as we don't
> have
> > >> full background, we kept hitting issues. Until we then saw that
> commenting
> > >> out the lines which we did actually works as well.
> > >>
> > >> I suggest the /2155 is reviewed by the involved stakeholders and
> based on
> > >> that we decide ?
> > >>
> > >>
> > >> thanks and toi-toi :-)
> > >>
> > >>
> > >> Kris
> > >>
> > >>
> > >>
> > >>
> > >
> > >
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Wido den Hollander]

> Op 22 juni 2017 om 21:38 schreef Kris Sterckx 
> :
> 
> 
> Sorry , i meant  PR/2084 
> 

Ok, so revert and RC6 then?

Wido

> On 22 June 2017 at 21:25, Kris Sterckx 
> wrote:
> 
> > Hi all
> >
> >
> > Thanks to Daan for driving the work at PR/2155
> >  , but i believe it needs
> > more soak time.
> >
> > We found today this PR is breaking VR-provided Guest DNS for SDN providers
> > also.
> >
> > As Daan also suggested, i would recommend taking it out 4.10 and give it
> > some more cycles in 4.11.
> >
> > We will support qualifying it.
> >
> > thanks,
> >
> > Kris
> >
> > - Nuage Networks
> >
> > On 21 June 2017 at 16:45, Kris Sterckx 
> > wrote:
> >
> >> Hi  Wido, Daan, all
> >>
> >>
> >> We have just pushed a workaround
> >>
> >> https://github.com/apache/cloudstack/pull/2155
> >>
> >> This works for us.
> >>
> >> The CsPassword class seems like not needed at all ?  The important part
> >> for us is that  iptables_change = True  is set also in case of password
> >> handling.  That was missing.
> >>
> >> Daan, we left a TODO for you to look into deeper though. We worked at
> >> getting the databag handling fixed inside the class but as we don't have
> >> full background, we kept hitting issues. Until we then saw that commenting
> >> out the lines which we did actually works as well.
> >>
> >> I suggest the /2155 is reviewed by the involved stakeholders and based on
> >> that we decide ?
> >>
> >>
> >> thanks and toi-toi :-)
> >>
> >>
> >> Kris
> >>
> >>
> >>
> >>
> >
> >

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Kris Sterckx]

Sorry , i meant  PR/2084 

On 22 June 2017 at 21:25, Kris Sterckx 
wrote:

> Hi all
>
>
> Thanks to Daan for driving the work at PR/2155
>  , but i believe it needs
> more soak time.
>
> We found today this PR is breaking VR-provided Guest DNS for SDN providers
> also.
>
> As Daan also suggested, i would recommend taking it out 4.10 and give it
> some more cycles in 4.11.
>
> We will support qualifying it.
>
> thanks,
>
> Kris
>
> - Nuage Networks
>
> On 21 June 2017 at 16:45, Kris Sterckx 
> wrote:
>
>> Hi  Wido, Daan, all
>>
>>
>> We have just pushed a workaround
>>
>> https://github.com/apache/cloudstack/pull/2155
>>
>> This works for us.
>>
>> The CsPassword class seems like not needed at all ?  The important part
>> for us is that  iptables_change = True  is set also in case of password
>> handling.  That was missing.
>>
>> Daan, we left a TODO for you to look into deeper though. We worked at
>> getting the databag handling fixed inside the class but as we don't have
>> full background, we kept hitting issues. Until we then saw that commenting
>> out the lines which we did actually works as well.
>>
>> I suggest the /2155 is reviewed by the involved stakeholders and based on
>> that we decide ?
>>
>>
>> thanks and toi-toi :-)
>>
>>
>> Kris
>>
>>
>>
>>
>
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Kris Sterckx]

Hi all


Thanks to Daan for driving the work at PR/2155
 , but i believe it needs
more soak time.

We found today this PR is breaking VR-provided Guest DNS for SDN providers
also.

As Daan also suggested, i would recommend taking it out 4.10 and give it
some more cycles in 4.11.

We will support qualifying it.

thanks,

Kris

- Nuage Networks

On 21 June 2017 at 16:45, Kris Sterckx 
wrote:

> Hi  Wido, Daan, all
>
>
> We have just pushed a workaround
>
> https://github.com/apache/cloudstack/pull/2155
>
> This works for us.
>
> The CsPassword class seems like not needed at all ?  The important part
> for us is that  iptables_change = True  is set also in case of password
> handling.  That was missing.
>
> Daan, we left a TODO for you to look into deeper though. We worked at
> getting the databag handling fixed inside the class but as we don't have
> full background, we kept hitting issues. Until we then saw that commenting
> out the lines which we did actually works as well.
>
> I suggest the /2155 is reviewed by the involved stakeholders and based on
> that we decide ?
>
>
> thanks and toi-toi :-)
>
>
> Kris
>
>
>
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Kris Sterckx]

Hi  Wido, Daan, all


We have just pushed a workaround

https://github.com/apache/cloudstack/pull/2155

This works for us.

The CsPassword class seems like not needed at all ?  The important part for
us is that  iptables_change = True  is set also in case of password
handling.  That was missing.

Daan, we left a TODO for you to look into deeper though. We worked at
getting the databag handling fixed inside the class but as we don't have
full background, we kept hitting issues. Until we then saw that commenting
out the lines which we did actually works as well.

I suggest the /2155 is reviewed by the involved stakeholders and based on
that we decide ?


thanks and toi-toi :-)


Kris

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Daan Hoogland]

It was an optimization that got merged and if someone is hindered we should 
back out and proceed, I’d say. 

On 21/06/17 16:00, "Wido den Hollander"  wrote:


> Op 20 juni 2017 om 21:35 schreef Kris Sterckx 
:
> 
> 
> I am sorry, I need to vote -1

:(

Anybody else have an idea on how to proceed? We keep having issues popping 
up with 4.10

This should be fixable right for 4.10?

We have so many work piling up for 4.11 right now, we should really get 
that going.

Wido

> 
> 
> https://github.com/apache/cloudstack/pull/2084  is causing password reset
> issues for us (Nuage) (i know in native tests pass though...).
> 
> We are trying to provide a fix but the following modified VR script is
> having severe issues :
> 
> 
https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
>  :
> 
> - import of  CsPassword  is missing
> 
> - line 910 : this invocation of the constructor is invalid  (ctor is  def
> __init__(self, dbag)  )
> 
> Also i believe for SDN provided networks there is something overlooked as
> we don't see the ip tables set for the VR to respond to password reset
> requests.  We believe the script is not setting iptables_change = True in
> case of networks for which the VR is not in the dataplane.
> 
> 
> I suggest this PR is backed out for now it this is not an urgent add to 
the
> 4.10 release, or we spend time at fixing it.
> 
> We definitely want to help in making that happen.
> 
> 
> Thanks,
> 
> Kris
> 
> -- Nuage Networks
> 

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

> On 20 June 2017 at 07:45, Rajani Karuturi  wrote:
> 
> > Hi All,
> >
> > I've created 4.10.0.0 release with the following artifacts up for a 
vote:
> >
> > Git Branch and Commit SH:
> > 
https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07
> > ab3e8424cd
> > Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> > Branch: 
https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> >
> > SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
> >
> > New PRs merged since RC4: #2150 and #2089
> >
> > 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)
> >
> >
> > Thanks,
> > ~Rajani
> > http://cloudplatform.accelerite.com/
> >

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Wido den Hollander]

> Op 20 juni 2017 om 21:35 schreef Kris Sterckx 
> :
> 
> 
> I am sorry, I need to vote -1

:(

Anybody else have an idea on how to proceed? We keep having issues popping up 
with 4.10

This should be fixable right for 4.10?

We have so many work piling up for 4.11 right now, we should really get that 
going.

Wido

> 
> 
> https://github.com/apache/cloudstack/pull/2084  is causing password reset
> issues for us (Nuage) (i know in native tests pass though...).
> 
> We are trying to provide a fix but the following modified VR script is
> having severe issues :
> 
> https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
>  :
> 
> - import of  CsPassword  is missing
> 
> - line 910 : this invocation of the constructor is invalid  (ctor is  def
> __init__(self, dbag)  )
> 
> Also i believe for SDN provided networks there is something overlooked as
> we don't see the ip tables set for the VR to respond to password reset
> requests.  We believe the script is not setting iptables_change = True in
> case of networks for which the VR is not in the dataplane.
> 
> 
> I suggest this PR is backed out for now it this is not an urgent add to the
> 4.10 release, or we spend time at fixing it.
> 
> We definitely want to help in making that happen.
> 
> 
> Thanks,
> 
> Kris
> 
> -- Nuage Networks
> 
> On 20 June 2017 at 07:45, Rajani Karuturi  wrote:
> 
> > Hi All,
> >
> > I've created 4.10.0.0 release with the following artifacts up for a vote:
> >
> > Git Branch and Commit SH:
> > https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07
> > ab3e8424cd
> > Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> > Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> >
> > SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
> >
> > New PRs merged since RC4: #2150 and #2089
> >
> > 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)
> >
> >
> > Thanks,
> > ~Rajani
> > http://cloudplatform.accelerite.com/
> >

Re:RE: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Haijiao]

I saw Pierre-Luc Dion is working on a PR upon this,  but it's not included in 
4.10 yet,  maybe 4.11


https://issues.apache.org/jira/browse/CLOUDSTACK-9839


在2017年06月21 10时24分, "Marty Godsey"<ma...@gonsource.com>写道:

Is XenServer 7.1 support being added in this release?

Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC

-Original Message-
From: Kris Sterckx [mailto:kris.ster...@nuagenetworks.net]
Sent: Tuesday, June 20, 2017 3:35 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

I am sorry, I need to vote -1


https://github.com/apache/cloudstack/pull/2084  is causing password reset 
issues for us (Nuage) (i know in native tests pass though...).

We are trying to provide a fix but the following modified VR script is having 
severe issues :

https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
:

- import of  CsPassword  is missing

- line 910 : this invocation of the constructor is invalid  (ctor is  def 
__init__(self, dbag)  )

Also i believe for SDN provided networks there is something overlooked as we 
don't see the ip tables set for the VR to respond to password reset requests.  
We believe the script is not setting iptables_change = True in case of networks 
for which the VR is not in the dataplane.


I suggest this PR is backed out for now it this is not an urgent add to the
4.10 release, or we spend time at fixing it.

We definitely want to help in making that happen.


Thanks,

Kris

-- Nuage Networks

On 20 June 2017 at 07:45, Rajani Karuturi <raj...@apache.org> wrote:

> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473
> ac07
> ab3e8424cd
> Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> Branch:
> https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
>
> New PRs merged since RC4: #2150 and #2089
>
> 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)
>
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>

RE: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Marty Godsey]

Is XenServer 7.1 support being added in this release?

Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC

-Original Message-
From: Kris Sterckx [mailto:kris.ster...@nuagenetworks.net] 
Sent: Tuesday, June 20, 2017 3:35 PM
To: dev@cloudstack.apache.org
Subject: Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

I am sorry, I need to vote -1


https://github.com/apache/cloudstack/pull/2084  is causing password reset 
issues for us (Nuage) (i know in native tests pass though...).

We are trying to provide a fix but the following modified VR script is having 
severe issues :

https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
 :

- import of  CsPassword  is missing

- line 910 : this invocation of the constructor is invalid  (ctor is  def 
__init__(self, dbag)  )

Also i believe for SDN provided networks there is something overlooked as we 
don't see the ip tables set for the VR to respond to password reset requests.  
We believe the script is not setting iptables_change = True in case of networks 
for which the VR is not in the dataplane.


I suggest this PR is backed out for now it this is not an urgent add to the
4.10 release, or we spend time at fixing it.

We definitely want to help in making that happen.


Thanks,

Kris

-- Nuage Networks

On 20 June 2017 at 07:45, Rajani Karuturi <raj...@apache.org> wrote:

> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473
> ac07
> ab3e8424cd
> Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> Branch: 
> https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
>
> New PRs merged since RC4: #2150 and #2089
>
> 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)
>
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Kris Sterckx]

I am sorry, I need to vote -1


https://github.com/apache/cloudstack/pull/2084  is causing password reset
issues for us (Nuage) (i know in native tests pass though...).

We are trying to provide a fix but the following modified VR script is
having severe issues :

https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
 :

- import of  CsPassword  is missing

- line 910 : this invocation of the constructor is invalid  (ctor is  def
__init__(self, dbag)  )

Also i believe for SDN provided networks there is something overlooked as
we don't see the ip tables set for the VR to respond to password reset
requests.  We believe the script is not setting iptables_change = True in
case of networks for which the VR is not in the dataplane.


I suggest this PR is backed out for now it this is not an urgent add to the
4.10 release, or we spend time at fixing it.

We definitely want to help in making that happen.


Thanks,

Kris

-- Nuage Networks

On 20 June 2017 at 07:45, Rajani Karuturi  wrote:

> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07
> ab3e8424cd
> Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
>
> New PRs merged since RC4: #2150 and #2089
>
> 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)
>
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Tutkowski, Mike]

I should also point out that I performed my tests on a fresh system (I did not 
upgrade from a prior system).

On 6/20/17, 9:24 AM, "Tutkowski, Mike"  wrote:

+1 (binding)

I ran all of the managed-storage automated regression tests against the 
prior RC. The results can be located here: 
https://github.com/apache/cloudstack/pull/2141.

As noted in https://github.com/apache/cloudstack/pull/2150, I submitted 
fixes to resolve two issues I had discovered.

I verified this new code is present in the new RC. I also examined the new 
commits to this new RC that were not related to my PR and I am comfortable that 
it should not adversely impact managed storage.

In addition to the automated tests noted above (which are related to 
XenServer), I performed a lot of manual testing using managed storage with 
vSphere and KVM and it all passed.

Thanks!
Mike

On 6/19/17, 11:45 PM, "Rajani Karuturi"  wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a 
vote:

Git Branch and Commit SH:

https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07ab3e8424cd
Commit:058e34224c0555396c043c6473ac07ab3e8424cd
Branch: 
https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/

New PRs merged since RC4: #2150 and #2089

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)


Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Milamber]

Hello,

I've tested this version on Ubuntu 16.04 / KVM with xenial deb packages 
(generated with docker build).


1/ One (major?) issue : On the management node, the 
cloudstack-management service don't start correctly. The error message 
from systemctl/jsvc is:
 jsvc.exec[9299]: 2017-06-20 16:29:35 9297 jsvc.exec error: Service 
killed by signal 11


(signal 11 is segmentation fault)

I can start the management service directly with the java command (with 
openjdk8 or oracle jdk8)



2/ One minor issue: during the first startup of the management service, 
the DB update process have this error [see below]


3/ A lot of this message in the log:
Tue Jun 20 18:10:18 WET 2017 WARN: Establishing SSL connection without 
server's identity verification is not recommended. According to MySQL 
5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be 
established by default if explicit option isn't set. For compliance with 
existing applications not using SSL the verifyServerCertificate property 
is set to 'false'. You need either to explicitly disable SSL by setting 
useSSL=false, or set useSSL=true and provide truststore for server 
certificate verification.


4/ Always this error using cloudmonkey
(xenial-mgr1) >  update configuration name="vm.password.length" value="8"
Error 431: Please enter a value greater than 6 for the configuration 
parameter:vm.password.length

cserrorcode = 4350
errorcode = 431
errortext = Please enter a value greater than 6 for the configuration 
parameter:vm.password.length


Fix by this PR: https://github.com/apache/cloudstack/pull/1902 
(CLOUDSTACK-9736)



Milamber

===

INFO  [c.c.u.DatabaseUpgradeChecker] (localhost-startStop-1:null) 
(logid:) DB version = 4.0.0 Code Version = 4.10.0.0
INFO  [c.c.u.DatabaseUpgradeChecker] (localhost-startStop-1:null) 
(logid:) Database upgrade must be performed from 4.0.0 to 4.10.0.0
INFO  [c.c.u.DatabaseUpgradeChecker] (localhost-startStop-1:null) 
(logid:) Cleanup upgrade Upgrade40to41 to upgrade from 4.0.0-4.1.0 to 4.1.0
ERROR [c.c.u.d.Upgrade410to420] (localhost-startStop-1:null) (logid:) 
migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in 
'field list'
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown 
column 'iso_id1' in 'field list'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
at com.mysql.jdbc.Util.getInstance(Util.java:387)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:939)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3878)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2478)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2625)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2551)
at 
com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861)
at 
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1962)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at 
com.cloud.upgrade.dao.Upgrade410to420.migrateDatafromIsoIdInVolumesTable(Upgrade410to420.java:2381)
at 
com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:110)
at 
com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:429)
at 
com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:509)
at 
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
at 
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)
at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:879)
at 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Tutkowski, Mike]

+1 (binding)

I ran all of the managed-storage automated regression tests against the prior 
RC. The results can be located here: 
https://github.com/apache/cloudstack/pull/2141.

As noted in https://github.com/apache/cloudstack/pull/2150, I submitted fixes 
to resolve two issues I had discovered.

I verified this new code is present in the new RC. I also examined the new 
commits to this new RC that were not related to my PR and I am comfortable that 
it should not adversely impact managed storage.

In addition to the automated tests noted above (which are related to 
XenServer), I performed a lot of manual testing using managed storage with 
vSphere and KVM and it all passed.

Thanks!
Mike

On 6/19/17, 11:45 PM, "Rajani Karuturi"  wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:

https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07ab3e8424cd
Commit:058e34224c0555396c043c6473ac07ab3e8424cd
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/

New PRs merged since RC4: #2150 and #2089

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)


Thanks,
~Rajani
http://cloudplatform.accelerite.com/

[VOTE] Apache CloudStack 4.10.0.0 RC5

[Rajani Karuturi]

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07ab3e8424cd
Commit:058e34224c0555396c043c6473ac07ab3e8424cd
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/

New PRs merged since RC4: #2150 and #2089

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)


Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

FYI: I located what was going on with VMware + managed storage. It looks like 
there was a feature that went in (at some point…not sure when) that added the 
ability to resize a root disk (so it doesn’t have to be the same size as the 
template it uses) when spinning up a VM. That code triggered an exception with 
managed storage because it was appending an extra “.vmdk” on to the file name 
(so the VMDK file couldn’t be located in the datastore). I have corrected the 
problem and pushed a second commit to PR 2141.

https://github.com/apache/cloudstack/pull/2141

If we’d like this targeted against master, let me know.

Thanks!
Mike

On 6/13/17, 4:56 AM, "Daan Hoogland"  wrote:

this is why i say we should branch on first RC, fix in release branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens  
wrote:
> I know it is hard to justify not merging PRs that seem ready but are not
> blockers in an RC, but it is a vicious circle which ultimately results in 
a
> longer RC process.
>
> It is something i struggled with as a release manager as well.
>
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi"  wrote:
>
> Thanks Mike,
>
> Will hold off next RC until we hear an update from you.
>
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi everyone,
>
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I’d like
> to investigate before we spin up the next RC. Let’s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>
> Thanks!
> Mike
>
> On 6/12/17, 2:40 AM, "Wido den Hollander" 
> wrote:
>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> :
>>
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
> it, I’m +1 on the new RC as long as this is the only commit added
> to it since the current RC.
>
> Thanks Mike!
>
> If this PR is good we should probably merge it asap and go for
> RC5.
>
> 4.10 should really be released by now.
>
> Wido
>
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
> snapshots on primary storage (which is a feature managed storage
> can support):
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>>
>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>>
>> At a high level, what it does is remove a row from the
> cloud.snapshot_store_ref table when a volume is deleted that has
> one or more volume snapshots.
>>
>> This is fine for non-managed (traditional) storage; however,
> managed storage can store volume snapshots on primary storage, so
> removing this row breaks that functionality.
>>
>> I can fix the problem that this commit introduced by looking
> at the primary storage that supports the volume snapshot and
> checking the following: 1) Is this managed storage? 2) If yes, is
> the snapshot in question stored on that primary storage?
>>
>> The problem is I will be out of the office for a couple weeks
> and will not be able to address this until I return.
>>
>> We could revert the commit, but I still will not have time to
> run the managed-storage regression test suite until I return.
>>
>> On a side note, it looks like this commit was introduced since
> the most recent RC. I would argue that it was not a blocker and
> should not have been placed into the new RC. We (as a community)
> tend to have a lot of code go in between RCs and that just
> increases the chances of introducing critical issues and thus
> delaying the release. We’ve gotten better at this over the years,
> but we should focus more on only allowing the entry of new code
> into a follow-on RC that is critical (or so trivial as to not at
> all be likely to introduce any problems…like fixing an error
> message).
>>

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Daan Hoogland]

this is why i say we should branch on first RC, fix in release branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens  wrote:
> I know it is hard to justify not merging PRs that seem ready but are not
> blockers in an RC, but it is a vicious circle which ultimately results in a
> longer RC process.
>
> It is something i struggled with as a release manager as well.
>
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi"  wrote:
>
> Thanks Mike,
>
> Will hold off next RC until we hear an update from you.
>
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi everyone,
>
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I’d like
> to investigate before we spin up the next RC. Let’s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>
> Thanks!
> Mike
>
> On 6/12/17, 2:40 AM, "Wido den Hollander" 
> wrote:
>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> :
>>
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
> it, I’m +1 on the new RC as long as this is the only commit added
> to it since the current RC.
>
> Thanks Mike!
>
> If this PR is good we should probably merge it asap and go for
> RC5.
>
> 4.10 should really be released by now.
>
> Wido
>
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
> snapshots on primary storage (which is a feature managed storage
> can support):
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>>
>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>>
>> At a high level, what it does is remove a row from the
> cloud.snapshot_store_ref table when a volume is deleted that has
> one or more volume snapshots.
>>
>> This is fine for non-managed (traditional) storage; however,
> managed storage can store volume snapshots on primary storage, so
> removing this row breaks that functionality.
>>
>> I can fix the problem that this commit introduced by looking
> at the primary storage that supports the volume snapshot and
> checking the following: 1) Is this managed storage? 2) If yes, is
> the snapshot in question stored on that primary storage?
>>
>> The problem is I will be out of the office for a couple weeks
> and will not be able to address this until I return.
>>
>> We could revert the commit, but I still will not have time to
> run the managed-storage regression test suite until I return.
>>
>> On a side note, it looks like this commit was introduced since
> the most recent RC. I would argue that it was not a blocker and
> should not have been placed into the new RC. We (as a community)
> tend to have a lot of code go in between RCs and that just
> increases the chances of introducing critical issues and thus
> delaying the release. We’ve gotten better at this over the years,
> but we should focus more on only allowing the entry of new code
> into a follow-on RC that is critical (or so trivial as to not at
> all be likely to introduce any problems…like fixing an error
> message).
>>
>> Thanks for your efforts on this, everyone!
>> Mike
>>
>> On 6/9/17, 8:52 AM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi Rajani,
>>
>> I will see if I can get all of my managed-storage testing
> (both automated and manual) done today. If not, we’ll need to see
> if someone else can complete it before we OK this RC as I won’t
> be back in the office for a couple weeks. I’ll report back later
> today.
>>
>> Thanks,
>> Mike
>>
>> On 6/9/17, 2:34 AM, "Rajani Karuturi" 
> wrote:
>>
>> Yup. thats right. I dont know how it happened but, it created
>> from the previous RC commit. The script is supposed to do a
> git
>> pull. I didn't notice any failures. Not sure what went wrong.
>>
>> Thanks for finding it mike. I am creating RC4 now and
> cancelling
>> this.
>>
>> ~ Rajani
>>
>> http://cloudplatform.accelerite.com/
>>
>> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
>> (mike.tutkow...@netapp.com) wrote:
>>
>> Hi Rajani,
>>
>> I don’t see the following PR in this RC:
>>
>> https://github.com/apache/cloudstack/pull/2098
>>
>> I ran all of my managed-storage regression tests. They all
>> passed with the exception of the one that 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Will Stevens]

I know it is hard to justify not merging PRs that seem ready but are not
blockers in an RC, but it is a vicious circle which ultimately results in a
longer RC process.

It is something i struggled with as a release manager as well.

On Jun 13, 2017 1:56 AM, "Rajani Karuturi"  wrote:

Thanks Mike,

Will hold off next RC until we hear an update from you.

Regarding merging non-blockers, unfortunately, its a side-effect
of taking more than three months in the RC phase :(

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 13, 2017 at 10:10 AM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi everyone,

I had a little time this evening and re-ran some VMware-related
tests around managed storage. I noticed a problem that I’d like
to investigate before we spin up the next RC. Let’s hold off on
the next RC until I can find out more (I should know more within
24 hours).

Thanks!
Mike

On 6/12/17, 2:40 AM, "Wido den Hollander" 
wrote:

> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
:
>
>
> Hi,
>
> I opened a PR against the most recent RC:
https://github.com/apache/cloudstack/pull/2141
>
> I ran all managed-storage regression tests against it and they
pass (as noted in detail in the PR).
>
> If someone wants to take this code and create a new RC from
it, I’m +1 on the new RC as long as this is the only commit added
to it since the current RC.

Thanks Mike!

If this PR is good we should probably merge it asap and go for
RC5.

4.10 should really be released by now.

Wido

>
> Thanks!
> Mike
>
> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
 wrote:
>
> Hi everyone,
>
> I found a critical issue that was introduced into this RC
since the most recent RC, so I am -1 on this RC.
>
> The fix for this ticket breaks the support for storing volume
snapshots on primary storage (which is a feature managed storage
can support):
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>
> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>
> At a high level, what it does is remove a row from the
cloud.snapshot_store_ref table when a volume is deleted that has
one or more volume snapshots.
>
> This is fine for non-managed (traditional) storage; however,
managed storage can store volume snapshots on primary storage, so
removing this row breaks that functionality.
>
> I can fix the problem that this commit introduced by looking
at the primary storage that supports the volume snapshot and
checking the following: 1) Is this managed storage? 2) If yes, is
the snapshot in question stored on that primary storage?
>
> The problem is I will be out of the office for a couple weeks
and will not be able to address this until I return.
>
> We could revert the commit, but I still will not have time to
run the managed-storage regression test suite until I return.
>
> On a side note, it looks like this commit was introduced since
the most recent RC. I would argue that it was not a blocker and
should not have been placed into the new RC. We (as a community)
tend to have a lot of code go in between RCs and that just
increases the chances of introducing critical issues and thus
delaying the release. We’ve gotten better at this over the years,
but we should focus more on only allowing the entry of new code
into a follow-on RC that is critical (or so trivial as to not at
all be likely to introduce any problems…like fixing an error
message).
>
> Thanks for your efforts on this, everyone!
> Mike
>
> On 6/9/17, 8:52 AM, "Tutkowski, Mike"
 wrote:
>
> Hi Rajani,
>
> I will see if I can get all of my managed-storage testing
(both automated and manual) done today. If not, we’ll need to see
if someone else can complete it before we OK this RC as I won’t
be back in the office for a couple weeks. I’ll report back later
today.
>
> Thanks,
> Mike
>
> On 6/9/17, 2:34 AM, "Rajani Karuturi" 
wrote:
>
> Yup. thats right. I dont know how it happened but, it created
> from the previous RC commit. The script is supposed to do a
git
> pull. I didn't notice any failures. Not sure what went wrong.
>
> Thanks for finding it mike. I am creating RC4 now and
cancelling
> this.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi Rajani,
>
> I don’t see the following PR in this RC:
>
> https://github.com/apache/cloudstack/pull/2098
>
> I ran all of my managed-storage regression tests. They all
> passed with the exception of the one that led to PR 2098.
>
> As I examine the RC in a bit more detail, it sits on top of
> ed2f573, but I think it should sit on top of ed376fc.
>
> As a result, I am -1 on the RC.
>
> It takes me about a day to run all of the managed-storage
> regression tests and I am out of the office for the next
couple
> weeks, so I’d really like to avoid another RC until I’m back
and
> able to test the next RC.
>
> 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

Thanks Mike,

Will hold off next RC until we hear an update from you.

Regarding merging non-blockers, unfortunately, its a side-effect
of taking more than three months in the RC phase :(

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 13, 2017 at 10:10 AM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi everyone,

I had a little time this evening and re-ran some VMware-related
tests around managed storage. I noticed a problem that I’d like
to investigate before we spin up the next RC. Let’s hold off on
the next RC until I can find out more (I should know more within
24 hours).

Thanks!
Mike

On 6/12/17, 2:40 AM, "Wido den Hollander" 
wrote:

> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
:
>
>
> Hi,
>
> I opened a PR against the most recent RC:
https://github.com/apache/cloudstack/pull/2141
>
> I ran all managed-storage regression tests against it and they
pass (as noted in detail in the PR).
>
> If someone wants to take this code and create a new RC from
it, I’m +1 on the new RC as long as this is the only commit added
to it since the current RC.

Thanks Mike!

If this PR is good we should probably merge it asap and go for
RC5.

4.10 should really be released by now.

Wido

>
> Thanks!
> Mike
>
> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
 wrote:
>
> Hi everyone,
>
> I found a critical issue that was introduced into this RC
since the most recent RC, so I am -1 on this RC.
>
> The fix for this ticket breaks the support for storing volume
snapshots on primary storage (which is a feature managed storage
can support):
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>
> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>
> At a high level, what it does is remove a row from the
cloud.snapshot_store_ref table when a volume is deleted that has
one or more volume snapshots.
>
> This is fine for non-managed (traditional) storage; however,
managed storage can store volume snapshots on primary storage, so
removing this row breaks that functionality.
>
> I can fix the problem that this commit introduced by looking
at the primary storage that supports the volume snapshot and
checking the following: 1) Is this managed storage? 2) If yes, is
the snapshot in question stored on that primary storage?
>
> The problem is I will be out of the office for a couple weeks
and will not be able to address this until I return.
>
> We could revert the commit, but I still will not have time to
run the managed-storage regression test suite until I return.
>
> On a side note, it looks like this commit was introduced since
the most recent RC. I would argue that it was not a blocker and
should not have been placed into the new RC. We (as a community)
tend to have a lot of code go in between RCs and that just
increases the chances of introducing critical issues and thus
delaying the release. We’ve gotten better at this over the years,
but we should focus more on only allowing the entry of new code
into a follow-on RC that is critical (or so trivial as to not at
all be likely to introduce any problems…like fixing an error
message).
>
> Thanks for your efforts on this, everyone!
> Mike
>
> On 6/9/17, 8:52 AM, "Tutkowski, Mike"
 wrote:
>
> Hi Rajani,
>
> I will see if I can get all of my managed-storage testing
(both automated and manual) done today. If not, we’ll need to see
if someone else can complete it before we OK this RC as I won’t
be back in the office for a couple weeks. I’ll report back later
today.
>
> Thanks,
> Mike
>
> On 6/9/17, 2:34 AM, "Rajani Karuturi" 
wrote:
>
> Yup. thats right. I dont know how it happened but, it created
> from the previous RC commit. The script is supposed to do a
git
> pull. I didn't notice any failures. Not sure what went wrong.
>
> Thanks for finding it mike. I am creating RC4 now and
cancelling
> this.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi Rajani,
>
> I don’t see the following PR in this RC:
>
> https://github.com/apache/cloudstack/pull/2098
>
> I ran all of my managed-storage regression tests. They all
> passed with the exception of the one that led to PR 2098.
>
> As I examine the RC in a bit more detail, it sits on top of
> ed2f573, but I think it should sit on top of ed376fc.
>
> As a result, I am -1 on the RC.
>
> It takes me about a day to run all of the managed-storage
> regression tests and I am out of the office for the next
couple
> weeks, so I’d really like to avoid another RC until I’m back
and
> able to test the next RC.
>
> Thanks!
> Mike
>
> On 6/7/17, 4:36 AM, "Rajani Karuturi" 
wrote:
>
> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up
> for a vote:
>
> Git Branch and Commit SH:
>

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

Hi everyone,

I had a little time this evening and re-ran some VMware-related tests around 
managed storage. I noticed a problem that I’d like to investigate before we 
spin up the next RC. Let’s hold off on the next RC until I can find out more (I 
should know more within 24 hours).

Thanks!
Mike

On 6/12/17, 2:40 AM, "Wido den Hollander"  wrote:

> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike" 
:
> 
> 
> Hi,
> 
> I opened a PR against the most recent RC: 
https://github.com/apache/cloudstack/pull/2141
> 
> I ran all managed-storage regression tests against it and they pass (as 
noted in detail in the PR).
> 
> If someone wants to take this code and create a new RC from it, I’m +1 on 
the new RC as long as this is the only commit added to it since the current RC.

Thanks Mike!

If this PR is good we should probably merge it asap and go for RC5.

4.10 should really be released by now.

Wido

> 
> Thanks!
> Mike
> 
> On 6/9/17, 7:43 PM, "Tutkowski, Mike"  wrote:
> 
> Hi everyone,
> 
> I found a critical issue that was introduced into this RC since the 
most recent RC, so I am -1 on this RC.
> 
> The fix for this ticket breaks the support for storing volume 
snapshots on primary storage (which is a feature managed storage can support):
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
> 
> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
> 
> At a high level, what it does is remove a row from the 
cloud.snapshot_store_ref table when a volume is deleted that has one or more 
volume snapshots.
> 
> This is fine for non-managed (traditional) storage; however, managed 
storage can store volume snapshots on primary storage, so removing this row 
breaks that functionality.
> 
> I can fix the problem that this commit introduced by looking at the 
primary storage that supports the volume snapshot and checking the following: 
1) Is this managed storage? 2) If yes, is the snapshot in question stored on 
that primary storage?
> 
> The problem is I will be out of the office for a couple weeks and 
will not be able to address this until I return.
> 
> We could revert the commit, but I still will not have time to run the 
managed-storage regression test suite until I return.
> 
> On a side note, it looks like this commit was introduced since the 
most recent RC. I would argue that it was not a blocker and should not have 
been placed into the new RC. We (as a community) tend to have a lot of code go 
in between RCs and that just increases the chances of introducing critical 
issues and thus delaying the release. We’ve gotten better at this over the 
years, but we should focus more on only allowing the entry of new code into a 
follow-on RC that is critical (or so trivial as to not at all be likely to 
introduce any problems…like fixing an error message).
> 
> Thanks for your efforts on this, everyone!
> Mike
> 
> On 6/9/17, 8:52 AM, "Tutkowski, Mike"  
wrote:
> 
> Hi Rajani,
> 
> I will see if I can get all of my managed-storage testing (both 
automated and manual) done today. If not, we’ll need to see if someone else can 
complete it before we OK this RC as I won’t be back in the office for a couple 
weeks. I’ll report back later today.
> 
> Thanks,
> Mike
> 
> On 6/9/17, 2:34 AM, "Rajani Karuturi"  wrote:
> 
> Yup. thats right. I dont know how it happened but, it created
> from the previous RC commit. The script is supposed to do a 
git
> pull. I didn't notice any failures. Not sure what went wrong.
> 
> Thanks for finding it mike. I am creating RC4 now and 
cancelling
> this.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
> 
> Hi Rajani,
> 
> I don’t see the following PR in this RC:
> 
> https://github.com/apache/cloudstack/pull/2098
> 
> I ran all of my managed-storage regression tests. They all
> passed with the exception of the one that led to PR 2098.
> 
> As I examine the RC in a bit more detail, it sits on top of
> ed2f573, but I think it should sit on top of ed376fc.
> 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Wido den Hollander]

> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike" 
> :
> 
> 
> Hi,
> 
> I opened a PR against the most recent RC: 
> https://github.com/apache/cloudstack/pull/2141
> 
> I ran all managed-storage regression tests against it and they pass (as noted 
> in detail in the PR).
> 
> If someone wants to take this code and create a new RC from it, I’m +1 on the 
> new RC as long as this is the only commit added to it since the current RC.

Thanks Mike!

If this PR is good we should probably merge it asap and go for RC5.

4.10 should really be released by now.

Wido

> 
> Thanks!
> Mike
> 
> On 6/9/17, 7:43 PM, "Tutkowski, Mike"  wrote:
> 
> Hi everyone,
> 
> I found a critical issue that was introduced into this RC since the most 
> recent RC, so I am -1 on this RC.
> 
> The fix for this ticket breaks the support for storing volume snapshots 
> on primary storage (which is a feature managed storage can support):
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
> 
> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
> 
> At a high level, what it does is remove a row from the 
> cloud.snapshot_store_ref table when a volume is deleted that has one or more 
> volume snapshots.
> 
> This is fine for non-managed (traditional) storage; however, managed 
> storage can store volume snapshots on primary storage, so removing this row 
> breaks that functionality.
> 
> I can fix the problem that this commit introduced by looking at the 
> primary storage that supports the volume snapshot and checking the following: 
> 1) Is this managed storage? 2) If yes, is the snapshot in question stored on 
> that primary storage?
> 
> The problem is I will be out of the office for a couple weeks and will 
> not be able to address this until I return.
> 
> We could revert the commit, but I still will not have time to run the 
> managed-storage regression test suite until I return.
> 
> On a side note, it looks like this commit was introduced since the most 
> recent RC. I would argue that it was not a blocker and should not have been 
> placed into the new RC. We (as a community) tend to have a lot of code go in 
> between RCs and that just increases the chances of introducing critical 
> issues and thus delaying the release. We’ve gotten better at this over the 
> years, but we should focus more on only allowing the entry of new code into a 
> follow-on RC that is critical (or so trivial as to not at all be likely to 
> introduce any problems…like fixing an error message).
> 
> Thanks for your efforts on this, everyone!
> Mike
> 
> On 6/9/17, 8:52 AM, "Tutkowski, Mike"  wrote:
> 
> Hi Rajani,
> 
> I will see if I can get all of my managed-storage testing (both 
> automated and manual) done today. If not, we’ll need to see if someone else 
> can complete it before we OK this RC as I won’t be back in the office for a 
> couple weeks. I’ll report back later today.
> 
> Thanks,
> Mike
> 
> On 6/9/17, 2:34 AM, "Rajani Karuturi"  wrote:
> 
> Yup. thats right. I dont know how it happened but, it created
> from the previous RC commit. The script is supposed to do a git
> pull. I didn't notice any failures. Not sure what went wrong.
> 
> Thanks for finding it mike. I am creating RC4 now and cancelling
> this.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
> 
> Hi Rajani,
> 
> I don’t see the following PR in this RC:
> 
> https://github.com/apache/cloudstack/pull/2098
> 
> I ran all of my managed-storage regression tests. They all
> passed with the exception of the one that led to PR 2098.
> 
> As I examine the RC in a bit more detail, it sits on top of
> ed2f573, but I think it should sit on top of ed376fc.
> 
> As a result, I am -1 on the RC.
> 
> It takes me about a day to run all of the managed-storage
> regression tests and I am out of the office for the next couple
> weeks, so I’d really like to avoid another RC until I’m back and
> able to test the next RC.
> 
> Thanks!
> Mike
> 
> On 6/7/17, 4:36 AM, "Rajani Karuturi"  wrote:
> 
> Hi All,
> 
> I've created 4.10.0.0 release with the following artifacts up
> for a vote:
> 
> 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

Hi,

I opened a PR against the most recent RC: 
https://github.com/apache/cloudstack/pull/2141

I ran all managed-storage regression tests against it and they pass (as noted 
in detail in the PR).

If someone wants to take this code and create a new RC from it, I’m +1 on the 
new RC as long as this is the only commit added to it since the current RC.

Thanks!
Mike

On 6/9/17, 7:43 PM, "Tutkowski, Mike"  wrote:

Hi everyone,

I found a critical issue that was introduced into this RC since the most 
recent RC, so I am -1 on this RC.

The fix for this ticket breaks the support for storing volume snapshots on 
primary storage (which is a feature managed storage can support):

https://issues.apache.org/jira/browse/CLOUDSTACK-9685

Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e

At a high level, what it does is remove a row from the 
cloud.snapshot_store_ref table when a volume is deleted that has one or more 
volume snapshots.

This is fine for non-managed (traditional) storage; however, managed 
storage can store volume snapshots on primary storage, so removing this row 
breaks that functionality.

I can fix the problem that this commit introduced by looking at the primary 
storage that supports the volume snapshot and checking the following: 1) Is 
this managed storage? 2) If yes, is the snapshot in question stored on that 
primary storage?

The problem is I will be out of the office for a couple weeks and will not 
be able to address this until I return.

We could revert the commit, but I still will not have time to run the 
managed-storage regression test suite until I return.

On a side note, it looks like this commit was introduced since the most 
recent RC. I would argue that it was not a blocker and should not have been 
placed into the new RC. We (as a community) tend to have a lot of code go in 
between RCs and that just increases the chances of introducing critical issues 
and thus delaying the release. We’ve gotten better at this over the years, but 
we should focus more on only allowing the entry of new code into a follow-on RC 
that is critical (or so trivial as to not at all be likely to introduce any 
problems…like fixing an error message).

Thanks for your efforts on this, everyone!
Mike

On 6/9/17, 8:52 AM, "Tutkowski, Mike"  wrote:

Hi Rajani,

I will see if I can get all of my managed-storage testing (both 
automated and manual) done today. If not, we’ll need to see if someone else can 
complete it before we OK this RC as I won’t be back in the office for a couple 
weeks. I’ll report back later today.

Thanks,
Mike

On 6/9/17, 2:34 AM, "Rajani Karuturi"  wrote:

Yup. thats right. I dont know how it happened but, it created
from the previous RC commit. The script is supposed to do a git
pull. I didn't notice any failures. Not sure what went wrong.

Thanks for finding it mike. I am creating RC4 now and cancelling
this.

~ Rajani

http://cloudplatform.accelerite.com/

On June 9, 2017 at 12:07 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi Rajani,

I don’t see the following PR in this RC:

https://github.com/apache/cloudstack/pull/2098

I ran all of my managed-storage regression tests. They all
passed with the exception of the one that led to PR 2098.

As I examine the RC in a bit more detail, it sits on top of
ed2f573, but I think it should sit on top of ed376fc.

As a result, I am -1 on the RC.

It takes me about a day to run all of the managed-storage
regression tests and I am out of the office for the next couple
weeks, so I’d really like to avoid another RC until I’m back and
able to test the next RC.

Thanks!
Mike

On 6/7/17, 4:36 AM, "Rajani Karuturi"  wrote:

Hi All,

I've created 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=a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Branch: 4.10.0.0-RC20170607T1407

Source release (checksums and signatures are available at the
same
location):

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

Hi everyone,

I found a critical issue that was introduced into this RC since the most recent 
RC, so I am -1 on this RC.

The fix for this ticket breaks the support for storing volume snapshots on 
primary storage (which is a feature managed storage can support):

https://issues.apache.org/jira/browse/CLOUDSTACK-9685

Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e

At a high level, what it does is remove a row from the cloud.snapshot_store_ref 
table when a volume is deleted that has one or more volume snapshots.

This is fine for non-managed (traditional) storage; however, managed storage 
can store volume snapshots on primary storage, so removing this row breaks that 
functionality.

I can fix the problem that this commit introduced by looking at the primary 
storage that supports the volume snapshot and checking the following: 1) Is 
this managed storage? 2) If yes, is the snapshot in question stored on that 
primary storage?

The problem is I will be out of the office for a couple weeks and will not be 
able to address this until I return.

We could revert the commit, but I still will not have time to run the 
managed-storage regression test suite until I return.

On a side note, it looks like this commit was introduced since the most recent 
RC. I would argue that it was not a blocker and should not have been placed 
into the new RC. We (as a community) tend to have a lot of code go in between 
RCs and that just increases the chances of introducing critical issues and thus 
delaying the release. We’ve gotten better at this over the years, but we should 
focus more on only allowing the entry of new code into a follow-on RC that is 
critical (or so trivial as to not at all be likely to introduce any 
problems…like fixing an error message).

Thanks for your efforts on this, everyone!
Mike

On 6/9/17, 8:52 AM, "Tutkowski, Mike"  wrote:

Hi Rajani,

I will see if I can get all of my managed-storage testing (both automated 
and manual) done today. If not, we’ll need to see if someone else can complete 
it before we OK this RC as I won’t be back in the office for a couple weeks. 
I’ll report back later today.

Thanks,
Mike

On 6/9/17, 2:34 AM, "Rajani Karuturi"  wrote:

Yup. thats right. I dont know how it happened but, it created
from the previous RC commit. The script is supposed to do a git
pull. I didn't notice any failures. Not sure what went wrong.

Thanks for finding it mike. I am creating RC4 now and cancelling
this.

~ Rajani

http://cloudplatform.accelerite.com/

On June 9, 2017 at 12:07 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi Rajani,

I don’t see the following PR in this RC:

https://github.com/apache/cloudstack/pull/2098

I ran all of my managed-storage regression tests. They all
passed with the exception of the one that led to PR 2098.

As I examine the RC in a bit more detail, it sits on top of
ed2f573, but I think it should sit on top of ed376fc.

As a result, I am -1 on the RC.

It takes me about a day to run all of the managed-storage
regression tests and I am out of the office for the next couple
weeks, so I’d really like to avoid another RC until I’m back and
able to test the next RC.

Thanks!
Mike

On 6/7/17, 4:36 AM, "Rajani Karuturi"  wrote:

Hi All,

I've created 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=a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Branch: 4.10.0.0-RC20170607T1407

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC3/

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

[VOTE] Apache Cloudstack 4.10.0.0 RC4

[Rajani Karuturi]

Hi All,

I've created 4.10.0.0 release with the following artifacts up for a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/2d3586b3fca18283e8e2449add2bf1864c4260f1
Commit:2d3586b3fca18283e8e2449add2bf1864c4260f1
Branch:
https://github.com/apache/cloudstack/commits/4.10.0.0-RC20170609T1354

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC4/

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 RC3

[Rajani Karuturi]

Yup. thats right. I dont know how it happened but, it created
from the previous RC commit. The script is supposed to do a git
pull. I didn't notice any failures. Not sure what went wrong.

Thanks for finding it mike. I am creating RC4 now and cancelling
this.

~ Rajani

http://cloudplatform.accelerite.com/

On June 9, 2017 at 12:07 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi Rajani,

I don’t see the following PR in this RC:

https://github.com/apache/cloudstack/pull/2098

I ran all of my managed-storage regression tests. They all
passed with the exception of the one that led to PR 2098.

As I examine the RC in a bit more detail, it sits on top of
ed2f573, but I think it should sit on top of ed376fc.

As a result, I am -1 on the RC.

It takes me about a day to run all of the managed-storage
regression tests and I am out of the office for the next couple
weeks, so I’d really like to avoid another RC until I’m back and
able to test the next RC.

Thanks!
Mike

On 6/7/17, 4:36 AM, "Rajani Karuturi"  wrote:

Hi All,

I've created 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=a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Branch: 4.10.0.0-RC20170607T1407

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC3/

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

Hi Rajani,

I don’t see the following PR in this RC:

https://github.com/apache/cloudstack/pull/2098

I ran all of my managed-storage regression tests. They all passed with the 
exception of the one that led to PR 2098.

As I examine the RC in a bit more detail, it sits on top of ed2f573, but I 
think it should sit on top of ed376fc.

As a result, I am -1 on the RC.

It takes me about a day to run all of the managed-storage regression tests and 
I am out of the office for the next couple weeks, so I’d really like to avoid 
another RC until I’m back and able to test the next RC.

Thanks!
Mike

On 6/7/17, 4:36 AM, "Rajani Karuturi"  wrote:

Hi All,

I've created 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=a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Branch: 4.10.0.0-RC20170607T1407

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC3/

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

[VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

Hi All,

I've created 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=a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
Branch: 4.10.0.0-RC20170607T1407

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC3/

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)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Wido den Hollander]

Will look into it asap. Just got back from travel from US.

Wido

> Op 24 mei 2017 om 12:14 heeft Rajani Karuturi <raj...@apache.org> het 
> volgende geschreven:
> 
> PR 2089 - vRouters fixes & performance improvement is the only blocker for 
> RC3. If we can resolve it quickly, I will create RC3.
> 
> Thanks,
> ~ Rajani
> http://cloudplatform.accelerite.com/
> 
>> On May 18, 2017 at 5:12 PM, Rohit Yadav (rohit.ya...@shapeblue.com) wrote:
> 
>> Thanks Rajani, 
>> 
>> 
>> I'll try to help over those pending PRs. 
>> 
>> 
>> Regards. 
>> 
>>  
>> From: Rajani K <rjnk...@gmail.com> 
>> Sent: 18 May 2017 15:50:56 
>> To: dev@cloudstack.apache.org 
>> Cc: Will Stevens; Wido den Hollander 
>> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2 
>> 
>> These are the pending PRs for RC3: 
>> https://github.com/apache/cloudstack/milestone/2 
>> 
>> Blockers are tagged as such. 
>> 
>> Thanks, 
>> 
>> ~ Rajani 
>> 
>> On May 18, 2017 at 2:49 PM, Rohit Yadav 
>> (rohit.ya...@shapeblue.com) wrote: 
>> 
>> All, 
>> 
>> Other than Mike's blocker fix #2098, do we have any other 
>> outstanding issues blocking the 4.10.0.0 release? 
>> 
>> Regards. 
>> 
>>  
>> From: Tutkowski, Mike <mike.tutkow...@netapp.com> 
>> Sent: 12 May 2017 01:53:44 
>> To: dev@cloudstack.apache.org 
>> Cc: Will Stevens; Wido den Hollander 
>> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2 
>> 
>> Hi Rajani, 
>> 
>> I opened the following PR (against master) to fix the blocker 
>> CLOUDSTACK-9917: 
>> 
>> https://github.com/apache/cloudstack/pull/2098 
>> 
>> Thanks! 
>> Mike 
>> 
>> On 5/10/17, 10:40 PM, "Rajani Karuturi" <raj...@apache.org> 
>> wrote: 
>> 
>> Thanks for testing Mike. 
>> 
>> RC3=RC2+PR#2089+Mike'sPR 
>> 
>> Any other additions? 
>> 
>> ~ Rajani 
>> 
>> http://cloudplatform.accelerite.com/ 
>> 
>> On May 10, 2017 at 7:47 PM, Tutkowski, Mike 
>> (mike.tutkow...@netapp.com) wrote: 
>> 
>> I've been running regression tests against the release 
>> candidate. 
>> 
>> So far, all tests but one have passed. 
>> 
>> The failing test is related to the storage cleanup thread. It 
>> looks like some code was changed in 4.10 with regards to this 
>> thread and that change is causing a problem around cleanup for 
>> managed storage in a particular situation. 
>> 
>> As a result of this, I was going to vote -1. 
>> 
>> I'm guessing the fix will not be complicated, but is important. 
>> 
>> I don't yet have the fix, however. Once I do, I can reply to 
>> this thread. 
>> 
>> On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org> 
>> wrote: 
>> 
>> I agree to your concerns Wido. I did check the PR before 
>> creating 
>> RC2. There were some outstanding comments on it. 
>> 
>> If no one has started testing RC2 and there are no objections, 
>> we 
>> can cancel this vote, quickly merge the PR and create RC3. 
>> 
>> ~ Rajani 
>> 
>> http://cloudplatform.accelerite.com/ 
>> 
>> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl) 
>> wrote: 
>> 
>> Op 10 mei 2017 om 0:33 schreef Will Stevens 
>> <williamstev...@gmail.com>: 
>> 
>> 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? 
>> 
>> Well, the provisioning is the same between Basic and Advanced. 
>> The VR is utterly slow in doing that. 
>> 
>> It happens when you have a lot of VMs in those networks. 
>> 
>> In our case we have a couple of thousands VMs. 
>> 
>> What I'd like to prevent is that this is merged into 4.9.3, but 
>> is not in 4.10. 
>> 
>> However, I don't want to delay 4.10 any longer. 
>> 
>> Wido 
>> 
>> On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl> 
>> 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://git

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rajani Karuturi]

PR 2089 - vRouters fixes & performance improvement is the only
blocker for RC3. If we can resolve it quickly, I will create RC3.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 18, 2017 at 5:12 PM, Rohit Yadav
(rohit.ya...@shapeblue.com) wrote:

Thanks Rajani,

I'll try to help over those pending PRs.

Regards.


From: Rajani K <rjnk...@gmail.com>
Sent: 18 May 2017 15:50:56
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

These are the pending PRs for RC3:
https://github.com/apache/cloudstack/milestone/2

Blockers are tagged as such.

Thanks,

~ Rajani

On May 18, 2017 at 2:49 PM, Rohit Yadav
(rohit.ya...@shapeblue.com) wrote:

All,

Other than Mike's blocker fix #2098, do we have any other
outstanding issues blocking the 4.10.0.0 release?

Regards.


From: Tutkowski, Mike <mike.tutkow...@netapp.com>
Sent: 12 May 2017 01:53:44
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

Hi Rajani,

I opened the following PR (against master) to fix the blocker
CLOUDSTACK-9917:

https://github.com/apache/cloudstack/pull/2098

Thanks!
Mike

On 5/10/17, 10:40 PM, "Rajani Karuturi" <raj...@apache.org>
wrote:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release
candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org>
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
<williamstev...@gmail.com>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl>
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
<raj...@apache.org>:

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/

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com 
( http://www.shapeblue.com<http://www.shapeblue.com )> 
( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

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

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rohit Yadav]

Thanks Rajani,


I'll try to help over those pending PRs.


Regards.


From: Rajani K <rjnk...@gmail.com>
Sent: 18 May 2017 15:50:56
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

These are the pending PRs for RC3:
https://github.com/apache/cloudstack/milestone/2

Blockers are tagged as such.

Thanks,

~ Rajani

On May 18, 2017 at 2:49 PM, Rohit Yadav
(rohit.ya...@shapeblue.com) wrote:

All,

Other than Mike's blocker fix #2098, do we have any other
outstanding issues blocking the 4.10.0.0 release?

Regards.


From: Tutkowski, Mike <mike.tutkow...@netapp.com>
Sent: 12 May 2017 01:53:44
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

Hi Rajani,

I opened the following PR (against master) to fix the blocker
CLOUDSTACK-9917:

https://github.com/apache/cloudstack/pull/2098

Thanks!
Mike

On 5/10/17, 10:40 PM, "Rajani Karuturi" <raj...@apache.org>
wrote:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release
candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org>
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
<williamstev...@gmail.com>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl>
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
<raj...@apache.org>:

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/

rohit.ya...@shapeblue.com
www.shapeblue.com<http://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: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rajani K]

These are the pending PRs for RC3:
https://github.com/apache/cloudstack/milestone/2

Blockers are tagged as such.

Thanks,

~ Rajani

On May 18, 2017 at 2:49 PM, Rohit Yadav
(rohit.ya...@shapeblue.com) wrote:

All,

Other than Mike's blocker fix #2098, do we have any other
outstanding issues blocking the 4.10.0.0 release?

Regards.


From: Tutkowski, Mike <mike.tutkow...@netapp.com>
Sent: 12 May 2017 01:53:44
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

Hi Rajani,

I opened the following PR (against master) to fix the blocker
CLOUDSTACK-9917:

https://github.com/apache/cloudstack/pull/2098

Thanks!
Mike

On 5/10/17, 10:40 PM, "Rajani Karuturi" <raj...@apache.org>
wrote:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release
candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org>
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
<williamstev...@gmail.com>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl>
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
<raj...@apache.org>:

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/

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

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rohit Yadav]

All,


Other than Mike's blocker fix #2098, do we have any other outstanding issues 
blocking the 4.10.0.0 release?


Regards.


From: Tutkowski, Mike <mike.tutkow...@netapp.com>
Sent: 12 May 2017 01:53:44
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

Hi Rajani,

I opened the following PR (against master) to fix the blocker CLOUDSTACK-9917:

https://github.com/apache/cloudstack/pull/2098

Thanks!
Mike

On 5/10/17, 10:40 PM, "Rajani Karuturi" <raj...@apache.org> wrote:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org>
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
<williamstev...@gmail.com>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl>
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
<raj...@apache.org>:

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/


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

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

Hi Rajani,

I opened the following PR (against master) to fix the blocker CLOUDSTACK-9917:

https://github.com/apache/cloudstack/pull/2098

Thanks!
Mike

On 5/10/17, 10:40 PM, "Rajani Karuturi"  wrote:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

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

[Rohit Yadav]

Hi Rajani,


While they are not blockers, but please consider merging these bugfix PRs:


https://github.com/apache/cloudstack/pull/2075
https://github.com/apache/cloudstack/pull/2070


Thanks.


Regards.



From: Rajani Karuturi <raj...@apache.org>
Sent: 11 May 2017 10:10:35
To: dev@cloudstack.apache.org
Cc: Will Stevens; Wido den Hollander
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi <raj...@apache.org>
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
<williamstev...@gmail.com>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

On May 9, 2017 5:39 PM, "Wido den Hollander" <w...@widodh.nl>
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
<raj...@apache.org>:

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/

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

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

Hi,

I went ahead and opened the following PR:

https://github.com/apache/cloudstack/pull/2096

Talk to you later!
Mike

On May 10, 2017, at 9:26 PM, Tutkowski, Mike 
> wrote:

Hi,

I analyzed the problematic PR and fixed the issue this way:

https://github.com/mike-tutkowski/cloudstack/commit/c463057c82656a4d7564fc9205bb79517317c629

If a couple people could take a look at this code and see what you think, I can 
create a PR against the RC and we can make use of this code in the next RC for 
4.10.

Thanks!
Mike

On 5/10/17, 2:34 PM, "Tutkowski, Mike" 
> wrote:

   OK, here’s the gist of the problem:

   In StorageManagerImpl.cleanupStorage(boolean), the following line in 4.9

   List vols = 
_volsDao.listVolumesToBeDestroyed(new Date(System.currentTimeMillis() - ((long) 
StorageCleanupDelay.value() << 10)));

   was changed to the following in 4.10

   // ROOT volumes will be destroyed as part of VM cleanup
   List vols = 
_volsDao.listNonRootVolumesToBeDestroyed(new Date(System.currentTimeMillis() - 
((long) StorageCleanupDelay.value() << 10)));

   This leads to a problem (for both managed and traditional storage) in the 
following situation:

   For example: Let’s say we have a system VM running on NFS primary storage. 
We then put this primary storage into maintenance mode, which creates the 
system VM (with the same name) on a different primary storage (we do not create 
a new row in the cloud.vm_instance table for this VM). While this VM works, the 
original root disk of the system VM remains on the original primary storage and 
is not destroyed by the code in StorageManagerImpl.cleanupStorage(boolean) in 
4.10 because 4.10 (as shown above) only asks for non-root volumes to consider 
for deletion. In the 4.9 version of the code, the original root disk is cleaned 
up in StorageManagerImpl.cleanupStorage(boolean). The problem with 4.10 relying 
on a root disk always being deleted when the VM it belongs to is deleted is 
that in a situation like this that the system VM doesn’t get deleted at this 
point – it gets a new root disk that’s hosted by a different primary storage 
(so now it’s original root disk is stranded).

   Here is the ticket and the PR where the code change went in:
   https://issues.apache.org/jira/browse/CLOUDSTACK-9660
   https://github.com/apache/cloudstack/pull/1825

   To me, this needs to be fixed before we release 4.10, so I am -1 on this RC.

   My suggestion would be to basically revert PR 1825 and to make use of just 
bits and pieces of it.

   For example, this part should be kept:

   -
volService.expungeVolumeAsync(volFactory.getVolume(vol.getId()));
+VolumeInfo volumeInfo = 
volFactory.getVolume(vol.getId());
+if (volumeInfo != null) {
+volService.expungeVolumeAsync(volumeInfo);
+} else {
+s_logger.debug("Volume " + vol.getUuid() + 
" is already destroyed");
+}

   On 5/10/17, 8:17 AM, "Tutkowski, Mike" 
> wrote:

   I've been running regression tests against the release candidate.

   So far, all tests but one have passed.

   The failing test is related to the storage cleanup thread. It looks like 
some code was changed in 4.10 with regards to this thread and that change is 
causing a problem around cleanup for managed storage in a particular situation.

   As a result of this, I was going to vote -1.

   I'm guessing the fix will not be complicated, but is important.

   I don't yet have the fix, however. Once I do, I can reply to this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:

I agree to your concerns Wido. I did check the PR before creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections, we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander 
(w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
>:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Today I am working  on this PR. Hopefully I will complete it.

Yesterday fixed test_01_isolate_network_FW_PF_default_routes_egress_true, 
test_01_isolate_network_FW_PF_default_routes_egress_false. Today working on RVR 
related tests.

Thanks,
Jayapal
On May 11, 2017, at 10:38 AM, Will Stevens 
> wrote:

Is 1866 ready? It looks like CI is failing on a lot of relevant network tests.

On May 11, 2017 12:48 AM, "Jayapal Uradi" 
> wrote:
Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi 
> > wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> >
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander 
> (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> >:
>
> 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?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> 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/




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.





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 

Re:Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Haijiao]

HI, Rajani



I think these 4 are ready and good for merging into RC3.


CLOUDSTACK-9690: Scale CentOS7 VM fails with error #1849
CLOUDSTACK-9017 : VPC VR DHCP broken for multihomed guest VMs #2082
CLOUDSTACK-9824: Resource count for Primary storage is considered twice - while 
creating and while attaching the disk #1992
CLOUDSTACK-9112: Deploy VM failing frequently due to capacity calculation not 
synchron… #1180






在2017年05月11 12时40分, "Rajani Karuturi"写道:

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

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

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Will Stevens]

Is 1866 ready? It looks like CI is failing on a lot of relevant network
tests.

On May 11, 2017 12:48 AM, "Jayapal Uradi" 
wrote:

Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi  wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
>
> 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?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> 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/




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.

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Jayapal Uradi]

Hi Rajani,

Also please  include the PR#1866.

Thanks,
Jayapal

> On May 11, 2017, at 10:10 AM, Rajani Karuturi  wrote:
>
> Thanks for testing Mike.
>
> RC3=RC2+PR#2089+Mike'sPR
>
> Any other additions?
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 7:47 PM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> I've been running regression tests against the release candidate.
>
> So far, all tests but one have passed.
>
> The failing test is related to the storage cleanup thread. It
> looks like some code was changed in 4.10 with regards to this
> thread and that change is causing a problem around cleanup for
> managed storage in a particular situation.
>
> As a result of this, I was going to vote -1.
>
> I'm guessing the fix will not be complicated, but is important.
>
> I don't yet have the fix, however. Once I do, I can reply to
> this thread.
>
> On May 10, 2017, at 5:47 AM, Rajani Karuturi 
> wrote:
>
> I agree to your concerns Wido. I did check the PR before
> creating
> RC2. There were some outstanding comments on it.
>
> If no one has started testing RC2 and there are no objections,
> we
> can cancel this vote, quickly merge the PR and create RC3.
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
>
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
>
> 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?
>
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
>
> It happens when you have a lot of VMs in those networks.
>
> In our case we have a couple of thousands VMs.
>
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
>
> However, I don't want to delay 4.10 any longer.
>
> Wido
>
> 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/




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.

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Rajani Karuturi]

Thanks for testing Mike.

RC3=RC2+PR#2089+Mike'sPR

Any other additions?

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 7:47 PM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It
looks like some code was changed in 4.10 with regards to this
thread and that change is causing a problem around cleanup for
managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to
this thread.

On May 10, 2017, at 5:47 AM, Rajani Karuturi 
wrote:

I agree to your concerns Wido. I did check the PR before
creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections,
we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

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

[Tutkowski, Mike]

Hi,

I analyzed the problematic PR and fixed the issue this way:

https://github.com/mike-tutkowski/cloudstack/commit/c463057c82656a4d7564fc9205bb79517317c629

If a couple people could take a look at this code and see what you think, I can 
create a PR against the RC and we can make use of this code in the next RC for 
4.10.

Thanks!
Mike

On 5/10/17, 2:34 PM, "Tutkowski, Mike"  wrote:

OK, here’s the gist of the problem:

In StorageManagerImpl.cleanupStorage(boolean), the following line in 4.9

List vols = 
_volsDao.listVolumesToBeDestroyed(new Date(System.currentTimeMillis() - ((long) 
StorageCleanupDelay.value() << 10)));

was changed to the following in 4.10

// ROOT volumes will be destroyed as part of VM cleanup
List vols = 
_volsDao.listNonRootVolumesToBeDestroyed(new Date(System.currentTimeMillis() - 
((long) StorageCleanupDelay.value() << 10)));

This leads to a problem (for both managed and traditional storage) in the 
following situation:

For example: Let’s say we have a system VM running on NFS primary storage. 
We then put this primary storage into maintenance mode, which creates the 
system VM (with the same name) on a different primary storage (we do not create 
a new row in the cloud.vm_instance table for this VM). While this VM works, the 
original root disk of the system VM remains on the original primary storage and 
is not destroyed by the code in StorageManagerImpl.cleanupStorage(boolean) in 
4.10 because 4.10 (as shown above) only asks for non-root volumes to consider 
for deletion. In the 4.9 version of the code, the original root disk is cleaned 
up in StorageManagerImpl.cleanupStorage(boolean). The problem with 4.10 relying 
on a root disk always being deleted when the VM it belongs to is deleted is 
that in a situation like this that the system VM doesn’t get deleted at this 
point – it gets a new root disk that’s hosted by a different primary storage 
(so now it’s original root disk is stranded).

Here is the ticket and the PR where the code change went in:
https://issues.apache.org/jira/browse/CLOUDSTACK-9660
https://github.com/apache/cloudstack/pull/1825

To me, this needs to be fixed before we release 4.10, so I am -1 on this RC.

My suggestion would be to basically revert PR 1825 and to make use of just 
bits and pieces of it.

For example, this part should be kept:

-
volService.expungeVolumeAsync(volFactory.getVolume(vol.getId()));
 +VolumeInfo volumeInfo = 
volFactory.getVolume(vol.getId());
 +if (volumeInfo != null) {
 +volService.expungeVolumeAsync(volumeInfo);
 +} else {
 +s_logger.debug("Volume " + vol.getUuid() 
+ " is already destroyed");
 +}

On 5/10/17, 8:17 AM, "Tutkowski, Mike"  wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks 
like some code was changed in 4.10 with regards to this thread and that change 
is causing a problem around cleanup for managed storage in a particular 
situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this 
thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  
wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> 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?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

OK, here’s the gist of the problem:

In StorageManagerImpl.cleanupStorage(boolean), the following line in 4.9

List vols = _volsDao.listVolumesToBeDestroyed(new 
Date(System.currentTimeMillis() - ((long) StorageCleanupDelay.value() << 10)));

was changed to the following in 4.10

// ROOT volumes will be destroyed as part of VM cleanup
List vols = 
_volsDao.listNonRootVolumesToBeDestroyed(new Date(System.currentTimeMillis() - 
((long) StorageCleanupDelay.value() << 10)));

This leads to a problem (for both managed and traditional storage) in the 
following situation:

For example: Let’s say we have a system VM running on NFS primary storage. We 
then put this primary storage into maintenance mode, which creates the system 
VM (with the same name) on a different primary storage (we do not create a new 
row in the cloud.vm_instance table for this VM). While this VM works, the 
original root disk of the system VM remains on the original primary storage and 
is not destroyed by the code in StorageManagerImpl.cleanupStorage(boolean) in 
4.10 because 4.10 (as shown above) only asks for non-root volumes to consider 
for deletion. In the 4.9 version of the code, the original root disk is cleaned 
up in StorageManagerImpl.cleanupStorage(boolean). The problem with 4.10 relying 
on a root disk always being deleted when the VM it belongs to is deleted is 
that in a situation like this that the system VM doesn’t get deleted at this 
point – it gets a new root disk that’s hosted by a different primary storage 
(so now it’s original root disk is stranded).

Here is the ticket and the PR where the code change went in:
https://issues.apache.org/jira/browse/CLOUDSTACK-9660
https://github.com/apache/cloudstack/pull/1825

To me, this needs to be fixed before we release 4.10, so I am -1 on this RC.

My suggestion would be to basically revert PR 1825 and to make use of just bits 
and pieces of it.

For example, this part should be kept:

-
volService.expungeVolumeAsync(volFactory.getVolume(vol.getId()));
 +VolumeInfo volumeInfo = 
volFactory.getVolume(vol.getId());
 +if (volumeInfo != null) {
 +volService.expungeVolumeAsync(volumeInfo);
 +} else {
 +s_logger.debug("Volume " + vol.getUuid() + " 
is already destroyed");
 +}

On 5/10/17, 8:17 AM, "Tutkowski, Mike"  wrote:

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks like 
some code was changed in 4.10 with regards to this thread and that change is 
causing a problem around cleanup for managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> 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?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
> 
> However, I don't want to delay 4.10 any longer.
> 
> Wido
> 
> 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
> 

Re: [VOTE] Apache Cloudstack 4.10.0.0 - RC2

[Tutkowski, Mike]

I've been running regression tests against the release candidate.

So far, all tests but one have passed.

The failing test is related to the storage cleanup thread. It looks like some 
code was changed in 4.10 with regards to this thread and that change is causing 
a problem around cleanup for managed storage in a particular situation.

As a result of this, I was going to vote -1.

I'm guessing the fix will not be complicated, but is important.

I don't yet have the fix, however. Once I do, I can reply to this thread.

> On May 10, 2017, at 5:47 AM, Rajani Karuturi  wrote:
> 
> I agree to your concerns Wido. I did check the PR before creating
> RC2. There were some outstanding comments on it.
> 
> If no one has started testing RC2 and there are no objections, we
> can cancel this vote, quickly merge the PR and create RC3.
> 
> ~ Rajani
> 
> http://cloudplatform.accelerite.com/
> 
> On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
> wrote:
> 
> Op 10 mei 2017 om 0:33 schreef Will Stevens
> :
> 
> 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?
> 
> Well, the provisioning is the same between Basic and Advanced.
> The VR is utterly slow in doing that.
> 
> It happens when you have a lot of VMs in those networks.
> 
> In our case we have a couple of thousands VMs.
> 
> What I'd like to prevent is that this is merged into 4.9.3, but
> is not in 4.10.
> 
> However, I don't want to delay 4.10 any longer.
> 
> Wido
> 
> 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

[Rajani Karuturi]

I agree to your concerns Wido. I did check the PR before creating
RC2. There were some outstanding comments on it.

If no one has started testing RC2 and there are no objections, we
can cancel this vote, quickly merge the PR and create RC3.

~ Rajani

http://cloudplatform.accelerite.com/

On May 10, 2017 at 3:04 PM, Wido den Hollander (w...@widodh.nl)
wrote:

Op 10 mei 2017 om 0:33 schreef Will Stevens
:

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?

Well, the provisioning is the same between Basic and Advanced.
The VR is utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but
is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

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

[Wido den Hollander]

> Op 10 mei 2017 om 0:33 schreef Will Stevens :
> 
> 
> 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?

Well, the provisioning is the same between Basic and Advanced. The VR is 
utterly slow in doing that.

It happens when you have a lot of VMs in those networks.

In our case we have a couple of thousands VMs.

What I'd like to prevent is that this is merged into 4.9.3, but is not in 4.10.

However, I don't want to delay 4.10 any longer.

Wido

> 
> 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

[Will Stevens]

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

[Wido den Hollander]

+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/

[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: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

Thanks Will.

~ Rajani

http://cloudplatform.accelerite.com/

On April 25, 2017 at 1:35 AM, Will Stevens
(wstev...@cloudops.com) wrote:

Here is a fix for CLOUDSTACK-9878:
https://github.com/apache/cloudstack/pull/2062

It doesn't look like Jenkins or Travis are running against PRs
now. Did
that get removed with the change to Gitbox? How are we doing
formal CI now?

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Mon, Apr 24, 2017 at 12:28 AM, Rajani Karuturi
<raj...@apache.org> wrote:

Quick update:

We have the following blockers and we dont have anyone working
on them.

CLOUDSTACK-9878 Remote Access VPN that losing connection when
new network
configs are introduced
CLOUDSTACK-9868: internal LB for VPC tier is broken

Thanks,

~Rajani
http://cloudplatform.accelerite.com/

On Thu, Apr 20, 2017 at 12:48 PM, Rohit Yadav
<rohit.ya...@shapeblue.com>
wrote:

Rajani,

Can you please review and merge

CLOUDSTACK-9408 - remove runtime references to
http://download.cloud.com

<

http://download.cloud.com/>: https://github.com/apache/
cloudstack/pull/1582

Regards.


From: Daan Hoogland <daan.hoogl...@shapeblue.com>
Sent: 20 April 2017 12:27:48
To: dev@cloudstack.apache.org
Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0

I rebased that last one. I don’t think this is still a blocker.

On 19/04/17 12:39, "Rajani Karuturi" <raj...@apache.org> wrote:

CLOUDSTACK-9408 - remove runtime references to
http://download.cloud.com

Thanks,

~Rajani

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

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

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Will Stevens]

​It looks like Travis is still there and has picked up the job.  :)​

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Mon, Apr 24, 2017 at 4:05 PM, Will Stevens <wstev...@cloudops.com> wrote:

> Here is a fix for CLOUDSTACK-9878: https://github.com/apache/cloudstack/
> pull/2062
>
> It doesn't look like Jenkins or Travis are running against PRs now.  Did
> that get removed with the change to Gitbox?  How are we doing formal CI now?
>
> *Will STEVENS*
> Lead Developer
>
> <https://goo.gl/NYZ8KK>
>
> On Mon, Apr 24, 2017 at 12:28 AM, Rajani Karuturi <raj...@apache.org>
> wrote:
>
>> Quick update:
>>
>> We have the following blockers and we dont have anyone working on them.
>>
>> CLOUDSTACK-9878 Remote Access VPN that losing connection when new network
>> configs are introduced
>> CLOUDSTACK-9868: internal LB for VPC tier is broken
>>
>> Thanks,
>>
>> ~Rajani
>> http://cloudplatform.accelerite.com/
>>
>> On Thu, Apr 20, 2017 at 12:48 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
>> wrote:
>>
>> > Rajani,
>> >
>> >
>> > Can you please review and merge
>> >
>> > CLOUDSTACK-9408 - remove runtime references to
>> http://download.cloud.com<
>> > http://download.cloud.com/>: https://github.com/apache/
>> > cloudstack/pull/1582
>> >
>> >
>> > Regards.
>> >
>> > 
>> > From: Daan Hoogland <daan.hoogl...@shapeblue.com>
>> > Sent: 20 April 2017 12:27:48
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
>> >
>> > I rebased that last one. I don’t think this is still a blocker.
>> >
>> > On 19/04/17 12:39, "Rajani Karuturi" <raj...@apache.org> wrote:
>> >
>> > CLOUDSTACK-9408 - remove runtime references to
>> > http://download.cloud.com
>> >
>> > Thanks,
>> >
>> > ~Rajani
>> >
>> >
>> >
>> > 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: :[VOTE] Apache Cloudstack 4.10.0.0

[Will Stevens]

Here is a fix for CLOUDSTACK-9878:
https://github.com/apache/cloudstack/pull/2062

It doesn't look like Jenkins or Travis are running against PRs now.  Did
that get removed with the change to Gitbox?  How are we doing formal CI now?

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Mon, Apr 24, 2017 at 12:28 AM, Rajani Karuturi <raj...@apache.org> wrote:

> Quick update:
>
> We have the following blockers and we dont have anyone working on them.
>
> CLOUDSTACK-9878 Remote Access VPN that losing connection when new network
> configs are introduced
> CLOUDSTACK-9868: internal LB for VPC tier is broken
>
> Thanks,
>
> ~Rajani
> http://cloudplatform.accelerite.com/
>
> On Thu, Apr 20, 2017 at 12:48 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
> wrote:
>
> > Rajani,
> >
> >
> > Can you please review and merge
> >
> > CLOUDSTACK-9408 - remove runtime references to http://download.cloud.com
> <
> > http://download.cloud.com/>: https://github.com/apache/
> > cloudstack/pull/1582
> >
> >
> > Regards.
> >
> > ____
> > From: Daan Hoogland <daan.hoogl...@shapeblue.com>
> > Sent: 20 April 2017 12:27:48
> > To: dev@cloudstack.apache.org
> > Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
> >
> > I rebased that last one. I don’t think this is still a blocker.
> >
> > On 19/04/17 12:39, "Rajani Karuturi" <raj...@apache.org> wrote:
> >
> > CLOUDSTACK-9408 - remove runtime references to
> > http://download.cloud.com
> >
> > Thanks,
> >
> > ~Rajani
> >
> >
> >
> > 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: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

Quick update:

We have the following blockers and we dont have anyone working on them.

CLOUDSTACK-9878 Remote Access VPN that losing connection when new network
configs are introduced
CLOUDSTACK-9868: internal LB for VPC tier is broken

Thanks,

~Rajani
http://cloudplatform.accelerite.com/

On Thu, Apr 20, 2017 at 12:48 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> Rajani,
>
>
> Can you please review and merge
>
> CLOUDSTACK-9408 - remove runtime references to http://download.cloud.com<
> http://download.cloud.com/>: https://github.com/apache/
> cloudstack/pull/1582
>
>
> Regards.
>
> 
> From: Daan Hoogland <daan.hoogl...@shapeblue.com>
> Sent: 20 April 2017 12:27:48
> To: dev@cloudstack.apache.org
> Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
>
> I rebased that last one. I don’t think this is still a blocker.
>
> On 19/04/17 12:39, "Rajani Karuturi" <raj...@apache.org> wrote:
>
> CLOUDSTACK-9408 - remove runtime references to
> http://download.cloud.com
>
> Thanks,
>
> ~Rajani
>
>
>
> 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: :[VOTE] Apache Cloudstack 4.10.0.0

[Rohit Yadav]

Rajani,


Can you please review and merge

CLOUDSTACK-9408 - remove runtime references to 
http://download.cloud.com<http://download.cloud.com/>: 
https://github.com/apache/cloudstack/pull/1582


Regards.


From: Daan Hoogland <daan.hoogl...@shapeblue.com>
Sent: 20 April 2017 12:27:48
To: dev@cloudstack.apache.org
Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0

I rebased that last one. I don’t think this is still a blocker.

On 19/04/17 12:39, "Rajani Karuturi" <raj...@apache.org> wrote:

CLOUDSTACK-9408 - remove runtime references to
http://download.cloud.com

Thanks,

~Rajani



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: :[VOTE] Apache Cloudstack 4.10.0.0

[Daan Hoogland]

I rebased that last one. I don’t think this is still a blocker.

On 19/04/17 12:39, "Rajani Karuturi"  wrote:

CLOUDSTACK-9408 - remove runtime references to
http://download.cloud.com

Thanks,

~Rajani



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

Re:Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Haijiao]

t;> > > On 3/7/17, 1:51 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com> wrote:
>>> > >
>>> > > Yes, I can open a ticket.
>>> > >
>>> > > > On Mar 7, 2017, at 1:50 PM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >
>>> > > > Yes that’s the bug. Can you open a ticket for this? @
>>> > nvazquez can
>>> > > you take a look?
>>> > > >
>>> > > > On 3/7/17, 12:44 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > This does seem messed up.
>>> > > >
>>> > > > If I add a new primary storage and give it a storage
>>> tag,
>>> > the tag
>>> > > ends up in storage_pool_details.
>>> > > >
>>> > > > If I edit an existing storage pool’s storage tags, it
>>> > places
>>> > them
>>> > > in storage_pool_tags.
>>> > > >
>>> > > > On 3/7/17, 1:39 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > I believe I have found another bug (one that we should
>>> > either
>>> > > fix or examine in detail before releasing 4.10).
>>> > > >
>>> > > > It looks like we have a new table:
>>> cloud.storage_pool_tags.
>>> > > >
>>> > > > The addition of this table seems to have broken the
>>> > > listStorageTags API command. When this command runs, it
>>> > doesn’t pick up any
>>> > > storage tags for me (and I know I have one storage tag).
>>> > > >
>>> > > > This data used to be stored in the
>>> > cloud.storage_pool_details
>>> > > table. It’s good to put it in its own table, but will our
>>> > upgrade process
>>> > > move the existing tags from storage_pool_details to
>>> > storage_pool_tags?
>>> > > >
>>> > > > I have not yet opened a ticket for this. I want to
>>> examine
>>> > it
>>> > > a bit more before doing so.
>>> > > >
>>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>>> > > mike.tutkow...@netapp.com> wrote:
>>> > > >
>>> > > > No VM snapshot.
>>> > > >
>>> > > > I tried while the VM was in the Running state and then
>>> I
>>> > > also tried in the Stopped state. Same results.
>>> > > >
>>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >>
>>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>> > > >>
>>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >>
>>> > > >> I seem to have found another blocker:
>>> > > >>
>>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>>> > > >>
>>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
>>> raj...@apache.org>
>>> > wrote:
>>> > > >>
>>> > > >> PRs are ready for the blockers. Waiting for reviews
>>> and
>>> > test
>>> > > >> results. Once they are ready, I will merge them(and a
>>> few
>>> > more
>>> > > >> bug fixes) and create RC2 (probably tomorrow,
>>> Wednesday)
>>> > > >>
>>> > > >> Thanks,
>>> > > >>
>>> > > >> ~ Rajani
>>> > > >>
>>> > > >> http://cloudplatform.accelerite.com/
>>> > > >>
>>> > > >> On March 3, 2017 at 4:30 PM, Rajani Karuturi (
>>> > > raj...@apache.org)
>>> > > >> wrote:
>>> > > >>
>>> > > >> I will create RC2 on Monday with the fixes mentioned
>>> in my
>>> > > >> previous mail.
>>> > > >>
>>> > > >> ~ Rajani
>>

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

;
>>> > > > On Mar 7, 2017, at 1:50 PM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >
>>> > > > Yes that’s the bug. Can you open a ticket for this? @
>>> > nvazquez can
>>> > > you take a look?
>>> > > >
>>> > > > On 3/7/17, 12:44 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > This does seem messed up.
>>> > > >
>>> > > > If I add a new primary storage and give it a storage
>>> tag,
>>> > the tag
>>> > > ends up in storage_pool_details.
>>> > > >
>>> > > > If I edit an existing storage pool’s storage tags, it
>>> > places
>>> > them
>>> > > in storage_pool_tags.
>>> > > >
>>> > > > On 3/7/17, 1:39 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > I believe I have found another bug (one that we should
>>> > either
>>> > > fix or examine in detail before releasing 4.10).
>>> > > >
>>> > > > It looks like we have a new table:
>>> cloud.storage_pool_tags.
>>> > > >
>>> > > > The addition of this table seems to have broken the
>>> > > listStorageTags API command. When this command runs, it
>>> > doesn’t pick up any
>>> > > storage tags for me (and I know I have one storage tag).
>>> > > >
>>> > > > This data used to be stored in the
>>> > cloud.storage_pool_details
>>> > > table. It’s good to put it in its own table, but will our
>>> > upgrade process
>>> > > move the existing tags from storage_pool_details to
>>> > storage_pool_tags?
>>> > > >
>>> > > > I have not yet opened a ticket for this. I want to
>>> examine
>>> > it
>>> > > a bit more before doing so.
>>> > > >
>>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>>> > > mike.tutkow...@netapp.com> wrote:
>>> > > >
>>> > > > No VM snapshot.
>>> > > >
>>> > > > I tried while the VM was in the Running state and then
>>> I
>>> > > also tried in the Stopped state. Same results.
>>> > > >
>>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >>
>>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>> > > >>
>>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >>
>>> > > >> I seem to have found another blocker:
>>> > > >>
>>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>>> > > >>
>>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
>>> raj...@apache.org>
>>> > wrote:
>>> > > >>
>>> > > >> PRs are ready for the blockers. Waiting for reviews
>>> and
>>> > test
>>> > > >> results. Once they are ready, I will merge them(and a
>>> few
>>> > more
>>> > > >> bug fixes) and create RC2 (probably tomorrow,
>>> Wednesday)
>>> > > >>
>>> > > >> Thanks,
>>> > > >>
>>> > > >> ~ Rajani
>>> > > >>
>>> > > >> http://cloudplatform.accelerite.com/
>>> > > >>
>>> > > >> On March 3, 2017 at 4:30 PM, Rajani Karuturi (
>>> > > raj...@apache.org)
>>> > > >> wrote:
>>> > > >>
>>> > > >> I will create RC2 on Monday with the fixes mentioned
>>> in my
>>> > > >> previous mail.
>>> > > >>
>>> > > >> ~ Rajani
>>> > > >>
>>> > > >> http://cloudplatform.accelerite.com/
>>> > > >>
>>> > > >> On March 3, 2017 at 2:36 PM, Rohit Yadav
>>> > > &

Re:Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Haijiao]

gt; <mike.tutkow...@netapp.com>:
>>> >
>>> > > Here’s the ticket:
>>> > >
>>> > > https://issues.apache.org/jira/browse/CLOUDSTACK-9827
>>> > >
>>> > > On 3/7/17, 1:51 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com> wrote:
>>> > >
>>> > > Yes, I can open a ticket.
>>> > >
>>> > > > On Mar 7, 2017, at 1:50 PM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >
>>> > > > Yes that’s the bug. Can you open a ticket for this? @
>>> > nvazquez can
>>> > > you take a look?
>>> > > >
>>> > > > On 3/7/17, 12:44 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > This does seem messed up.
>>> > > >
>>> > > > If I add a new primary storage and give it a storage
>>> tag,
>>> > the tag
>>> > > ends up in storage_pool_details.
>>> > > >
>>> > > > If I edit an existing storage pool’s storage tags, it
>>> > places
>>> > them
>>> > > in storage_pool_tags.
>>> > > >
>>> > > > On 3/7/17, 1:39 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > I believe I have found another bug (one that we should
>>> > either
>>> > > fix or examine in detail before releasing 4.10).
>>> > > >
>>> > > > It looks like we have a new table:
>>> cloud.storage_pool_tags.
>>> > > >
>>> > > > The addition of this table seems to have broken the
>>> > > listStorageTags API command. When this command runs, it
>>> > doesn’t pick up any
>>> > > storage tags for me (and I know I have one storage tag).
>>> > > >
>>> > > > This data used to be stored in the
>>> > cloud.storage_pool_details
>>> > > table. It’s good to put it in its own table, but will our
>>> > upgrade process
>>> > > move the existing tags from storage_pool_details to
>>> > storage_pool_tags?
>>> > > >
>>> > > > I have not yet opened a ticket for this. I want to
>>> examine
>>> > it
>>> > > a bit more before doing so.
>>> > > >
>>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>>> > > mike.tutkow...@netapp.com> wrote:
>>> > > >
>>> > > > No VM snapshot.
>>> > > >
>>> > > > I tried while the VM was in the Running state and then
>>> I
>>> > > also tried in the Stopped state. Same results.
>>> > > >
>>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >>
>>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>> > > >>
>>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >>
>>> > > >> I seem to have found another blocker:
>>> > > >>
>>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>>> > > >>
>>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

/browse/CLOUDSTACK-9827
>>> > >
>>> > > On 3/7/17, 1:51 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com> wrote:
>>> > >
>>> > > Yes, I can open a ticket.
>>> > >
>>> > > > On Mar 7, 2017, at 1:50 PM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >
>>> > > > Yes that’s the bug. Can you open a ticket for this? @
>>> > nvazquez can
>>> > > you take a look?
>>> > > >
>>> > > > On 3/7/17, 12:44 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > This does seem messed up.
>>> > > >
>>> > > > If I add a new primary storage and give it a storage
>>> tag,
>>> > the tag
>>> > > ends up in storage_pool_details.
>>> > > >
>>> > > > If I edit an existing storage pool’s storage tags, it
>>> > places
>>> > them
>>> > > in storage_pool_tags.
>>> > > >
>>> > > > On 3/7/17, 1:39 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >
>>> > > > I believe I have found another bug (one that we should
>>> > either
>>> > > fix or examine in detail before releasing 4.10).
>>> > > >
>>> > > > It looks like we have a new table:
>>> cloud.storage_pool_tags.
>>> > > >
>>> > > > The addition of this table seems to have broken the
>>> > > listStorageTags API command. When this command runs, it
>>> > doesn’t pick up any
>>> > > storage tags for me (and I know I have one storage tag).
>>> > > >
>>> > > > This data used to be stored in the
>>> > cloud.storage_pool_details
>>> > > table. It’s good to put it in its own table, but will our
>>> > upgrade process
>>> > > move the existing tags from storage_pool_details to
>>> > storage_pool_tags?
>>> > > >
>>> > > > I have not yet opened a ticket for this. I want to
>>> examine
>>> > it
>>> > > a bit more before doing so.
>>> > > >
>>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>>> > > mike.tutkow...@netapp.com> wrote:
>>> > > >
>>> > > > No VM snapshot.
>>> > > >
>>> > > > I tried while the VM was in the Running state and then
>>> I
>>> > > also tried in the Stopped state. Same results.
>>> > > >
>>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>>> > > sergey.levits...@autodesk.com> wrote:
>>> > > >>
>>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>>> > > >>
>>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>>> > <mike.tutkow...@netapp.com>
>>> > > wrote:
>>> > > >>
>>> > > >> I seem to have found another blocker:
>>> > > >>
>>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>>> > > >>
>>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
>>> raj...@apache.org>
>>> > wrote:
>>> > > >>
>>> > > >> PRs are ready for the b

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

..@netapp.com>
>> > > wrote:
>> > > >
>> > > > I believe I have found another bug (one that we should
>> > either
>> > > fix or examine in detail before releasing 4.10).
>> > > >
>> > > > It looks like we have a new table:
>> cloud.storage_pool_tags.
>> > > >
>> > > > The addition of this table seems to have broken the
>> > > listStorageTags API command. When this command runs, it
>> > doesn’t pick up any
>> > > storage tags for me (and I know I have one storage tag).
>> > > >
>> > > > This data used to be stored in the
>> > cloud.storage_pool_details
>> > > table. It’s good to put it in its own table, but will our
>> > upgrade process
>> > > move the existing tags from storage_pool_details to
>> > storage_pool_tags?
>> > > >
>> > > > I have not yet opened a ticket for this. I want to
>> examine
>> > it
>> > > a bit more before doing so.
>> > > >
>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>> > > mike.tutkow...@netapp.com> wrote:
>> > > >
>> > > > No VM snapshot.
>> > > >
>> > > > I tried while the VM was in the Running state and then I
>> > > also tried in the Stopped state. Same results.
>> > > >
>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>> > > sergey.levits...@autodesk.com> wrote:
>> > > >>
>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>> > > >>
>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>> > <mike.tutkow...@netapp.com>
>> > > wrote:
>> > > >>
>> > > >> I seem to have found another blocker:
>> > > >>
>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>> > > >>
>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
>> raj...@apache.org>
>> > wrote:
>> > > >>
>> > > >> PRs are ready for the blockers. Waiting for reviews and
>> > test
>> > > >> results. Once they are ready, I will merge them(and a
>> few
>> > more
>> > > >> bug fixes) and create RC2 (probably tomorrow,
>> Wednesday)
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> ~ Rajani
>> > > >>
>> > > >> http://cloudplatform.accelerite.com/
>> > > >>
>> > > >> On March 3, 2017 at 4:30 PM, Rajani Karuturi (
>> > > raj...@apache.org)
>> > > >> wrote:
>> > > >>
>> > > >> I will create RC2 on Monday with the fixes mentioned
>> in my
>> > > >> previous mail.
>> > > >>
>> > > >> ~ Rajani
>> > > >>
>> > > >> http://cloudplatform.accelerite.com/
>> > > >>
>> > > >> On March 3, 2017 at 2:36 PM, Rohit Yadav
>> > > >> (rohit.ya...@shapeblue.com) wrote:
>> > > >>
>> > > >> Thanks Koushik, I did not realize Kishan had sent this
>> > > already.
>> > > >> Let's get either of the PRs merged and kick a RC2.
>> > > >>
>> > > >> Regards.
>> > > >>
>> > > >> 
>> > > >> From: Koushik 

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Rajani Karuturi]

; > >
> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
> > > sergey.levits...@autodesk.com> wrote:
> > > >>
> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
> > > >>
> >     > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
> > <mike.tutkow...@netapp.com>
> > > wrote:
> > > >>
> > > >> I seem to have found another blocker:
> > > >>
> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
> > > >>
> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
> raj...@apache.org>
> > wrote:
> > > >>
> > > >> PRs are ready for the blockers. Waiting for reviews and
> > test
> > > >> results. Once they are ready, I will merge them(and a
> few
> > more
> > > >> bug fixes) and create RC2 (probably tomorrow, Wednesday)
> > > >>
> > > >> Thanks,
> > > >>
> > > >> ~ Rajani
> > > >>
> > > >> http://cloudplatform.accelerite.com/
> > > >>
> > > >> On March 3, 2017 at 4:30 PM, Rajani Karuturi (
> > > raj...@apache.org)
> > > >> wrote:
> > > >>
> > > >> I will create RC2 on Monday with the fixes mentioned in
> my
> > > >> previous mail.
> > > >>
> > > >> ~ Rajani
> > > >>
> > > >> http://cloudplatform.accelerite.com/
> > > >>
> > > >> On March 3, 2017 at 2:36 PM, Rohit Yadav
> > > >> (rohit.ya...@shapeblue.com) wrote:
> > > >>
> > > >> Thanks Koushik, I did not realize Kishan had sent this
> > > already.
> > > >> Let's get either of the PRs merged and kick a RC2.
> > > >>
> > > >> Regards.
> >     > >>
> > > >> 
> > > >> From: Koushik Das <koushik@accelerite.com>
> > > >> Sent: 03 March 2017 14:14:56
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
> > > >>
> > > >> Looks like there is already a PR for the same issue
> > > >> https://github.com/apache/cloudstack/pull/1982 from
> > Kishan.
> > > >>
> > > >> -Koushik
> > > >>
> > > >> On 03/03/17, 1:58 PM, "Rohit Yadav" <
> > > rohit.ya...@shapeblue.com>
> > > >> wrote:
> > > >>
> > > >> -1 (binding)
> > > >>
> > > >> All, I've found an upgrade blocker. Pre 4.6 users are
> > required
> > > >> to seed 4.6 systemvmtemplate to proceed with the upgrade
> > > >> otherwise upgrade fails, and from 4.9 upgrade to 4.10
> does
> > no
> > > >> check/enforcement that 4.10 based systemvmtemplate has
> > been
> > > >> seeded/registered, nor the minimum required
> > systemvmtemplate
> > > >> version is changed from 4.6.0 to 4.10.0.
> > > >>
> > > >> After we have merged the strongswan/java8 PR, I had
> > updated
> > > the
> > > >> upgrade docs on how to upgrade the systemvmtemplate
> here:
> > > >>
> > > >> http://docs.cloudstack.apache.org/projects/cloudstack-
> > > release-notes/en/4.10/upgrade/upgrade-4.9.html
> > > >>
> > > >> Using the above, I've tried to fix these issues here,
> >  

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Wei ZHOU]

   > >
>> > > > The addition of this table seems to have broken the
>> > > listStorageTags API command. When this command runs, it
>> > doesn’t pick up any
>> > > storage tags for me (and I know I have one storage tag).
>> > > >
>> > > > This data used to be stored in the
>> > cloud.storage_pool_details
>> > > table. It’s good to put it in its own table, but will our
>> > upgrade process
>> > > move the existing tags from storage_pool_details to
>> > storage_pool_tags?
>> > > >
>> > > > I have not yet opened a ticket for this. I want to
>> examine
>> > it
>> > > a bit more before doing so.
>> > > >
>> > > > On 3/7/17, 8:10 AM, "Tutkowski, Mike" <
>> > > mike.tutkow...@netapp.com> wrote:
>> > > >
>> > > > No VM snapshot.
>> > > >
>> > > > I tried while the VM was in the Running state and then I
>> > > also tried in the Stopped state. Same results.
>> > > >
>> > > >> On Mar 7, 2017, at 7:54 AM, Sergey Levitskiy <
>> > > sergey.levits...@autodesk.com> wrote:
>> > > >>
>> > > >> Is VM has an VMsnaphsot? Is VM in Stopped state?
>> > > >>
>> > > >> On 3/6/17, 10:32 PM, "Tutkowski, Mike"
>> > <mike.tutkow...@netapp.com>
>> > > wrote:
>> > > >>
>> > > >> I seem to have found another blocker:
>> > > >>
>> > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-9822
>> > > >>
>> > > >> On 3/6/17, 9:51 PM, "Rajani Karuturi" <
>> raj...@apache.org>
>> > wrote:
>> > > >>
>> > > >> PRs are ready for the blockers. Waiting for reviews and
>> > test
>> > > >> results. Once they are ready, I will merge them(and a
>> few
>> > more
>> > > >> bug fixes) and create RC2 (probably tomorrow,
>> Wednesday)
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> ~ Rajani
>> > > >>
>> > > >> http://cloudplatform.accelerite.com/
>> > > >>
>> > > >> On March 3, 2017 at 4:30 PM, Rajani Karuturi (
>> > > raj...@apache.org)
>> > > >> wrote:
>> > > >>
>> > > >> I will create RC2 on Monday with the fixes mentioned
>> in my
>> > > >> previous mail.
>> > > >>
>> > > >> ~ Rajani
>> > > >>
>> > > >> http://cloudplatform.accelerite.com/
>> > > >>
>> > > >> On March 3, 2017 at 2:36 PM, Rohit Yadav
>> > > >> (rohit.ya...@shapeblue.com) wrote:
>> > > >>
>> > > >> Thanks Koushik, I did not realize Kishan had sent this
>> > > already.
>> > > >> Let's get either of the PRs merged and kick a RC2.
>> > > >>
>> > > >> Regards.
>> > > >>
>> > > >> 
>> > > >> From: Koushik Das <koushik@accelerite.com>
>> > > >> Sent: 03 March 2017 14:14:56
>> > > >> To: dev@cloudstack.apache.org
>> > > >> Subject: Re: :[VOTE] Apache Cloudstack 4.10.0.0
>> > > >>
>> > > >> Looks like there is already a PR for the same issue
>> > > >> https://github.c