date:20150422

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/22/2015 12:38 AM, Andrei Mikhailovsky wrote:
> Ilya, Mark, thanks for your feedback,
> 
> I also see the need to restructure the release schedule for ACS as
> the current release cycles are not really working. There is no
> _reliable_ release cycle of the product and as we have recently
> seen with the 4.5 branch, the release did not happen for months and
> it is still not clear when this will take place. In my (I must
> admit somewhat limited) experience if there are no deadlines,
> developers are not keen on releases and the release are likely to
> be delayed. This is what we've seen with the past ACS releases,
> they are overdue by many months.
> 
> The community might get a much better responce if there is a much
> shorter release cycle even if it means pushing out less features
> with each release. At least some features will get completed,
> tested and implemented in a set time frame. I would rather see a
> release cycle of every 3-4 months with 5 new features than a
> release with 15 new features which may or may not get released
> every 9 - 12 months.
> 
> By any means, please comment if someone disagrees or thinks there
> is a better alternative.
> 

Well, one of my comments on this is that you expect the developers to
have all the time available to actually work on this.

Remember that most people have a $dayjob on which they need to focus
and that finding the time to work on ACS is sometimes difficult.

Myself for example, the last few months I haven't been able to work on
ACS as much as I wanted to. My TODO list is full of things I want to
work on, but simply can't get to.

I can imagine this happens with more developers, they can't find the
time to work on ACS.

So as much as I would love to see very frequent releases of ACS, we
also have to think about the resources which are required to make that
happen.

In the end it all comes down to more hands writing code and doing
stuff for the project.

Wido

> Andrei - Original Message -
> 
>> From: "ilya"  To:
>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34
>> PM Subject: Re: Next ACS release?
> 
>> Andrei,
> 
>> To best of my knowledge, both 4.4.x and 4.5.x are being worked
>> on actively. As a community, we need to get better on QA of each
>> release - this is something we are planning to cover this year
>> with distributed QA model, this was not widely discussed yet but
>> something we need to tackle.
> 
>> 4.5 rc2 got stalled and we need to restart. We had a 4 month
>> release cycle, but we can really stick to it hard - as its
>> community driven. May will have to revise it down to 6 months or
>> so.
> 
>> Regards ilya
> 
>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
>>> Hello guys,
>>> 
>>> Looking at the dev and user lists it is becoming less certain
>>> if version 4.5.x is ever coming out. It seems like a few months
>>> have passed since the not so fortunate release of 4.5.0 and I
>>> can't find a release schedule for the 4.5.1, which seems to
>>> have stopped at rc2 stage and haven't progressed further to a
>>> release stage.
>>> 
>>> Are we likely to see any progress with the 4.5.x branch or is
>>> the community switching towards the 4.6.x branch without
>>> releasing the 4.5.x?
>>> 
>>> I am a bit unclear as there are no release dates, schedules or
>>> dead lines that the community should work with. Possibly as a
>>> result of this, the ACS releases are not being released on time
>>> or fast enough.
>>> 
>>> Does it make sense to introduce release schedules for ACS that
>>> the dev community should stick to? Similar to what is being
>>> done in many other projects, like Ubuntu, etc. Or would this
>>> break the ACS project releases even more?
>>> 
>>> Andrei
>>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVN0pnAAoJEAGbWC3bPspCj9oP/A+wBs47t3lEWLgb/LOAEeC/
oCDypTH+iBrX6sFdcD+HYof+XI979z6T70gYBxHYfxTxnscPOdQfdtWMHsUBkY6w
/UVeWkMQl7RwmnN8Uq2ASNSVoTe9rLSxXkjjvrDMO4mcjnNSEkWKv2tk5lC1o0ac
ryN01Acs/usZSJ5VdmaW/ixgVdeEV1qbCD20OIq4/z/vnmy+Ef+ui0GkopltlZ8I
bzPhRX6Dj4LAFujlVaIuxR/hbV7z9GJi6YMcPTB9GfdgM4cZVUYl802UZ0NGvnzg
7lW4CdSa0obM2HeakpdH1VGaWr4TxjVROaOZjZ8VkzDXOS0rJ0HgWktvk5z+uZXh
GSNgAlkWQoGhcP20Mls23WcGGktveLHxzfbAVDo7YSS5a/Q7ejDVVMVL1T/w7P0V
I7l/TCTkGYZHRTBrQxMSTRoW1Ieo192opAio09y12KtMeb7rpvh0OD6kHpkgHaoB
6uXWmOqy1eUnqkS5NxfecV+f6weNpHioug0irrLfqiZPA2PmnrNJzMNATR9AqbxB
1ohOwoPr8Rewbm96RtgsAR+/8yroLbPL0lHZni5AKklvdUlEL28vzT0ceve7tua3
anzLX4PLkXuzKrWNzawQbdr+5el/CvJW3pZ3yNlNG+b4qgskBmy3Sub/9S2dnDrp
+u5v88xGl5YFWpefLKb0
=FIJ3
-END PGP SIGNATURE-

Re: getting rid of 3rd party repositories (ceph, libvirt)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/21/2015 09:12 PM, Laszlo Hornyak wrote:
> Hi,
> 
> I have uploaded the libvirt dependency to maven central and you
> should never get the maven failure if the libvirt.org server goes
> down, it will be downloaded from central. I have sent a PR (#180)
> to remove the libvirt.org repository from the build.
> 
> With ceph.org the situation: - I have requested permission to
> publish like with libvirt, my request was rejected since the
> ceph.com team holds ownership - The only solution from here is to
> change the groupId of the dependency. - org.apache.* is very likely
> no go, it is owned by apache, artifacts are synchonrized to central
> through the apache repository, which is for apache artifacts only. 
> - we can upload with a new groupId - suggestions are welcome
> 

I wrote the rados-java bindings and licensed it under the Apache License
.

I choose com.ceph as a package since that was the easiest way. It
would be changed but I don't want to break all the existing code for
users.

Any ideas?

Wido

> Regards, Laszlo
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVN0unAAoJEAGbWC3bPspCKbAP/1d8gAmu+//zR/uhFAju+gEI
TGLvXhFv4uX9IKwGwMS9oiNDxYDQ9GPY17zShf41B271Ft9F8HZ8ovEfj8uauwaV
sr/2jHhI14Hb7d09vSBc1DmXzJ3iYyrQFYno/z7rVRTHJmJ67xrJPT7+ZjPOxI7E
aXoZMIBSuKPEJKwJl2vY8AsdFeU1LnPaKPC/vqUqqh94eIw1jk67ZgoCLctKOIig
43b0eZiRCrsGsiXYURH8pihlxDKY5ipz5utRY0ngb64xJRx2u/XSBDPFGtiwNR2O
dWTVACqgqnSKdDdr3cqZ6eDEaxKmViupi672fOTjZjgpnQojWKvLti4DVdcqMFle
BYGguzVcJZQpt8MSiiS9ATtm4WJkaePQsTS3T4BiqrxIpUfeYhhrCeE3Q+dykIYn
BdtsMBhAdM930Lv+6Zk/W6mmcxKmeXXU6ImOV95nYnvN53Q2+DEya06fZHsH80nR
eEO8uzS/Rz2GcumPClVV9Hv+g+nt6gYw+8w+OuVQIsU4YdQ0coOhsOYRleTeurBY
3JSZ8q4XX+PCZVpwLOZ6myKgNZFqGjk0CWi6DD3RssCQiZo5yWAJyENfVrX8GjO+
8pEQup2ACn/WR/A3o4q4Zq0m4B4u0wYXFmRgQ/kvOxSSeqhMhQlGZPsdrYLbM4P9
WeH67OGvyb+F/83N5ezx
=W4ry
-END PGP SIGNATURE-

Jenkins build is still unstable: simulator-singlerun #1135

2015-04-22 Thread jenkins

See

RE: Next ACS release?

2015-04-22 Thread Stephen Turner

I have to admit I'm a bit sceptical because when we did have a four-month 
release cycle, we never seemed to manage to meet it. Personally I think 
six-monthly might be easier.

Having said that, part of the problem was the long close-down period where we 
kept finding critical bugs, so more automated testing might help to shorten the 
cycle.

-- 
Stephen Turner

-Original Message-
From: Andrei Mikhailovsky [mailto:and...@arhont.com] 
Sent: 21 April 2015 11:39 PM
To: dev@cloudstack.apache.org
Subject: Re: Next ACS release?

Ilya, Mark, thanks for your feedback, 

I also see the need to restructure the release schedule for ACS as the current 
release cycles are not really working. There is no _reliable_ release cycle of 
the product and as we have recently seen with the 4.5 branch, the release did 
not happen for months and it is still not clear when this will take place. In 
my (I must admit somewhat limited) experience if there are no deadlines, 
developers are not keen on releases and the release are likely to be delayed. 
This is what we've seen with the past ACS releases, they are overdue by many 
months. 

The community might get a much better responce if there is a much shorter 
release cycle even if it means pushing out less features with each release. At 
least some features will get completed, tested and implemented in a set time 
frame. I would rather see a release cycle of every 3-4 months with 5 new 
features than a release with 15 new features which may or may not get released 
every 9 - 12 months. 

By any means, please comment if someone disagrees or thinks there is a better 
alternative. 

Andrei
- Original Message -

> From: "ilya" 
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 21 April, 2015 7:30:34 PM
> Subject: Re: Next ACS release?

> Andrei,

> To best of my knowledge, both 4.4.x and 4.5.x are being worked on 
> actively. As a community, we need to get better on QA of each release
> -
> this is something we are planning to cover this year with distributed 
> QA model, this was not widely discussed yet but something we need to 
> tackle.

> 4.5 rc2 got stalled and we need to restart. We had a 4 month release 
> cycle, but we can really stick to it hard - as its community driven.
> May
> will have to revise it down to 6 months or so.

> Regards
> ilya

> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
> > Hello guys,
> >
> > Looking at the dev and user lists it is becoming less certain if 
> > version 4.5.x is ever coming out. It seems like a few months have 
> > passed since the not so fortunate release of 4.5.0 and I can't find 
> > a release schedule for the 4.5.1, which seems to have stopped at rc2 
> > stage and haven't progressed further to a release stage.
> >
> > Are we likely to see any progress with the 4.5.x branch or is the 
> > community switching towards the 4.6.x branch without releasing the 
> > 4.5.x?
> >
> > I am a bit unclear as there are no release dates, schedules or dead 
> > lines that the community should work with. Possibly as a result of 
> > this, the ACS releases are not being released on time or fast 
> > enough.
> >
> > Does it make sense to introduce release schedules for ACS that the 
> > dev community should stick to? Similar to what is being done in many 
> > other projects, like Ubuntu, etc. Or would this break the ACS 
> > project releases even more?
> >
> > Andrei
> >

announce mail to announce lists

Can someone forward the announce mail I send yesterday to the lists
annou...@apache.org and annou...@cloudstack.apache.org. My login at
apache is not allright and mail from other domains to these lists is
rejected.

thanks
-- 
Daan

Re: Next ACS release?

I strongly advice my fellow community members to go for a lower
duration, not longer. Each feature deserves a release and I'd say
let's release every 2 months, provides a new feature was added. Also
we now release fix releases when we feel the urgency. This means
users, that are not also developers have little influence. Let's
release every two weeks, provided fixes where applicable.

€0,02++
wanting to get out of this vicious circle is my drive

On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner
 wrote:
> I have to admit I'm a bit sceptical because when we did have a four-month 
> release cycle, we never seemed to manage to meet it. Personally I think 
> six-monthly might be easier.
>
> Having said that, part of the problem was the long close-down period where we 
> kept finding critical bugs, so more automated testing might help to shorten 
> the cycle.
>
> --
> Stephen Turner
>
>
>
>
> -Original Message-
> From: Andrei Mikhailovsky [mailto:and...@arhont.com]
> Sent: 21 April 2015 11:39 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Next ACS release?
>
> Ilya, Mark, thanks for your feedback,
>
> I also see the need to restructure the release schedule for ACS as the 
> current release cycles are not really working. There is no _reliable_ release 
> cycle of the product and as we have recently seen with the 4.5 branch, the 
> release did not happen for months and it is still not clear when this will 
> take place. In my (I must admit somewhat limited) experience if there are no 
> deadlines, developers are not keen on releases and the release are likely to 
> be delayed. This is what we've seen with the past ACS releases, they are 
> overdue by many months.
>
> The community might get a much better responce if there is a much shorter 
> release cycle even if it means pushing out less features with each release. 
> At least some features will get completed, tested and implemented in a set 
> time frame. I would rather see a release cycle of every 3-4 months with 5 new 
> features than a release with 15 new features which may or may not get 
> released every 9 - 12 months.
>
> By any means, please comment if someone disagrees or thinks there is a better 
> alternative.
>
> Andrei
> - Original Message -
>
>> From: "ilya" 
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 21 April, 2015 7:30:34 PM
>> Subject: Re: Next ACS release?
>
>> Andrei,
>
>> To best of my knowledge, both 4.4.x and 4.5.x are being worked on
>> actively. As a community, we need to get better on QA of each release
>> -
>> this is something we are planning to cover this year with distributed
>> QA model, this was not widely discussed yet but something we need to
>> tackle.
>
>> 4.5 rc2 got stalled and we need to restart. We had a 4 month release
>> cycle, but we can really stick to it hard - as its community driven.
>> May
>> will have to revise it down to 6 months or so.
>
>> Regards
>> ilya
>
>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
>> > Hello guys,
>> >
>> > Looking at the dev and user lists it is becoming less certain if
>> > version 4.5.x is ever coming out. It seems like a few months have
>> > passed since the not so fortunate release of 4.5.0 and I can't find
>> > a release schedule for the 4.5.1, which seems to have stopped at rc2
>> > stage and haven't progressed further to a release stage.
>> >
>> > Are we likely to see any progress with the 4.5.x branch or is the
>> > community switching towards the 4.6.x branch without releasing the
>> > 4.5.x?
>> >
>> > I am a bit unclear as there are no release dates, schedules or dead
>> > lines that the community should work with. Possibly as a result of
>> > this, the ACS releases are not being released on time or fast
>> > enough.
>> >
>> > Does it make sense to introduce release schedules for ACS that the
>> > dev community should stick to? Similar to what is being done in many
>> > other projects, like Ubuntu, etc. Or would this break the ACS
>> > project releases even more?
>> >
>> > Andrei
>> >



-- 
Daan

Re: Next ACS release?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/22/2015 10:08 AM, Daan Hoogland wrote:
> I strongly advice my fellow community members to go for a lower 
> duration, not longer. Each feature deserves a release and I'd say 
> let's release every 2 months, provides a new feature was added.
> Also we now release fix releases when we feel the urgency. This
> means users, that are not also developers have little influence.
> Let's release every two weeks, provided fixes where applicable.
> 
> €0,02++ wanting to get out of this vicious circle is my drive
> 

Oh, I would really love that to happen. No doubt about it :-)

> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner 
>  wrote:
>> I have to admit I'm a bit sceptical because when we did have a
>> four-month release cycle, we never seemed to manage to meet it.
>> Personally I think six-monthly might be easier.
>> 
>> Having said that, part of the problem was the long close-down
>> period where we kept finding critical bugs, so more automated
>> testing might help to shorten the cycle.
>> 
>> -- Stephen Turner
>> 
>> 
>> 
>> 
>> -Original Message- From: Andrei Mikhailovsky
>> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To:
>> dev@cloudstack.apache.org Subject: Re: Next ACS release?
>> 
>> Ilya, Mark, thanks for your feedback,
>> 
>> I also see the need to restructure the release schedule for ACS
>> as the current release cycles are not really working. There is no
>> _reliable_ release cycle of the product and as we have recently
>> seen with the 4.5 branch, the release did not happen for months
>> and it is still not clear when this will take place. In my (I
>> must admit somewhat limited) experience if there are no
>> deadlines, developers are not keen on releases and the release
>> are likely to be delayed. This is what we've seen with the past
>> ACS releases, they are overdue by many months.
>> 
>> The community might get a much better responce if there is a much
>> shorter release cycle even if it means pushing out less features
>> with each release. At least some features will get completed,
>> tested and implemented in a set time frame. I would rather see a
>> release cycle of every 3-4 months with 5 new features than a
>> release with 15 new features which may or may not get released
>> every 9 - 12 months.
>> 
>> By any means, please comment if someone disagrees or thinks there
>> is a better alternative.
>> 
>> Andrei - Original Message -
>> 
>>> From: "ilya"  To:
>>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34
>>> PM Subject: Re: Next ACS release?
>> 
>>> Andrei,
>> 
>>> To best of my knowledge, both 4.4.x and 4.5.x are being worked
>>> on actively. As a community, we need to get better on QA of
>>> each release - this is something we are planning to cover this
>>> year with distributed QA model, this was not widely discussed
>>> yet but something we need to tackle.
>> 
>>> 4.5 rc2 got stalled and we need to restart. We had a 4 month
>>> release cycle, but we can really stick to it hard - as its
>>> community driven. May will have to revise it down to 6 months
>>> or so.
>> 
>>> Regards ilya
>> 
>>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
 Hello guys,
 
 Looking at the dev and user lists it is becoming less certain
 if version 4.5.x is ever coming out. It seems like a few
 months have passed since the not so fortunate release of
 4.5.0 and I can't find a release schedule for the 4.5.1,
 which seems to have stopped at rc2 stage and haven't
 progressed further to a release stage.
 
 Are we likely to see any progress with the 4.5.x branch or is
 the community switching towards the 4.6.x branch without
 releasing the 4.5.x?
 
 I am a bit unclear as there are no release dates, schedules
 or dead lines that the community should work with. Possibly
 as a result of this, the ACS releases are not being released
 on time or fast enough.
 
 Does it make sense to introduce release schedules for ACS
 that the dev community should stick to? Similar to what is
 being done in many other projects, like Ubuntu, etc. Or would
 this break the ACS project releases even more?
 
 Andrei
 
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVN1lgAAoJEAGbWC3bPspCaCYP/iKp9N1XEne9pEzlDm/cTRMm
wM0qNKiKNepXQocfxm2l35BSsdbnQZHwbXhs/IhcvOGsOfoYq+HvLDsuQWm/ut4F
RQdz38A5fHTX9wuQHeO11OQN12FE2PR61EUL1+NBt86Z9z/qjuXYuc6I3zQfj4Cn
fS+3EF62gsrudDvQA1JLbjQe/v3YlHYoYavn2miOSJMpnDnVnil1M5ZDASGFAoY+
nWFODk4P/8PbYAQmLOCS+TUxF3WcOEYV5sDgYdJS2cMTTtzoTCbI70scXViuzwOE
JikMF8v5rOXpVLbu9wsIzpbpbiXB+h+Gx4jzWTpV+BMpmbbw40Q/X/Wm92Gqkw6N
lnrWqDo5DipTEfNnDlzwEUS9axJPQvgkwF2QJndPgJNg3r7b9alzddJh48LoO47w
1wMyf3OrxzFSa0R1WdrDJTdc8kf2wh8VJRR1/EEkLi+rIiZ8qlI32Dljh2JDipxJ
QavTNDAAXUOK4L5TLclVN/s9pTllJee/gQvOookafmwmDq6LZNqq5uVebV9IN7oZ
va5ZYrXqybLhPtaYwquzjYVj+Zyp2eeoNb+bauCvAcnosjKHkr7GncKe3UVTUagJ
VM+0zYHxgbPz7E7p1DSEfppTCg6xYGegm

Re: Next ACS release?

the community is us... (well not just us, Wido) Having a master RM
would be my first step towards this goal.

On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 04/22/2015 10:08 AM, Daan Hoogland wrote:
>> I strongly advice my fellow community members to go for a lower
>> duration, not longer. Each feature deserves a release and I'd say
>> let's release every 2 months, provides a new feature was added.
>> Also we now release fix releases when we feel the urgency. This
>> means users, that are not also developers have little influence.
>> Let's release every two weeks, provided fixes where applicable.
>>
>> €0,02++ wanting to get out of this vicious circle is my drive
>>
>
> Oh, I would really love that to happen. No doubt about it :-)
>
>> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner
>>  wrote:
>>> I have to admit I'm a bit sceptical because when we did have a
>>> four-month release cycle, we never seemed to manage to meet it.
>>> Personally I think six-monthly might be easier.
>>>
>>> Having said that, part of the problem was the long close-down
>>> period where we kept finding critical bugs, so more automated
>>> testing might help to shorten the cycle.
>>>
>>> -- Stephen Turner
>>>
>>>
>>>
>>>
>>> -Original Message- From: Andrei Mikhailovsky
>>> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To:
>>> dev@cloudstack.apache.org Subject: Re: Next ACS release?
>>>
>>> Ilya, Mark, thanks for your feedback,
>>>
>>> I also see the need to restructure the release schedule for ACS
>>> as the current release cycles are not really working. There is no
>>> _reliable_ release cycle of the product and as we have recently
>>> seen with the 4.5 branch, the release did not happen for months
>>> and it is still not clear when this will take place. In my (I
>>> must admit somewhat limited) experience if there are no
>>> deadlines, developers are not keen on releases and the release
>>> are likely to be delayed. This is what we've seen with the past
>>> ACS releases, they are overdue by many months.
>>>
>>> The community might get a much better responce if there is a much
>>> shorter release cycle even if it means pushing out less features
>>> with each release. At least some features will get completed,
>>> tested and implemented in a set time frame. I would rather see a
>>> release cycle of every 3-4 months with 5 new features than a
>>> release with 15 new features which may or may not get released
>>> every 9 - 12 months.
>>>
>>> By any means, please comment if someone disagrees or thinks there
>>> is a better alternative.
>>>
>>> Andrei - Original Message -
>>>
 From: "ilya"  To:
 dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34
 PM Subject: Re: Next ACS release?
>>>
 Andrei,
>>>
 To best of my knowledge, both 4.4.x and 4.5.x are being worked
 on actively. As a community, we need to get better on QA of
 each release - this is something we are planning to cover this
 year with distributed QA model, this was not widely discussed
 yet but something we need to tackle.
>>>
 4.5 rc2 got stalled and we need to restart. We had a 4 month
 release cycle, but we can really stick to it hard - as its
 community driven. May will have to revise it down to 6 months
 or so.
>>>
 Regards ilya
>>>
 On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
> Hello guys,
>
> Looking at the dev and user lists it is becoming less certain
> if version 4.5.x is ever coming out. It seems like a few
> months have passed since the not so fortunate release of
> 4.5.0 and I can't find a release schedule for the 4.5.1,
> which seems to have stopped at rc2 stage and haven't
> progressed further to a release stage.
>
> Are we likely to see any progress with the 4.5.x branch or is
> the community switching towards the 4.6.x branch without
> releasing the 4.5.x?
>
> I am a bit unclear as there are no release dates, schedules
> or dead lines that the community should work with. Possibly
> as a result of this, the ACS releases are not being released
> on time or fast enough.
>
> Does it make sense to introduce release schedules for ACS
> that the dev community should stick to? Similar to what is
> being done in many other projects, like Ubuntu, etc. Or would
> this break the ACS project releases even more?
>
> Andrei
>
>>
>>
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVN1lgAAoJEAGbWC3bPspCaCYP/iKp9N1XEne9pEzlDm/cTRMm
> wM0qNKiKNepXQocfxm2l35BSsdbnQZHwbXhs/IhcvOGsOfoYq+HvLDsuQWm/ut4F
> RQdz38A5fHTX9wuQHeO11OQN12FE2PR61EUL1+NBt86Z9z/qjuXYuc6I3zQfj4Cn
> fS+3EF62gsrudDvQA1JLbjQe/v3YlHYoYavn2miOSJMpnDnVnil1M5ZDASGFAoY+
> nWFODk4P/8PbYAQmLOCS+TUxF3WcOEYV5sDgYdJS2cMTTtzoTCbI70scXViuzwOE
> JikMF8v5rOXpVLbu9wsIzpbpbiXB+h+Gx4jzWTpV+BMpmbbw40Q/X/Wm92Gqkw6N
> lnrWqDo5DipTEfNnDlzw

Re: Next ACS release?

2015-04-22 Thread Erik Weber

On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner 
wrote:

> I have to admit I'm a bit sceptical because when we did have a four-month
> release cycle, we never seemed to manage to meet it. Personally I think
> six-monthly might be easier.
>
> Having said that, part of the problem was the long close-down period where
> we kept finding critical bugs, so more automated testing might help to
> shorten the cycle.
>
>

- Shorter cycle means that it's less of a problem to miss a deadline,
meaning you can spend more time on QA.
- Longer cycle means that it could be critical to meet the deadline,
meaning you might end up doing less QA while stressing to get your feature
in.

My $.002

-- 
Erik

Re: Next ACS release?

2015-04-22 Thread Nux!

What is required for this RM to happen?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Sent: Wednesday, 22 April, 2015 09:28:27
> Subject: Re: Next ACS release?

> the community is us... (well not just us, Wido) Having a master RM
> would be my first step towards this goal.
> 
> On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> On 04/22/2015 10:08 AM, Daan Hoogland wrote:
>>> I strongly advice my fellow community members to go for a lower
>>> duration, not longer. Each feature deserves a release and I'd say
>>> let's release every 2 months, provides a new feature was added.
>>> Also we now release fix releases when we feel the urgency. This
>>> means users, that are not also developers have little influence.
>>> Let's release every two weeks, provided fixes where applicable.
>>>
>>> €0,02++ wanting to get out of this vicious circle is my drive
>>>
>>
>> Oh, I would really love that to happen. No doubt about it :-)
>>
>>> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner
>>>  wrote:
 I have to admit I'm a bit sceptical because when we did have a
 four-month release cycle, we never seemed to manage to meet it.
 Personally I think six-monthly might be easier.

 Having said that, part of the problem was the long close-down
 period where we kept finding critical bugs, so more automated
 testing might help to shorten the cycle.

 -- Stephen Turner




 -Original Message- From: Andrei Mikhailovsky
 [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To:
 dev@cloudstack.apache.org Subject: Re: Next ACS release?

 Ilya, Mark, thanks for your feedback,

 I also see the need to restructure the release schedule for ACS
 as the current release cycles are not really working. There is no
 _reliable_ release cycle of the product and as we have recently
 seen with the 4.5 branch, the release did not happen for months
 and it is still not clear when this will take place. In my (I
 must admit somewhat limited) experience if there are no
 deadlines, developers are not keen on releases and the release
 are likely to be delayed. This is what we've seen with the past
 ACS releases, they are overdue by many months.

 The community might get a much better responce if there is a much
 shorter release cycle even if it means pushing out less features
 with each release. At least some features will get completed,
 tested and implemented in a set time frame. I would rather see a
 release cycle of every 3-4 months with 5 new features than a
 release with 15 new features which may or may not get released
 every 9 - 12 months.

 By any means, please comment if someone disagrees or thinks there
 is a better alternative.

 Andrei - Original Message -

> From: "ilya"  To:
> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34
> PM Subject: Re: Next ACS release?

> Andrei,

> To best of my knowledge, both 4.4.x and 4.5.x are being worked
> on actively. As a community, we need to get better on QA of
> each release - this is something we are planning to cover this
> year with distributed QA model, this was not widely discussed
> yet but something we need to tackle.

> 4.5 rc2 got stalled and we need to restart. We had a 4 month
> release cycle, but we can really stick to it hard - as its
> community driven. May will have to revise it down to 6 months
> or so.

> Regards ilya

> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
>> Hello guys,
>>
>> Looking at the dev and user lists it is becoming less certain
>> if version 4.5.x is ever coming out. It seems like a few
>> months have passed since the not so fortunate release of
>> 4.5.0 and I can't find a release schedule for the 4.5.1,
>> which seems to have stopped at rc2 stage and haven't
>> progressed further to a release stage.
>>
>> Are we likely to see any progress with the 4.5.x branch or is
>> the community switching towards the 4.6.x branch without
>> releasing the 4.5.x?
>>
>> I am a bit unclear as there are no release dates, schedules
>> or dead lines that the community should work with. Possibly
>> as a result of this, the ACS releases are not being released
>> on time or fast enough.
>>
>> Does it make sense to introduce release schedules for ACS
>> that the dev community should stick to? Similar to what is
>> being done in many other projects, like Ubuntu, etc. Or would
>> this break the ACS project releases even more?
>>
>> Andrei
>>
>>>
>>>
>>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJVN1lgAAoJEAGbWC3bPspCaCYP/i

Re: Next ACS release?

Yes, Eric and the amount of qa needed is less as well. Bare with me
for a little rant here.

When less new features are introduced less new interdependencies are
introduced. I could try and expand on this but people make phd on the
subject so that would be presumptuous of me.

un-educated guess is (m + n)! - m!
where m is old features and n is new features

example:
1 old feature + 1 new feature mean 1 check to see if they (still) work
1 old feature + 2 new features means 3 checks to see if they all work
2 + 2 = 6 of which only 1 is old and should be fine
2 + 3 = 10, see the n! progressing ;)

