Re: failing unit tests....

[Laszlo Hornyak]

That sounds like a good plan to me.


On Sun, Oct 27, 2013 at 12:45 AM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:

> There is also a lot of static initialization.  I don't know exactly
> what was the issue that broke the build, but I assume its because
> Transaction(Legacy) got loaded, and that class in a static block loads
> db.properties, which then call some encryption utilities that will
> fail if db.properties is not there.  I'd rather remove the static
> initializer (or atleast make it not blow up if its not there).  The
> tricky part is that there are so many "main class" utilities that
> depend on Transaction class.  I really want to standardize all
> utilities that they initialize in the same way so we can clean this
> stuff up, but that just takes time.
>
> Darren
>
> On Sat, Oct 26, 2013 at 11:17 AM, Laszlo Hornyak
>  wrote:
> > Hi Alex,
> >
> > The build was failing again today so I have sent another quick fix with
> > commit id
> > 7902315287c268ff81e3b6664df6ddee7351716a looks like the build is back to
> > normal. The prevous fix was reverted as after Darren's latest changes the
> > jdbc driver was no longer needed for tests in that project.
> >
> > The tests are a bit fragile and in my opinion the reason is that the
> > components are building a bit too much on the environment they are
> running
> > in. So writing good tests is a bit difficult in some cases, in some other
> > cases almost impossible.
> >
> >
> >
> >
> > On Sat, Oct 26, 2013 at 12:57 AM, Alex Huang 
> wrote:
> >
> >> Hi Laszlo,
> >>
> >> Thanks for the fix.  It does fix this problem.  I took a quick look.
> >>
> >> As I understand it from Alena, Darren had to move the initialization of
> >> the LockMasterListener higher due to some problems Mike experienced.  My
> >> guess is that it had to be higher because Spring cannot work with the
> >> ordered initialization that we used to have for the components (new,
> >> configure, start) so it was moved into static which relies on jvm
> >> initialization order.  So moving the initialization of
> LockMasterListener
> >> back into start() method of ManagementServer basically will break things
> >> for Mike again.  I'll leave it to Darren to resolve this for now.  I
> don't
> >> know enough about Spring loading to resolve this correctly for both
> cases.
> >>
> >> --Alex
> >>
> >> > -Original Message-
> >> > From: Laszlo Hornyak [mailto:laszlo.horn...@gmail.com]
> >> > Sent: Friday, October 25, 2013 3:19 PM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: Re: failing unit tests
> >> >
> >> > I have just sent a fix for that, looks like everything is green now.
> >> Please check!
> >> >
> >> >
> >> > On Fri, Oct 25, 2013 at 11:52 PM, Darren Shepherd <
> >> > darren.s.sheph...@gmail.com> wrote:
> >> >
> >> > > I'll fix that.
> >> > >
> >> > > Darren
> >> > >
> >> > > On Fri, Oct 25, 2013 at 1:54 PM, Alex Huang 
> >> > wrote:
> >> > > > I'm getting this failing unit test when building with the latest
> >> > > > from
> >> > > master.  Anyone working on it or know what it is already?  From the
> >> > > stack, it looks like it's a problem location the jdbc driver.  This
> >> > > was working just yesterday.
> >> > > >
> >> > > > Test set: com.cloud.alert.AlertControlsUnitTest
> >> > > >
> >> > >
> --
> >> > > -
> >> > > > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> >> > > > 0.175
> >> > > sec <<< FAILURE!
> >> > > > warning(junit.framework.TestSuite$1)  Time elapsed: 0.004 sec  <<<
> >> > > FAILURE!
> >> > > > junit.framework.AssertionFailedError: Exception in constructor:
> >> > > testInjected (java.lang.ExceptionInInitializerError
> >> > > > at
> >> > >
> com.cloud.alert.AlertControlsUnitTest.(AlertControlsUnitTest.jav
> >> > > a:46)
> >> > > > at
> >> > > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >> > > Method)
> >> > > > at
> >> > >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo
> >> > > rAccessorImpl.java:57)
> >> > > > at
> >> > >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo
> >> > > nstructorAccessorImpl.java:45)
> >> > > > at
> >> > > java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> >> > > > at junit.framework.TestSuite.createTest(TestSuite.java:61)
> >> > > > at
> >> junit.framework.TestSuite.addTestMethod(TestSuite.java:294)
> >> > > > at
> >> > > junit.framework.TestSuite.addTestsFromTestCase(TestSuite.java:150)
> >> > > > at junit.framework.TestSuite.(TestSuite.java:129)
> >> > > > at
> >> > >
> org.junit.internal.runners.JUnit38ClassRunner.(JUnit38ClassRunne
> >> > > r.java:71)
> >> > > > at
> >> > >
> org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder
> >> > > .java:14)
> >> > > > at
> >> > >
> org.junit.runners.model.RunnerBuilder.safeRunnerForClas

Intermittent File Access to cloudstack.apt-get.eu

[Marty Sweet]

Hi Guys,

During the upgrade process I also kept experiencing the packages needed
disappearing from the cloudstack.apt-get.eu website, this caused multiple
servers to fail on update/install processes only to work several minutes
later once the files had been restored. It's clear the files are changing
regularly on there as their dates are being constantly updated.

I can reproduce this on our production nodes and from a web browser using a
different ISP, this will definitely cause issues with new people to CS and
could be a confusing first hurdle for some.

http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.2/

Has anyone else experienced these issues? Just refresh the directory a few
times today and see when files appear/disappear.

Thanks,
Marty

RN-KnownIssuesIn4.2

[Marty Sweet]

Hi Guys,

Following the issues I have had upgrading to 4.2.0, I have noticed that the
known issues filter in Jira is set to used fixedVersion as opposed to
affectedVersion. This changes the results dramatically, if I was able to
see any of the issues I was having using this filter I believe the upgrade
would of gone a lot smoother. This is linked from the Known Issues part of
4.2.0 documentation.

https://issues.apache.org/jira/browse/CLOUDSTACK-4902?filter=12324873

It's currently:
project = CLOUDSTACK AND type = Bug AND fixVersion = "4.2.0" AND resolution
is EMPTY AND level = "Public" ORDER BY priority DESC, key ASC

I think it should be:
project = CLOUDSTACK AND type = Bug AND affectedVersion = "4.2.0" AND
resolution is EMPTY AND level = "Public" ORDER BY priority DESC, key ASC

Thanks,
Marty

Re: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)

[Marty Sweet]

Thanks Kelcey, that worked a treat!

Do you know of any plans to update the official documentation?

Marty


On Sun, Oct 27, 2013 at 1:16 AM, kel...@backbonetechnology.com <
kel...@backbonetechnology.com> wrote:

