date:20131027

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

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)

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 shadow...@gmail.com
To: dev@cloudstack.apache.org
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 msweet@gmail.com 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 shadow...@gmail.com
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 msweet@gmail.com 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 image.

I also note that the new systemvms don't seem to be mounting the NFS
and
are instead using /usr/share/cloudstack-common/vms/systemvm.iso.

Opening a

Re: Migrating/managing secondary storages

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,  mailingli...@isg.si 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

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 daan.hoogl...@gmail.comwrote:

 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 msweet@gmail.com 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 daan.hoogl...@gmail.com
  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 msweet@gmail.com
  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

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 nsla...@apache.org 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)

2013-10-27 Thread 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 msweet@gmail.com
To: dev@cloudstack.apache.org 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 shadow...@gmail.com
 To: dev@cloudstack.apache.org
 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 msweet@gmail.com 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 shadow...@gmail.com
  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 msweet@gmail.com 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

Re: Mailing list search

2013-10-27 Thread 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

2013-10-27 Thread 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

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

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

Re: Mailing list search

2013-10-27 Thread 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 daan.hoogl...@gmail.com wrote:

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

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

Re: Mailing list search

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 i...@ianduffy.ie 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 daan.hoogl...@gmail.com wrote:

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

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

Re: Tiered Quality

2013-10-27 Thread 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

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

2013-10-27 Thread 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 laszlo.horn...@gmail.com 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

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

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

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

2013-10-27 Thread 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

2013-10-27 Thread 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 laszlo.horn...@gmail.com
 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

2013-10-27 Thread 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

2013-10-27 Thread 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-user2apiKey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WAcommand=assignVirtualMachinedomainid=cfc19b03-0858-4f39-9058-e0b67685bc2fresponse=jsonvirtualmachineid=939f1c53-91e8-47a1-92d1-9ec9c2c1802csignature=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.twhttps://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.URL=mailto%3aryanlei%40cht.com.tw
or
ryanlei750...@gmail.com



On Fri, Oct 25, 2013 at 7:02 PM, Rohit Yadav bhais...@apache.org 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 ryan...@cht.com.tw 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 module
  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)
File /usr/lib64/python2.6/cmd.py, line 219, in onecmd
  return func(arg)
File
 
 
 /usr/lib/python2.6/site-packages/cloudmonkey-5.0.0-py2.6.egg/cloudmonkey/cloudmonkey.py,
  line 134, in

Migrate from existing xenserver pool into cloudstack

2013-10-27 Thread 王健

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

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

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 laszlo.horn...@gmail.com
  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

2013-10-27 Thread 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

2013-10-27 Thread 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

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


---
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


---
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


---
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