this is an over simplification as the complexity of features comes in
play as well. I make them out for being function points here. those
are fables of course.

thanks for baring that.

On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber  wrote:
> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner 
> wrote:
>
>> I have to admit I'm a bit sceptical because when we did have a four-month
>> release cycle, we never seemed to manage to meet it. Personally I think
>> six-monthly might be easier.
>>
>> Having said that, part of the problem was the long close-down period where
>> we kept finding critical bugs, so more automated testing might help to
>> shorten the cycle.
>>
>>
>
> - Shorter cycle means that it's less of a problem to miss a deadline,
> meaning you can spend more time on QA.
> - Longer cycle means that it could be critical to meet the deadline,
> meaning you might end up doing less QA while stressing to get your feature
> in.
>
> My $.002
>
> --
> Erik

-- 
Daan

Re: Next ACS release?

for us all to agree we should go this way. then for us to have a
(scheduled?) volunteer.

On Wed, Apr 22, 2015 at 10:44 AM, Nux!  wrote:
> What is required for this RM to happen?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Wednesday, 22 April, 2015 09:28:27
>> Subject: Re: Next ACS release?
>
>> the community is us... (well not just us, Wido) Having a master RM
>> would be my first step towards this goal.
>>
>> On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>>
>>>
>>> On 04/22/2015 10:08 AM, Daan Hoogland wrote:
 I strongly advice my fellow community members to go for a lower
 duration, not longer. Each feature deserves a release and I'd say
 let's release every 2 months, provides a new feature was added.
 Also we now release fix releases when we feel the urgency. This
 means users, that are not also developers have little influence.
 Let's release every two weeks, provided fixes where applicable.

 €0,02++ wanting to get out of this vicious circle is my drive

>>>
>>> Oh, I would really love that to happen. No doubt about it :-)
>>>
 On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner
  wrote:
> I have to admit I'm a bit sceptical because when we did have a
> four-month release cycle, we never seemed to manage to meet it.
> Personally I think six-monthly might be easier.
>
> Having said that, part of the problem was the long close-down
> period where we kept finding critical bugs, so more automated
> testing might help to shorten the cycle.
>
> -- Stephen Turner
>
>
>
>
> -Original Message- From: Andrei Mikhailovsky
> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To:
> dev@cloudstack.apache.org Subject: Re: Next ACS release?
>
> Ilya, Mark, thanks for your feedback,
>
> I also see the need to restructure the release schedule for ACS
> as the current release cycles are not really working. There is no
> _reliable_ release cycle of the product and as we have recently
> seen with the 4.5 branch, the release did not happen for months
> and it is still not clear when this will take place. In my (I
> must admit somewhat limited) experience if there are no
> deadlines, developers are not keen on releases and the release
> are likely to be delayed. This is what we've seen with the past
> ACS releases, they are overdue by many months.
>
> The community might get a much better responce if there is a much
> shorter release cycle even if it means pushing out less features
> with each release. At least some features will get completed,
> tested and implemented in a set time frame. I would rather see a
> release cycle of every 3-4 months with 5 new features than a
> release with 15 new features which may or may not get released
> every 9 - 12 months.
>
> By any means, please comment if someone disagrees or thinks there
> is a better alternative.
>
> Andrei - Original Message -
>
>> From: "ilya"  To:
>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34
>> PM Subject: Re: Next ACS release?
>
>> Andrei,
>
>> To best of my knowledge, both 4.4.x and 4.5.x are being worked
>> on actively. As a community, we need to get better on QA of
>> each release - this is something we are planning to cover this
>> year with distributed QA model, this was not widely discussed
>> yet but something we need to tackle.
>
>> 4.5 rc2 got stalled and we need to restart. We had a 4 month
>> release cycle, but we can really stick to it hard - as its
>> community driven. May will have to revise it down to 6 months
>> or so.
>
>> Regards ilya
>
>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote:
>>> Hello guys,
>>>
>>> Looking at the dev and user lists it is becoming less certain
>>> if version 4.5.x is ever coming out. It seems like a few
>>> months have passed since the not so fortunate release of
>>> 4.5.0 and I can't find a release schedule for the 4.5.1,
>>> which seems to have stopped at rc2 stage and haven't
>>> progressed further to a release stage.
>>>
>>> Are we likely to see any progress with the 4.5.x branch or is
>>> the community switching towards the 4.6.x branch without
>>> releasing the 4.5.x?
>>>
>>> I am a bit unclear as there are no release dates, schedules
>>> or dead lines that the community should work with. Possibly
>>> as a result of this, the ACS releases are not being released
>>> on time or fast enough.
>>>
>>> Does it make sense to introduce release schedules for ACS
>>> that the dev community should stick to? Similar to what is
>>>

Re: Next ACS release?

2015-04-22 Thread Erik Weber

On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland 
wrote:

> On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber  wrote:
> > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
> stephen.tur...@citrix.com>
> > wrote:
> >
> >> I have to admit I'm a bit sceptical because when we did have a
> four-month
> >> release cycle, we never seemed to manage to meet it. Personally I think
> >> six-monthly might be easier.
> >>
> >> Having said that, part of the problem was the long close-down period
> where
> >> we kept finding critical bugs, so more automated testing might help to
> >> shorten the cycle.
> >>
> >>
> >
> > - Shorter cycle means that it's less of a problem to miss a deadline,
> > meaning you can spend more time on QA.
> > - Longer cycle means that it could be critical to meet the deadline,
> > meaning you might end up doing less QA while stressing to get your
> feature
> > in.
> >
> > My $.002
>
>
Yes, Eric and the amount of qa needed is less as well. Bare with me
> for a little rant here.
>
> When less new features are introduced less new interdependencies are
> introduced. I could try and expand on this but people make phd on the
> subject so that would be presumptuous of me.
>
> un-educated guess is (m + n)! - m!
> where m is old features and n is new features
>
> example:
> 1 old feature + 1 new feature mean 1 check to see if they (still) work
> 1 old feature + 2 new features means 3 checks to see if they all work
> 2 + 2 = 6 of which only 1 is old and should be fine
> 2 + 3 = 10, see the n! progressing ;)
>
>
> this is an over simplification as the complexity of features comes in
> play as well. I make them out for being function points here. those
> are fables of course.
>
> thanks for baring that.
>
>
I'm all with you on this Daan.
Just for the record, my notion of QA was meant at the feature developer,
ie. that they could use more time on test coverage etc. without having to
worry that much about feature freeze dates.

-- 
Erik

Re: Next ACS release?

2015-04-22 Thread Remi Bergsma

I'd be happy to help here as well. Last week in Austin, we also discussed
this topic a couple of times. I do agree shorter release cycles are better.

In my opinion, the first thing to improve is the minor releases in both the
4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks
we will be able to do the next minor release with less effort and users can
choose to either wait to start using 4.5 or start now and upgrade when the
next minor release is available. This would have helped in getting 4.5 out
on time and quickly fixing issues after the initial release. Also, it will
save time which we can invest in getting the next release out on time, etc.

The common thing here is we need more automated testing, preferably
functional testing in addition to unit testing. There might also be other
steps that we do manually now that can be automated. I'll try to understand
the current process first and then come up with a proposal to improve which
we can discuss.

Regards,
Remi

2015-04-22 10:56 GMT+02:00 Erik Weber :

> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland 
> wrote:
>
> > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
> wrote:
> > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
> > stephen.tur...@citrix.com>
> > > wrote:
> > >
> > >> I have to admit I'm a bit sceptical because when we did have a
> > four-month
> > >> release cycle, we never seemed to manage to meet it. Personally I
> think
> > >> six-monthly might be easier.
> > >>
> > >> Having said that, part of the problem was the long close-down period
> > where
> > >> we kept finding critical bugs, so more automated testing might help to
> > >> shorten the cycle.
> > >>
> > >>
> > >
> > > - Shorter cycle means that it's less of a problem to miss a deadline,
> > > meaning you can spend more time on QA.
> > > - Longer cycle means that it could be critical to meet the deadline,
> > > meaning you might end up doing less QA while stressing to get your
> > feature
> > > in.
> > >
> > > My $.002
> >
> >
> Yes, Eric and the amount of qa needed is less as well. Bare with me
> > for a little rant here.
> >
> > When less new features are introduced less new interdependencies are
> > introduced. I could try and expand on this but people make phd on the
> > subject so that would be presumptuous of me.
> >
> > un-educated guess is (m + n)! - m!
> > where m is old features and n is new features
> >
> > example:
> > 1 old feature + 1 new feature mean 1 check to see if they (still) work
> > 1 old feature + 2 new features means 3 checks to see if they all work
> > 2 + 2 = 6 of which only 1 is old and should be fine
> > 2 + 3 = 10, see the n! progressing ;)
> >
> >
> > this is an over simplification as the complexity of features comes in
> > play as well. I make them out for being function points here. those
> > are fables of course.
> >
> > thanks for baring that.
> >
> >
> I'm all with you on this Daan.
> Just for the record, my notion of QA was meant at the feature developer,
> ie. that they could use more time on test coverage etc. without having to
> worry that much about feature freeze dates.
>
> --
> Erik
>

AW: Next ACS release?

2015-04-22 Thread S . Brüseke - proIO GmbH

In my opinion we need to improve QA! If smaller cycles will help to do that 
this is the way to go. I joined this list after the "release" of 4.5, but as 
far as I know 4.5 is not really usable for production because of critical bugs 
in it that good QA would not have passed.
So if CS releases new version every 2 month with just a few new features, but 
these are working, it would be great. We also can do some bug fixing and 
code-cleaning too.

My $.002

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke

-Ursprüngliche Nachricht-
Von: Remi Bergsma [mailto:r...@remi.nl] 
Gesendet: Mittwoch, 22. April 2015 11:25
An: dev@cloudstack.apache.org
Betreff: Re: Next ACS release?

I'd be happy to help here as well. Last week in Austin, we also discussed this 
topic a couple of times. I do agree shorter release cycles are better.

In my opinion, the first thing to improve is the minor releases in both the
4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we 
will be able to do the next minor release with less effort and users can choose 
to either wait to start using 4.5 or start now and upgrade when the next minor 
release is available. This would have helped in getting 4.5 out on time and 
quickly fixing issues after the initial release. Also, it will save time which 
we can invest in getting the next release out on time, etc.

The common thing here is we need more automated testing, preferably functional 
testing in addition to unit testing. There might also be other steps that we do 
manually now that can be automated. I'll try to understand the current process 
first and then come up with a proposal to improve which we can discuss.

Regards,
Remi

2015-04-22 10:56 GMT+02:00 Erik Weber :

> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland 
> 
> wrote:
>
> > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
> wrote:
> > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
> > stephen.tur...@citrix.com>
> > > wrote:
> > >
> > >> I have to admit I'm a bit sceptical because when we did have a
> > four-month
> > >> release cycle, we never seemed to manage to meet it. Personally I
> think
> > >> six-monthly might be easier.
> > >>
> > >> Having said that, part of the problem was the long close-down 
> > >> period
> > where
> > >> we kept finding critical bugs, so more automated testing might 
> > >> help to shorten the cycle.
> > >>
> > >>
> > >
> > > - Shorter cycle means that it's less of a problem to miss a 
> > > deadline, meaning you can spend more time on QA.
> > > - Longer cycle means that it could be critical to meet the 
> > > deadline, meaning you might end up doing less QA while stressing 
> > > to get your
> > feature
> > > in.
> > >
> > > My $.002
> >
> >
> Yes, Eric and the amount of qa needed is less as well. Bare with me
> > for a little rant here.
> >
> > When less new features are introduced less new interdependencies are 
> > introduced. I could try and expand on this but people make phd on 
> > the subject so that would be presumptuous of me.
> >
> > un-educated guess is (m + n)! - m!
> > where m is old features and n is new features
> >
> > example:
> > 1 old feature + 1 new feature mean 1 check to see if they (still) 
> > work
> > 1 old feature + 2 new features means 3 checks to see if they all 
> > work
> > 2 + 2 = 6 of which only 1 is old and should be fine
> > 2 + 3 = 10, see the n! progressing ;)
> >
> >
> > this is an over simplification as the complexity of features comes 
> > in play as well. I make them out for being function points here. 
> > those are fables of course.
> >
> > thanks for baring that.
> >
> >
> I'm all with you on this Daan.
> Just for the record, my notion of QA was meant at the feature 
> developer, ie. that they could use more time on test coverage etc. 
> without having to worry that much about feature freeze dates.
>
> --
> Erik
>

- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet. 

This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail in error) 
please notify 
the sender immediately and destroy this e-mail.  
Any unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

[GitHub] cloudstack pull request: Incorporated Review comments provided in ...

GitHub user sanju1010 opened a pull request:

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

Incorporated Review comments provided in PR # 183



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sanju1010/cloudstack CS-38815

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/187.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #187


commit a3117dae26ca34f0e165ed45b4d3157cdbb04ea6
Author: sanjeev 
Date:   2015-04-21T12:11:38Z