> Hi,
>
> Try this, it was written for your situation!
>
>
> http://cloud.kelceydamage.com/cloudfire/blog/2013/10/08/conquering-the-cloudstack-4-2-dragon-kvm/
>
> -Kelcey
>
> Sent from my HTC
>
> - Reply message -
> From: "Marcus Sorensen" 
> To: 
> Subject: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)
> Date: Sat, Oct 26, 2013 4:22 PM
>
> I'm not sure. Somebody on the list has asked about this before, so you may
> be able to find answers in the history. I've never actually done it because
> I could never get answers about how it was supposed to work. I did do some
> digging and found that cloudstack always looks for the newest system type
> template of a certain name and uses that. But I wasn't sure how the script
> went about triggering a redeploy of the root disk, it just seemed to reboot
> the VMS.
>
> Personally, I've always just replaced the template file by hand, swapping
> out the old file with the the new on secondary and primary storage, then
> set the global variable that recreates system VMs when you restart them. I
> wouldn't recommend doing it that way unless you don't care if it gets
> messed up (Dev environment).
>
> When I ran through upgrade scenarios in testing the release, I was always
> using the newer template with 4.1 thus didn't need to do that step.
> On Oct 26, 2013 3:08 PM, "Marty Sweet"  wrote:
>
> > Hi Marcus,
> >
> > That is so irritating, when registering the new template using the
> > interface should the routing box be checked?
> > I say this because on past system templates they appear as routing in the
> > database although it is not specifically stated in the docs (as I assume
> it
> > wasn't an option in 3.x).
> >
> > Also, how would I go about downloading this now? Seeing as my SecStorage
> VM
> > is offline?
> > This script seems to have little effect:
> >
> >
> >
> /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt
> > -m /var/export/secondary -u
> >
> >
> http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
> > -h kvm -s mykey -F -o localhost -r root -d mypassword
> >
> > cloudstack-sysvmadm -d 127.0.0.1 -u cloud -p -a
> > Running item 12 fails with and shows a nice list of options for the
> > command:
> >  /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No
> such
> > file or directory
> >
> > Thanks for your help so far!
> > Marty
> >
> >
> > On Sat, Oct 26, 2013 at 9:51 PM, Marcus Sorensen  > >wrote:
> >
> > > Yes, you do need to upgrade your system VMS, and you should also have a
> > new
> > > systemvm.iso that was bundled in the cloudstack-common deb file that
> > would
> > > have been installed as an upgrade on your KVM hosts. I also feel that
> the
> > > documentation of system vm upgrade is lacking. The only place I know if
> > is
> > > in the release notes:
> > >
> > >
> >
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Release_Notes/index.html
> > > ,
> > > see 3.1 "Upgrade Instructions", item 12. It references a script
> > > "cloudstack-sysvmadm", but the upgrade of the system vm template should
> > be
> > > done beforehand.  Now look at the section just below, 3.2. This
> > > documentation is obviously messed up because it first says "this
> applies
> > > only to VMware", and then it promptly gives system vm upgrade
> > instructions
> > > for XenServer, KVM, and VMWare hosts.  It's unclear why this system vm
> > > upgrade would only apply to zones which had VMware hosts, and why these
> > > instructions aren't also on the 4.1.x to 4.2.x instructions. At any
> rate,
> > > the system vm instuctions there for KVM should apply. Register the
> > template
> > > (optionally, check the data base to ensure the template is set as
> system
> > > type), then restart the system vms per the item 12 script. If your KVM
> > > hosts relaunch the system vms per the new template and they have the
> new
> > > systemvm.iso, they should work.
> > >
> > >
> > > On Oct 26, 2013 2:19 PM, "Marty Sweet"  wrote:
> > >
> > > > Hi Guys,
> > > >
> > > > I have just upgraded to 4.2.0 from 4.1.1 and am having some issues
> with
> > > the
> > > > SystemVMs.
> > > > I understand that we are meant to upgrade to the new system image?
> > Using
> > > > the script in the 'Prepare systemvm' documentation I did this with no
> > > > avail, editing the database to suit what I think would work has also
> > not
> > > > worked.
> > > >
> > > > Restoring a backup, I now have my original 4.1.1 acton systemvm
> > > templates.
> > > > What steps should I take to launch a systemVM successfully?
> > > >
> > > > The upgrade documentation is pretty lacking in this respect, and just
> > > says
> > > > restart the systemvms, with no reference to upgrading the i

Re: Migrating/managing secondary storages

[Daan Hoogland]

h mailinglists,

There is no maintenance mode for secondary storage at this time. Make
sure no snapshot is being taken or virtual machine is being
instantiated at the time and shutdown the ms. there is no other way at
the time.

(mailinglists is not a very inviting from address to respond to, just
thought I'd mention it)

regards,
Daan

On Fri, Oct 25, 2013 at 12:30 PM,   wrote:
> Thought I'd ask here as well.
>
>
>
> I have a CS 4.2 and 4 secondary NFS storages (s1, s2, s3, s4). I'd like to
>
> migrate everything (all the templates, snapshots,…) from s1 and s2 to s3
>
> and s4 and then shutdown s1 & s2. Is there a way to do it via GUI? The only
>
> instructions I found are to stop CloudStack, copy everything from one
>
> secondary storage to another change the references to that secondary
>
> storage in the database to the new secondary storage and restart
>
> cloudstack.
>
>
>
> Any first hand experiences/advices on how to do it, what to look out for?
>
>
>
> Best regards,
>
>
>
> F.

Re: [DOC] 4.2.0 Templates

[Marty Sweet]

Hi,

Is there any update on this?
My commit
https://github.com/apache/cloudstack/commit/f5e7f46dadda741f10e5b674d0578ade9ba719d7
made
it into the 4.2.0 docs but
https://github.com/apache/cloudstack/commit/922ef76224d4a8534f67f47b97cf664e5c65ecba
hasn't,
I have gone to use this several times just to remember it's not there :)

Thanks,
Marty


On Thu, Oct 10, 2013 at 10:05 AM, Daan Hoogland wrote:

> Marty,
>
> As I understand the master branch for docs will be filled as work on
> it starts. the ones in the 4.2 branch are the current ones.
>
> btw commits get hidden, rarely lost :p
>
> regards,
>
> On Thu, Oct 10, 2013 at 8:29 AM, Marty Sweet  wrote:
> > Where will the docs commited to the master become available? This
> probably
> > isn't the only case where commits have been lost?
> >
> > https://reviews.apache.org/r/13745/
> >
> >
> >
> > On Thu, Oct 10, 2013 at 1:17 AM, Radhika Puthiyetath <
> > radhika.puthiyet...@citrix.com> wrote:
> >
> >> 4.2 docs are from 4.2 branch.
> >>
> >> -Original Message-
> >> From: Marty Sweet [mailto:msweet@gmail.com]
> >> Sent: Thursday, October 10, 2013 3:27 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [DOC] 4.2.0 Templates
> >>
> >> Hi Daan,
> >>
> >> Yeah the doc directory in the repo commited to master, where is the
> >> current
> >>
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/working-with-templates.html
> >> being
> >> built from?
> >>
> >> Marty
> >>
> >>
> >> On Wed, Oct 9, 2013 at 8:55 PM, Daan Hoogland  >> >wrote:
> >>
> >> > Marty,
> >> >
> >> > I am not sure what you mean. Do you mean the doc dir in the repo? I
> >> > think you need to look in
> >> > https://git-wip-us.apache.org/repos/asf/cloudstack-docs.git for the
> >> > 4.2 docs.
> >> >
> >> > regards,
> >> > Daan
> >> >
> >> > On Sun, Oct 6, 2013 at 10:51 PM, Marty Sweet 
> >> wrote:
> >> > > Hi guys,
> >> > >
> >> > > I created a document for creating Linux documentation for the 4.2.0
> >> > > release. Checking the documentation it seems that it is not there?
> >> > > Is
> >> > there
> >> > > any reason for this?
> >> > >
> >> > >
> >> >
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/A
> >> > dmin_Guide/working-with-templates.html
> >> > >
> >> > >
> >> >
> https://github.com/apache/cloudstack/commit/922ef76224d4a8534f67f47b97
> >> > cf664e5c65ecba
> >> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4329
> >> > >
> >> > > Thanks,
> >> > > Marty
> >> >
> >>
>

Re: Mailing list search

[Daan Hoogland]

H Noah,

I recall entering a ticket for infra, and forgot about it. I suppose
you are talking about markmail. I don't know how to change the setting
for it. I'll do some follow up. (anybody knows what the management
acoount for the apache markmail account is?)

regards,
Daan

On Fri, Oct 25, 2013 at 8:58 PM, Noah Slater  wrote:
> Hi,
>
> Mailing list search on our site still points to the incubator:
>
> http://cloudstack.apache.org/mailing-lists.html
>
> I recall discussing this in the past with someone and was asked to
> hold back, as the Incubator lists still had most of the traffic.
>
> Is it time we switched this over?
>
> Thanks,
>
> --
> Noah Slater
> https://twitter.com/nslater

Re: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)

[kel...@backbonetechnology.com]

Not yet. This is a 'hack'. Officially the process is to download update 
templates as step 1, before the stuff in the release notes.

Sent from my HTC

- Reply message -
From: "Marty Sweet" 
To: "dev@cloudstack.apache.org" 
Subject: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)
Date: Sun, Oct 27, 2013 3:40 AM

Thanks Kelcey, that worked a treat!

Do you know of any plans to update the official documentation?

Marty


On Sun, Oct 27, 2013 at 1:16 AM, kel...@backbonetechnology.com <
kel...@backbonetechnology.com> wrote:

> Hi,
>
> Try this, it was written for your situation!
>
>
> http://cloud.kelceydamage.com/cloudfire/blog/2013/10/08/conquering-the-cloudstack-4-2-dragon-kvm/
>
> -Kelcey
>
> Sent from my HTC
>
> - Reply message -
> From: "Marcus Sorensen" 
> To: 
> Subject: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)
> Date: Sat, Oct 26, 2013 4:22 PM
>
> I'm not sure. Somebody on the list has asked about this before, so you may
> be able to find answers in the history. I've never actually done it because
> I could never get answers about how it was supposed to work. I did do some
> digging and found that cloudstack always looks for the newest system type
> template of a certain name and uses that. But I wasn't sure how the script
> went about triggering a redeploy of the root disk, it just seemed to reboot
> the VMS.
>
> Personally, I've always just replaced the template file by hand, swapping
> out the old file with the the new on secondary and primary storage, then
> set the global variable that recreates system VMs when you restart them. I
> wouldn't recommend doing it that way unless you don't care if it gets
> messed up (Dev environment).
>
> When I ran through upgrade scenarios in testing the release, I was always
> using the newer template with 4.1 thus didn't need to do that step.
> On Oct 26, 2013 3:08 PM, "Marty Sweet"  wrote:
>
> > Hi Marcus,
> >
> > That is so irritating, when registering the new template using the
> > interface should the routing box be checked?
> > I say this because on past system templates they appear as routing in the
> > database although it is not specifically stated in the docs (as I assume
> it
> > wasn't an option in 3.x).
> >
> > Also, how would I go about downloading this now? Seeing as my SecStorage
> VM
> > is offline?
> > This script seems to have little effect:
> >
> >
> >
> /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt
> > -m /var/export/secondary -u
> >
> >
> http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
> > -h kvm -s mykey -F -o localhost -r root -d mypassword
> >
> > cloudstack-sysvmadm -d 127.0.0.1 -u cloud -p -a
> > Running item 12 fails with and shows a nice list of options for the
> > command:
> >  /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No
> such
> > file or directory
> >
> > Thanks for your help so far!
> > Marty
> >
> >
> > On Sat, Oct 26, 2013 at 9:51 PM, Marcus Sorensen  > >wrote:
> >
> > > Yes, you do need to upgrade your system VMS, and you should also have a
> > new
> > > systemvm.iso that was bundled in the cloudstack-common deb file that
> > would
> > > have been installed as an upgrade on your KVM hosts. I also feel that
> the
> > > documentation of system vm upgrade is lacking. The only place I know if
> > is
> > > in the release notes:
> > >
> > >
> >
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Release_Notes/index.html
> > > ,
> > > see 3.1 "Upgrade Instructions", item 12. It references a script
> > > "cloudstack-sysvmadm", but the upgrade of the system vm template should
> > be
> > > done beforehand.  Now look at the section just below, 3.2. This
> > > documentation is obviously messed up because it first says "this
> applies
> > > only to VMware", and then it promptly gives system vm upgrade
> > instructions
> > > for XenServer, KVM, and VMWare hosts.  It's unclear why this system vm
> > > upgrade would only apply to zones which had VMware hosts, and why these
> > > instructions aren't also on the 4.1.x to 4.2.x instructions. At any
> rate,
> > > the system vm instuctions there for KVM should apply. Register the
> > template
> > > (optionally, check the data base to ensure the template is set as
> system
> > > type), then restart the system vms per the item 12 script. If your KVM
> > > hosts relaunch the system vms per the new template and they have the
> new
> > > systemvm.iso, they should work.
> > >
> > >
> > > On Oct 26, 2013 2:19 PM, "Marty Sweet"  wrote:
> > >
> > > > Hi Guys,
> > > >
> > > > I have just upgraded to 4.2.0 from 4.1.1 and am having some issues
> with
> > > the
> > > > SystemVMs.
> > > > I understand that we are meant to upgrade to the new system image?
> > Using
> > > > the script in the 'Prepare systemvm' documentation I did this with no
> > > > avail, editing the database to suit what I think would work has also
> > not
> > > > worked.

Re: Mailing list search

[Ian Duffy]

>  I don't know how to change the setting for it.

Should just be a case of modifying the form action within that page.
I can go ahead and do it if there are no objections.

Tiered Quality

[Darren Shepherd]

I don't know if a similar thing has been talked about before but I
thought I'd just throws this out there.  The ultimate way to ensure
quality is that we have unit test and integration test coverage on all
functionality.  That way somebody authors some code, commits to, for
example, 4.2, but then when we release 4.3, 4.4, etc they aren't on
the hook to manually tests the functionality with each release.  The
obvious nature of a community project is that people come and go.  If
a contributor wants to ensure the long term viability of the
component, they should ensure that there are unit+integration tests.

Now, for whatever reason whether good or bad, it's not always possible
to have full integration tests.  I don't want to throw down the gamut
and say everything must have coverage because that will mean some
useful code/feature will not get in because of some coverage wasn't
possible at the time.

What I propose is that for every feature or function we put it in a
tier of what is the quality of it (very similar to how OpenStack
qualifies their hypervisor integration).  Tier A means unit test and
integration test coverage gates the release.  Tier B means unit test
coverage gates the release.  Tier C mean who knows, it compiled.  We
can go through and classify the components and then as a community we
can try to get as much into Tier A as possible.

Darren

Re: Mailing list search

[Daan Hoogland]

On Sun, Oct 27, 2013 at 4:19 PM, Ian Duffy  wrote:
> modifying the form action within that page.

I have no idea what you are talking about, so please do.

Re: Mailing list search

[Ian Duffy]

Sorry, just looked at this more.
I made the false assumption that the lists for org.apache.cloudstack-*
already existed on mailmark and that it was just a matter of switching the
search form.


On 27 October 2013 16:05, Daan Hoogland  wrote:

> On Sun, Oct 27, 2013 at 4:19 PM, Ian Duffy  wrote:
> > modifying the form action within that page.
>
> I have no idea what you are talking about, so please do.
>

Re: Mailing list search

[Daan Hoogland]

infra told me to contact markmail so i submitted a request at the
markmail site for help.

On Sun, Oct 27, 2013 at 5:29 PM, Ian Duffy  wrote:
> Sorry, just looked at this more.
> I made the false assumption that the lists for org.apache.cloudstack-*
> already existed on mailmark and that it was just a matter of switching the
> search form.
>
>
> On 27 October 2013 16:05, Daan Hoogland  wrote:
>
>> On Sun, Oct 27, 2013 at 4:19 PM, Ian Duffy  wrote:
>> > modifying the form action within that page.
>>
>> I have no idea what you are talking about, so please do.
>>

Re: Tiered Quality

[Laszlo Hornyak]

I believe this will be very useful for users.
As far as I understand someone will have to qualify components. What will
be the method for qualification? I do not think simply the test coverage
would be right. But then if you want to go deeper, then you need a bigger
effort testing the components.



On Sun, Oct 27, 2013 at 4:51 PM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:

> I don't know if a similar thing has been talked about before but I
> thought I'd just throws this out there.  The ultimate way to ensure
> quality is that we have unit test and integration test coverage on all
> functionality.  That way somebody authors some code, commits to, for
> example, 4.2, but then when we release 4.3, 4.4, etc they aren't on
> the hook to manually tests the functionality with each release.  The
> obvious nature of a community project is that people come and go.  If
> a contributor wants to ensure the long term viability of the
> component, they should ensure that there are unit+integration tests.
>
> Now, for whatever reason whether good or bad, it's not always possible
> to have full integration tests.  I don't want to throw down the gamut
> and say everything must have coverage because that will mean some
> useful code/feature will not get in because of some coverage wasn't
> possible at the time.
>
> What I propose is that for every feature or function we put it in a
> tier of what is the quality of it (very similar to how OpenStack
> qualifies their hypervisor integration).  Tier A means unit test and
> integration test coverage gates the release.  Tier B means unit test
> coverage gates the release.  Tier C mean who knows, it compiled.  We
> can go through and classify the components and then as a community we
> can try to get as much into Tier A as possible.
>
> Darren
>



-- 

EOF

Cannot change Host OS preference from xyz -> None

[Marty Sweet]

Hi Guys,

When you get a moment can you test to see if this bug exists on your
setups? Wondering if it is a coding issue or a DB inconsistency.

Reproduce:
1) Infrastructure > Hosts (View All) > Click Host > Edit
2) Change OS Preference to Ubuntu
3) Save
4) Refresh > go back into menu, it is Ubuntu

5) Edit > Change OS Preference to None
6) Save
7) Refresh > go back into menu, it is Ubuntu
Changing from an OS -> None does not save.

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

Many thanks,
Marty

Re: Tiered Quality

[Darren Shepherd]

I think it can't be at a component level because components are too large.  It 
needs to be at a feature for implementation level.  For example, live storage 
migration for xen and live storage migration for kvm (don't know if that's a 
real thing) would be two separate items.  

Darren

> On Oct 27, 2013, at 10:57 AM, Laszlo Hornyak  wrote:
> 
> I believe this will be very useful for users.
> As far as I understand someone will have to qualify components. What will
> be the method for qualification? I do not think simply the test coverage
> would be right. But then if you want to go deeper, then you need a bigger
> effort testing the components.
> 
> 
> 
> On Sun, Oct 27, 2013 at 4:51 PM, Darren Shepherd <
> darren.s.sheph...@gmail.com> wrote:
> 
>> I don't know if a similar thing has been talked about before but I
>> thought I'd just throws this out there.  The ultimate way to ensure
>> quality is that we have unit test and integration test coverage on all
>> functionality.  That way somebody authors some code, commits to, for
>> example, 4.2, but then when we release 4.3, 4.4, etc they aren't on
>> the hook to manually tests the functionality with each release.  The
>> obvious nature of a community project is that people come and go.  If
>> a contributor wants to ensure the long term viability of the
>> component, they should ensure that there are unit+integration tests.
>> 
>> Now, for whatever reason whether good or bad, it's not always possible
>> to have full integration tests.  I don't want to throw down the gamut
>> and say everything must have coverage because that will mean some
>> useful code/feature will not get in because of some coverage wasn't
>> possible at the time.
>> 
>> What I propose is that for every feature or function we put it in a
>> tier of what is the quality of it (very similar to how OpenStack
>> qualifies their hypervisor integration).  Tier A means unit test and
>> integration test coverage gates the release.  Tier B means unit test
>> coverage gates the release.  Tier C mean who knows, it compiled.  We
>> can go through and classify the components and then as a community we
>> can try to get as much into Tier A as possible.
>> 
>> Darren
> 
> 
> 
> -- 
> 
> EOF

[Responsiveness report] users 2013w42

[Daan Hoogland]