Added additional verification steps to make sure that removing secondary ip 
from nic works fine

commit bbf976444b144ad09886b44c8ec9fc93ad5ec907
Author: sanjeev 
Date:   2015-04-21T12:18:44Z

Removed tag from the attr

commit 91b5dbca81ce68a841e798482921ca8567591de8
Author: sanjeev 
Date:   2015-04-22T09:44:52Z

Incorporated review comments provided in PR#183




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Add more verifications to make sure that ...

Github user sanju1010 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Add more verifications to make sure that ...

Github user sanju1010 commented on the pull request:

https://github.com/apache/cloudstack/pull/183#issuecomment-95104669
  
Created new PR #187 with the review comments incorporated.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Escalations

Github user sanju1010 commented on the pull request:

https://github.com/apache/cloudstack/pull/184#issuecomment-95113695
  
Looks good. I am taking this patch.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: [DISCUSS] 4.6 release management

2015-04-22 Thread Raja Pullela

Sebastien, I am taking about the tests we have under "test/integration/smoke" 
folder.  
Not sure how the tests run through Travis, will try to understand.
These are tests were run on a local cloudstack env.  

best,
Raja
-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Friday, April 17, 2015 1:14 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management


> On Apr 17, 2015, at 6:26 AM, Raja Pullela  wrote:
> 
> +1 for the "Some people (I'm part of them) are concerned on our current way 
> of supporting and back porting fixes to multiple release"
> This should be a top priority along with keeping master stable - make sure 
> BVTs are passing at 100% all the time.

Raja, which BVT are you talking about ? AFAIK, all current tests run on all 
commits through Travis.

> Also if we can plan/target increasing test/BVT coverage, that will be super!
> 
> Thanks,
> Raja
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, April 17, 2015 4:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
> 
> "storage plugin involve changes on Hypervisor code"
> 
> I know this is just an example, but at least on KVM side this is no longer 
> true. Previously you had to implement a KVM-specific 'StorageAdaptor' that 
> would run on the hypervisor, and register that with the agent code, but Mike 
> and I added some reflection/annotation that allows for auto-detection of the 
> adaptor upon Agent start up, so storage plugins can be completely 
> self-contained now. They don't even have to be a part of our code base.
> 
> There may be other parts of the code where we can do similar things to 
> decouple if we can identify those points.  Ideally, if someone has to modify 
> core code to add their plugin it should only be because they are adding some 
> new functionality *that core cloudstack needs to be aware of*, and that 
> functionality should be added in a way that other plugins can also 
> provide/implement it. Otherwise, they can always add new APIs specific to 
> their appliance or product and leveraging data from cloudstack's db, all via 
> plugin. They can add new global/zone/cluster configs and UI tools via plugin 
> as well.
> 
> On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion  wrote:
>> Today during the CloudStackdays  we did a round table about Release 
>> management targeting the next 4.6 releases.
>> 
>> 
>> Quick bullet point discussions:
>> 
>> ideas to change release planning
>> 
>>   - Plugin contribution is complicated because often  a new plugin involve
>>   change on the core:
>>  - ex: storage plugin involve changes on Hypervisor code
>>   - There is an idea of going on a 2 weeks release model which could
>>   introduce issue the database schema.
>>   - Database schema version should be different then the application
>>   version.
>>   - There is a will to enforce git workflow in 4.6  and trigger simulator
>>   job on  PullRequest.
>>   - Some people (I'm part of them) are concerned on our current way of
>>   supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>   4.5.x). But the current level of confidence against latest release is low,
>>   so that need to be improved.
>> 
>> 
>> So, the main messages is that w'd like to improve the release 
>> velocity, and release branch stability.  so we would like to propose 
>> few change in the way we would add code to the 4.6 branch as follow:
>> 
>> - All new contribution to 4.6 would be thru Pull Request or merge 
>> request, which would trigger a simulator job, ideally only if that 
>> pass the PR would be accepted and automatically merged.  At this 
>> time, I think we pretty much have everything in place to do that. At 
>> a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>> 
>> Please comments :-)

[GitHub] cloudstack pull request: Incorporated Review comments provided in ...

Github user sanju1010 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: getting rid of 3rd party repositories (ceph, libvirt)

2015-04-22 Thread Laszlo Hornyak

Hi Wido,

I should have read the git log first :-)

No license issues and no code change needed. All I want to have is
rados-java in the central maven repository for two reasons:
- central is the most reliable service
- we can not upload our artifacts to central until we have a dependency on
other repositories, and therefore users and developers are not able to reuse

I will send you a PR for the pom file. This is needed in order to compliy
central repository upload policy, no functional changes, only meta-data.

And then, let's see.. do you own the repository in central repo? Basically
either you can upload or I can upload for you if you give me permission, in
any case I will try to help.

Best regards,
Laszlo

On Wed, Apr 22, 2015 at 9:20 AM, Wido den Hollander  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 04/21/2015 09:12 PM, Laszlo Hornyak wrote:
> > Hi,
> >
> > I have uploaded the libvirt dependency to maven central and you
> > should never get the maven failure if the libvirt.org server goes
> > down, it will be downloaded from central. I have sent a PR (#180)
> > to remove the libvirt.org repository from the build.
> >
> > With ceph.org the situation: - I have requested permission to
> > publish like with libvirt, my request was rejected since the
> > ceph.com team holds ownership - The only solution from here is to
> > change the groupId of the dependency. - org.apache.* is very likely
> > no go, it is owned by apache, artifacts are synchonrized to central
> > through the apache repository, which is for apache artifacts only.
> > - we can upload with a new groupId - suggestions are welcome
> >
>
> I wrote the rados-java bindings and licensed it under the Apache License
> .
>
> I choose com.ceph as a package since that was the easiest way. It
> would be changed but I don't want to break all the existing code for
> users.
>
> Any ideas?
>
> Wido
>
> > Regards, Laszlo
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVN0unAAoJEAGbWC3bPspCKbAP/1d8gAmu+//zR/uhFAju+gEI
> TGLvXhFv4uX9IKwGwMS9oiNDxYDQ9GPY17zShf41B271Ft9F8HZ8ovEfj8uauwaV
> sr/2jHhI14Hb7d09vSBc1DmXzJ3iYyrQFYno/z7rVRTHJmJ67xrJPT7+ZjPOxI7E
> aXoZMIBSuKPEJKwJl2vY8AsdFeU1LnPaKPC/vqUqqh94eIw1jk67ZgoCLctKOIig
> 43b0eZiRCrsGsiXYURH8pihlxDKY5ipz5utRY0ngb64xJRx2u/XSBDPFGtiwNR2O
> dWTVACqgqnSKdDdr3cqZ6eDEaxKmViupi672fOTjZjgpnQojWKvLti4DVdcqMFle
> BYGguzVcJZQpt8MSiiS9ATtm4WJkaePQsTS3T4BiqrxIpUfeYhhrCeE3Q+dykIYn
> BdtsMBhAdM930Lv+6Zk/W6mmcxKmeXXU6ImOV95nYnvN53Q2+DEya06fZHsH80nR
> eEO8uzS/Rz2GcumPClVV9Hv+g+nt6gYw+8w+OuVQIsU4YdQ0coOhsOYRleTeurBY
> 3JSZ8q4XX+PCZVpwLOZ6myKgNZFqGjk0CWi6DD3RssCQiZo5yWAJyENfVrX8GjO+
> 8pEQup2ACn/WR/A3o4q4Zq0m4B4u0wYXFmRgQ/kvOxSSeqhMhQlGZPsdrYLbM4P9
> WeH67OGvyb+F/83N5ezx
> =W4ry
> -END PGP SIGNATURE-
>



-- 

EOF

Jenkins build is still unstable: simulator-singlerun #1136

2015-04-22 Thread jenkins

See

Re: Jenkins build is still unstable: simulator-singlerun #1136

The simulator run has not been stable for three weeks. Anybody knows
what the problem with the ISO test is?

On Wed, Apr 22, 2015 at 1:48 PM,   wrote:
> See 
>



-- 
Daan

Re: Jenkins build is still unstable: simulator-singlerun #1136

2015-04-22 Thread Ian Southam

Traceback (most recent call last):
  File 
"/var/lib/jenkins/workspace/simulator-singlerun/tools/marvin/marvin/sshClient.py",
 line 121, in createConnection
timeout=self.timeout)
  File "/usr/local/lib/python2.7/site-packages/paramiko/client.py", line 251, 
in connect
retry_on_signal(lambda: sock.connect(addr))
  File "/usr/local/lib/python2.7/site-packages/paramiko/util.py", line 270, in 
retry_on_signal
return function()
  File "/usr/local/lib/python2.7/site-packages/paramiko/client.py", line 251, 
in 
retry_on_signal(lambda: sock.connect(addr))
  File "/usr/local/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
timeout: timed out
Trying SSH Connection: Host:192.168.2.5 User:root   
Port:22 RetryCnt:1===


I am seeing something similar on my test env.  Looking at it now.

—
Ian

On 22 Apr 2015, at 14:02, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

The simulator run has not been stable for three weeks. Anybody knows
what the problem with the ISO test is?

On Wed, Apr 22, 2015 at 1:48 PM,  
mailto:jenk...@cloudstack.org>> wrote:
See 




--
Daan

Re: [DISCUSS] Moving to Java 8

2015-04-22 Thread Wilder Rodrigues

Hi Wido,

Thanks for the reply and making a good point concerning Ubuntu 14.04.

Besides the difficulty in writing testes without increasing even more out 
technical dept, another point on the Java 8 platform is the EOL (end of this 
month) of Java 1.7.

For now I created a ticket on Apache Jira to keep track of it: 
https://issues.apache.org/jira/browse/CLOUDSTACK-8397. Could you please have a 
look and let me know if the content of the ticket is appropriate?

We will start a new sprint in 1 week and will take some time to discuss what to 
do and when. Will keep the community updated on that matter.

Thanks a gain.

Cheers,
Wilder


On 21 Apr 2015, at 15:49, Wido den Hollander 
mailto:w...@widodh.nl>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/21/2015 03:27 PM, Wilder Rodrigues wrote:
Hi all,

Yesterday I started working on the LibvirtComputingResource class
in order to apply the same patterns I used in the
CitrixResourceBase + add more unit tests to it After 10 hours of
work I got a bit stuck with the 1st test, which would cover the
refactored LibvirtStopCommandWrapper. Why did I get stuck? The
class used a few static methods that call native libraries, which I
would like to mock. However, when writing the tests I faced
problems with the current Mockito/PowerMock we are using: they are
simply not enough for the task.

What did I do then? I added a dependency to EasyMock and
PowerMock-EasyMock API. It worked almost fine, but I had to add a
“-noverify” to both my Eclipse Runtime configuration and also to
the cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not
nice, but was my first attempt of getting it to work. After trying
to first full build I faced more problems related to
ClassDefNotFoundExpcetion which were complaining about Mockito
classes. I then found out that adding the PowerMockRunner to all
the tests classes was going to be a heavy burden and would also
mess up future changes (e.g. the -noverify flag was removed from
Java 8, thus adding it now would be a problem soon).

Now that the first 2 paragraphs explain a bit about the problem,
let’s get to the solution: Java 8

The VerifyError that I was getting was due to the use of the latest
EasyMock  release (3.3.1). I tried to downgrade it to 3.1/3.2 but
it also did not work. My decision: do not refactor if the proper
tests cannot be added. This left me with one action: migrate to
Java 8.

There were mentions about Java 8 in february[1] and now I will put
some energy in making it happen.

What is your opinion on it?


I'm not against it technically, but practically I am.

Ubuntu 14.04 does not ship a Java 8 JRE in the repositories.

CentOS 7 has java-1.8.0-openjdk.x86_64 available, so it would work
there. But Ubuntu is also widely used with CloudStack, so those users
couldn't use CloudStack without any additional repositories.

Since that isn't easy I would vote -1 on this if it came that far.

Wido

Thanks in advance.

Cheers, Wilder

http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3
c54eef6be.5040...@shapeblue.com%3E>>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVNlV2AAoJEAGbWC3bPspCfYgQAMoXgekM6/NHXivIGLfbhekK
ghf+Ll1EFku+9IdMUdaholO0bLz7TQ+DOphr+xikVNizqakSnYCSF5wjiKQYtc+g
LCPvWhbp8UG4LjbjWdK80FPtbx0WH9OZg/XK097NQoFRNpchxRprpFoSSYJMAhqh
WjDvwfgzCITw9pqC3jI8l3Sy/i1/yv7fFRv//w4vHOqRa+4urst+dXASGer83IAX
zCJdp+SxOx2VnUDta32KJFc6CsV2rV4BW+5dPAhJad7mFd6EafngSWZRuJmjkbsq
tSiULlUAluXSnZ86FQESDhffYJdp/fkjWbmZvSRYgE+Xn5cAyB02z9ukLeJktNgq
3UjIyINiU7182IXlrRUciZXXexc8jfYCaQ8wmgOjxmpPdih0zqWBa4RWA8VCt4SM
Sw5BXO3hDjXljxrbeXs3AHSDPAslNoSDOEmKVeLYDdMWbO0Z7FvUurRuv4LKgOdE
lofDGIcUBw++AE1DuF+vIU/Gnfo61oMzY2FPvXp4V+wHekf+uet8H4MPs0Y5PFDD
9HyewO+aWEC0w8LQVAIevP8pwbArv4zX65AtSWI2IKqmwQOpvIeuB2M7sdxgoNM+
M7IMdYBC3XyIcxqYwDvevlAM0PoeUhpYY9m6fpfirlhJMXS8nBEA1H45cQQBCVDz
/uhF9CC8wnEQcb2cu+lF
=Hhwq
-END PGP SIGNATURE-

Re: [DISCUSS] Moving to Java 8

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 04/22/2015 02:13 PM, Wilder Rodrigues wrote:
> Hi Wido,
> 
> Thanks for the reply and making a good point concerning Ubuntu
> 14.04.
> 
> Besides the difficulty in writing testes without increasing even
> more out technical dept, another point on the Java 8 platform is
> the EOL (end of this month) of Java 1.7.
> 