http://markmail.org/message/b4l22x3gxw6ccb47 client issue - no tomcat
deployment by Kevin Yeandel
http://markmail.org/message/yby5o6rgsffnnitv Traffic Type : public
gone when using SG and advanced network by Bjoern Teipel
http://markmail.org/message/s4mbftpgjmkilmcu Building 4.2 -nonoss by
Fred Messinger

[Responsiveness report] dev 2013w42

[Daan Hoogland]

http://markmail.org/message/fekg3fk6h6yqvbvl Error Codes\ Export
Import Config by
 Santhosh Edukulla

Latest automation result on master - KVM /10/27/13

[Rayees Namathponnan]

Here the BVT automation result on KVM,  You can  see the result @ 
http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/992/ 

Looks like there is regression while delete network;  network test cases failed 
to delete network; unfortunately I don't have setup to test this manually; 


Below defect are still open; 

https://issues.apache.org/jira/browse/CLOUDSTACK-4835
https://issues.apache.org/jira/browse/CLOUDSTACK-4833


Automation result on master

Configuration Nam   
 AllFailed  Defect
test_affinity_groups
1   1   Failed to create Affinity group
test_deploy_vm  
1   0   
test_deploy_vm_with_userdata2   0   
test_deploy_vms_with_varied_deploymentplanners  3   0   
test_disk_offerings 
   30   
test_global_settings
   22   CLOUDSTACK-4835
test_guest_vlan_range   
   10   
test_internal_lb
   10   
test_iso
   21   CLOUDSTACK-4833
test_loadbalance3   
1   "Ssh failure, looks like test case issue"
test_multipleips_per_nic1   0   
test_network  8 
1   Failed to delete network ;  looks like its regression;  this test cases 
was passing in my last report 
test_network_acl  1 0   
test_nic  1 
0   
test_non_contigiousvlan   1 0   
test_portable_publicip  3   
1   Failed to delete network ;  looks like its regression;  this test cases 
was passing in my last report 
test_privategw_acl1 1   
test_public_ip_range  1 0   
test_pvlan1 
1   Failed to delete network ;  looks like its regression;  this test cases 
was passing in my last report 
test_regions  1 0   
test_reset_vm_on_reboot10   
test_resource_detail  1 0   
test_routers 9  
0   
test_scale_vm  
11   
test_service_offerings   4  0   
test_ssvm  10   
0   
test_templates  8   1   
CLOUDSTACK-4833
test_vm_life_cycle  10  6   
test_vm_snapshots   3   3   
test_volumes9   2   
Failed  to create volume
test_vpc_vpn1   0   

Regards,
Rayees

Re: Tiered Quality

[Laszlo Hornyak]

Ok, makes sense, but that sounds like even more work :) Can you share the
plan on how will this work?


On Sun, Oct 27, 2013 at 7:54 PM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:

> I think it can't be at a component level because components are too large.
>  It needs to be at a feature for implementation level.  For example, live
> storage migration for xen and live storage migration for kvm (don't know if
> that's a real thing) would be two separate items.
>
> Darren
>
> > On Oct 27, 2013, at 10:57 AM, Laszlo Hornyak 
> wrote:
> >
> > I believe this will be very useful for users.
> > As far as I understand someone will have to qualify components. What will
> > be the method for qualification? I do not think simply the test coverage
> > would be right. But then if you want to go deeper, then you need a bigger
> > effort testing the components.
> >
> >
> >
> > On Sun, Oct 27, 2013 at 4:51 PM, Darren Shepherd <
> > darren.s.sheph...@gmail.com> wrote:
> >
> >> I don't know if a similar thing has been talked about before but I
> >> thought I'd just throws this out there.  The ultimate way to ensure
> >> quality is that we have unit test and integration test coverage on all
> >> functionality.  That way somebody authors some code, commits to, for
> >> example, 4.2, but then when we release 4.3, 4.4, etc they aren't on
> >> the hook to manually tests the functionality with each release.  The
> >> obvious nature of a community project is that people come and go.  If
> >> a contributor wants to ensure the long term viability of the
> >> component, they should ensure that there are unit+integration tests.
> >>
> >> Now, for whatever reason whether good or bad, it's not always possible
> >> to have full integration tests.  I don't want to throw down the gamut
> >> and say everything must have coverage because that will mean some
> >> useful code/feature will not get in because of some coverage wasn't
> >> possible at the time.
> >>
> >> What I propose is that for every feature or function we put it in a
> >> tier of what is the quality of it (very similar to how OpenStack
> >> qualifies their hypervisor integration).  Tier A means unit test and
> >> integration test coverage gates the release.  Tier B means unit test
> >> coverage gates the release.  Tier C mean who knows, it compiled.  We
> >> can go through and classify the components and then as a community we
> >> can try to get as much into Tier A as possible.
> >>
> >> Darren
> >
> >
> >
> > --
> >
> > EOF
>



-- 

EOF

cloudmonkey exit value

[Darren Shepherd]

It would be really nice if the API failed if cloudmonkey exited with
!=0 exit code.  I've been scripting some stuff with cloud monkey and
this makes it difficult.  It would also be nice to somehow specific
which field you want printed.  So when I do a create command I can say
just echo id value only.  Would make my scripts much easier.

Darren

Re: [Cloudmonkey] assignVirtualMachine API causes index out of range error

[Ryan Lei]

Here's the assignVirtualMachine response json from log:

2013-10-25 17:02:54,107 - cloudmonkey.py:83 - [DEBUG] Loaded config fields:
['cache_file=/root/.cloudmonkey/cache',
'log_file=/root/.cloudmonkey/log', 'asyncblock=true',
'paramcompletion=false', 'history_file=/root/.cloudmonkey/history',
'color=true', 'prompt=> ', 'display=table',
'secretkey=wOV6_F8BZXxXV0zfX_DLVscCtbGrZgV3h8AcWfQLIa-OBCddLJimXTIQaM9hFH5ggItwwIFcivjJ77zn7LjWCQ',
'apikey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA',
'path=/client/api', 'host=localhost', 'protocol=http', 'port=8080',
'timeout=3600']

2013-10-25 17:03:19,839 - requester.py:45 - [DEBUG]  START
Request 
2013-10-25 17:03:19,840 - requester.py:45 - [DEBUG] Requesting
command=assignVirtualMachine, args={'account': 'domain1-user2',
'domainid': 'cfc19b03-0858-4f39-9058-e0b67685bc2f',
'virtualmachineid': '939f1c53-91e8-47a1-92d1-9ec9c2c1802c'}
2013-10-25 17:03:19,841 - requester.py:45 - [DEBUG] Request sent:
http://localhost:8080/client/api?account=domain1-user2&apiKey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA&command=assignVirtualMachine&domainid=cfc19b03-0858-4f39-9058-e0b67685bc2f&response=json&virtualmachineid=939f1c53-91e8-47a1-92d1-9ec9c2c1802c&signature=gcqky6emSpV08QHZuavLZFS6Pcg%3D

2013-10-25 17:03:20,107 - requester.py:45 - [DEBUG] Response received:
{ "virtualmachine" :  { "virtualmachine" :
{"id":"939f1c53-91e8-47a1-92d1-9ec9c2c1802c","name":"domain1-admin","displayname":"domain1-admin","account":"domain1-user2","domainid":"cfc19b03-0858-4f39-9058-e0b67685bc2f","domain":"domain1","created":"2013-10-25T15:15:03+0800","state":"Stopped","haenable":false,"zoneid":"6e0b2791-513e-49be-bbd8-62c2597640ef","zonename":"Zone-Xen","templateid":"855b7915-9739-4ad7-945e-8b8514040198","templatename":"CentOS-6.4-x86_64
(scalable)","templatedisplaytext":"CentOS-6.4-x86_64
(scalable)","passwordenabled":false,"serviceofferingid":"32f7668c-5edd-4152-b927-c7b744281dc2","serviceofferingname":"Small
Instance","cpunumber":1,"cpuspeed":500,"memory":512,"cpuused":"0%","networkkbsread":0,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"f70b6aaa-37da-11e3-9cb9-46ca9f9b4d97","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"nic":[{"id":"2f2a6ff3-ab11-4127-8991-2813a9a1c3ba","networkid":"aad53b98-3a6c-4cd3-a1e3-cbb84834d8c1","networkname":"domain1-user2-network","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.204","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:17:61:00:01"}],"hypervisor":"XenServer","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
}  }
2013-10-25 17:03:20,108 - requester.py:45 - [DEBUG]  END
Request 


I'm using Cloudmonkey from git (corresponding to 5.0.0), and I have tried
using root admin and domain admin to call this API. Both turned out to
succeed but crash Cloudmonkey.

---
Yu-Heng (Ryan) Lei, Associate Researcher
Chunghwa Telecom Laboratories / Cloud Computing Laboratory
ryan...@cht.com.tw
or
ryanlei750...@gmail.com



On Fri, Oct 25, 2013 at 7:02 PM, Rohit Yadav  wrote:

> Hi Ryan,
>
> Will check this next week, the issue is clearly with response which lacks a
> key with name 'response' in it, it could be a case issue as well. Can you
> share with us the response json from cloudmonkey's log in
> ~/.cloudmonkey/log, you may confirm the keys from the json. Also, check if
> you're allowed to call the API as different user groups can have access to
> different set of APIs.
>
> Cheers.
>
>
> On Fri, Oct 25, 2013 at 2:27 PM, Ryan Lei  wrote:
>
> > I'm using Cloudmonkey 5.0.0 under CloudStack 4.2.0 + XenServer 6.2.
> > For now, the only way to change the ownership of a VM is by the
> > assignVirtualMachine API.
> >
> > But executing this API using Cloudmonkey leads to the following error
> that
> > crashes the program:
> >
> > > assign virtualmachine
> > virtualmachineid=7fe548bb-b2a7-4aec-92c5-5012ef9fd4f4
> account=domain1-user1
> > domainid=cfc19b03-0858-4f39-9058-e0b67685bc2f
> > Traceback (most recent call last):
> >   File "/usr/bin/cloudmonkey", line 9, in 
> > load_entry_point('cloudmonkey==5.0.0', 'console_scripts',
> > 'cloudmonkey')()
> >   File
> >
> >
> "/usr/lib/python2.6/site-packages/cloudmonkey-5.0.0-py2.6.egg/cloudmonkey/cloudmonkey.py",
> > line 536, in main
> > shell.cmdloop()
> >   File
> >
> >
> "/usr/lib/python2.6/site-packages/cloudmonkey-5.0.0-py2.6.egg/cloudmonkey/cloudmonkey.py",
> > line 106, in cmdloop
> > super(CloudMonkeyShell, self).cmdloop(intro="")
> >   File "/usr/lib64/python2.6/cmd.py", line 142, in cmdloop
> > stop = self.onecmd(line)
>

Migrate from existing xenserver pool into cloudstack

[王健]

Is there a tool for migrating from existing xenserver pool into cloudstack?
---
Confidentiality Notice: The information contained in this e-mail and any 
accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential 
and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of 
this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, 
disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this 
communication in error,please 
immediately notify the sender by return e-mail, and delete the original message 
and all copies from 
your system. Thank you. 
---

Re: cloudmonkey exit value

[Prasanna Santhanam]

On Sun, Oct 27, 2013 at 04:49:35PM -0700, Darren Shepherd wrote:
> It would be really nice if the API failed if cloudmonkey exited with
> !=0 exit code.  I've been scripting some stuff with cloud monkey and
> this makes it difficult.  It would also be nice to somehow specific
> which field you want printed.  So when I do a create command I can say
> just echo id value only.  Would make my scripts much easier.
> 
you can pipe with grep?
$ cloudmonkey createCommand | grep id

> Darren

-- 
Prasanna.,


Powered by BigRock.com

Re: Tiered Quality

[Prasanna Santhanam]

We need a way to check coverage of (unit+integration) tests. How many
lines of code hit on a deployed system that corresponds to the
component donated/committed. We don't have that for existing tests so
it makes it hard to judge if a feature that comes with tests covers
enough of itself.

On Sun, Oct 27, 2013 at 11:00:46PM +0100, Laszlo Hornyak wrote:
> Ok, makes sense, but that sounds like even more work :) Can you share the
> plan on how will this work?
> 
> 
> On Sun, Oct 27, 2013 at 7:54 PM, Darren Shepherd <
> darren.s.sheph...@gmail.com> wrote:
> 
> > I think it can't be at a component level because components are too large.
> >  It needs to be at a feature for implementation level.  For example, live
> > storage migration for xen and live storage migration for kvm (don't know if
> > that's a real thing) would be two separate items.
> >
> > Darren
> >
> > > On Oct 27, 2013, at 10:57 AM, Laszlo Hornyak 
> > wrote:
> > >
> > > I believe this will be very useful for users.
> > > As far as I understand someone will have to qualify components. What will
> > > be the method for qualification? I do not think simply the test coverage
> > > would be right. But then if you want to go deeper, then you need a bigger
> > > effort testing the components.
> > >
> > >
> > >
> > > On Sun, Oct 27, 2013 at 4:51 PM, Darren Shepherd <
> > > darren.s.sheph...@gmail.com> wrote:
> > >
> > >> I don't know if a similar thing has been talked about before but I
> > >> thought I'd just throws this out there.  The ultimate way to ensure
> > >> quality is that we have unit test and integration test coverage on all
> > >> functionality.  That way somebody authors some code, commits to, for
> > >> example, 4.2, but then when we release 4.3, 4.4, etc they aren't on
> > >> the hook to manually tests the functionality with each release.  The
> > >> obvious nature of a community project is that people come and go.  If
> > >> a contributor wants to ensure the long term viability of the
> > >> component, they should ensure that there are unit+integration tests.
> > >>
> > >> Now, for whatever reason whether good or bad, it's not always possible
> > >> to have full integration tests.  I don't want to throw down the gamut
> > >> and say everything must have coverage because that will mean some
> > >> useful code/feature will not get in because of some coverage wasn't
> > >> possible at the time.
> > >>
> > >> What I propose is that for every feature or function we put it in a
> > >> tier of what is the quality of it (very similar to how OpenStack
> > >> qualifies their hypervisor integration).  Tier A means unit test and
> > >> integration test coverage gates the release.  Tier B means unit test
> > >> coverage gates the release.  Tier C mean who knows, it compiled.  We
> > >> can go through and classify the components and then as a community we
> > >> can try to get as much into Tier A as possible.
> > >>
> > >> Darren
> > >
> > >
> > >
> > > --
> > >
> > > EOF
> >
> 
> 
> 
> -- 
> 
> EOF

-- 
Prasanna.,


Powered by BigRock.com

Suggestion - Marvin Code coverage

[Rayees Namathponnan]

Hi All,

I am trying to run code coverage tool with Marvin framework;   basically I want 
to find how much percentage  our product's code covered in Marvin automation 
including BVT and regression.

Seems  there are few tools to perform code coverage with black automation;  
with those tools you can instrument on the fly;  unfortunately I didn't get 
anything  really useful.

Any suggestion here ? anyone tried this earlier ?

Regards,
Rayees

Re: Review Request 14827: hyperv unit tests

[Devdeep Singh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14827/#review27588
---

Ship it!


Ship It!

- Devdeep Singh


On Oct. 23, 2013, 11:05 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14827/
> ---
> 
> (Updated Oct. 23, 2013, 11:05 a.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, Devdeep Singh, Donal 
> Lafferty, and Rajesh Battala.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Hyperv Unit tests written using NSubstitute and XUnit. Description for this 
> can be found at 
> 
> http://nsubstitute.github.io/help/getting-started/
> http://xunit.codeplex.com/wikipage?title=HowToUse
> http://xunit.codeplex.com/wikipage?title=Comparisons
> 
> Currently packages have to be manually copied for Linux. buildagent script is 
> not downloading them.
> 
> I have also changed the existing tests to xunit 
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/.gitignore cf9cb85 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/.nuget/NuGet.Config 
> PRE-CREATION 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/.nuget/NuGet.targets 
> PRE-CREATION 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentSettings.Designer.cs
>  a73e6bb 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentSettings.settings
>  435b8e0 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentShell.csproj 
> fe055d0 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/packages.config 
> f5f47e6 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResource.csproj
>  dbd7b15 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
>  7a0c2db 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/IWmiCalls.cs 
> PRE-CREATION 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/IWmiCallsV2.cs
>  PRE-CREATION 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCalls.cs 
> 1b9e073 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
> 7557320 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/packages.config
>  b0f2ace 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/App.config
>  1bf17d4 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/HypervResourceController1Test.cs
>  PRE-CREATION 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/HypervResourceControllerTest.cs
>  8a86727 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/ServerResource.Tests.csproj
>  381245e 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/packages.config
>  08ef691 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/WmiWrappers/WmiWrappers.csproj
>  d3baab4 
>   plugins/hypervisors/hyperv/buildagent.sh f2a4921 
>   
> plugins/hypervisors/hyperv/var/test/storagepool/TestCopiedLocalTemplate.vhdx 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14827/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Suggestion - Marvin Code coverage

[Prasanna Santhanam]

On Mon, Oct 28, 2013 at 05:07:36AM +, Rayees Namathponnan wrote:
> Hi All,
> 
> I am trying to run code coverage tool with Marvin framework;
> basically I want to find how much percentage  our product's code
> covered in Marvin automation including BVT and regression.
> 
> Seems  there are few tools to perform code coverage with black
> automation;  with those tools you can instrument on the fly;
> unfortunately I didn't get anything  really useful.
> 

Emma with offline instrumentation may be. There's plenty others listed
here (that I haven't tried) -
https://en.wikipedia.org/wiki/Java_Code_Coverage_Tools

Darren brought up the same concerns here:
http://markmail.org/message/rwjqwcqbux7wpzrj

May be we can collate this discussion there?

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 14199: Adding missing test cases: Snapshots Improvement

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14199/
---

(Updated Oct. 28, 2013, 5:53 a.m.)


Review request for cloudstack, Girish Shilamkar and suresh sadhu.


Changes
---

including feature reviewers


Repository: cloudstack-git


Description
---

Adding 5 missing test cases.
Change in asyncJobMgr.py >> the method "make_request" in cloudstackConnection 
does not exist now. Replaced it by "marvin_request". Checked running async jobs 
with this change. Works correctly.


Diffs
-

  test/integration/component/test_snapshots_improvement.py PRE-CREATION 
  tools/marvin/marvin/asyncJobMgr.py 25818a6 

Diff: https://reviews.apache.org/r/14199/diff/


Testing
---

Tested locally on KVM Advanced setup.

test_01_concurrent_snapshots_live_migrate 
(test_snapshots_improvement.TestCreateSnapshot)
Test perform concurrent snapshots and migrate the vm from one host ... ok
test_02_stop_vm_concurrent_snapshots 
(test_snapshots_improvement.TestCreateSnapshot)
Test stop running VM while performing concurrent snapshot on volume ... ok
test_03_concurrent_snapshots_create_template 
(test_snapshots_improvement.TestCreateSnapshot)
Test while parent concurrent snapshot job in progress,create ... ok
test_04_concurrent_snapshots_create_volume 
(test_snapshots_improvement.TestCreateSnapshot)
Test while parent concurrent snapshot job in progress,create volume ... ok
test_01_snapshot_on_rootVolume 
(test_snapshots_improvement.TestSnapshotOnRootVolume)
Test create VM with default cent os template and create snapshot ... ok

--
Ran 5 tests in 1420.575s

OK


Thanks,

Gaurav Aradhye

Re: Review Request 14426: Tests for Netscaler support as external LB Provider in VPC

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14426/
---

(Updated Oct. 28, 2013, 5:53 a.m.)


Review request for cloudstack, Rajesh Battala, Santhosh Edukulla, and Sowmya 
Krishnan.


Bugs: CLOUDSTACK-4776
https://issues.apache.org/jira/browse/CLOUDSTACK-4776


Repository: cloudstack-git


Description
---

Created tests for Netscaler as external LB provider in VPC
Used ddt to achieve this without adding new tests but modifying the existing 
tests
Created new network_offering_vpcNS 
Handled addition on NS as optional in setup - if NS addition fails, the non-NS 
tests still work and NS tests alone will be skipped
Removed the creation of vpc Offering for each test, instead, using Default 
offering
test_03_create_network_netscaler is no more valid - removed it. I am adding new 
tests for NS as external LB provider. So this is not needed.


Diffs
-

  test/integration/component/test_vpc_network.py 970a625 

Diff: https://reviews.apache.org/r/14426/diff/


Testing
---

Tested script locally. Long running script... Latest run looks good so far. 

output so far:
Test create network in VPC ... ok
Test create network in VPC ... ok
Test create network in VPC mismatched services (Should fail) ... ok
Test create network in VPC mismatched services (Should fail) ... ok
Test create multiple networks with LB service (Should fail) ... ok
Test create multiple networks with LB service (Should fail) ... ok
Test create network with external LB devices ... ok
Test create network with redundant router capability ... SKIP: skipped - RvR 
didn't support VPC currently
Test create network services not supported by VPC (Should fail) ... ok
Test create network without sourceNAT service in VPC (should fail) ... ok
Test create network with shared network offering ... ok
Test create network with shared network offering ... ok
Test create network with conserve mode ON ... ok
Test create network with conserve mode ON ... ok
Test network gc after shutdown of vms in the network ... FAIL
Test network rules after starting a VpcVr that was shutdown after network.gc 
... ok
Test Stop all the Vms that are part of the a Network ... ok
Test create network outside cidr range of VPC ... ok
Test create network outside cidr range of VPC ... ok
Test create network outside cidr range of VPC ... ok
Test create network inside cidr range of VPC ... ok
Test create network inside cidr range of VPC ... ok
Test create network overlapping cidr range of VPC ...


Thanks,

Sowmya Krishnan

Re: Review Request 13841: Missing tests from QA repo to ASF - 3 tests from test_vmware_drs.py

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13841/
---

(Updated Oct. 28, 2013, 5:54 a.m.)


Review request for cloudstack, Girish Shilamkar and Harikrishna Patnala.


Repository: cloudstack-git


Description
---

New File added: test_vmware_drs.py
Tests added   : def test_vm_creation_in_fully_automated_mode(self):
def test_vmware_anti_affinity(self):
def test_vmware_affinity(self):

The tests need manual setup and therefore have been marked as WIP and
skipped for the moment


Diffs
-

  test/integration/component/test_vmware_drs.py PRE-CREATION 

Diff: https://reviews.apache.org/r/13841/diff/


Testing
---

Tested locally.

One test case is working, two are skipped (one due to unavailability of 
particular setup and other die to feature not available in cloudstack yet)

Run Log:
==> client.log <==
2013-10-08 02:27:43,371 - DEBUG - test_vm_creation_in_fully_automated_mode 
(test_vmware_drs.TestVMPlacement) - max memory: 14911

==> result.log <==
test_vmware_affinity (test_vmware_drs.TestAffinityRules)
Test Set up affinity rules ... skipped 'Skip'
test_vmware_anti_affinity (test_vmware_drs.TestAntiAffinityRules)
Test Set up anti-affinity rules ... skipped 'Skip'
test_vm_creation_in_fully_automated_mode (test_vmware_drs.TestVMPlacement)
Test VM Creation in  automation mode = Fully automated ...
==> client.log <==
2013-10-08 02:28:53,855 - DEBUG - test_vm_creation_in_fully_automated_mode 
(test_vmware_drs.TestVMPlacement) - Deploying VM in account: test-R7LY31

==> result.log <==
ok

--
Ran 3 tests in 241.612s

OK (skipped=2)


Thanks,

Ashutosh Kelkar

Re: Review Request 14925: Added few misc changes to marvin

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14925/#review27589
---



tools/marvin/marvin/marvinPlugin.py


Any reason to remove the debug logger? This will cause the write of all 
logs without timestamp and component.


- Prasanna Santhanam


On Oct. 25, 2013, 10:58 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14925/
> ---
> 
> (Updated Oct. 25, 2013, 10:58 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added few misc changes.
> Deleted some unwanted code.
> Few naming convention changes 
> Added a validateList utility function
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/codes.py 6099d88 
>   tools/marvin/marvin/configGenerator.py 50614c1 
>   tools/marvin/marvin/deployDataCenter.py f2dccdb 
>   tools/marvin/marvin/integration/lib/utils.py d81e80d 
>   tools/marvin/marvin/marvinPlugin.py 3b282e4 
> 
> Diff: https://reviews.apache.org/r/14925/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Re: Review Request 14930: Added readable timestamp changes for start and end time to debug logs

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14930/#review27591
---

Ship it!


b4ceefa - master

- Prasanna Santhanam


On Oct. 25, 2013, 1:06 p.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14930/
> ---
> 
> (Updated Oct. 25, 2013, 1:06 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added few timestamp changes for start and endtime.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/marvinPlugin.py 3b282e4 
> 
> Diff: https://reviews.apache.org/r/14930/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Re: Review Request 14459: CLOUDSTACK-2243: Add automation tests for VMs base image update faclity

[Ashutosh Kelkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14459/
---

(Updated Oct. 28, 2013, 6:02 a.m.)


Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.


Changes
---

Updated patch as per review.


Bugs: CLOUDSTACK-2243
https://issues.apache.org/jira/browse/CLOUDSTACK-2243


Repository: cloudstack-git


Description
---

Added new test class to test Base Image Updation Facility.


Diffs
-

  test/integration/component/test_base_image_updation.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py 4f15137 

Diff: https://reviews.apache.org/r/14459/diff/


Testing
---

Tested locally on KVM advanced setup:

Log:

==> result.log <==
test_01_deploy_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate)
Test deploy an instance with service offerings with IsVolatile set. ... ok
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate)
Test rebooting instances created with isVolatile service offerings ...
==> client.log <==
2013-10-09 20:22:30,659 - DEBUG - 
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate) - Checking root
th isVolatile=True
2013-10-09 20:22:30,695 - DEBUG - 
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate) - Checking root
th isVolatile=False

==> result.log <==
ok
test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate)
Test restoring a vm with different template than the one it was created with ...
==> client.log <==
2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Registered a template of fo
ith ID: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Waiting for download of tem
: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
2013-10-09 20:38:25,367 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
le=True
2013-10-09 20:38:25,386 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
le=False
2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Creating recurring snapshot po
 disk on vm created with IsVolatile=True
2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Snapshot Policy - Type : HOURL
inute : 53
2013-10-09 20:38:30,982 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Sleeping for 25 minutes till t
snapshoted

==> result.log <==
ok
test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) ...
==> client.log <==
2013-10-09 21:11:51,780 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Checking whether root disk of
atile=True was destroyed
2013-10-09 21:11:51,827 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Checking whether snapshot rule
isVolatile=True was destroyed

==> result.log <==
ok

--
Ran 4 tests in 3534.241s

OK


Thanks,

Ashutosh Kelkar

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

[Prasanna Santhanam]

> On Oct. 25, 2013, 6:10 a.m., Prasanna Santhanam wrote:
> > I actually don't quite see how marvin uses the typeInfo. Will it only act 
> > as a carrier for this information? 
> > 
> > How would a test case author use this? It would've been nice if we could 
> > use the type info to deserialize the response returned by the server so 
> > each field gets its appropriate type. But in most tests we don't use the 
> > type information afaik.
> 
> Ryan Dietrich wrote:
> Yes, a carrier.  The main goal was to get the type into commands.xml, so 
> other "things" could take advantage of this extra meta-data.

I'm okay with it going to the 'commands.xml'. But may be we could wait on 
including it in cloudstackAPI stubs since you're not using this information 
directly from marvin? 


- Prasanna


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27513
---


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> ---
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I have a requirement for some work I am doing to "fail early".  The existing 
> marvin cloudstackAPI classes give me both the "legal" and "required" elements 
> for each API call as well as the response attributes.  However, they do not 
> tell me the types of each value.  I've gone ahead and exposed that type 
> information to python and to commands.xml as well.  I decided to try and 
> expose things so we're being as descriptive as possible.  It's a little 
> deflating how the Request/Response annotations aren't equal (Requests can 
> expose "strings" as "uuid's", allowing me to auto generate regex's for 
> validation).  Responses however, simply fall back to the specific java type, 
> (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid 
> parameters from being sent to Cloudstack in the first place (client side 
> validation is good, right?)
> I also think the UI could use this as part of their validation routines, if 
> they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> ---
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14889: Expose as much type information to commands.xml as well as to the generated python clasesss for Marvin

[Prasanna Santhanam]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14889/#review27593
---


One last thing - if you change the ApiXmlDocWriter to include type information, 
you might want to include that in the API discovery plugin as well. Many of the 
downstream tools (cloudmonkey/marvin) use the listApis call to sync against the 
management server's exposed API set.

- Prasanna Santhanam


On Oct. 23, 2013, 9:38 p.m., Ryan Dietrich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14889/
> ---
> 
> (Updated Oct. 23, 2013, 9:38 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I have a requirement for some work I am doing to "fail early".  The existing 
> marvin cloudstackAPI classes give me both the "legal" and "required" elements 
> for each API call as well as the response attributes.  However, they do not 
> tell me the types of each value.  I've gone ahead and exposed that type 
> information to python and to commands.xml as well.  I decided to try and 
> expose things so we're being as descriptive as possible.  It's a little 
> deflating how the Request/Response annotations aren't equal (Requests can 
> expose "strings" as "uuid's", allowing me to auto generate regex's for 
> validation).  Responses however, simply fall back to the specific java type, 
> (Integer, Long, String, Boolean).
> 
> I believe cloudmonkey could take advantage of this, by stopping invalid 
> parameters from being sent to Cloudstack in the first place (client side 
> validation is good, right?)
> I also think the UI could use this as part of their validation routines, if 
> they're using commands.xml as part of their build process.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/doc/ApiXmlDocWriter.java c3c0cab 
>   server/src/com/cloud/api/doc/Argument.java 29c361e 
>   tools/marvin/marvin/codegenerator.py 96729f6 
> 
> Diff: https://reviews.apache.org/r/14889/diff/
> 
> 
> Testing
> ---
> 
> mvn clean
> mvn
> cd tools/apidoc
> mvn
> inspect target/commands.xml
> cd ../tools/marvin
> mvn
> inspect python classes
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 14200: CLOUDSTACK-4686: Fixed volume limit for domain

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14200/#review27594
---


Commit c8b91f1b72d228b9979bdd38d62138eb84cb69c3 in branch refs/heads/master 
from Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c8b91f1 ]

CLOUDSTACK-4686: Fixed volume limit for domain


- ASF Subversion and Git Services


On Sept. 18, 2013, noon, Girish Shilamkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14200/
> ---
> 
> (Updated Sept. 18, 2013, noon)
> 
> 
> Review request for cloudstack and sailaja mada.
> 
> 
> Bugs: CLOUDSTACK-4686
> https://issues.apache.org/jira/browse/CLOUDSTACK-4686
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4686: Fixed volume limit for domain
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py 833723c 
> 
> Diff: https://reviews.apache.org/r/14200/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Girish Shilamkar
> 
>

Re: Review Request 14459: CLOUDSTACK-2243: Add automation tests for VMs base image update faclity

[Girish Shilamkar]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14459/#review27595
---

Ship it!


Ship It!

- Girish Shilamkar


On Oct. 28, 2013, 6:02 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14459/
> ---
> 
> (Updated Oct. 28, 2013, 6:02 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added new test class to test Base Image Updation Facility.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py 4f15137 
> 
> Diff: https://reviews.apache.org/r/14459/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced setup:
> 
> Log:
> 
> ==> result.log <==
> test_01_deploy_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate)
> Test deploy an instance with service offerings with IsVolatile set. ... ok
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate)
> Test rebooting instances created with isVolatile service offerings ...
> ==> client.log <==
> 2013-10-09 20:22:30,659 - DEBUG - 
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate) - Checking root
> th isVolatile=True
> 2013-10-09 20:22:30,695 - DEBUG - 
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate) - Checking root
> th isVolatile=False
> 
> ==> result.log <==
> ok
> test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate)
> Test restoring a vm with different template than the one it was created with 
> ...
> ==> client.log <==
> 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Registered a template of fo
> ith ID: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
> 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Waiting for download of tem
> : 5a9190a9-8a59-487f-b90f-4a76a0f509a0
> 2013-10-09 20:38:25,367 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
> le=True
> 2013-10-09 20:38:25,386 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
> le=False
> 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Creating recurring snapshot 
> po
>  disk on vm created with IsVolatile=True
> 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Snapshot Policy - Type : 
> HOURL
> inute : 53
> 2013-10-09 20:38:30,982 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Sleeping for 25 minutes till 
> t
> snapshoted
> 
> ==> result.log <==
> ok
> test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) ...
> ==> client.log <==
> 2013-10-09 21:11:51,780 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Checking whether root disk of
> atile=True was destroyed
> 2013-10-09 21:11:51,827 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Checking whether snapshot 
> rule
> isVolatile=True was destroyed
> 
> ==> result.log <==
> ok
> 
> --
> Ran 4 tests in 3534.241s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

[DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for launching tests

[Prasanna Santhanam]

I like the concept of a health check before launching tests. But it's
a difficult distinction to make whether to run a specific test because
its required hardware component/external dependency is not
available/not ready in the deployment OR have the test ensure that the
deployment is suitable for its run.

So our current health check only ensures two things
- SystemVMs are up and running
- Default Templates are 'Ready' in the system

Take the example of LDAP here that you quoted. In such a case I'd
prefer that the test itself check for the deployment guarantees
without pushing that to the framework or the deployment scripts to
decipher.

There is a counter case - some tests use the netaddr module to do
subnet arithmetic. For these to run we need to ensure the virtualenv
under which the test module runs contains netaddr. This is something
that can be ensured by the deployment scripts.

So this is a question of guidelines to test authors on what to expect
and what not to expect when writing a test. Also how to have the
dependencies added automatically before the test gets executed. I
don't see a one-size-fits-all solution.

On Mon, Oct 28, 2013 at 05:49:39AM +, Santhosh Kumar Edukulla (JIRA) wrote:
> Santhosh Kumar Edukulla created CLOUDSTACK-4971:
> 
> 1, Currently test scripts are running despite the test setup has
> issues. EX: In one of the test scenario, where ldap server was down,
> then test suite depending upon them was still running. 
> 
> 2, Ideally, the setup should check for these dependencies before
> running the test script and exit wherever possible with proper log
> and reporting .
> 
> 3,  We may not be able to cover all setup issues, but the purpose of
> setup is also to check for its existence and dependencies. If
> scripts depending upon particular server conditions, should have a
> proper setup verifying the server existence before proceeding
> further. 
> 
> 4, I believe running test cases when setup is down is also not
> idealistic. 
> 
> 5. Purpose is to reduce script errors vs failures due to product
> bugs. 
> 
> 6. Logging this bug to track the setup issue cases or script
> failures. 
> 
-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 13735: CLOUDSTACK-4450: Possibility of /tmp/xapilog filling up the Root disk on Xenserver.

[Devdeep Singh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13735/#review27596
---

Ship it!


Ship It!

- Devdeep Singh


On Aug. 22, 2013, 3:45 p.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13735/
> ---
> 
> (Updated Aug. 22, 2013, 3:45 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-4450
> https://issues.apache.org/jira/browse/CLOUDSTACK-4450
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4450: Possibility of /tmp/xapilog filling up the Root disk on 
> Xenserver.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4450
> 
> 
> Diffs
> -
> 
>   scripts/vm/hypervisor/xenserver/hostvmstats.py 38609b1 
> 
> Diff: https://reviews.apache.org/r/13735/diff/
> 
> 
> Testing
> ---
> 
> Verified the fix locally on cloudstack setup with 4.2-forward branch code and 
> Xenserver 6.2.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 14199: Adding missing test cases: Snapshots Improvement

[Girish Shilamkar]

> On Oct. 23, 2013, 8:57 a.m., Prasanna Santhanam wrote:
> > Patch will require few changes before applying to master. Can you please 
> > rebase against latest?

The patch applies cleanly to master.


- Girish


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14199/#review27371
---


On Oct. 28, 2013, 5:53 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14199/
> ---
> 
> (Updated Oct. 28, 2013, 5:53 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and suresh sadhu.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding 5 missing test cases.
> Change in asyncJobMgr.py >> the method "make_request" in cloudstackConnection 
> does not exist now. Replaced it by "marvin_request". Checked running async 
> jobs with this change. Works correctly.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_snapshots_improvement.py PRE-CREATION 
>   tools/marvin/marvin/asyncJobMgr.py 25818a6 
> 
> Diff: https://reviews.apache.org/r/14199/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM Advanced setup.
> 
> test_01_concurrent_snapshots_live_migrate 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test perform concurrent snapshots and migrate the vm from one host ... ok
> test_02_stop_vm_concurrent_snapshots 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test stop running VM while performing concurrent snapshot on volume ... ok
> test_03_concurrent_snapshots_create_template 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test while parent concurrent snapshot job in progress,create ... ok
> test_04_concurrent_snapshots_create_volume 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test while parent concurrent snapshot job in progress,create volume ... ok
> test_01_snapshot_on_rootVolume 
> (test_snapshots_improvement.TestSnapshotOnRootVolume)
> Test create VM with default cent os template and create snapshot ... ok
> 
> --
> Ran 5 tests in 1420.575s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

RE: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for launching tests

[Santhosh Edukulla]

Here, we mean test setup, not marvin setup ( or setup.py ) . 

Each test has their own dependency, we are having setup,flow,teardown for test 
module. By below content of bug description, we mean verifying the test 
dependencies under setup class of a test feature or module not the marvin 
setup. The test feature or module setup can take care to verify these 
dependencies and exit with better log and reporting as against reporting the 
test cases as failures.

Some dependencies at marvin setup can be verified, but the below purpose is to 
ensure test dependencies are met before running tests. The goal is to make less 
or zero % test script errors, against genuine product bugs as failures. 

Santhosh

From: Prasanna Santhanam [t...@apache.org]
Sent: Monday, October 28, 2013 2:15 AM
To: dev@cloudstack.apache.org
Cc: iss...@cloudstack.apache.org
Subject: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for 
launching tests

I like the concept of a health check before launching tests. But it's
a difficult distinction to make whether to run a specific test because
its required hardware component/external dependency is not
available/not ready in the deployment OR have the test ensure that the
deployment is suitable for its run.

So our current health check only ensures two things
- SystemVMs are up and running
- Default Templates are 'Ready' in the system

Take the example of LDAP here that you quoted. In such a case I'd
prefer that the test itself check for the deployment guarantees
without pushing that to the framework or the deployment scripts to
decipher.

There is a counter case - some tests use the netaddr module to do
subnet arithmetic. For these to run we need to ensure the virtualenv
under which the test module runs contains netaddr. This is something
that can be ensured by the deployment scripts.

So this is a question of guidelines to test authors on what to expect
and what not to expect when writing a test. Also how to have the
dependencies added automatically before the test gets executed. I
don't see a one-size-fits-all solution.

On Mon, Oct 28, 2013 at 05:49:39AM +, Santhosh Kumar Edukulla (JIRA) wrote:
> Santhosh Kumar Edukulla created CLOUDSTACK-4971:
>
> 1, Currently test scripts are running despite the test setup has
> issues. EX: In one of the test scenario, where ldap server was down,
> then test suite depending upon them was still running.
>
> 2, Ideally, the setup should check for these dependencies before
> running the test script and exit wherever possible with proper log
> and reporting .
>
> 3,  We may not be able to cover all setup issues, but the purpose of
> setup is also to check for its existence and dependencies. If
> scripts depending upon particular server conditions, should have a
> proper setup verifying the server existence before proceeding
> further.
>
> 4, I believe running test cases when setup is down is also not
> idealistic.
>
> 5. Purpose is to reduce script errors vs failures due to product
> bugs.
>
> 6. Logging this bug to track the setup issue cases or script
> failures.
>
--
Prasanna.,


Powered by BigRock.com

Re: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for launching tests

[Prasanna Santhanam]

On Mon, Oct 28, 2013 at 06:24:05AM +, Santhosh Edukulla wrote:
> Here, we mean test setup, not marvin setup ( or setup.py ) . 

Sure - I understand that :). Marvin's setup is only a build+packaging
file. I should've been clear - when I say deployment scripts those are
the cloud-autodeploy scripts that setup the testbed. Marvin's dumb in
that respect and only comes in when cloudstack is configured and tests
are launched.

> 
> Each test has their own dependency, we are having
> setup,flow,teardown for test module. By below content of bug
> description, we mean verifying the test dependencies under setup
> class of a test feature or module not the marvin setup. The test
> feature or module setup can take care to verify these dependencies
> and exit with better log and reporting as against reporting the test
> cases as failures.

Right - so you're saying you'll change the tests. But as I mentioned
with 'netaddr' it's the problem of the python environment running the
test. The test is free to import 'netaddr' but not install it.

> 
> Some dependencies at marvin setup can be verified, but the below
> purpose is to ensure test dependencies are met before running tests.
> The goal is to make less or zero % test script errors, against
> genuine product bugs as failures. 
> 

Okay - by 'met before running' you mean during deployment or before
test launch? Or as part of the setUpClass? If it is part of the
setUpClass. Isn't that just a guideline to the test case writer?

> Santhosh
> 
> From: Prasanna Santhanam [t...@apache.org]
> Sent: Monday, October 28, 2013 2:15 AM
> To: dev@cloudstack.apache.org
> Cc: iss...@cloudstack.apache.org
> Subject: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for 
> launching tests
> 
> I like the concept of a health check before launching tests. But it's
> a difficult distinction to make whether to run a specific test because
> its required hardware component/external dependency is not
> available/not ready in the deployment OR have the test ensure that the
> deployment is suitable for its run.
> 
> So our current health check only ensures two things
> - SystemVMs are up and running
> - Default Templates are 'Ready' in the system
> 
> Take the example of LDAP here that you quoted. In such a case I'd
> prefer that the test itself check for the deployment guarantees
> without pushing that to the framework or the deployment scripts to
> decipher.
> 
> There is a counter case - some tests use the netaddr module to do
> subnet arithmetic. For these to run we need to ensure the virtualenv
> under which the test module runs contains netaddr. This is something
> that can be ensured by the deployment scripts.
> 
> So this is a question of guidelines to test authors on what to expect
> and what not to expect when writing a test. Also how to have the
> dependencies added automatically before the test gets executed. I
> don't see a one-size-fits-all solution.
> 
> On Mon, Oct 28, 2013 at 05:49:39AM +, Santhosh Kumar Edukulla (JIRA) 
> wrote:
> > Santhosh Kumar Edukulla created CLOUDSTACK-4971:
> >
> > 1, Currently test scripts are running despite the test setup has
> > issues. EX: In one of the test scenario, where ldap server was down,
> > then test suite depending upon them was still running.
> >
> > 2, Ideally, the setup should check for these dependencies before
> > running the test script and exit wherever possible with proper log
> > and reporting .
> >
> > 3,  We may not be able to cover all setup issues, but the purpose of
> > setup is also to check for its existence and dependencies. If
> > scripts depending upon particular server conditions, should have a
> > proper setup verifying the server existence before proceeding
> > further.
> >
> > 4, I believe running test cases when setup is down is also not
> > idealistic.
> >
> > 5. Purpose is to reduce script errors vs failures due to product
> > bugs.
> >
> > 6. Logging this bug to track the setup issue cases or script
> > failures.
> >
> --
> Prasanna.,
> 
> 
> Powered by BigRock.com

-- 
Prasanna.,


Powered by BigRock.com

Re: Intermittent File Access to cloudstack.apt-get.eu

[Wido den Hollander]

On 10/27/2013 11:07 AM, Marty Sweet wrote:

Hi Guys,

During the upgrade process I also kept experiencing the packages needed
disappearing from the cloudstack.apt-get.eu website, this caused multiple
servers to fail on update/install processes only to work several minutes
later once the files had been restored. It's clear the files are changing
regularly on there as their dates are being constantly updated.

I can reproduce this on our production nodes and from a web browser using a
different ISP, this will definitely cause issues with new people to CS and
could be a confusing first hurdle for some.

http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.2/

Has anyone else experienced these issues? Just refresh the directory a few
times today and see when files appear/disappear.



Hmm, that's odd. I maintain that server and there is a script which 
re-indexes all packages, but it should re-index what is already there.


I'll check on this.

Wido


Thanks,
Marty