Yes, I'm aware of that. So that makes this situation difficult.

There is a bug open for backporting OpenJDK 8 to Ubuntu 14.04:
https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1341628

More votes there would really help.

> For now I created a ticket on Apache Jira to keep track of it:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8397. Could you
> please have a look and let me know if the content of the ticket is
> appropriate?
> 
> We will start a new sprint in 1 week and will take some time to
> discuss what to do and when. Will keep the community updated on
> that matter.
> 
> Thanks a gain.
> 
> Cheers, Wilder
> 
> 
> On 21 Apr 2015, at 15:49, Wido den Hollander
> mailto:w...@widodh.nl>> wrote:
> 
> 
> 
> On 04/21/2015 03:27 PM, Wilder Rodrigues wrote: Hi all,
> 
> Yesterday I started working on the LibvirtComputingResource class 
> in order to apply the same patterns I used in the 
> CitrixResourceBase + add more unit tests to it After 10 hours of 
> work I got a bit stuck with the 1st test, which would cover the 
> refactored LibvirtStopCommandWrapper. Why did I get stuck? The 
> class used a few static methods that call native libraries, which
> I would like to mock. However, when writing the tests I faced 
> problems with the current Mockito/PowerMock we are using: they are 
> simply not enough for the task.
> 
> What did I do then? I added a dependency to EasyMock and 
> PowerMock-EasyMock API. It worked almost fine, but I had to add a 
> “-noverify” to both my Eclipse Runtime configuration and also to 
> the cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not 
> nice, but was my first attempt of getting it to work. After trying 
> to first full build I faced more problems related to 
> ClassDefNotFoundExpcetion which were complaining about Mockito 
> classes. I then found out that adding the PowerMockRunner to all 
> the tests classes was going to be a heavy burden and would also 
> mess up future changes (e.g. the -noverify flag was removed from 
> Java 8, thus adding it now would be a problem soon).
> 
> Now that the first 2 paragraphs explain a bit about the problem, 
> let’s get to the solution: Java 8
> 
> The VerifyError that I was getting was due to the use of the
> latest EasyMock  release (3.3.1). I tried to downgrade it to
> 3.1/3.2 but it also did not work. My decision: do not refactor if
> the proper tests cannot be added. This left me with one action:
> migrate to Java 8.
> 
> There were mentions about Java 8 in february[1] and now I will put 
> some energy in making it happen.
> 
> What is your opinion on it?
> 
> 
> I'm not against it technically, but practically I am.
> 
> Ubuntu 14.04 does not ship a Java 8 JRE in the repositories.
> 
> CentOS 7 has java-1.8.0-openjdk.x86_64 available, so it would work 
> there. But Ubuntu is also widely used with CloudStack, so those
> users couldn't use CloudStack without any additional repositories.
> 
> Since that isn't easy I would vote -1 on this if it came that far.
> 
> Wido
> 
> Thanks in advance.
> 
> Cheers, Wilder
> 
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3
>
> 
c54eef6be.5040...@shapeblue.com%
3E box/cloudstack-dev/201502.mbox/<54eef6be.5040...@shapeblue.com>>
>
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVN5dgAAoJEAGbWC3bPspCzX8P/0o8V8ZZPF+mOiXwfvZxOoqn
Xtb084SajpLvB4KFT207FecJ6rKJyJiSXZSW6esj1F5OBzoDzF30vWHityvvatCA
LsY5zCj2LF01itmjK8SVXuuwK8sSINycJPu2jJVotYr4ooPM1pHJjv/UnQfrUgp3
yv8vT3VKhrPLkGOIIcRR8zmIPH6qtgTf/ILBsc9hUrkvYgfmReH1dkeQY4gid3TZ
sHGrnYHby2SgW+9KbuEfdvOrHvItYbJpRWz6W3R6l+DQeZxMt/pMbZRXEM4LXkuL
/t450iwybpMZzwwnPYqu0TjTjSI0AFZp9gq+obygEnbDsbCXMuUKRHNymCdUZH3r
hldfP1dmAwPEjJ0Z9PgybvmitaAqvUg80BeS7iS/6SPulGx6hFiafrdCgjdQ7bxM
qN4nGcFIwxmzphhljnLARxRxl2/50KuZTYmC3XmyfbrUYX+BiDW8FoMbCd5qJJyC
r48w2gPQW52HyVckM532PFpMWah7If8Q0Ee9w0JrTEF3RRkMQ7NySUvK0Y9er8ay
D6fmw5szuWWNF7bSC6wNx5bY7EyNGp7rDa1Ki4f4G7chh6m16yhYSQ0fLBjro6fw
sFbs7EKAa9iCsyHbPQBpz3IoqkSbCknnHbXAInQOyybLKendwZ2f9LVA8K0GFlHH
uMsBvF/FH1bnVg+oX8N3
=oFqF
-END PGP SIGNATURE-

Doc need to update for ACS 4.5 Important

2015-04-22 Thread Keerthiraja SJ

Hi All,

I installed ACS 4.5 with reference below link.

http://cloudstack-installation.readthedocs.org/en/latest/management-server/index.html#install-the-management-server-on-the-first-host

In the doc there is a step which says need to download the vhd-util and
copy.

Downloading vhd-util

This procedure is required only for installations where XenServer is
installed on the hypervisor hosts.

Before setting up the Management Server, download vhd-util
from
http://download.cloud.com.s3.amazonaws.com/tools/vhd-util. and copy it into
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver of the
Management Server.

But as per the default install I could see the vhd-util seems to be there
in the location already. If this is not required I hope we can delete this
line and make the doc small.

Another issue I could see is there no any specification for MariaDB
setting. If any users try to install using MariaDB I don't think below
setting will work for the MariaDB.

If any recommendation is there for the MariaDB we need to provide for the
users.

*This pasted line only talk about the setting for the MYSQL.*

Open the MySQL configuration file. The configuration file is /etc/my.cnf or
/etc/mysql/my.cnf, depending on your OS.

Insert the following lines in the [mysqld] section.

You can put these lines below the datadir line. The max_connections
parameter should be set to 350 multiplied by the number of Management
Servers you are deploying. This example assumes one Management Server.

innodb_rollback_on_timeout=1innodb_lock_wait_timeout=600max_connections=350
log-bin=mysql-bin

binlog-format = 'ROW'

As per the ACS 4.5.1 we Improved Use of MariaDB as cloudstack management
server database.

For this point I hope we might need to guide little about the MariaDB.

Thanks,
Keerthi

[GitHub] cloudstack-docs-install pull request: Update xenserver.rst

2015-04-22 Thread SheerIce

GitHub user SheerIce opened a pull request:

https://github.com/apache/cloudstack-docs-install/pull/23

Update xenserver.rst

Fixed typo.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SheerIce/cloudstack-docs-install patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack-docs-install/pull/23.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #23


commit 93c5db59dac35aaba333a6284f48c84846faa1dc
Author: Kyle 
Date:   2015-04-22T15:04:47Z

Update xenserver.rst

Fixed typo.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8395: vmops plugin should work...

2015-04-22 Thread bhaisaab

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/186#issuecomment-95254152
  
@xenserverarmy @agneya2001 the latest update I did was to flush iptables 
rules before setting up ipset rules, this removes ipset references so easier to 
remove old iphash based ipset (when swapping). This way, the solutions works 
irrespective of upgrades issues, disconnects/reconnects etc.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: Next ACS release?

2015-04-22 Thread Paul Angus

I fully support the idea of a stable master with an automated CD process to 
protect against regressions.

However, we obviously don't currently have fantastic integration testing 
otherwise we wouldn't have relied on 'people' to pick up the release blockers 
recently.  A 2 week release cycle IMHO is way too frequent to expect 'people' 
to be carrying out integration testing.

Maybe 1 month is a workable compromise until the integration testing is of a 
coverage and standard that can give real confidence.

I'm also going to compile a list of people who vote "+1 - it works on my 
laptop" and devise a Guinness related punishment for any of them that show up 
at the CloudStack day in Dublin.

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Remi Bergsma [mailto:r...@remi.nl]
Sent: 22 April 2015 10:25
To: dev@cloudstack.apache.org
Subject: Re: Next ACS release?

I'd be happy to help here as well. Last week in Austin, we also discussed this 
topic a couple of times. I do agree shorter release cycles are better.

In my opinion, the first thing to improve is the minor releases in both the
4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we 
will be able to do the next minor release with less effort and users can choose 
to either wait to start using 4.5 or start now and upgrade when the next minor 
release is available. This would have helped in getting 4.5 out on time and 
quickly fixing issues after the initial release. Also, it will save time which 
we can invest in getting the next release out on time, etc.

The common thing here is we need more automated testing, preferably functional 
testing in addition to unit testing. There might also be other steps that we do 
manually now that can be automated. I'll try to understand the current process 
first and then come up with a proposal to improve which we can discuss.

Regards,
Remi

2015-04-22 10:56 GMT+02:00 Erik Weber :

> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
> 
> wrote:
>
> > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
> wrote:
> > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
> > stephen.tur...@citrix.com>
> > > wrote:
> > >
> > >> I have to admit I'm a bit sceptical because when we did have a
> > four-month
> > >> release cycle, we never seemed to manage to meet it. Personally I
> think
> > >> six-monthly might be easier.
> > >>
> > >> Having said that, part of the problem was the long close-down
> > >> period
> > where
> > >> we kept finding critical bugs, so more automated testing might
> > >> help to shorten the cycle.
> > >>
> > >>
> > >
> > > - Shorter cycle means that it's less of a problem to miss a
> > > deadline, meaning you can spend more time on QA.
> > > - Longer cycle means that it could be critical to meet the
> > > deadline, meaning you might end up doing less QA while stressing
> > > to get your
> > feature
> > > in.
> > >
> > > My $.002
> >
> >
> Yes, Eric and the amount of qa needed is less as well. Bare with me
> > for a little rant here.
> >
> > When less new features are introduced less new interdependencies are
> > introduced. I could try and expand on this but people make phd on
> > the subject so that would be presumptuous of me.
> >
> > un-educated guess is (m + n)! - m!
> > where m is old features and n is new features
> >
> > example:
> > 1 old feature + 1 new feature mean 1 check to see if they (still)
> > work
> > 1 old feature + 2 new features means 3 checks to see if they all
> > work
> > 2 + 2 = 6 of which only 1 is old and should be fine
> > 2 + 3 = 10, see the n! progressing ;)
> >
> >
> > this is an over simplification as the complexity of features comes
> > in play as well. I make them out for being function points here.
> > those are fables of course.
> >
> > thanks for baring that.
> >
> >
> I'm all with you on this Daan.
> Just for the record, my notion of QA was meant at the feature
> developer, ie. that they could use more time on test coverage etc.
> without having to worry that much about feature freeze dates.
>
> --
> Erik
>
Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not th

Re: Next ACS release?

2015-04-22 Thread Nux!

+1 what Paul said.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Paul Angus" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 22 April, 2015 19:13:04
> Subject: RE: Next ACS release?

> I fully support the idea of a stable master with an automated CD process to
> protect against regressions.
> 
> However, we obviously don't currently have fantastic integration testing
> otherwise we wouldn't have relied on 'people' to pick up the release blockers
> recently.  A 2 week release cycle IMHO is way too frequent to expect 'people'
> to be carrying out integration testing.
> 
> Maybe 1 month is a workable compromise until the integration testing is of a
> coverage and standard that can give real confidence.
> 
> 
> 
> I'm also going to compile a list of people who vote "+1 - it works on my 
> laptop"
> and devise a Guinness related punishment for any of them that show up at the
> CloudStack day in Dublin.
> 
> Regards
> 
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> paul.an...@shapeblue.com
> 
> -Original Message-
> From: Remi Bergsma [mailto:r...@remi.nl]
> Sent: 22 April 2015 10:25
> To: dev@cloudstack.apache.org
> Subject: Re: Next ACS release?
> 
> I'd be happy to help here as well. Last week in Austin, we also discussed this
> topic a couple of times. I do agree shorter release cycles are better.
> 
> In my opinion, the first thing to improve is the minor releases in both the
> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we
> will be able to do the next minor release with less effort and users can 
> choose
> to either wait to start using 4.5 or start now and upgrade when the next minor
> release is available. This would have helped in getting 4.5 out on time and
> quickly fixing issues after the initial release. Also, it will save time which
> we can invest in getting the next release out on time, etc.
> 
> The common thing here is we need more automated testing, preferably functional
> testing in addition to unit testing. There might also be other steps that we 
> do
> manually now that can be automated. I'll try to understand the current process
> first and then come up with a proposal to improve which we can discuss.
> 
> Regards,
> Remi
> 
> 2015-04-22 10:56 GMT+02:00 Erik Weber :
> 
>> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
>> 
>> wrote:
>>
>> > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
>> wrote:
>> > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
>> > stephen.tur...@citrix.com>
>> > > wrote:
>> > >
>> > >> I have to admit I'm a bit sceptical because when we did have a
>> > four-month
>> > >> release cycle, we never seemed to manage to meet it. Personally I
>> think
>> > >> six-monthly might be easier.
>> > >>
>> > >> Having said that, part of the problem was the long close-down
>> > >> period
>> > where
>> > >> we kept finding critical bugs, so more automated testing might
>> > >> help to shorten the cycle.
>> > >>
>> > >>
>> > >
>> > > - Shorter cycle means that it's less of a problem to miss a
>> > > deadline, meaning you can spend more time on QA.
>> > > - Longer cycle means that it could be critical to meet the
>> > > deadline, meaning you might end up doing less QA while stressing
>> > > to get your
>> > feature
>> > > in.
>> > >
>> > > My $.002
>> >
>> >
>> Yes, Eric and the amount of qa needed is less as well. Bare with me
>> > for a little rant here.
>> >
>> > When less new features are introduced less new interdependencies are
>> > introduced. I could try and expand on this but people make phd on
>> > the subject so that would be presumptuous of me.
>> >
>> > un-educated guess is (m + n)! - m!
>> > where m is old features and n is new features
>> >
>> > example:
>> > 1 old feature + 1 new feature mean 1 check to see if they (still)
>> > work
>> > 1 old feature + 2 new features means 3 checks to see if they all
>> > work
>> > 2 + 2 = 6 of which only 1 is old and should be fine
>> > 2 + 3 = 10, see the n! progressing ;)
>> >
>> >
>> > this is an over simplification as the complexity of features comes
>> > in play as well. I make them out for being function points here.
>> > those are fables of course.
>> >
>> > thanks for baring that.
>> >
>> >
>> I'm all with you on this Daan.
>> Just for the record, my notion of QA was meant at the feature
>> developer, ie. that they could use more time on test coverage etc.
>> without having to worry that much about feature freeze dates.
>>
>> --
>> Erik
>>
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software
> Engineering
> CloudStack Infrastructure
> Support

Re: Next ACS release?

2015-04-22 Thread Remi Bergsma

Hi,

The '2 week cycle' was intended as something to work towards, like a
mission. The nice thing is that it immediately shows that we cannot achieve
such a thing if we keep our current method of (semi)manual testing, as you
said. Totally agree.

That's why we need to improve on our automated functional testing. And that
will of course take time and effort. As I don't currently have a clear
overview of what is already available, I'll try to get that first and work
from there. I spoke to several people recently and most seem to do testing
on their own way (with sometimes cool automatic stuff going on!). It'd be
interesting to bring that together and share.
I think improving this is important, so I'll try to spend as much time on
this as possible.

However, the tread started with comments on 4.5. Let's try to get it stable
and deliver 4.5.1. What is still to be done here? Can we share the load
somehow to fasten it?

Regards,
Remi

2015-04-22 20:13 GMT+02:00 Paul Angus :

> I fully support the idea of a stable master with an automated CD process
> to protect against regressions.
>
> However, we obviously don't currently have fantastic integration
> testing otherwise we wouldn't have relied on 'people' to pick up the
> release blockers recently.  A 2 week release cycle IMHO is way too frequent
> to expect 'people' to be carrying out integration testing.
>
> Maybe 1 month is a workable compromise until the integration testing is of
> a coverage and standard that can give real confidence.
>
>
>
> I'm also going to compile a list of people who vote "+1 - it works on my
> laptop" and devise a Guinness related punishment for any of them that show
> up at the CloudStack day in Dublin.
>
> Regards
>
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Remi Bergsma [mailto:r...@remi.nl]
> Sent: 22 April 2015 10:25
> To: dev@cloudstack.apache.org
> Subject: Re: Next ACS release?
>
> I'd be happy to help here as well. Last week in Austin, we also discussed
> this topic a couple of times. I do agree shorter release cycles are better.
>
> In my opinion, the first thing to improve is the minor releases in both the
> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks
> we will be able to do the next minor release with less effort and users can
> choose to either wait to start using 4.5 or start now and upgrade when the
> next minor release is available. This would have helped in getting 4.5 out
> on time and quickly fixing issues after the initial release. Also, it will
> save time which we can invest in getting the next release out on time, etc.
>
> The common thing here is we need more automated testing, preferably
> functional testing in addition to unit testing. There might also be other
> steps that we do manually now that can be automated. I'll try to understand
> the current process first and then come up with a proposal to improve which
> we can discuss.
>
> Regards,
> Remi
>
> 2015-04-22 10:56 GMT+02:00 Erik Weber :
>
> > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
> > 
> > wrote:
> >
> > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
> > wrote:
> > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
> > > stephen.tur...@citrix.com>
> > > > wrote:
> > > >
> > > >> I have to admit I'm a bit sceptical because when we did have a
> > > four-month
> > > >> release cycle, we never seemed to manage to meet it. Personally I
> > think
> > > >> six-monthly might be easier.
> > > >>
> > > >> Having said that, part of the problem was the long close-down
> > > >> period
> > > where
> > > >> we kept finding critical bugs, so more automated testing might
> > > >> help to shorten the cycle.
> > > >>
> > > >>
> > > >
> > > > - Shorter cycle means that it's less of a problem to miss a
> > > > deadline, meaning you can spend more time on QA.
> > > > - Longer cycle means that it could be critical to meet the
> > > > deadline, meaning you might end up doing less QA while stressing
> > > > to get your
> > > feature
> > > > in.
> > > >
> > > > My $.002
> > >
> > >
> > Yes, Eric and the amount of qa needed is less as well. Bare with me
> > > for a little rant here.
> > >
> > > When less new features are introduced less new interdependencies are
> > > introduced. I could try and expand on this but people make phd on
> > > the subject so that would be presumptuous of me.
> > >
> > > un-educated guess is (m + n)! - m!
> > > where m is old features and n is new features
> > >
> > > example:
> > > 1 old feature + 1 new feature mean 1 check to see if they (still)
> > > work
> > > 1 old feature + 2 new features means 3 checks to see if they all
> > > work
> > > 2 + 2 = 6 of which only 1 is old and should be fine
> > > 2 + 3 = 10, see the n! progressing ;)
> > >
> > >
> > > this is an over simplification as the complexity of features comes
> > > in play as well. I make them out for being function points here.
>

Re: [DISCUSS] Moving to Java 8

2015-04-22 Thread Laszlo Hornyak

Is java 1.8 on the roadmap for ubuntu 14?
It does not seem to make sense to have a LTS supported until 2019 with a
JDK no longer supported.


On Wed, Apr 22, 2015 at 2:43 PM, Wido den Hollander  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 04/22/2015 02:13 PM, Wilder Rodrigues wrote:
> > Hi Wido,
> >
> > Thanks for the reply and making a good point concerning Ubuntu
> > 14.04.
> >
> > Besides the difficulty in writing testes without increasing even
> > more out technical dept, another point on the Java 8 platform is
> > the EOL (end of this month) of Java 1.7.
> >
>
> Yes, I'm aware of that. So that makes this situation difficult.
>
> There is a bug open for backporting OpenJDK 8 to Ubuntu 14.04:
> https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1341628
>
> More votes there would really help.
>
> > For now I created a ticket on Apache Jira to keep track of it:
> > https://issues.apache.org/jira/browse/CLOUDSTACK-8397. Could you
> > please have a look and let me know if the content of the ticket is
> > appropriate?
> >
> > We will start a new sprint in 1 week and will take some time to
> > discuss what to do and when. Will keep the community updated on
> > that matter.
> >
> > Thanks a gain.
> >
> > Cheers, Wilder
> >
> >
> > On 21 Apr 2015, at 15:49, Wido den Hollander
> > mailto:w...@widodh.nl>> wrote:
> >
> >
> >
> > On 04/21/2015 03:27 PM, Wilder Rodrigues wrote: Hi all,
> >
> > Yesterday I started working on the LibvirtComputingResource class
> > in order to apply the same patterns I used in the
> > CitrixResourceBase + add more unit tests to it After 10 hours of
> > work I got a bit stuck with the 1st test, which would cover the
> > refactored LibvirtStopCommandWrapper. Why did I get stuck? The
> > class used a few static methods that call native libraries, which
> > I would like to mock. However, when writing the tests I faced
> > problems with the current Mockito/PowerMock we are using: they are
> > simply not enough for the task.
> >
> > What did I do then? I added a dependency to EasyMock and
> > PowerMock-EasyMock API. It worked almost fine, but I had to add a
> > “-noverify” to both my Eclipse Runtime configuration and also to
> > the cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not
> > nice, but was my first attempt of getting it to work. After trying
> > to first full build I faced more problems related to
> > ClassDefNotFoundExpcetion which were complaining about Mockito
> > classes. I then found out that adding the PowerMockRunner to all
> > the tests classes was going to be a heavy burden and would also
> > mess up future changes (e.g. the -noverify flag was removed from
> > Java 8, thus adding it now would be a problem soon).
> >
> > Now that the first 2 paragraphs explain a bit about the problem,
> > let’s get to the solution: Java 8
> >
> > The VerifyError that I was getting was due to the use of the
> > latest EasyMock  release (3.3.1). I tried to downgrade it to
> > 3.1/3.2 but it also did not work. My decision: do not refactor if
> > the proper tests cannot be added. This left me with one action:
> > migrate to Java 8.
> >
> > There were mentions about Java 8 in february[1] and now I will put
> > some energy in making it happen.
> >
> > What is your opinion on it?
> >
> >
> > I'm not against it technically, but practically I am.
> >
> > Ubuntu 14.04 does not ship a Java 8 JRE in the repositories.
> >
> > CentOS 7 has java-1.8.0-openjdk.x86_64 available, so it would work
> > there. But Ubuntu is also widely used with CloudStack, so those
> > users couldn't use CloudStack without any additional repositories.
> >
> > Since that isn't easy I would vote -1 on this if it came that far.
> >
> > Wido
> >
> > Thanks in advance.
> >
> > Cheers, Wilder
> >
> > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3
> >
> >
> c54eef6be.5040...@shapeblue.com%
> 3E > box/cloudstack-dev/201502.mbox/<54eef6be.5040...@shapeblue.com 54eef6be.5040...@shapeblue.com>>>
> >
> >
> >
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVN5dgAAoJEAGbWC3bPspCzX8P/0o8V8ZZPF+mOiXwfvZxOoqn
> Xtb084SajpLvB4KFT207FecJ6rKJyJiSXZSW6esj1F5OBzoDzF30vWHityvvatCA
> LsY5zCj2LF01itmjK8SVXuuwK8sSINycJPu2jJVotYr4ooPM1pHJjv/UnQfrUgp3
> yv8vT3VKhrPLkGOIIcRR8zmIPH6qtgTf/ILBsc9hUrkvYgfmReH1dkeQY4gid3TZ
> sHGrnYHby2SgW+9KbuEfdvOrHvItYbJpRWz6W3R6l+DQeZxMt/pMbZRXEM4LXkuL
> /t450iwybpMZzwwnPYqu0TjTjSI0AFZp9gq+obygEnbDsbCXMuUKRHNymCdUZH3r
> hldfP1dmAwPEjJ0Z9PgybvmitaAqvUg80BeS7iS/6SPulGx6hFiafrdCgjdQ7bxM
> qN4nGcFIwxmzphhljnLARxRxl2/50KuZTYmC3XmyfbrUYX+BiDW8FoMbCd5qJJyC
> r48w2gPQW52HyVckM532PFpMWah7If8Q0Ee9w0JrTEF3RRkMQ7NySUvK0Y9er8ay
> D6fmw5szuWWNF7bSC6wNx5bY7EyNGp7rDa1Ki4f4G7chh6m16yhYSQ0fLBjro6fw
> sFbs7EKAa9iCsyHbPQBpz3IoqkSbCknnHbXAInQOyybLKendwZ2f9LVA8K0GFlHH
> uMsBvF/FH1bnVg+oX8N3
> =oFqF
> -END PGP SIGNATURE-
>



-- 

EOF

Re: AW: Next ACS release?

2015-04-22 Thread ilya

We need a distributed QA framework, where folks with all kind of setups 
- fetch code continuously, build cloudstack, run tests, sanitize outputs 
and submit upstream.


Some folks on this list would want to remain anonymous, but this build, 
deploy, test and submit results process needs to be automated. Would be 
a great project for GSOC interns.



On 4/22/15 2:51 AM, S. Brüseke - proIO GmbH wrote:

In my opinion we need to improve QA! If smaller cycles will help to do that this is the 
way to go. I joined this list after the "release" of 4.5, but as far as I know 
4.5 is not really usable for production because of critical bugs in it that good QA would 
not have passed.
So if CS releases new version every 2 month with just a few new features, but 
these are working, it would be great. We also can do some bug fixing and 
code-cleaning too.

My $.002

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke


-Ursprüngliche Nachricht-
Von: Remi Bergsma [mailto:r...@remi.nl]
Gesendet: Mittwoch, 22. April 2015 11:25
An: dev@cloudstack.apache.org
Betreff: Re: Next ACS release?

I'd be happy to help here as well. Last week in Austin, we also discussed this 
topic a couple of times. I do agree shorter release cycles are better.

In my opinion, the first thing to improve is the minor releases in both the
4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we 
will be able to do the next minor release with less effort and users can choose 
to either wait to start using 4.5 or start now and upgrade when the next minor 
release is available. This would have helped in getting 4.5 out on time and 
quickly fixing issues after the initial release. Also, it will save time which 
we can invest in getting the next release out on time, etc.

The common thing here is we need more automated testing, preferably functional 
testing in addition to unit testing. There might also be other steps that we do 
manually now that can be automated. I'll try to understand the current process 
first and then come up with a proposal to improve which we can discuss.

Regards,
Remi

2015-04-22 10:56 GMT+02:00 Erik Weber :


On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland

wrote:


On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 

wrote:

On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <

stephen.tur...@citrix.com>

wrote:


I have to admit I'm a bit sceptical because when we did have a

four-month

release cycle, we never seemed to manage to meet it. Personally I

think

six-monthly might be easier.

Having said that, part of the problem was the long close-down
period

where

we kept finding critical bugs, so more automated testing might
help to shorten the cycle.



- Shorter cycle means that it's less of a problem to miss a
deadline, meaning you can spend more time on QA.
- Longer cycle means that it could be critical to meet the
deadline, meaning you might end up doing less QA while stressing
to get your

feature

in.

My $.002



Yes, Eric and the amount of qa needed is less as well. Bare with me

for a little rant here.

When less new features are introduced less new interdependencies are
introduced. I could try and expand on this but people make phd on
the subject so that would be presumptuous of me.

un-educated guess is (m + n)! - m!
where m is old features and n is new features

example:
1 old feature + 1 new feature mean 1 check to see if they (still)
work
1 old feature + 2 new features means 3 checks to see if they all
work
2 + 2 = 6 of which only 1 is old and should be fine
2 + 3 = 10, see the n! progressing ;)


this is an over simplification as the complexity of features comes
in play as well. I make them out for being function points here.
those are fables of course.

thanks for baring that.



I'm all with you on this Daan.
Just for the record, my notion of QA was meant at the feature
developer, ie. that they could use more time on test coverage etc.
without having to worry that much about feature freeze dates.

--
Erik




- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) 
please notify
the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.

Re: Next ACS release?

2015-04-22 Thread Marcus

We just have to do it.  We just freeze master at some point, do all of
the release bugfixes, and when it is solid enough to pass a release
vote we branch a release from it, and then only allow merges to master
that have been tested in a merge branch, or something along those
lines. Things will slip through, because our testing isn't full
coverage, but we can begin to add to it.

I've said it before, but I think we're also a bit stingy regarding
bugfix releases. Unless we cause a regression, there should be no need
for bugfix releases to go through multiple RCs. We get caught on bugs
that are already in the shipping version and make them blockers for
the other bug fixes, or a pet patch needs to slip in (which also only
matters because bugfix releases are so few and hard to release).

On Wed, Apr 22, 2015 at 12:32 PM, Remi Bergsma  wrote:
> Hi,
>
> The '2 week cycle' was intended as something to work towards, like a
> mission. The nice thing is that it immediately shows that we cannot achieve
> such a thing if we keep our current method of (semi)manual testing, as you
> said. Totally agree.
>
> That's why we need to improve on our automated functional testing. And that
> will of course take time and effort. As I don't currently have a clear
> overview of what is already available, I'll try to get that first and work
> from there. I spoke to several people recently and most seem to do testing
> on their own way (with sometimes cool automatic stuff going on!). It'd be
> interesting to bring that together and share.
> I think improving this is important, so I'll try to spend as much time on
> this as possible.
>
> However, the tread started with comments on 4.5. Let's try to get it stable
> and deliver 4.5.1. What is still to be done here? Can we share the load
> somehow to fasten it?
>
> Regards,
> Remi
>
> 2015-04-22 20:13 GMT+02:00 Paul Angus :
>
>> I fully support the idea of a stable master with an automated CD process
>> to protect against regressions.
>>
>> However, we obviously don't currently have fantastic integration
>> testing otherwise we wouldn't have relied on 'people' to pick up the
>> release blockers recently.  A 2 week release cycle IMHO is way too frequent
>> to expect 'people' to be carrying out integration testing.
>>
>> Maybe 1 month is a workable compromise until the integration testing is of
>> a coverage and standard that can give real confidence.
>>
>>
>>
>> I'm also going to compile a list of people who vote "+1 - it works on my
>> laptop" and devise a Guinness related punishment for any of them that show
>> up at the CloudStack day in Dublin.
>>
>> Regards
>>
>> Paul Angus
>> Cloud Architect
>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>> paul.an...@shapeblue.com
>>
>> -Original Message-
>> From: Remi Bergsma [mailto:r...@remi.nl]
>> Sent: 22 April 2015 10:25
>> To: dev@cloudstack.apache.org
>> Subject: Re: Next ACS release?
>>
>> I'd be happy to help here as well. Last week in Austin, we also discussed
>> this topic a couple of times. I do agree shorter release cycles are better.
>>
>> In my opinion, the first thing to improve is the minor releases in both the
>> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks
>> we will be able to do the next minor release with less effort and users can
>> choose to either wait to start using 4.5 or start now and upgrade when the
>> next minor release is available. This would have helped in getting 4.5 out
>> on time and quickly fixing issues after the initial release. Also, it will
>> save time which we can invest in getting the next release out on time, etc.
>>
>> The common thing here is we need more automated testing, preferably
>> functional testing in addition to unit testing. There might also be other
>> steps that we do manually now that can be automated. I'll try to understand
>> the current process first and then come up with a proposal to improve which
>> we can discuss.
>>
>> Regards,
>> Remi
>>
>> 2015-04-22 10:56 GMT+02:00 Erik Weber :
>>
>> > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland
>> > 
>> > wrote:
>> >
>> > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber 
>> > wrote:
>> > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner <
>> > > stephen.tur...@citrix.com>
>> > > > wrote:
>> > > >
>> > > >> I have to admit I'm a bit sceptical because when we did have a
>> > > four-month
>> > > >> release cycle, we never seemed to manage to meet it. Personally I
>> > think
>> > > >> six-monthly might be easier.
>> > > >>
>> > > >> Having said that, part of the problem was the long close-down
>> > > >> period
>> > > where
>> > > >> we kept finding critical bugs, so more automated testing might
>> > > >> help to shorten the cycle.
>> > > >>
>> > > >>
>> > > >
>> > > > - Shorter cycle means that it's less of a problem to miss a
>> > > > deadline, meaning you can spend more time on QA.
>> > > > - Longer cycle means that it could be critical to meet the
>> > > > deadline, meaning you might en

Re: [DISCUSS] Moving to Java 8

2015-04-22 Thread Marcus

I agree with Wido. The first thing that came to mind is legacy
installs of CentOS that have java6,7 but not java8. I'd prefer to wait
until we can reasonably say that Ubuntu 12.04 and CentOS6.x are
artifacts of the past that people should not be running (maybe 6-12mo
past LTS, or something). Unless there's a real necessity to switch,
I'd say we don't.

I think the distributions which have shipped these versions, if they
don't provide a newer version in a point release will contribute to
support/patch the version of openjdk they do ship in their LTS.

On Wed, Apr 22, 2015 at 1:44 PM, Laszlo Hornyak
 wrote:
> Is java 1.8 on the roadmap for ubuntu 14?
> It does not seem to make sense to have a LTS supported until 2019 with a
> JDK no longer supported.
>
>
> On Wed, Apr 22, 2015 at 2:43 PM, Wido den Hollander  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> On 04/22/2015 02:13 PM, Wilder Rodrigues wrote:
>> > Hi Wido,
>> >
>> > Thanks for the reply and making a good point concerning Ubuntu
>> > 14.04.
>> >
>> > Besides the difficulty in writing testes without increasing even
>> > more out technical dept, another point on the Java 8 platform is
>> > the EOL (end of this month) of Java 1.7.
>> >
>>
>> Yes, I'm aware of that. So that makes this situation difficult.
>>
>> There is a bug open for backporting OpenJDK 8 to Ubuntu 14.04:
>> https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1341628
>>
>> More votes there would really help.
>>
>> > For now I created a ticket on Apache Jira to keep track of it:
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-8397. Could you
>> > please have a look and let me know if the content of the ticket is
>> > appropriate?
>> >
>> > We will start a new sprint in 1 week and will take some time to
>> > discuss what to do and when. Will keep the community updated on
>> > that matter.
>> >
>> > Thanks a gain.
>> >
>> > Cheers, Wilder
>> >
>> >
>> > On 21 Apr 2015, at 15:49, Wido den Hollander
>> > mailto:w...@widodh.nl>> wrote:
>> >
>> >
>> >
>> > On 04/21/2015 03:27 PM, Wilder Rodrigues wrote: Hi all,
>> >
>> > Yesterday I started working on the LibvirtComputingResource class
>> > in order to apply the same patterns I used in the
>> > CitrixResourceBase + add more unit tests to it After 10 hours of
>> > work I got a bit stuck with the 1st test, which would cover the
>> > refactored LibvirtStopCommandWrapper. Why did I get stuck? The
>> > class used a few static methods that call native libraries, which
>> > I would like to mock. However, when writing the tests I faced
>> > problems with the current Mockito/PowerMock we are using: they are
>> > simply not enough for the task.
>> >
>> > What did I do then? I added a dependency to EasyMock and
>> > PowerMock-EasyMock API. It worked almost fine, but I had to add a
>> > “-noverify” to both my Eclipse Runtime configuration and also to
>> > the cloud-plugin-hypervisor-kvm/pom.xml file. I agree that’s not
>> > nice, but was my first attempt of getting it to work. After trying
>> > to first full build I faced more problems related to
>> > ClassDefNotFoundExpcetion which were complaining about Mockito
>> > classes. I then found out that adding the PowerMockRunner to all
>> > the tests classes was going to be a heavy burden and would also
>> > mess up future changes (e.g. the -noverify flag was removed from
>> > Java 8, thus adding it now would be a problem soon).
>> >
>> > Now that the first 2 paragraphs explain a bit about the problem,
>> > let’s get to the solution: Java 8
>> >
>> > The VerifyError that I was getting was due to the use of the
>> > latest EasyMock  release (3.3.1). I tried to downgrade it to
>> > 3.1/3.2 but it also did not work. My decision: do not refactor if
>> > the proper tests cannot be added. This left me with one action:
>> > migrate to Java 8.
>> >
>> > There were mentions about Java 8 in february[1] and now I will put
>> > some energy in making it happen.
>> >
>> > What is your opinion on it?
>> >
>> >
>> > I'm not against it technically, but practically I am.
>> >
>> > Ubuntu 14.04 does not ship a Java 8 JRE in the repositories.
>> >
>> > CentOS 7 has java-1.8.0-openjdk.x86_64 available, so it would work
>> > there. But Ubuntu is also widely used with CloudStack, so those
>> > users couldn't use CloudStack without any additional repositories.
>> >
>> > Since that isn't easy I would vote -1 on this if it came that far.
>> >
>> > Wido
>> >
>> > Thanks in advance.
>> >
>> > Cheers, Wilder
>> >
>> > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3
>> >
>> >
>> c54eef6be.5040...@shapeblue.com%
>> 3E> > box/cloudstack-dev/201502.mbox/<54eef6be.5040...@shapeblue.com> 54eef6be.5040...@shapeblue.com>>>
>> >
>> >
>> >
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJVN5dgAAoJEAGbWC3bPspCzX8P/0o8V8ZZPF+mOiXwfvZxOoqn
>> Xtb084SajpLvB4KFT207FecJ6rKJyJiSXZSW6esj

Re: [DISCUSS] Moving to Java 8

2015-04-22 Thread Marcus

Kind of a tangent, but I'd actually like to see some work done to
clean up LibvirtComputing resource. One model I've prototyped that
seems to work is to create an annotation, such as
'KVMCommandExecutor', with a 'handles' property. With this annotation,
you implement a class that handles, e.g. StartCommand, etc. Then in
LibvirtComputingResource, the 'configure' method fetches all of these
executors via reflection and stores them in an object. Then, instead
of having all of the 'instanceof' lines in LibvirtComputingResource,
the executeRequest method fetches the executor that handles the
incoming command and runs it.

I think this would break up LibvirtComputingResource into smaller,
more testable and manageable chunks, and force things like config and
utility methods to move to a more sane location, as well. As a bonus,
this model makes things pluggable. Someone could ship KVM plugin code
containing standalone command executors that are discovered at runtime
for things they need to run at the hypervisor level.

On Tue, Apr 21, 2015 at 6:27 AM, Wilder Rodrigues
 wrote:
> Hi all,
>
> Yesterday I started working on the LibvirtComputingResource class in order to 
> apply the same patterns I used in the CitrixResourceBase + add more unit 
> tests to it After 10 hours of work I got a bit stuck with the 1st test, which 
> would cover the refactored LibvirtStopCommandWrapper. Why did I get stuck? 
> The class used a few static methods that call native libraries, which I would 
> like to mock. However, when writing the tests I faced problems with the 
> current Mockito/PowerMock we are using: they are simply not enough for the 
> task.
>
> What did I do then? I added a dependency to EasyMock and PowerMock-EasyMock 
> API. It worked almost fine, but I had to add a “-noverify” to both my Eclipse 
> Runtime configuration and also to the cloud-plugin-hypervisor-kvm/pom.xml 
> file. I agree that’s not nice, but was my first attempt of getting it to 
> work. After trying to first full build I faced more problems related to 
> ClassDefNotFoundExpcetion which were complaining about Mockito classes. I 
> then found out that adding the PowerMockRunner to all the tests classes was 
> going to be a heavy burden and would also mess up future changes (e.g. the 
> -noverify flag was removed from Java 8, thus adding it now would be a problem 
> soon).
>
> Now that the first 2 paragraphs explain a bit about the problem, let’s get to 
> the solution: Java 8
>
> The VerifyError that I was getting was due to the use of the latest EasyMock  
> release (3.3.1). I tried to downgrade it to 3.1/3.2 but it also did not work. 
> My decision: do not refactor if the proper tests cannot be added. This left 
> me with one action: migrate to Java 8.
>
> There were mentions about Java 8 in february[1] and now I will put some 
> energy in making it happen.
>
> What is your opinion on it?
>
> Thanks in advance.
>
> Cheers,
> Wilder
>
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201502.mbox/%3c54eef6be.5040...@shapeblue.com%3E>

Re: Next ACS release?

2015-04-22 Thread David Nalley

On Wed, Apr 22, 2015 at 4:47 PM, Marcus  wrote:
> We just have to do it.  We just freeze master at some point, do all of
> the release bugfixes, and when it is solid enough to pass a release
> vote we branch a release from it, and then only allow merges to master
> that have been tested in a merge branch, or something along those
> lines. Things will slip through, because our testing isn't full
> coverage, but we can begin to add to it.
>
> I've said it before, but I think we're also a bit stingy regarding
> bugfix releases. Unless we cause a regression, there should be no need
> for bugfix releases to go through multiple RCs. We get caught on bugs
> that are already in the shipping version and make them blockers for
> the other bug fixes, or a pet patch needs to slip in (which also only
> matters because bugfix releases are so few and hard to release).
>

It's not just new features that cause problems though.
We've had bug fixes that cause issues, sometimes worse than the one
they solved. Every change is a threat to stability, so we'd like to
have smaller bug fix releases too. There's an inherent cost in doing
releases in their current form.

--David

Re: CentOS 7 KVM Agent installation fails

2015-04-22 Thread Rajani Karuturi

The changes came in from the commit
555c4329462ac632890c7cde3bac8db8b6e8a682 and were reverted by
16806b19a04f8a8df1b8d106e9757395e47ee710

The revert only reverted in management package and not in agent or usage
package.

~Rajani

On Wed, Apr 22, 2015 at 1:41 AM, Remi Bergsma  wrote:

> Hi Wido,
>
> Take them from here:
> http://jenkins.buildacloud.org/view/4.4/job/package-centos7-4.4-noredist/
>  >
>
> or here:
> http://cloudstack.apt-get.eu/centos/4.4/7/ <
> http://cloudstack.apt-get.eu/centos/4.4/7/>
>
> Worked for me.
>
> Regards,
> Remi
>
>
> > On 21 Apr 2015, at 20:10 , Remi Bergsma  wrote:
> >
> > Hi,
> >
> > The RPM’s I use were baked from the 4.4 branch (4.4.3-SNAPSHOT) a few
> weeks back. Hence, the now released 4.4.3 should also work. Marcus is
> right, the dependency is now on ‘java >= 1.7.0’.
> >
> > CentOS 7 support was needed in our setup and Daan helped me backport the
> needed changes from to 4.4. This allowed me to test in a production-like
> environment and fix whatever did not work properly. These patches are
> included in 4.4.3. Even though it runs fine now, we will probably find some
> new issues over time so I can understand the ’tech preview’ status.
> >
> > If you need more info or help, drop me a line.
> >
> > Regards,
> > Remi
> >
> >
> >> On 21 Apr 2015, at 18:38 , Marcus  wrote:
> >>
> >> This requires has actually bitten us in the past. It needs to change
> >> to 'java-1.7.0', because 'java7' isn't satisfied by anything in EL7,
> >> and 'java >= 1.7.0' actually is satisfied by java 1.6 due to epoch
> >> issues.
> >>
> >> That said, EL7 support was considered 'tech preview' even with 4.5,
> >> I'm not sure what the status of it is in 4.4.
> >>
> >> Also, in 4.5 we use packaging/centos63/package.sh -o rhel7. I haven't
> >> researched why/when this was added here or if it is applicable to 4.4,
> >> but it works.
> >>
> >> On Tue, Apr 21, 2015 at 9:17 AM, Remi Bergsma  wrote:
> >>> There are some fixes in 4.4.3 for kvm on CentOS7 so that's a good idea.
> >>>
> >>> Regards, Remi
> >>>
> >>> Sent from my iPhone
> >>>
>  On 21 Apr 2015, at 18:09, Rohit Yadav 
> wrote:
> 
>  Hi Wido,
> 
>  You can try the latest 4.4.3 release from this EL6 repo:
> http://packages.shapeblue.com/cloudstack/upstream/centos/4.4
> 
> > On 21-Apr-2015, at 4:25 pm, Wido den Hollander 
> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >> On 04/21/2015 04:10 PM, Remi Bergsma wrote:
> >> Hi Wido,
> >>
> >> We run kvm on centos7 without problems. When I'm back in the office
> >> I will check which package we used. It seems el6 is for centos6?
> >
> > Thanks! Aha, let me check if the packages coming from Jenkins do
> work.
> >
> > Wido
> >
> >> Will let you know!
> >>
> >> Remi
> >>
> >> Sent from my iPhone
> >>
> >>> On 21 Apr 2015, at 16:00, Wido den Hollander 
> >>> wrote:
> >> Hi,
> >>
> >> I'm trying to install cloudstack-agent on CentOS but it fails
> >> with:
> >>
> >> --> Finished Dependency Resolution Error: Package:
> >> cloudstack-agent-4.4.2-NONOSS_1.el6.x86_64 (cloudstack-repo)
> >> Requires: java7 Error: Package:
> >> cloudstack-common-4.4.2-NONOSS_1.el6.x86_64 (cloudstack-repo)
> >> Requires: python(abi) = 2.6 Installed: python-2.7.5-16.el7.x86_64
> >> (@anaconda) python(abi) = 2.7 python(abi) = 2.7 You could try using
> >> --skip-broken to work around the problem You could try running: rpm
> >> -Va --nofiles --nodigest
> >>
> >>
> >> Looking at packaging/centos7/cloud.spec I found this:
> >>
> >> %package agent Summary: CloudStack Agent for KVM hypervisors .
> >> Requires: java => 1.7.0 .
> >>
> >> So where does "java7" come from?
> >>
> >> I used these packages btw: http://cloudstack.apt-get.eu/rhel/4.4/
> >>
> >> Any clues on why this is happening?
> >>
> >> Wido
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJVNl3kAAoJEAGbWC3bPspCbSUQAI1E/Rk7nByBiaXM0oTMPwWK
> > zefmTQ2R5at6RBqR1zM8HSR8pNiyUn53uua0/FIhKy9HmoRhNjw5BDIDzpz4RcgY
> > HNUSRyaAI+YqI5g4FcDalsc+Vqelcv9zEzvksG5VkspESrdhJTEX73FLWiBUr7oM
> > FemnBO8smX7Pc2awZRS/XBjoGq8GISmUO3mIHmT2UFyjhynlRGehhOhQGyLWjN9a
> > gxLs7vtkKFdBuinsWny9NsX6D4RSnMoWAZ0h4fdDYINbzh24ZBBNiRhCPGaya0We
> > 0YY8/WBy8CIQ5IH42/DoPbRdlZL/5744MdTaVU/ZkkQ6J4T9T6UFECk19YptwVgF
> > Aq9E3nsuxwDeW+8TksHscy/0/Z8HKQGSa9YqqSneAYQGKNdjXylroc7/JcH7mSpo
> > /RvS60l2k4NQ9mJrp8ta8rrwzahqiBLUKBQEs9KA0OqR67uV+p6SSXaVWEqx+819
> > bjFqZR1rm2GBoS6xFITZpq1G9eB3RNe7ak7Nzdv5LfgQ4RMbtHvQ+DaSL8bAnyQo
> > EMDbe4J7IQGLIQtfmeUnZsz2Lmz02XdYtzIFBc9CKP3EGYJSKDVqAQH4dGwPBkBY
> > 9c56ggRXgLBtKcDQijZNM/h6geP6C2fAP/HdLjx0qfydR5ktML66dW6IFN3aAgwW
> > lFlQurU8D0Ug0uW/T/0k
> > =ogdp
>

Jenkins build is still unstable: simulator-singlerun #1137

2015-04-22 Thread jenkins

See

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/181#discussion_r28939755
  
--- Diff: 
test/integration/testpaths/testpath_volume_cuncurrent_snapshots.py ---
@@ -0,0 +1,827 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for VM/Volume snapshot Test Path
--- End diff --

Add detailed comment for what feature testpath is testing


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/181#discussion_r28939823
  
--- Diff: 
test/integration/testpaths/testpath_volume_cuncurrent_snapshots.py ---
@@ -0,0 +1,827 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for VM/Volume snapshot Test Path
+"""
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase, unittest
+from marvin.lib.utils import (cleanup_resources, is_snapshot_on_nfs,
+  validateList)
+from marvin.lib.base import (Account,
+ StoragePool,
+ Host,
+ ServiceOffering,
+ VirtualMachine,
+ Configurations,
+ Snapshot,
+ SnapshotPolicy,
+ )
+from marvin.lib.common import (get_domain,
+   list_snapshot_policy,
+   get_zone,
+   get_template,
+   list_volumes,
+   list_snapshots,
+   list_virtual_machines,
+   createChecksum,
+   )
+from marvin.sshClient import SshClient
+import time
+
+from threading import Thread
+from marvin.codes import PASS
+
+
+def MigrateRootVolume(self,
+  vm,
+  destinationHost,
+  expectexception=False):
+""" Migrate given volume to type of storage pool mentioned in 
migrateto:
+
+Inputs:
+1. vm:   VM to be migrated
+ is to be migrated
+2. expectexception:  If exception is expected while migration
+3. destinationHost:  Destination host where the VM should get 
migrated
+"""
+
+if expectexception:
+with self.assertRaises(Exception):
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+else:
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+
+migrated_vm_response = list_virtual_machines(
+self.apiclient,
+id=vm.id
+)
+
+self.assertEqual(
+isinstance(migrated_vm_response, list),
+True,
+"Check list virtual machines response for valid list"
+)
+
+self.assertNotEqual(
+migrated_vm_response,
+None,
+"Check if virtual machine exists in ListVirtualMachines"
+)
+
+migrated_vm = migrated_vm_response[0]
+
+vm_list = VirtualMachine.list(
+self.apiclient,
+id=migrated_vm.id
+)
+
+self.assertEqual(
+vm_list[0].hostid,
+destinationHost.id,
+"Check volume is on migrated pool"
+)
+return
+
+
+def CreateSnapshot(self, root_volume, is_recurring):
+"""Create Snapshot"""
+if is_recurring:
+recurring_snapshot = SnapshotPolicy.create(
+self.apiclient,
+root_volume.id,
+self.testdata["recurring_snapshot"]
+)
+self.rec_policy_pool.append(recurring_snapshot)
+else:
+root_vol_snap = Snapshot.create(
+self.apiclient,
+root_volume.id)
+
+self.snapshot_pool.append(root_vol_snap)
+
+
+class TestConcurrentSnapshots(cloudstackTestCase):
+
+@classmethod
+

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/181#discussion_r28940101
  
--- Diff: 
test/integration/testpaths/testpath_volume_cuncurrent_snapshots.py ---
@@ -0,0 +1,827 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for VM/Volume snapshot Test Path
+"""
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase, unittest
+from marvin.lib.utils import (cleanup_resources, is_snapshot_on_nfs,
+  validateList)
+from marvin.lib.base import (Account,
+ StoragePool,
+ Host,
+ ServiceOffering,
+ VirtualMachine,
+ Configurations,
+ Snapshot,
+ SnapshotPolicy,
+ )
+from marvin.lib.common import (get_domain,
+   list_snapshot_policy,
+   get_zone,
+   get_template,
+   list_volumes,
+   list_snapshots,
+   list_virtual_machines,
+   createChecksum,
+   )
+from marvin.sshClient import SshClient
+import time
+
+from threading import Thread
+from marvin.codes import PASS
+
+
+def MigrateRootVolume(self,
+  vm,
+  destinationHost,
+  expectexception=False):
+""" Migrate given volume to type of storage pool mentioned in 
migrateto:
+
+Inputs:
+1. vm:   VM to be migrated
+ is to be migrated
+2. expectexception:  If exception is expected while migration
+3. destinationHost:  Destination host where the VM should get 
migrated
+"""
+
+if expectexception:
+with self.assertRaises(Exception):
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+else:
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+
+migrated_vm_response = list_virtual_machines(
+self.apiclient,
+id=vm.id
+)
+
+self.assertEqual(
+isinstance(migrated_vm_response, list),
+True,
+"Check list virtual machines response for valid list"
+)
+
+self.assertNotEqual(
+migrated_vm_response,
+None,
+"Check if virtual machine exists in ListVirtualMachines"
+)
+
+migrated_vm = migrated_vm_response[0]
+
+vm_list = VirtualMachine.list(
+self.apiclient,
+id=migrated_vm.id
+)
+
+self.assertEqual(
+vm_list[0].hostid,
+destinationHost.id,
+"Check volume is on migrated pool"
+)
+return
+
+
+def CreateSnapshot(self, root_volume, is_recurring):
+"""Create Snapshot"""
+if is_recurring:
+recurring_snapshot = SnapshotPolicy.create(
+self.apiclient,
+root_volume.id,
+self.testdata["recurring_snapshot"]
+)
+self.rec_policy_pool.append(recurring_snapshot)
+else:
+root_vol_snap = Snapshot.create(
+self.apiclient,
+root_volume.id)
+
+self.snapshot_pool.append(root_vol_snap)
+
+
+class TestConcurrentSnapshots(cloudstackTestCase):
+
+@classmethod
+

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...

Github user gauravaradhye commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/181#discussion_r28940210
  
--- Diff: 
test/integration/testpaths/testpath_volume_cuncurrent_snapshots.py ---
@@ -0,0 +1,827 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+""" Test cases for VM/Volume snapshot Test Path
+"""
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase, unittest
+from marvin.lib.utils import (cleanup_resources, is_snapshot_on_nfs,
+  validateList)
+from marvin.lib.base import (Account,
+ StoragePool,
+ Host,
+ ServiceOffering,
+ VirtualMachine,
+ Configurations,
+ Snapshot,
+ SnapshotPolicy,
+ )
+from marvin.lib.common import (get_domain,
+   list_snapshot_policy,
+   get_zone,
+   get_template,
+   list_volumes,
+   list_snapshots,
+   list_virtual_machines,
+   createChecksum,
+   )
+from marvin.sshClient import SshClient
+import time
+
+from threading import Thread
+from marvin.codes import PASS
+
+
+def MigrateRootVolume(self,
+  vm,
+  destinationHost,
+  expectexception=False):
+""" Migrate given volume to type of storage pool mentioned in 
migrateto:
+
+Inputs:
+1. vm:   VM to be migrated
+ is to be migrated
+2. expectexception:  If exception is expected while migration
+3. destinationHost:  Destination host where the VM should get 
migrated
+"""
+
+if expectexception:
+with self.assertRaises(Exception):
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+else:
+VirtualMachine.migrate(
+vm,
+self.apiclient,
+hostid=destinationHost.id,
+)
+
+migrated_vm_response = list_virtual_machines(
+self.apiclient,
+id=vm.id
+)
+
+self.assertEqual(
+isinstance(migrated_vm_response, list),
+True,
+"Check list virtual machines response for valid list"
+)
+
+self.assertNotEqual(
+migrated_vm_response,
+None,
+"Check if virtual machine exists in ListVirtualMachines"
+)
+
+migrated_vm = migrated_vm_response[0]
+
+vm_list = VirtualMachine.list(
+self.apiclient,
+id=migrated_vm.id
+)
+
+self.assertEqual(
+vm_list[0].hostid,
+destinationHost.id,
+"Check volume is on migrated pool"
+)
+return
+
+
+def CreateSnapshot(self, root_volume, is_recurring):
+"""Create Snapshot"""
+if is_recurring:
+recurring_snapshot = SnapshotPolicy.create(
+self.apiclient,
+root_volume.id,
+self.testdata["recurring_snapshot"]
+)
+self.rec_policy_pool.append(recurring_snapshot)
+else:
+root_vol_snap = Snapshot.create(
+self.apiclient,
+root_volume.id)
+
+self.snapshot_pool.append(root_vol_snap)
+
+
+class TestConcurrentSnapshots(cloudstackTestCase):
+
+@classmethod
+

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...