Re: Guidelines for test developers

[Srikanteswararao Talluri]

Thanks Gaurav for putting up this guidelines page. Good work!

~Talluri

On 19/03/15 10:59 am, "Gaurav Aradhye"  wrote:

>I have added Wiki page for this in QA section.
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Guidelines+for+test
>+developers
>
>Not a very polished one, but I will be adding and polishing it soon.
>
>Regards,
>Gaurav
>
>On Thu, Mar 19, 2015 at 9:52 AM, Gaurav Aradhye
>
>wrote:
>
>> Paul,
>>
>> Some pages on wiki talk about general guidelines to Dev, but there is no
>> page stating detailed guidelines for test developers.
>> I would like to add a new page in QA section for this. Will drop
>>separate
>> mail for write access to wiki.
>>
>> Daan,
>>
>> I will have to check on this. I will find out how we can include static
>> analysis for tests similar to that it is in place for dev code
>>(findbugs).
>>
>> Regards,
>> Gaurav
>>
>> On Wed, Mar 18, 2015 at 8:22 PM, Daan Hoogland 
>> wrote:
>>
>>> good write-up Gaurav, I hope that most of these can be
>>> validated/verified checkstyle-style. pep8 can of course. Some others
>>> must remain judged by humanoids, like the one where functions are
>>> pulled up to higher abstraction layers. Maybe you could shine your
>>> light on what we can automate? i.e. can pyflakes be added to a target?
>>>
>>> > -Original Message-
>>> > From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com]
>>> > Sent: 18 March 2015 07:16
>>> > To: dev@cloudstack.apache.org
>>> > Subject: Guidelines for test developers
>>> >
>>> > Hello all,
>>> >
>>> > Last year after improving Marvin framework, we have been continuously
>>> spending time in improving old test cases which are written in old
>>>style or
>>> they don't abide to certain guidelines, also which don't use new
>>>functions
>>> available in marvin. Many times a test developer who is adding test
>>>case
>>> for the first time or feature developers adding Basic Validation Tests
>>> > (BVTs) tend to copy paste the code available in certain test case and
>>> try to modify it according to feature and commit it. This adds to
>>> inconsistencies.
>>> >
>>> > As and when I touch a file for fixing an issue or adding/editing it,
>>>I
>>> try to incorporate below guidelines and improve the existing code. But
>>> still few test files are not up to the mark. Our final goal is to have
>>>good
>>> code in every file.So writing this mail to consolidate few rules that
>>> should be known/considered by everyone adding tests to Marvin. Also,
>>>if you
>>> touch a file, feel free to remove any inconsistencies that are already
>>> present in the file.
>>> >
>>> > *1. Import * should always be avoided*. When I started two years
>>>back,
>>> and tried to understand the code flow/ test cases, I could not easily
>>> understand from where the particular module is imported. The imports
>>>must
>>> be specific.
>>> >
>>> > When the imports are specific, it eliminates the possibility of test
>>> case failure due to invalid import when specific import is removed from
>>> dependent module.
>>> >
>>> > E.g. If your test case has following import.
>>> >
>>> > from A import *
>>> >
>>> > And it uses time module which is not imported explicitly in test case
>>> and comes from module A. Then the test case will start failing when
>>>"import
>>> time"is removed from module A. You certainly don't want this to happen.
>>> >
>>> > *2. Maintaining Pep8 standards for python code.*
>>> >
>>> > The code is read more often that it is written. Pep8 standards
>>>improve
>>> the readability of the code making it consistent in style. There is a
>>>tool
>>> named "*autopep8*" which you can install with pip install and then you
>>>can
>>> run following command on your test file.
>>> >
>>> > autopep8 -i -a -a testFile.py
>>> >
>>> > This will make the file pep8 consistent and will also remove the
>>>white
>>> spaces. But some issues need human intervention and can't be fixed with
>>> tool. For fixing those, check the pep8 issues with "pep8 testFile.py"
>>>and
>>> fix manually.
>>> >
>>> > *3. Keep only imports which are used* in the test suite and remove
>>> unwanted imports.
>>> >
>>> > *4. Keep all the configuration parameters* (such as data which is
>>> passed to API while creating Network offering, Service offering,
>>>account
>>> etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't
>>>include
>>> them in test suite itself.
>>> >
>>> > Many of the dictionaries are reusable and if you are adding a new
>>>test,
>>> there are only a few dictionaries you will have to add in the file.
>>> >
>>> > If any of the data contains URLs or any data which should be changed
>>> according to setup/env, then include the dict in "*configurableData*"
>>> > section in test_data.py file. This makes it easier to identify which
>>> data needs to be dynamic according to the setup and which data doesn't
>>>need
>>> to be touched when env is changed.
>>> >
>>> > *5. Before committing a test case, run it* with the latest branch
>>> against which you are ad

Re: Review Request 28437: CLOUDSTACK-6282 Added automated ACL tests

[anusha bilgi]

> On March 16, 2015, 8:46 a.m., Gaurav Aradhye wrote:
> > test/integration/component/test_escalations_networks.py, line 20
> > 
> >
> > Please remvoe all import *

Hi,

I have made the changes and uploaded the same.
Could you review this.

Thanks,
Anusha


- anusha


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


On March 16, 2015, 10:25 a.m., anusha bilgi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28437/
> ---
> 
> (Updated March 16, 2015, 10:25 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: cloudstack-6282
> https://issues.apache.org/jira/browse/cloudstack-6282
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6282 Added automated ACL tests
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_networks.py fb2196c 
> 
> Diff: https://reviews.apache.org/r/28437/diff/
> 
> 
> Testing
> ---
> 
> Tests the changed files and attached are the results for the same
> 
> 
> File Attachments
> 
> 
> results.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/25/61351189-70e9-4fa6-8bcf-035d28fa61e6__results.txt
> 
> 
> Thanks,
> 
> anusha bilgi
> 
>

Build failed in Jenkins: build-master-jdk18 #6

[jenkins]

See 

Changes:

[talluri] CLOUDSTACK-8236: Automation for storage migration test path

[talluri] CLOUDSTACK-8286: Adding Basic validation test case to test deploying 
VM from ISO and correcting old regression test case to test HA VM from ISO

[talluri] fixed license header

[talluri] CLOUDSTACK-8290: Adding BVT to verofy product issue

[Rohit Yadav] hypervisors: add OVM3 plugin that supports OVM 3.2.1/3.3.x

[likitha.shetty] CLOUDSTACK-8318. Storage vMotion support for VMFS.

[likitha.shetty] CLOUDSTACK-8319. For both 'MigrateVolume' and 
'MigrateVMWithVolumes, ensure VM's vconfiguration files are migrated along with 
VM's root volume.

[likitha.shetty] CLOUDSTACK-8320. Upon a failed migration, a dummy volume is 
created which remains in 'Expunging' state.

[Rohit Yadav] engine: Add Upgrade path from 4.5.0 to 4.5.1

[Rohit Yadav] CLOUDSTACK-8272: Python based file-lock free password server 
implementation

[Rohit Yadav] ovm3: fix rat license, use license header that satisfies RAT

[Rohit Yadav] CLOUDSTACK-8236: Automation test cases for storage migration test 
path review changes

[Rohit Yadav] CLOUDSTACK-8314: Add test case to validate VM.DESTROY event is 
logged when VM deployment fails

[Rohit Yadav] CLOUDSTACK-8311: Adding test case to confirm Volume Snapshot for 
root disk is

[Rohit Yadav] README: tell the world we've OVM power :fist:

[Rohit Yadav] CLOUDSTACK-8323: Adding BVT to test NIC Adapter for Vmware

[sanjay.tripathi] Fixed simulator and vmware NPE issue.

[Rohit Yadav] Fix encoding for user account label in header

[Rohit Yadav] Error message exposes domain Id when deployVirtualMachine() is 
attempted on a shared network to which the user doesnot have access to.

[Rohit Yadav] CS-20680: The user's secret key is not encrypted in the 
UserCredentialsVO class

[Rohit Yadav] CS-19734:Session cookie is exposed to scripts.

[Rohit Yadav] CS-18149: UI - no longer store sessionKey in cookie. After

[Rohit Yadav] CS-17504: Weak SSL ciphers supported by the management server

[Rohit Yadav] Avoid distributing private key for realhostip.com

[Rohit Yadav] Avoid logging password when adding srx device

[Rohit Yadav] ui: if session cookie exists, use it to set global session holder 
and invalidate it

[Rohit Yadav] utils: use a better extended implementation of SSLSocketFactory

[Rajani Karuturi] CLOUDSTACK-7348 InvalidParameter Exception while executing 
scale vm.

[Rajani Karuturi] CLOUDSTACK-5236 : ability to identify where the user is from 
(ex. LDAP)

[Rohit Yadav] user-authenticators: don't allow empty usernames or passwords

[wrodrigues] CLOUDSTACK-7143: a better fix for kernel upgrade disk space 
problems

[wrodrigues] Make sure the location for the persistant configs exists

[wrodrigues] Switch ip associations to the new config file system

[wrodrigues] Removed useless array from SetStaticRoutesCmd.

[wrodrigues] Cherry-pick of 11c00977f77f45aa7b0c387dc88360eba0819e8a:

[wrodrigues] This file isn't used, so remove it

[wrodrigues] Add a placeholder for the trigger file

[wrodrigues] Vagrant virtualbox based testing suite

[wrodrigues] Added curl to the base install

[wrodrigues] Merged cookbooks from vpc branch

[wrodrigues] Remove scripts directory no longer necessary

[wrodrigues] Replace CreateGuestNetwork config script with a json file.

[wrodrigues] Tuning/reformatting/defensible-ing Vagrantfile

[wrodrigues] Add the Python bits

[wrodrigues] Added cs_ip module

[wrodrigues] Use json naming standards instead of camelCase

[wrodrigues] Changed from camelCase to json_case

[wrodrigues] Create a json file for SetNetworkACL

[wrodrigues] Only ip_association files for now

[wrodrigues] Can now read the ips out of the cmdline databag (if present)

[wrodrigues] Correct small typo in error message

[wrodrigues] Remove debug code

[wrodrigues] Include a type field in all json configuration objects

[wrodrigues] Switch ip associations to new model and update the recipes

[wrodrigues] Disable cmdline check until it's fixed

[wrodrigues] 1.  Completed provider for ip rules (fwmark)

[wrodrigues] Corrected a hole in my logic

[wrodrigues] Rewrite networkacl model to have separate entries for each rule

[wrodrigues] Add some debug logging to keep track of timing

[wrodrigues] Change vmdata to the new config system

[wrodrigues] A working test-kitchen setup for testing systemvm boxes.

[wrodrigues] Include the guestnetwork code

[wrodrigues] Split Databag in to separate class as I would now need this

[wrodrigues] junit report output for vagrant systemvm tests

[wrodrigues] Use bundler to exec test-kitchen

[wrodrigues] Commit missing .kitchen.yml

[wrodrigues] Massively simpler serverspec invocation

[wrodrigues] Missing gem for vagrant magic

[wrodrigues] Documentation and license headers for new systemvm testing tools.

[wrodrigues] Plan B

[wrodrigues] Test data for ipassociation

[wrodrigues] Added some lost lines back using Hugo witchcr

Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature

[Avinash Gautam]

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

(Updated March 19, 2015, 5:52 a.m.)


Review request for cloudstack and Santhosh Edukulla.


Changes
---

Modified tests and incorporated changes.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6282 - Added automated tests for filter feature


Diffs (updated)
-

  test/integration/component/test_escalations_ipaddresses.py c60c5b6 
  test/integration/component/test_escalations_vpncustomergateways.py b09930a 

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


Testing
---

Tested all the files to which tests are added and atatched are the result files


File Attachments


IPAddressresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt
ISOresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt
Networksresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt
SecurityGroupsresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt
Snapshotresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt
Templatesresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt
Volumeresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt
VPNCustomerGatewaysresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt


Thanks,

Avinash Gautam

Re: Guidelines for test developers

[Gaurav Aradhye]

I have added Wiki page for this in QA section.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Guidelines+for+test+developers

Not a very polished one, but I will be adding and polishing it soon.

Regards,
Gaurav

On Thu, Mar 19, 2015 at 9:52 AM, Gaurav Aradhye 
wrote:

> Paul,
>
> Some pages on wiki talk about general guidelines to Dev, but there is no
> page stating detailed guidelines for test developers.
> I would like to add a new page in QA section for this. Will drop separate
> mail for write access to wiki.
>
> Daan,
>
> I will have to check on this. I will find out how we can include static
> analysis for tests similar to that it is in place for dev code (findbugs).
>
> Regards,
> Gaurav
>
> On Wed, Mar 18, 2015 at 8:22 PM, Daan Hoogland 
> wrote:
>
>> good write-up Gaurav, I hope that most of these can be
>> validated/verified checkstyle-style. pep8 can of course. Some others
>> must remain judged by humanoids, like the one where functions are
>> pulled up to higher abstraction layers. Maybe you could shine your
>> light on what we can automate? i.e. can pyflakes be added to a target?
>>
>> > -Original Message-
>> > From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com]
>> > Sent: 18 March 2015 07:16
>> > To: dev@cloudstack.apache.org
>> > Subject: Guidelines for test developers
>> >
>> > Hello all,
>> >
>> > Last year after improving Marvin framework, we have been continuously
>> spending time in improving old test cases which are written in old style or
>> they don't abide to certain guidelines, also which don't use new functions
>> available in marvin. Many times a test developer who is adding test case
>> for the first time or feature developers adding Basic Validation Tests
>> > (BVTs) tend to copy paste the code available in certain test case and
>> try to modify it according to feature and commit it. This adds to
>> inconsistencies.
>> >
>> > As and when I touch a file for fixing an issue or adding/editing it, I
>> try to incorporate below guidelines and improve the existing code. But
>> still few test files are not up to the mark. Our final goal is to have good
>> code in every file.So writing this mail to consolidate few rules that
>> should be known/considered by everyone adding tests to Marvin. Also, if you
>> touch a file, feel free to remove any inconsistencies that are already
>> present in the file.
>> >
>> > *1. Import * should always be avoided*. When I started two years back,
>> and tried to understand the code flow/ test cases, I could not easily
>> understand from where the particular module is imported. The imports must
>> be specific.
>> >
>> > When the imports are specific, it eliminates the possibility of test
>> case failure due to invalid import when specific import is removed from
>> dependent module.
>> >
>> > E.g. If your test case has following import.
>> >
>> > from A import *
>> >
>> > And it uses time module which is not imported explicitly in test case
>> and comes from module A. Then the test case will start failing when "import
>> time"is removed from module A. You certainly don't want this to happen.
>> >
>> > *2. Maintaining Pep8 standards for python code.*
>> >
>> > The code is read more often that it is written. Pep8 standards improve
>> the readability of the code making it consistent in style. There is a tool
>> named "*autopep8*" which you can install with pip install and then you can
>> run following command on your test file.
>> >
>> > autopep8 -i -a -a testFile.py
>> >
>> > This will make the file pep8 consistent and will also remove the white
>> spaces. But some issues need human intervention and can't be fixed with
>> tool. For fixing those, check the pep8 issues with "pep8 testFile.py" and
>> fix manually.
>> >
>> > *3. Keep only imports which are used* in the test suite and remove
>> unwanted imports.
>> >
>> > *4. Keep all the configuration parameters* (such as data which is
>> passed to API while creating Network offering, Service offering, account
>> etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include
>> them in test suite itself.
>> >
>> > Many of the dictionaries are reusable and if you are adding a new test,
>> there are only a few dictionaries you will have to add in the file.
>> >
>> > If any of the data contains URLs or any data which should be changed
>> according to setup/env, then include the dict in "*configurableData*"
>> > section in test_data.py file. This makes it easier to identify which
>> data needs to be dynamic according to the setup and which data doesn't need
>> to be touched when env is changed.
>> >
>> > *5. Before committing a test case, run it* with the latest branch
>> against which you are adding the test case and attach the results in Pull
>> Request.
>> > If in case change is very small, and doesn't need to be run, then at
>> least check syntactical errors with python command and also with the help
>> of tools such as pyflakes.
>> >
>> > 6. If you add a new function in your tes

Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature

[Gaurav Aradhye]

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


Please close the fixed issues.

- Gaurav Aradhye


On March 19, 2015, 10:38 a.m., Avinash Gautam wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27611/
> ---
> 
> (Updated March 19, 2015, 10:38 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6282
> https://issues.apache.org/jira/browse/CLOUDSTACK-6282
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6282 - Added automated tests for filter feature
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_ipaddresses.py c60c5b6 
>   test/integration/component/test_escalations_isos.py 4e818a5 
>   test/integration/component/test_escalations_networks.py fb2196c 
>   test/integration/component/test_escalations_volumes.py 58f5845 
>   test/integration/component/test_escalations_vpncustomergateways.py b09930a 
> 
> Diff: https://reviews.apache.org/r/27611/diff/
> 
> 
> Testing
> ---
> 
> Tested all the files to which tests are added and atatched are the result 
> files
> 
> 
> File Attachments
> 
> 
> IPAddressresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt
> ISOresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt
> Networksresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt
> SecurityGroupsresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt
> Snapshotresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt
> Templatesresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt
> Volumeresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt
> VPNCustomerGatewaysresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt
> 
> 
> Thanks,
> 
> Avinash Gautam
> 
>

Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature

[Gaurav Aradhye]

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



test/integration/component/test_escalations_ipaddresses.py


Please remove white-spaces.



test/integration/component/test_escalations_vpncustomergateways.py


Please fix pep8 issues


- Gaurav Aradhye


On March 19, 2015, 10:38 a.m., Avinash Gautam wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27611/
> ---
> 
> (Updated March 19, 2015, 10:38 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6282
> https://issues.apache.org/jira/browse/CLOUDSTACK-6282
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6282 - Added automated tests for filter feature
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_ipaddresses.py c60c5b6 
>   test/integration/component/test_escalations_isos.py 4e818a5 
>   test/integration/component/test_escalations_networks.py fb2196c 
>   test/integration/component/test_escalations_volumes.py 58f5845 
>   test/integration/component/test_escalations_vpncustomergateways.py b09930a 
> 
> Diff: https://reviews.apache.org/r/27611/diff/
> 
> 
> Testing
> ---
> 
> Tested all the files to which tests are added and atatched are the result 
> files
> 
> 
> File Attachments
> 
> 
> IPAddressresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt
> ISOresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt
> Networksresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt
> SecurityGroupsresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt
> Snapshotresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt
> Templatesresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt
> Volumeresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt
> VPNCustomerGatewaysresults.txt
>   
> https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt
> 
> 
> Thanks,
> 
> Avinash Gautam
> 
>

Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature

[Avinash Gautam]

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

(Updated March 19, 2015, 5:08 a.m.)


Review request for cloudstack and Santhosh Edukulla.


Changes
---

Modified the tests and incorporated the review comments.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6282 - Added automated tests for filter feature


Diffs (updated)
-

  test/integration/component/test_escalations_ipaddresses.py c60c5b6 
  test/integration/component/test_escalations_isos.py 4e818a5 
  test/integration/component/test_escalations_networks.py fb2196c 
  test/integration/component/test_escalations_volumes.py 58f5845 
  test/integration/component/test_escalations_vpncustomergateways.py b09930a 

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


Testing
---

Tested all the files to which tests are added and atatched are the result files


File Attachments


IPAddressresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt
ISOresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt
Networksresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt
SecurityGroupsresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt
Snapshotresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt
Templatesresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt
Volumeresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt
VPNCustomerGatewaysresults.txt
  
https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt


Thanks,

Avinash Gautam

Re: Require write/edit access to Cloudstack wiki

[Gaurav Aradhye]

Thanks Rajani.

Regards,
Gaurav

On Thu, Mar 19, 2015 at 10:05 AM, Rajani Karuturi  wrote:

> done
>
> ~Rajani
>
> On Thu, Mar 19, 2015 at 9:53 AM, Gaurav Aradhye <
> gaurav.arad...@clogeny.com>
> wrote:
>
> > I would like to add a page to wiki stating "Guidelines for test
> > developers". Can somebody give me access? My username is aradhye.gaurav
> >
> > Regards,
> > Gaurav
> >
>

Re: Require write/edit access to Cloudstack wiki

[Rajani Karuturi]

done

~Rajani

On Thu, Mar 19, 2015 at 9:53 AM, Gaurav Aradhye 
wrote:

> I would like to add a page to wiki stating "Guidelines for test
> developers". Can somebody give me access? My username is aradhye.gaurav
>
> Regards,
> Gaurav
>

Require write/edit access to Cloudstack wiki

[Gaurav Aradhye]

I would like to add a page to wiki stating "Guidelines for test
developers". Can somebody give me access? My username is aradhye.gaurav

Regards,
Gaurav

Re: Guidelines for test developers

[Gaurav Aradhye]

Paul,

Some pages on wiki talk about general guidelines to Dev, but there is no
page stating detailed guidelines for test developers.
I would like to add a new page in QA section for this. Will drop separate
mail for write access to wiki.

Daan,

I will have to check on this. I will find out how we can include static
analysis for tests similar to that it is in place for dev code (findbugs).

Regards,
Gaurav

On Wed, Mar 18, 2015 at 8:22 PM, Daan Hoogland 
wrote:

> good write-up Gaurav, I hope that most of these can be
> validated/verified checkstyle-style. pep8 can of course. Some others
> must remain judged by humanoids, like the one where functions are
> pulled up to higher abstraction layers. Maybe you could shine your
> light on what we can automate? i.e. can pyflakes be added to a target?
>
> > -Original Message-
> > From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com]
> > Sent: 18 March 2015 07:16
> > To: dev@cloudstack.apache.org
> > Subject: Guidelines for test developers
> >
> > Hello all,
> >
> > Last year after improving Marvin framework, we have been continuously
> spending time in improving old test cases which are written in old style or
> they don't abide to certain guidelines, also which don't use new functions
> available in marvin. Many times a test developer who is adding test case
> for the first time or feature developers adding Basic Validation Tests
> > (BVTs) tend to copy paste the code available in certain test case and
> try to modify it according to feature and commit it. This adds to
> inconsistencies.
> >
> > As and when I touch a file for fixing an issue or adding/editing it, I
> try to incorporate below guidelines and improve the existing code. But
> still few test files are not up to the mark. Our final goal is to have good
> code in every file.So writing this mail to consolidate few rules that
> should be known/considered by everyone adding tests to Marvin. Also, if you
> touch a file, feel free to remove any inconsistencies that are already
> present in the file.
> >
> > *1. Import * should always be avoided*. When I started two years back,
> and tried to understand the code flow/ test cases, I could not easily
> understand from where the particular module is imported. The imports must
> be specific.
> >
> > When the imports are specific, it eliminates the possibility of test
> case failure due to invalid import when specific import is removed from
> dependent module.
> >
> > E.g. If your test case has following import.
> >
> > from A import *
> >
> > And it uses time module which is not imported explicitly in test case
> and comes from module A. Then the test case will start failing when "import
> time"is removed from module A. You certainly don't want this to happen.
> >
> > *2. Maintaining Pep8 standards for python code.*
> >
> > The code is read more often that it is written. Pep8 standards improve
> the readability of the code making it consistent in style. There is a tool
> named "*autopep8*" which you can install with pip install and then you can
> run following command on your test file.
> >
> > autopep8 -i -a -a testFile.py
> >
> > This will make the file pep8 consistent and will also remove the white
> spaces. But some issues need human intervention and can't be fixed with
> tool. For fixing those, check the pep8 issues with "pep8 testFile.py" and
> fix manually.
> >
> > *3. Keep only imports which are used* in the test suite and remove
> unwanted imports.
> >
> > *4. Keep all the configuration parameters* (such as data which is passed
> to API while creating Network offering, Service offering, account etc...)
> *in tools/marvin/marvin/config/test_data.py file*. Don't include them in
> test suite itself.
> >
> > Many of the dictionaries are reusable and if you are adding a new test,
> there are only a few dictionaries you will have to add in the file.
> >
> > If any of the data contains URLs or any data which should be changed
> according to setup/env, then include the dict in "*configurableData*"
> > section in test_data.py file. This makes it easier to identify which
> data needs to be dynamic according to the setup and which data doesn't need
> to be touched when env is changed.
> >
> > *5. Before committing a test case, run it* with the latest branch
> against which you are adding the test case and attach the results in Pull
> Request.
> > If in case change is very small, and doesn't need to be run, then at
> least check syntactical errors with python command and also with the help
> of tools such as pyflakes.
> >
> > 6. If you add a new function in your test case and you think it can be
> used in future by other test cases, then please *add that function to
> common or utils file* in Marvin. Don't keep it local to test case. This
> will prevent multiple contributors adding same functions in their test case
> to achieve a particular goal.
> >
> > *7. Please make sure all the resources created through the test cases
> are deleted *when test case e

Build failed in Jenkins: simulator-4.5-singlerun #180

[jenkins]

See 

Changes:

[Rohit Yadav] CLOUDSTACK-7639: make cidrlist update when updateNetworkAclItem 
is called

[Rohit Yadav] CLOUDSTACK-7639: make cidr updation more efficient

[Rohit Yadav] systemvm: avoid tcp responses with timestamp

[Rohit Yadav] systemvm: correct sftp subsystem path of debian wheezy

[Rohit Yadav] scripts: add ip set interface up because in CentOS7 the interface 
will not auto up

[Rohit Yadav] CLOUDSTACK-8312: The storage usage of "Primary Storage Allocated" 
is incorrect.

[Rohit Yadav] CLOUDSTACK-8304: disable snapshots from non-snapshot repositories

[Rohit Yadav] systemvms: use Debian http redirector for apt repos

[Rohit Yadav] api: avoid sending sensitive data in api response

[Rohit Yadav] CLOUDSTACK-8315: CS API listVMSnapshot doesn't have tags 
‘project’ and ‘projectid’.

[Rohit Yadav] server: remove unused import in ImageStoreJoinDaoImpl

[Rohit Yadav] Update pom and version usage to 4.5.1-SNAPSHOT

[Rohit Yadav] engine: Add Upgrade path from 4.5.0 to 4.5.1

[Rohit Yadav] CLOUDSTACK-8272: Python based file-lock free password server 
implementation

[Rohit Yadav] Fix encoding for user account label in header

[Rohit Yadav] Error message exposes domain Id when deployVirtualMachine() is 
attempted on a shared network to which the user doesnot have access to.

[Rohit Yadav] CS-20680: The user's secret key is not encrypted in the 
UserCredentialsVO class

[Rohit Yadav] CS-19734:Session cookie is exposed to scripts.

[Rohit Yadav] CS-18149: UI - no longer store sessionKey in cookie. After

[Rohit Yadav] CS-17504: Weak SSL ciphers supported by the management server

[Rohit Yadav] Avoid distributing private key for realhostip.com

[Rohit Yadav] Avoid logging password when adding srx device

[Rohit Yadav] ui: if session cookie exists, use it to set global session holder 
and invalidate it

[Rohit Yadav] utils: use a better extended implementation of SSLSocketFactory

[Rajani Karuturi] CLOUDSTACK-7348 InvalidParameter Exception while executing 
scale vm.

[Rajani Karuturi] CLOUDSTACK-5236 : ability to identify where the user is from 
(ex. LDAP)

[Rohit Yadav] user-authenticators: don't allow empty usernames or passwords

[w.zhou] UI: Fix typo in ui/scripts/configuration.js

[w.zhou] CLOUDSTACK-8329: CloudStack accepts IP ends with dot

[Rajani Karuturi] Fixed build failure due to commit 
843f6b16914159ea6241c6c1a0a04e9d0fefaed4

[Rohit Yadav] savepassword: use eth0's IP address, as password listens on that 
IP

[Rohit Yadav] CLOUDSTACK-8331: savepassword should try all IPs on eth0

[Rohit Yadav] vpc_passwd_server: use the improved Python based password server

[Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces

--
[...truncated 8858 lines...]
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 

 to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.1-SNAPSHOT/cloud-developer-4.5.1-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 2:03.730s
[INFO] Finished at: Wed Mar 18 23:56:13 EDT 2015
[INFO] Final Memory: 42M/190M
[INFO] 
[WARNING] The requested profile "simulator" could not be activated because it 
does not exist.
[simulator-4.5-singlerun] $ mvn -P developer -pl developer -Ddeploydb-simulator
[INFO] Scanning for projects...
[INFO] 
[INFO

Re: junkins

[Rajani Karuturi]

Thanks Pierre-Luc

~Rajani

On Thu, Mar 19, 2015 at 8:50 AM, Pierre-Luc Dion  wrote:

> I've  fixed the slave msaz-slave-01 so it can build centos7 rpms and add
> the label cloudstack-buildslave-centos6 to coohq-slave-01.
> coohq-slave-01 run Ubuntu 14.04 I hope it does not affect something.
>
> some build jobs are back to green.
>
>
> On Wed, Mar 18, 2015 at 11:53 AM, Ian Southam  >
> wrote:
>
> > Daan,
> > On 17 Mar 2015, at 12:23, Daan Hoogland  > daan.hoogl...@gmail.com>> wrote:
> >
> > Laszlo, I don't think anyone is working on this. Jenkins output is
> > largely ignored in this community. The fact that the present cause is
> > a resource problem is worrying. I think these are SBP hosted slaves
> > and will have a look (not in the office now). If I fix this the
> > slowbuild will not work at least. The last time I saw it passing by it
> > had 6 new unattended issues from the findbugs output. Coverity
> > complained about new issues as well, i noticed just now.
> >
> > Do I have access to these boxes?  Quite happy to have a look.
> >
> > —
> > Ian
> >
>

Build failed in Jenkins: package-rhel63-4.5 #212

[jenkins]

See 

Changes:

[Rohit Yadav] CLOUDSTACK-7639: make cidrlist update when updateNetworkAclItem 
is called

[Rohit Yadav] CLOUDSTACK-7639: make cidr updation more efficient

[Rohit Yadav] systemvm: avoid tcp responses with timestamp

[Rohit Yadav] systemvm: correct sftp subsystem path of debian wheezy

[Rohit Yadav] scripts: add ip set interface up because in CentOS7 the interface 
will not auto up

[Rohit Yadav] CLOUDSTACK-8312: The storage usage of "Primary Storage Allocated" 
is incorrect.

[Rohit Yadav] CLOUDSTACK-8304: disable snapshots from non-snapshot repositories

[Rohit Yadav] systemvms: use Debian http redirector for apt repos

[Rohit Yadav] api: avoid sending sensitive data in api response

[Rohit Yadav] CLOUDSTACK-8315: CS API listVMSnapshot doesn't have tags 
���project��� and ���projectid���.

[Rohit Yadav] server: remove unused import in ImageStoreJoinDaoImpl

[Rohit Yadav] Update pom and version usage to 4.5.1-SNAPSHOT

[Rohit Yadav] engine: Add Upgrade path from 4.5.0 to 4.5.1

[Rohit Yadav] CLOUDSTACK-8272: Python based file-lock free password server 
implementation

[Rohit Yadav] Fix encoding for user account label in header

[Rohit Yadav] Error message exposes domain Id when deployVirtualMachine() is 
attempted on a shared network to which the user doesnot have access to.

[Rohit Yadav] CS-20680: The user's secret key is not encrypted in the 
UserCredentialsVO class

[Rohit Yadav] CS-19734:Session cookie is exposed to scripts.

[Rohit Yadav] CS-18149: UI - no longer store sessionKey in cookie. After

[Rohit Yadav] CS-17504: Weak SSL ciphers supported by the management server

[Rohit Yadav] Avoid distributing private key for realhostip.com

[Rohit Yadav] Avoid logging password when adding srx device

[Rohit Yadav] ui: if session cookie exists, use it to set global session holder 
and invalidate it

[Rohit Yadav] utils: use a better extended implementation of SSLSocketFactory

[Rajani Karuturi] CLOUDSTACK-7348 InvalidParameter Exception while executing 
scale vm.

[Rajani Karuturi] CLOUDSTACK-5236 : ability to identify where the user is from 
(ex. LDAP)

[Rohit Yadav] user-authenticators: don't allow empty usernames or passwords

[w.zhou] UI: Fix typo in ui/scripts/configuration.js

[w.zhou] CLOUDSTACK-8329: CloudStack accepts IP ends with dot

[Rajani Karuturi] Fixed build failure due to commit 
843f6b16914159ea6241c6c1a0a04e9d0fefaed4

[Rohit Yadav] savepassword: use eth0's IP address, as password listens on that 
IP

[Rohit Yadav] CLOUDSTACK-8331: savepassword should try all IPs on eth0

[Rohit Yadav] vpc_passwd_server: use the improved Python based password server

[Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces

--
[...truncated 7471 lines...]
[INFO] Total time: 16:01.738s
[INFO] Finished at: Wed Mar 18 23:39:28 EDT 2015
[INFO] Final Memory: 82M/286M
[INFO] 
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IyCKPj
+ umask 022
+ cd 

+ '[' 

 '!=' / ']'
+ rm -rf 

++ dirname 

+ mkdir -p 

+ mkdir 

+ cd cloudstack-4.5.1-SNAPSHOT
+ LANG=C
+ export LANG
+ unset DISPLAY
+ '[' 

 '!=' / ']'
+ rm -rf 

+ mkdir -p 

+ mkdir -p 

+ mkdir -p 

+ mkdir -p 

+ mkdir -p 

+ mkdir -p 

Jenkins build is back to normal : build-4.5-simulator #226

[jenkins]

See 

Jenkins build is back to normal : build-4.5-noredist #225

[jenkins]

See 

Build failed in Jenkins: build-4.5-simulator #225

[jenkins]

See 

--
Started by upstream project "build-4.5" build number 406
originally caused by:
 Started by user Pierre-Luc Dion
[EnvInject] - Loading node environment variables.
Building remotely on coohq-slave-01 (cloudstack-buildslave-centos6 
systemvmbuilder) in workspace 

Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git init 
 >  # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
hudson.AbortException: No test report files were found. Configuration error?
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to coohq-slave-01(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:970)
at hudson.FilePath.act(FilePath.java:959)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at 
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1784)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)

Jenkins build is back to normal : build-4.5 #406

[jenkins]

See 

Re: junkins

[Pierre-Luc Dion]

I've  fixed the slave msaz-slave-01 so it can build centos7 rpms and add
the label cloudstack-buildslave-centos6 to coohq-slave-01.
coohq-slave-01 run Ubuntu 14.04 I hope it does not affect something.

some build jobs are back to green.


On Wed, Mar 18, 2015 at 11:53 AM, Ian Southam 
wrote:

> Daan,
> On 17 Mar 2015, at 12:23, Daan Hoogland  daan.hoogl...@gmail.com>> wrote:
>
> Laszlo, I don't think anyone is working on this. Jenkins output is
> largely ignored in this community. The fact that the present cause is
> a resource problem is worrying. I think these are SBP hosted slaves
> and will have a look (not in the office now). If I fix this the
> slowbuild will not work at least. The last time I saw it passing by it
> had 6 new unattended issues from the findbugs output. Coverity
> complained about new issues as well, i noticed just now.
>
> Do I have access to these boxes?  Quite happy to have a look.
>
> —
> Ian
>

Build failed in Jenkins: build-4.5 #405

[jenkins]

See 

--
Started by user Pierre-Luc Dion
[EnvInject] - Loading node environment variables.
Building remotely on coohq-slave-01 (cloudstack-buildslave-centos6 
systemvmbuilder) in workspace 
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git init  # 
 > timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=10
 > /usr/bin/git config --add remote.origin.fetch 
 > +refs/heads/*:refs/remotes/origin/* # timeout=10
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/4.5^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/4.5^{commit} # timeout=10
Checking out Revision b8192114767040ef4869a7e71886df5965dadb37 
(refs/remotes/origin/4.5)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f b8192114767040ef4869a7e71886df5965dadb37
 > /usr/bin/git rev-list b8192114767040ef4869a7e71886df5965dadb37 # timeout=10
[copy-to-slave] Copying 'settings.xml', excluding nothing, from 
'file:/var/lib/jenkins/userContent/' on the master to 
' on 'coohq-slave-01'.
Unpacking 
http://archive.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip to 
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1 on 
coohq-slave-01
[build-4.5] $ 
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn
 -s  
-Psystemvm,awsapi -T 2C clean test
Error: JAVA_HOME is not defined correctly.
  We cannot execute /usr/lib/jvm/java-1.7.0//bin/java
Build step 'Invoke top-level Maven targets' marked build as failure
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
hudson.AbortException: No test report files were found. Configuration error?
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to coohq-slave-01(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:970)
at hudson.FilePath.act(FilePath.java:959)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at 
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1784)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Execu

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Marcus]

+1, I think trying to catch and keep up with all of the great tooling
existing for container scheduling is a losing battle. I'm not against
implementing it as a hypervisor alongside lxc, but I'm not sure how much
value people will find in that compared to the other advanced and
purpose-built solutions out there, and to compete with those solutions
would be a lot of work if you measure by the effort in those other projects.

I like the idea of focusing on making cloudstack an attractive place to
host infrastructure for container environments. There have been community
members having great success providing and selling container services
within CloudStack infrastructure.

I do fear a bit that supporting it as a hypervisor will fracture the
message a bit or misdirect people away from this option, but it can be
overcome. If people see value in making it a top-tier hypervisor, I'm all
for that, but my first choice would be to look for integration points with
existing, mature technologies.
On Mar 18, 2015 5:57 PM, "Nux!"  wrote:

> +1 Pierre and Sebastien.
> We should make sure CoreOS & co run fine on ACS, then let people do their
> thing using specific tools.
>
> Plus I wouldn't like Docker to run straight on shared bare metal servers
> (hypervisors), they're not as secure as VMs.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Pierre-Luc Dion" 
> > To: dev@cloudstack.apache.org
> > Sent: Thursday, 19 March, 2015 00:39:43
> > Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack (
> CloudStack / CLOUDSTACK-8205)
>
> > I really like Sebastien concept of Container as workload because it could
> > be used into an existing cloud without introducing a new hypervisor,
> also,
> > it might be possible to reuse current networking features of cloudstack.
> >
> >
> >
> >
> >
> >
> > On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen 
> > wrote:
> >
> >>
> >> > On Mar 18, 2015, at 10:43 AM, Rohit Yadav 
> >> wrote:
> >> >
> >> > Hi Diwas,
> >> >
> >> > The idea is to support Docker in ACS, much like LXC since they are
> >> > similar (containers). This of course would have some limitations wrt
> >> > supporting various network models and disk operations such as taking
> >> > snapshot and migrations across hosts.
> >> >
> >> > ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
> >> > community) in CloudStack using libvirt which is another interesting
> >> > project.))
> >> >
> >> > Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will
> be,
> >> > assume it will be at least Linux 3.16. Assume using barebone
> >> > technologies instead of relying on other orchestration or high level
> >> > systems to control Docker images unless what you're willing to use are
> >> > stable enough.
> >> >
> >> > While it's an open discussion on what the scope or the best way to do
> >> > it; IMO, the basic things I'm looking for are:
> >> >
> >> > - Support Basic networking (supporting at least Linux bridge or maybe
> >> > OVS - I'm not sure the best way to do it)
> >> > - SystemVMs can be Docker based or VMs running on KVM
> >> > - Local or NFS based shared storage. Support basic operations such as
> -
> >> > upload/register template, create VMs using template.
> >> > - Console proxy support (if possible).
> >> >
> >> > Since most players in the docker arena are still figuring out best way
> >> > to deal with networking and storage, the expectation of the work is
> >> > limited to producing an experimental hypervisor plugin.
> >> >
> >> > For implementation details, read CloudStack 101 on the wiki, see how
> >> > plugins are written and follow the LXC plugin implementation or see
> this
> >> > commit:
> >> >
> >> >
> >>
> https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157
> >> >
> >>
> >> I understand why we you would like to do this, however I see Docker as a
> >> ‘workload’. It is easy to setup in a VM or bare metal.
> >> The Docker ecosystem is booming and there are a ton of Docker
> >> “orchestrator” being worked on. It seems to me it will be very
> difficult to
> >> keep up development of a proper docker management service in CloudStack.
> >>
> >> Personally, I’d rather see us put efforts in properly supporting all the
> >> new Docker customized OS (making cloudstack templates for them), fixing
> our
> >> cloudinit support and extending our API to create clusters of machines.
> >> That way it will be easy for CloudStack users to start a Docker cluster
> and
> >> use their docker container orchestrator of choice.
> >>
> >> Very much like if you want to deploy Mesos or the like in CloudStack,
> >> Docker orchestrators are really workloads in our clouds.
> >>
> >> Our strategy for Docker support should be to make it extremely easy for
> >> folks to use Docker in CloudStack VMs. Do things like Docker machine
> >> support, Docker swarm support etc….and if we want a tighter integration
> we

Jenkins build is back to normal : build-master-noredist #4150

[jenkins]

See 

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Star Guo]

Now, CloudStack supports running CoreOS on XS, KVM, Hyper-V, VMware, bellow as:
https://coreos.com/docs/running-coreos/platforms/cloudstack/
http://dl.openvm.eu/cloudstack/coreos/x86_64/

Best Regards,
Star Guo

-邮件原件-
发件人: Nux! [mailto:n...@li.nux.ro] 
发送时间: 2015年3月19日 8:51
收件人: dev@cloudstack.apache.org
主题: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / 
CLOUDSTACK-8205)

+1 Pierre and Sebastien.
We should make sure CoreOS & co run fine on ACS, then let people do their thing 
using specific tools.

Plus I wouldn't like Docker to run straight on shared bare metal servers 
(hypervisors), they're not as secure as VMs.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Pierre-Luc Dion" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 19 March, 2015 00:39:43
> Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( 
> CloudStack / CLOUDSTACK-8205)

> I really like Sebastien concept of Container as workload because it 
> could be used into an existing cloud without introducing a new 
> hypervisor, also, it might be possible to reuse current networking features 
> of cloudstack.
> 
> 
> 
> 
> 
> 
> On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen 
> wrote:
> 
>>
>> > On Mar 18, 2015, at 10:43 AM, Rohit Yadav 
>> > 
>> wrote:
>> >
>> > Hi Diwas,
>> >
>> > The idea is to support Docker in ACS, much like LXC since they are 
>> > similar (containers). This of course would have some limitations 
>> > wrt supporting various network models and disk operations such as 
>> > taking snapshot and migrations across hosts.
>> >
>> > ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
>> > community) in CloudStack using libvirt which is another interesting
>> > project.))
>> >
>> > Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will 
>> > be, assume it will be at least Linux 3.16. Assume using barebone 
>> > technologies instead of relying on other orchestration or high 
>> > level systems to control Docker images unless what you're willing 
>> > to use are stable enough.
>> >
>> > While it's an open discussion on what the scope or the best way to 
>> > do it; IMO, the basic things I'm looking for are:
>> >
>> > - Support Basic networking (supporting at least Linux bridge or 
>> > maybe OVS - I'm not sure the best way to do it)
>> > - SystemVMs can be Docker based or VMs running on KVM
>> > - Local or NFS based shared storage. Support basic operations such 
>> > as - upload/register template, create VMs using template.
>> > - Console proxy support (if possible).
>> >
>> > Since most players in the docker arena are still figuring out best 
>> > way to deal with networking and storage, the expectation of the 
>> > work is limited to producing an experimental hypervisor plugin.
>> >
>> > For implementation details, read CloudStack 101 on the wiki, see 
>> > how plugins are written and follow the LXC plugin implementation or 
>> > see this
>> > commit:
>> >
>> >
>> https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd
>> 651b1d809811157
>> >
>>
>> I understand why we you would like to do this, however I see Docker 
>> as a ‘workload’. It is easy to setup in a VM or bare metal.
>> The Docker ecosystem is booming and there are a ton of Docker 
>> “orchestrator” being worked on. It seems to me it will be very 
>> difficult to keep up development of a proper docker management service in 
>> CloudStack.
>>
>> Personally, I’d rather see us put efforts in properly supporting all 
>> the new Docker customized OS (making cloudstack templates for them), 
>> fixing our cloudinit support and extending our API to create clusters of 
>> machines.
>> That way it will be easy for CloudStack users to start a Docker 
>> cluster and use their docker container orchestrator of choice.
>>
>> Very much like if you want to deploy Mesos or the like in CloudStack, 
>> Docker orchestrators are really workloads in our clouds.
>>
>> Our strategy for Docker support should be to make it extremely easy 
>> for folks to use Docker in CloudStack VMs. Do things like Docker 
>> machine support, Docker swarm support etc….and if we want a tighter 
>> integration we should look at the AWS ECS API and the GCE container 
>> engine API and extend our EC2/GCE bridges to support them.
>>
>> my 2 cts.
>>
>> >
>> > On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote:
>> >> hello, I would like to work on the following issue for
>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google
>> summer of
>> >> code 2015. It would be really helpful if someone can tell me more 
>> >> about
>> the
>> >> idea and provide guidelines to get started with this.
>> >>
>> >> regards
>> >>
>> >
>> > --
>> > Regards,
>> > Rohit Yadav
>> > Software Architect, ShapeBlue
>> > M. +91 8826230892 | rohit.ya...@shapeblue.com
>> > Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer 
>> > below, I did not add it :) Fin

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Nux!]

+1 Pierre and Sebastien.
We should make sure CoreOS & co run fine on ACS, then let people do their thing 
using specific tools.

Plus I wouldn't like Docker to run straight on shared bare metal servers 
(hypervisors), they're not as secure as VMs.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Pierre-Luc Dion" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 19 March, 2015 00:39:43
> Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( 
> CloudStack / CLOUDSTACK-8205)

> I really like Sebastien concept of Container as workload because it could
> be used into an existing cloud without introducing a new hypervisor, also,
> it might be possible to reuse current networking features of cloudstack.
> 
> 
> 
> 
> 
> 
> On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen 
> wrote:
> 
>>
>> > On Mar 18, 2015, at 10:43 AM, Rohit Yadav 
>> wrote:
>> >
>> > Hi Diwas,
>> >
>> > The idea is to support Docker in ACS, much like LXC since they are
>> > similar (containers). This of course would have some limitations wrt
>> > supporting various network models and disk operations such as taking
>> > snapshot and migrations across hosts.
>> >
>> > ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
>> > community) in CloudStack using libvirt which is another interesting
>> > project.))
>> >
>> > Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be,
>> > assume it will be at least Linux 3.16. Assume using barebone
>> > technologies instead of relying on other orchestration or high level
>> > systems to control Docker images unless what you're willing to use are
>> > stable enough.
>> >
>> > While it's an open discussion on what the scope or the best way to do
>> > it; IMO, the basic things I'm looking for are:
>> >
>> > - Support Basic networking (supporting at least Linux bridge or maybe
>> > OVS - I'm not sure the best way to do it)
>> > - SystemVMs can be Docker based or VMs running on KVM
>> > - Local or NFS based shared storage. Support basic operations such as -
>> > upload/register template, create VMs using template.
>> > - Console proxy support (if possible).
>> >
>> > Since most players in the docker arena are still figuring out best way
>> > to deal with networking and storage, the expectation of the work is
>> > limited to producing an experimental hypervisor plugin.
>> >
>> > For implementation details, read CloudStack 101 on the wiki, see how
>> > plugins are written and follow the LXC plugin implementation or see this
>> > commit:
>> >
>> >
>> https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157
>> >
>>
>> I understand why we you would like to do this, however I see Docker as a
>> ‘workload’. It is easy to setup in a VM or bare metal.
>> The Docker ecosystem is booming and there are a ton of Docker
>> “orchestrator” being worked on. It seems to me it will be very difficult to
>> keep up development of a proper docker management service in CloudStack.
>>
>> Personally, I’d rather see us put efforts in properly supporting all the
>> new Docker customized OS (making cloudstack templates for them), fixing our
>> cloudinit support and extending our API to create clusters of machines.
>> That way it will be easy for CloudStack users to start a Docker cluster and
>> use their docker container orchestrator of choice.
>>
>> Very much like if you want to deploy Mesos or the like in CloudStack,
>> Docker orchestrators are really workloads in our clouds.
>>
>> Our strategy for Docker support should be to make it extremely easy for
>> folks to use Docker in CloudStack VMs. Do things like Docker machine
>> support, Docker swarm support etc….and if we want a tighter integration we
>> should look at the AWS ECS API and the GCE container engine API and extend
>> our EC2/GCE bridges to support them.
>>
>> my 2 cts.
>>
>> >
>> > On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote:
>> >> hello, I would like to work on the following issue for
>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google
>> summer of
>> >> code 2015. It would be really helpful if someone can tell me more about
>> the
>> >> idea and provide guidelines to get started with this.
>> >>
>> >> regards
>> >>
>> >
>> > --
>> > Regards,
>> > Rohit Yadav
>> > Software Architect, ShapeBlue
>> > M. +91 8826230892 | rohit.ya...@shapeblue.com
>> > Blog: bhaisaab.org | Twitter: @_bhaisaab
>> > PS. If you see any footer below, I did not add it :)
>> > Find out more about ShapeBlue and our range of CloudStack related
>> services
>> >
>> > IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> > CSForge – rapid IaaS deployment framework
>> > CloudStack Consulting
>> > CloudStack Software Engineering<
>> http://shapeblue.com/cloudstack-software-engineering/>
>> > CloudStack Infrastructure Support<
>> http://shap

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Pierre-Luc Dion]

I really like Sebastien concept of Container as workload because it could
be used into an existing cloud without introducing a new hypervisor, also,
it might be possible to reuse current networking features of cloudstack.






On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen 
wrote:

>
> > On Mar 18, 2015, at 10:43 AM, Rohit Yadav 
> wrote:
> >
> > Hi Diwas,
> >
> > The idea is to support Docker in ACS, much like LXC since they are
> > similar (containers). This of course would have some limitations wrt
> > supporting various network models and disk operations such as taking
> > snapshot and migrations across hosts.
> >
> > ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
> > community) in CloudStack using libvirt which is another interesting
> > project.))
> >
> > Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be,
> > assume it will be at least Linux 3.16. Assume using barebone
> > technologies instead of relying on other orchestration or high level
> > systems to control Docker images unless what you're willing to use are
> > stable enough.
> >
> > While it's an open discussion on what the scope or the best way to do
> > it; IMO, the basic things I'm looking for are:
> >
> > - Support Basic networking (supporting at least Linux bridge or maybe
> > OVS - I'm not sure the best way to do it)
> > - SystemVMs can be Docker based or VMs running on KVM
> > - Local or NFS based shared storage. Support basic operations such as -
> > upload/register template, create VMs using template.
> > - Console proxy support (if possible).
> >
> > Since most players in the docker arena are still figuring out best way
> > to deal with networking and storage, the expectation of the work is
> > limited to producing an experimental hypervisor plugin.
> >
> > For implementation details, read CloudStack 101 on the wiki, see how
> > plugins are written and follow the LXC plugin implementation or see this
> > commit:
> >
> >
> https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157
> >
>
> I understand why we you would like to do this, however I see Docker as a
> ‘workload’. It is easy to setup in a VM or bare metal.
> The Docker ecosystem is booming and there are a ton of Docker
> “orchestrator” being worked on. It seems to me it will be very difficult to
> keep up development of a proper docker management service in CloudStack.
>
> Personally, I’d rather see us put efforts in properly supporting all the
> new Docker customized OS (making cloudstack templates for them), fixing our
> cloudinit support and extending our API to create clusters of machines.
> That way it will be easy for CloudStack users to start a Docker cluster and
> use their docker container orchestrator of choice.
>
> Very much like if you want to deploy Mesos or the like in CloudStack,
> Docker orchestrators are really workloads in our clouds.
>
> Our strategy for Docker support should be to make it extremely easy for
> folks to use Docker in CloudStack VMs. Do things like Docker machine
> support, Docker swarm support etc….and if we want a tighter integration we
> should look at the AWS ECS API and the GCE container engine API and extend
> our EC2/GCE bridges to support them.
>
> my 2 cts.
>
> >
> > On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote:
> >> hello, I would like to work on the following issue for
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google
> summer of
> >> code 2015. It would be really helpful if someone can tell me more about
> the
> >> idea and provide guidelines to get started with this.
> >>
> >> regards
> >>
> >
> > --
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +91 8826230892 | rohit.ya...@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> > PS. If you see any footer below, I did not add it :)
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework
> > CloudStack Consulting
> > CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> > CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
> >
> > This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed. Any
> views or opinions expressed are solely those of the author and do not
> necessarily represent those of Shape Blue Ltd or related companies. If you
> are not the intended recipient of this email, you must neither take any
> action based upon its contents, nor copy or show it to anyone. Please
> contact the sender if you believe you have received this email in error.
> Shape Blue Ltd is a com

Re: Cloudstack modules on maven repository

[Ian Duffy]

Hey,

There is an apache Nexus repository available at https://repository.apache.org

If you search cloudstack you will see there are some old builds up
there https://repository.apache.org/#nexus-search;quick~cloudstack

There is documentation on the apache site about pushing items up there
http://www.apache.org/dev/publishing-maven-artifacts.html

It would be neat if we could get our CI to do versioning and push a
build artifact for each build.

** slightly off topic **  Awhile back I changed some of the jenkins
jobs to expose the cloud-client-ui war. All of the JARs are included
within this. This script
(https://github.com/imduffy15/cloudstack-cloudmonkey/blob/master/.tools/ci/cloudstack-simulator.sh)
shows downloading that war, unzipping it, finding the database util
classes, running the database creator scripts and deploying the WAR
with jetty. 
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-maven-build-noredist/lastSuccessfulBuild/

On 18 March 2015 at 21:15, Rafael Weingartner
 wrote:
> Got it.
> Thanks for registering the jira issue.
> I was going to do that. ;)
>
> On Wed, Mar 18, 2015 at 6:00 PM, Laszlo Hornyak 
> wrote:
>
>> Hi,
>>
>> As far asI know, there is no such repsoitory. It would be great to use the
>> central repository, but first we have to get rid of extra maven
>> repositories. (libvirt and ceph for example)
>> I registered a jira issue:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8335
>>
>>
>> On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner <
>> rafaelweingart...@gmail.com> wrote:
>>
>> > Hi devs,
>> >
>> > I just started extending Cloustack, I have spent almost a whole day
>> > configuring and building everything on eclipse. I noticed that CS modules
>> > are not in maven central repository, therefore, I have to download,
>> > configure, compile and build everything in order to work in one or other
>> > module. I was wondering is there any repository out there on the
>> Internet,
>> > maybe an apache dev repository, with all of those modules ready to use
>> that
>> > I can point as an extra repository in maven?
>> >
>> > --
>> > Rafael Weingärtner
>> >
>>
>>
>>
>> --
>>
>> EOF
>>
>
>
>
> --
> Rafael Weingärtner

Re: Root disk size support in UI - problem with instanceWizard.js

[Marcus]

I don't recall. There was a big long thread about it at one point, but
I wasn't paying full attention to it.

On Wed, Mar 18, 2015 at 12:39 PM, Nux!  wrote:
> If it's to save on download sizes, I prefer John's approach to proxy and 
> cache via Apache HTTPd (which brings other advantages as well, like easy SSL 
> configuration, mod_security etc etc).
>
> http://theresnomon.co/2014/improving-cloudstack-ui-performance/
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Nux!" 
>> To: dev@cloudstack.apache.org
>> Sent: Wednesday, 18 March, 2015 19:34:02
>> Subject: Re: Root disk size support in UI - problem with instanceWizard.js
>
>> Marcus,
>>
>> Thanks, after gzipping it I can see the field!
>>
>> Why are we doing this?
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Marcus" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Wednesday, 18 March, 2015 18:55:08
>>> Subject: Re: Root disk size support in UI - problem with instanceWizard.js
>>
>>> for 4.5, you'll need to gzip any js files after editing them. At least
>>> that's what I've observed. You should see a .js and a .js.gz for each.
>>>
>>> On Wed, Mar 18, 2015 at 11:44 AM, Nux!  wrote:
 Thanks Ian, tried your suggestions, but to no effect that I can observe.
 The root disk field does not appear on the instance creation page.

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
> From: "Ian Duffy" 
> To: "CloudStack Dev" 
> Sent: Wednesday, 18 March, 2015 16:52:30
> Subject: Re: Root disk size support in UI - problem with instanceWizard.js

> Hey Nux,
>
> This is completely untested and based of reading the source code.
>
> Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
> find a call to the custom hidden function which determines whether or
> not to set display = none on the root resize box.
>
> Within the ui/scripts/instanceWizard.js you'll see that the root
> resize is applied if its element isn't set to display none.
>
> I'd suggest just setting var custom = false; as a quick and easy fix.
>
> https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437
>
>
> On 18 March 2015 at 16:25, Nux!  wrote:
>> Hello,
>>
>> In my 4.4.1 install I can use this patch[1] to specify a custom root 
>> disk size
>> for an instance[2]. This is of course very handy, enabled me to get rid 
>> of tens
>> of templates with custom sizes.
>> In 4.5 this patch no longer does it's job, there is no Root Disk field 
>> appearing
>> during instance creation.
>>
>> Can anyone have a look?
>>
>> [1]
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
>> [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature 
>> for now
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> > >> > www.nux.ro

Re: BUG: anybody addressing this one ?

[Marcus]

Well, I think many people will want to be able to leave disks detached
without deleting them, I'm not sure what the use case was that caused
Andrija to want to delete those disks. It sounds like he wanted to
delete attached disks and keep the vm.

>From experience, it would be relatively trivial to have a
'deleteVolume deferred=true' parameter that simply marks the volume as
destroyed, then the storage cleanup thread will expunge it. The list
volumes api call would also need to be changed to show destroyed
volumes optionally, and there'd need to be a new API call that allows
you to mark the volume read again to 'undo'.  This isn't much work but
unfortunately I'm not in a position to do that at the moment.

The big issue is really that drilling down into members of entities in
the UI seems to be broken, whether it's "view volumes" attached to a
vm or "view instances" on a host.

On Wed, Mar 18, 2015 at 12:52 PM, ilya  wrote:
> It looks like we have 2 issues here.
>
> 1) you are seeing volumes you should not see
>
> 2) volume purging is not implemented
>
> There are several solution to #2
>
> 1) I've written a shell script that deletes all volumes that are in detached
> state for over X number of days. I'll see if i can share the script. This
> could be temporary solution run as cronjob periodically.
>
> 2) Marcus has written an API extension call that will delete the VM with
> volumes, slightly different API call needs to be invoked, something like
> destroyVmWithVolumes, the volumes will be expunged at the same time as VM.
> Its not part of the cloudstack UI, but could be integrated - hoping someone
> with UI experience can do that. The code will be committed upstream
> hopefully soon, there is some internal delay for releasing that, but we will
> work this through.
>
>
>
> On 3/18/15 4:58 AM, Andrija Panic wrote:
>>
>> Hi,
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-7926
>>
>> Currently I have hit a bug, when I click on some instance, then on View
>> Volumes, and then I get listed volumes that belong to some other VM - it
>> already happened to me that I deleted the volumes - beacuse of ACS bug in
>> GUI !
>>
>> So, I suggest to consider maybe to implement purging volumes the same way
>> it is implemented with VM-s - so the VM is not really deleted - and the
>> purge thread in ACS will acually delete it when it runs...
>>
>

Re: Cloudstack modules on maven repository

[Rafael Weingartner]

Got it.
Thanks for registering the jira issue.
I was going to do that. ;)

On Wed, Mar 18, 2015 at 6:00 PM, Laszlo Hornyak 
wrote:

> Hi,
>
> As far asI know, there is no such repsoitory. It would be great to use the
> central repository, but first we have to get rid of extra maven
> repositories. (libvirt and ceph for example)
> I registered a jira issue:
> https://issues.apache.org/jira/browse/CLOUDSTACK-8335
>
>
> On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner <
> rafaelweingart...@gmail.com> wrote:
>
> > Hi devs,
> >
> > I just started extending Cloustack, I have spent almost a whole day
> > configuring and building everything on eclipse. I noticed that CS modules
> > are not in maven central repository, therefore, I have to download,
> > configure, compile and build everything in order to work in one or other
> > module. I was wondering is there any repository out there on the
> Internet,
> > maybe an apache dev repository, with all of those modules ready to use
> that
> > I can point as an extra repository in maven?
> >
> > --
> > Rafael Weingärtner
> >
>
>
>
> --
>
> EOF
>



-- 
Rafael Weingärtner

Re: Cloudstack modules on maven repository

[Laszlo Hornyak]

Hi,

As far asI know, there is no such repsoitory. It would be great to use the
central repository, but first we have to get rid of extra maven
repositories. (libvirt and ceph for example)
I registered a jira issue:
https://issues.apache.org/jira/browse/CLOUDSTACK-8335


On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner <
rafaelweingart...@gmail.com> wrote:

> Hi devs,
>
> I just started extending Cloustack, I have spent almost a whole day
> configuring and building everything on eclipse. I noticed that CS modules
> are not in maven central repository, therefore, I have to download,
> configure, compile and build everything in order to work in one or other
> module. I was wondering is there any repository out there on the Internet,
> maybe an apache dev repository, with all of those modules ready to use that
> I can point as an extra repository in maven?
>
> --
> Rafael Weingärtner
>



-- 

EOF

Cloudstack modules on maven repository

[Rafael Weingartner]

Hi devs,

I just started extending Cloustack, I have spent almost a whole day
configuring and building everything on eclipse. I noticed that CS modules
are not in maven central repository, therefore, I have to download,
configure, compile and build everything in order to work in one or other
module. I was wondering is there any repository out there on the Internet,
maybe an apache dev repository, with all of those modules ready to use that
I can point as an extra repository in maven?

-- 
Rafael Weingärtner

Build failed in Jenkins: cloudstack-4.4-maven-build #594

[jenkins]

See 

Changes:

[Daan Hoogland] Avoid distributing private key for realhostip.com

--
[...truncated 9576 lines...]
359/612 KB   344/380 KB   
363/612 KB   344/380 KB   
367/612 KB   344/380 KB   
371/612 KB   344/380 KB   
375/612 KB   344/380 KB   
379/612 KB   344/380 KB   
383/612 KB   344/380 KB   
387/612 KB   344/380 KB   
391/612 KB   344/380 KB   
395/612 KB   344/380 KB   
395/612 KB   348/380 KB   
395/612 KB   349/380 KB   
395/612 KB   352/380 KB   
395/612 KB   355/380 KB   
395/612 KB   359/380 KB   
395/612 KB   363/380 KB   
395/612 KB   367/380 KB   
395/612 KB   371/380 KB   
395/612 KB   375/380 KB   
395/612 KB   379/380 KB   
395/612 KB   380/380 KB   
399/612 KB   380/380 KB   
403/612 KB   380/380 KB   
407/612 KB   380/380 KB   
411/612 KB   380/380 KB   
415/612 KB   380/380 KB   
419/612 KB   380/380 KB   
423/612 KB   380/380 KB   
427/612 KB   380/380 KB   
431/612 KB   380/380 KB   
435/612 KB   380/380 KB   
439/612 KB   380/380 KB   
443/612 KB   380/380 KB   
447/612 KB   380/380 KB   
451/612 KB   380/380 KB   
455/612 KB   380/380 KB   
459/612 KB   380/380 KB   
463/612 KB   380/380 KB   
467/612 KB   380/380 KB   
471/612 KB   380/380 KB   
475/612 KB   380/380 KB   
479/612 KB   380/380 KB   
483/612 KB   380/380 KB   
487/612 KB   380/380 KB   
491/612 KB   380/380 KB   
495/612 KB   380/380 KB   
499/612 KB   380/380 KB   
503/612 KB   380/380 KB   
507/612 KB   380/380 KB   
511/612 KB   380/380 KB   
515/612 KB   380/380 KB   
519/612 KB   380/380 KB   
523/612 KB   380/380 KB   
527/612 KB   380/380 KB   
531/612 KB   380/380 KB   
535/612 KB   380/380 KB   
539/612 KB   380/380 KB   
543/612 KB   380/380 KB   
544/612 KB   380/380 KB   
548/612 KB   380/380 KB   
552/612 KB   380/380 KB   
556/612 KB   380/380 KB   
560/612 KB   380/380 KB   
564/612 KB   380/380 KB   
568/612 KB   380/380 KB   
572/612 KB   380/380 KB   
576/612 KB   380/380 KB   
580/612 KB   380/380 KB   
584/612 KB   380/380 KB   
588/612 KB   380/380 KB   
592/612 KB   380/380 KB   
596/612 KB   380/380 KB   
600/612 KB   380/380 KB   
604/612 KB   380/380 KB   
608/612 KB   380/380 KB   
612/612 KB   380/380 KB   
  
Downloaded: 
http://repo.maven.apache.org/maven2/javax/mail/mail/1.4/mail-1.4.jar (380 KB at 
2133.4 KB/sec)
  
Downloaded: 
http://repo.maven.apache.org/maven2/org/springframework/spring-web/3.2.4.RELEASE/spring-web-3.2.4.RELEASE.jar
 (612 KB at 3086.9 KB/sec)
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-server ---
[INFO] Deleting 
 
(includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-server ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-server 
---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (generate-resource) @ cloud-server ---
[INFO] Executing tasks

main:
 [copy] Copying 3 files to 

 [copy] Copying 1 file to 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 30 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-server 
---
[INFO] Compiling 360 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[195,12]
 error: cannot find symbol
[ERROR]   symbol:   class SecureRandom
  location: class AgentHookBase
:[195,34]
 error: cannot find symbol
[ERROR]   symbol:   variable SecureRandom
  location: class AgentHookBase
:[199,19]
 error: variable storePassword is already defined in method 
startAgentHttpHandlerInVM(StartupProxyCommand)
[ERROR] 
:[199,35]
 error: cannot find symbol
[ERROR]   symbol:   variable Base64
  location: class AgentHookBase

Re: BUG: anybody addressing this one ?

[ilya]

It looks like we have 2 issues here.

1) you are seeing volumes you should not see

2) volume purging is not implemented

There are several solution to #2

1) I've written a shell script that deletes all volumes that are in 
detached state for over X number of days. I'll see if i can share the 
script. This could be temporary solution run as cronjob periodically.


2) Marcus has written an API extension call that will delete the VM with 
volumes, slightly different API call needs to be invoked, something like 
destroyVmWithVolumes, the volumes will be expunged at the same time as 
VM. Its not part of the cloudstack UI, but could be integrated - hoping 
someone with UI experience can do that. The code will be committed 
upstream hopefully soon, there is some internal delay for releasing 
that, but we will work this through.



On 3/18/15 4:58 AM, Andrija Panic wrote:

Hi,

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

Currently I have hit a bug, when I click on some instance, then on View
Volumes, and then I get listed volumes that belong to some other VM - it
already happened to me that I deleted the volumes - beacuse of ACS bug in
GUI !

So, I suggest to consider maybe to implement purging volumes the same way
it is implemented with VM-s - so the VM is not really deleted - and the
purge thread in ACS will acually delete it when it runs...

Re: Root disk size support in UI - problem with instanceWizard.js

[Nux!]

If it's to save on download sizes, I prefer John's approach to proxy and cache 
via Apache HTTPd (which brings other advantages as well, like easy SSL 
configuration, mod_security etc etc).

http://theresnomon.co/2014/improving-cloudstack-ui-performance/

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 18 March, 2015 19:34:02
> Subject: Re: Root disk size support in UI - problem with instanceWizard.js

> Marcus,
> 
> Thanks, after gzipping it I can see the field!
> 
> Why are we doing this?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Marcus" 
>> To: dev@cloudstack.apache.org
>> Sent: Wednesday, 18 March, 2015 18:55:08
>> Subject: Re: Root disk size support in UI - problem with instanceWizard.js
> 
>> for 4.5, you'll need to gzip any js files after editing them. At least
>> that's what I've observed. You should see a .js and a .js.gz for each.
>> 
>> On Wed, Mar 18, 2015 at 11:44 AM, Nux!  wrote:
>>> Thanks Ian, tried your suggestions, but to no effect that I can observe.
>>> The root disk field does not appear on the instance creation page.
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Ian Duffy" 
 To: "CloudStack Dev" 
 Sent: Wednesday, 18 March, 2015 16:52:30
 Subject: Re: Root disk size support in UI - problem with instanceWizard.js
>>>
 Hey Nux,

 This is completely untested and based of reading the source code.

 Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
 find a call to the custom hidden function which determines whether or
 not to set display = none on the root resize box.

 Within the ui/scripts/instanceWizard.js you'll see that the root
 resize is applied if its element isn't set to display none.

 I'd suggest just setting var custom = false; as a quick and easy fix.

 https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437


 On 18 March 2015 at 16:25, Nux!  wrote:
> Hello,
>
> In my 4.4.1 install I can use this patch[1] to specify a custom root disk 
> size
> for an instance[2]. This is of course very handy, enabled me to get rid 
> of tens
> of templates with custom sizes.
> In 4.5 this patch no longer does it's job, there is no Root Disk field 
> appearing
> during instance creation.
>
> Can anyone have a look?
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
> [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature 
> for now
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> > >> > www.nux.ro

Re: Root disk size support in UI - problem with instanceWizard.js

[Nux!]

Marcus,

Thanks, after gzipping it I can see the field!

Why are we doing this?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Marcus" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 18 March, 2015 18:55:08
> Subject: Re: Root disk size support in UI - problem with instanceWizard.js

> for 4.5, you'll need to gzip any js files after editing them. At least
> that's what I've observed. You should see a .js and a .js.gz for each.
> 
> On Wed, Mar 18, 2015 at 11:44 AM, Nux!  wrote:
>> Thanks Ian, tried your suggestions, but to no effect that I can observe.
>> The root disk field does not appear on the instance creation page.
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Ian Duffy" 
>>> To: "CloudStack Dev" 
>>> Sent: Wednesday, 18 March, 2015 16:52:30
>>> Subject: Re: Root disk size support in UI - problem with instanceWizard.js
>>
>>> Hey Nux,
>>>
>>> This is completely untested and based of reading the source code.
>>>
>>> Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
>>> find a call to the custom hidden function which determines whether or
>>> not to set display = none on the root resize box.
>>>
>>> Within the ui/scripts/instanceWizard.js you'll see that the root
>>> resize is applied if its element isn't set to display none.
>>>
>>> I'd suggest just setting var custom = false; as a quick and easy fix.
>>>
>>> https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437
>>>
>>>
>>> On 18 March 2015 at 16:25, Nux!  wrote:
 Hello,

 In my 4.4.1 install I can use this patch[1] to specify a custom root disk 
 size
 for an instance[2]. This is of course very handy, enabled me to get rid of 
 tens
 of templates with custom sizes.
 In 4.5 this patch no longer does it's job, there is no Root Disk field 
 appearing
 during instance creation.

 Can anyone have a look?

 [1]
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature 
 for now

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
> >> > www.nux.ro

Re: Root disk size support in UI - problem with instanceWizard.js

[Marcus]

for 4.5, you'll need to gzip any js files after editing them. At least
that's what I've observed. You should see a .js and a .js.gz for each.

On Wed, Mar 18, 2015 at 11:44 AM, Nux!  wrote:
> Thanks Ian, tried your suggestions, but to no effect that I can observe.
> The root disk field does not appear on the instance creation page.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Ian Duffy" 
>> To: "CloudStack Dev" 
>> Sent: Wednesday, 18 March, 2015 16:52:30
>> Subject: Re: Root disk size support in UI - problem with instanceWizard.js
>
>> Hey Nux,
>>
>> This is completely untested and based of reading the source code.
>>
>> Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
>> find a call to the custom hidden function which determines whether or
>> not to set display = none on the root resize box.
>>
>> Within the ui/scripts/instanceWizard.js you'll see that the root
>> resize is applied if its element isn't set to display none.
>>
>> I'd suggest just setting var custom = false; as a quick and easy fix.
>>
>> https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437
>>
>>
>> On 18 March 2015 at 16:25, Nux!  wrote:
>>> Hello,
>>>
>>> In my 4.4.1 install I can use this patch[1] to specify a custom root disk 
>>> size
>>> for an instance[2]. This is of course very handy, enabled me to get rid of 
>>> tens
>>> of templates with custom sizes.
>>> In 4.5 this patch no longer does it's job, there is no Root Disk field 
>>> appearing
>>> during instance creation.
>>>
>>> Can anyone have a look?
>>>
>>> [1]
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
>>> [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature 
>>> for now
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>> > www.nux.ro

Re: Root disk size support in UI - problem with instanceWizard.js

[Nux!]

Thanks Ian, tried your suggestions, but to no effect that I can observe.
The root disk field does not appear on the instance creation page.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Ian Duffy" 
> To: "CloudStack Dev" 
> Sent: Wednesday, 18 March, 2015 16:52:30
> Subject: Re: Root disk size support in UI - problem with instanceWizard.js

> Hey Nux,
> 
> This is completely untested and based of reading the source code.
> 
> Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
> find a call to the custom hidden function which determines whether or
> not to set display = none on the root resize box.
> 
> Within the ui/scripts/instanceWizard.js you'll see that the root
> resize is applied if its element isn't set to display none.
> 
> I'd suggest just setting var custom = false; as a quick and easy fix.
> 
> https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437
> 
> 
> On 18 March 2015 at 16:25, Nux!  wrote:
>> Hello,
>>
>> In my 4.4.1 install I can use this patch[1] to specify a custom root disk 
>> size
>> for an instance[2]. This is of course very handy, enabled me to get rid of 
>> tens
>> of templates with custom sizes.
>> In 4.5 this patch no longer does it's job, there is no Root Disk field 
>> appearing
>> during instance creation.
>>
>> Can anyone have a look?
>>
>> [1]
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
>> [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for 
>> now
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
> > www.nux.ro

Re: BUG: anybody addressing this one ?

[Andrei Mikhailovsky]

Just done. 

As i've commented in the bug report, similar behaviour happens when you go to 
Infrastructure > Hosts > host > View Instances. Sometimes you get a list of all 
instances, even the stopped instances, instead of only those that run on the 
chosen host. 

Andrei 

- Original Message -

> From: "Andrija Panic" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 18 March, 2015 1:58:35 PM
> Subject: Re: BUG: anybody addressing this one ?

> Andrei, please comment the JIRA with same text if you have time :)
> otherwise...no use here I guess

> Thanks

> On 18 March 2015 at 14:26, Andrei Mikhailovsky 
> wrote:

> > Happened to me on several occasions as well. However, I am double
> > careful
> > now and I double check the volume names before deleting to make
> > sure I do
> > the right one.
> >
> > This little bug is annoying to say the least )))
> >
> > Andrei
> >
> > - Original Message -
> >
> > > From: "Andrija Panic" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Wednesday, 18 March, 2015 11:58:53 AM
> > > Subject: BUG: anybody addressing this one ?
> >
> > > Hi,
> >
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-7926
> >
> > > Currently I have hit a bug, when I click on some instance, then
> > > on
> > > View
> > > Volumes, and then I get listed volumes that belong to some other
> > > VM -
> > > it
> > > already happened to me that I deleted the volumes - beacuse of
> > > ACS
> > > bug in
> > > GUI !
> >
> > > So, I suggest to consider maybe to implement purging volumes the
> > > same
> > > way
> > > it is implemented with VM-s - so the VM is not really deleted -
> > > and
> > > the
> > > purge thread in ACS will acually delete it when it runs...
> >
> > > --
> >
> > > Andrija Panić
> >

> --

> Andrija Panić

Build failed in Jenkins: build-master-slowbuild #1131

[jenkins]

See 

--
[...truncated 87799 lines...]
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[INFO] Cobertura: Loaded information on 6393 classes.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostMountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartPartsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartUploadsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultipartMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/OfferingDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SAclDao.java.  Ensure this class was instrumented, 
and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SBucketDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SObjectDao.java.  Ensure this class was 
instrumented, and this data fi

Re: Root disk size support in UI - problem with instanceWizard.js

[Ian Duffy]

Hey Nux,

This is completely untested and based of reading the source code.

Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should
find a call to the custom hidden function which determines whether or
not to set display = none on the root resize box.

Within the ui/scripts/instanceWizard.js you'll see that the root
resize is applied if its element isn't set to display none.

I'd suggest just setting var custom = false; as a quick and easy fix.

https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437


On 18 March 2015 at 16:25, Nux!  wrote:
> Hello,
>
> In my 4.4.1 install I can use this patch[1] to specify a custom root disk 
> size for an instance[2]. This is of course very handy, enabled me to get rid 
> of tens of templates with custom sizes.
> In 4.5 this patch no longer does it's job, there is no Root Disk field 
> appearing during instance creation.
>
> Can anyone have a look?
>
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
> [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for 
> now
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Root disk size support in UI - problem with instanceWizard.js

[Nux!]

Hello,

In my 4.4.1 install I can use this patch[1] to specify a custom root disk size 
for an instance[2]. This is of course very handy, enabled me to get rid of tens 
of templates with custom sizes.
In 4.5 this patch no longer does it's job, there is no Root Disk field 
appearing during instance creation.

Can anyone have a look?

[1] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44
[2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: junkins

[Ian Southam]

Daan,
On 17 Mar 2015, at 12:23, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

Laszlo, I don't think anyone is working on this. Jenkins output is
largely ignored in this community. The fact that the present cause is
a resource problem is worrying. I think these are SBP hosted slaves
and will have a look (not in the office now). If I fix this the
slowbuild will not work at least. The last time I saw it passing by it
had 6 new unattended issues from the findbugs output. Coverity
complained about new issues as well, i noticed just now.

Do I have access to these boxes?  Quite happy to have a look.

—
Ian

Re: Guidelines for test developers

[Daan Hoogland]

good write-up Gaurav, I hope that most of these can be
validated/verified checkstyle-style. pep8 can of course. Some others
must remain judged by humanoids, like the one where functions are
pulled up to higher abstraction layers. Maybe you could shine your
light on what we can automate? i.e. can pyflakes be added to a target?

> -Original Message-
> From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com]
> Sent: 18 March 2015 07:16
> To: dev@cloudstack.apache.org
> Subject: Guidelines for test developers
>
> Hello all,
>
> Last year after improving Marvin framework, we have been continuously 
> spending time in improving old test cases which are written in old style or 
> they don't abide to certain guidelines, also which don't use new functions 
> available in marvin. Many times a test developer who is adding test case for 
> the first time or feature developers adding Basic Validation Tests
> (BVTs) tend to copy paste the code available in certain test case and try to 
> modify it according to feature and commit it. This adds to inconsistencies.
>
> As and when I touch a file for fixing an issue or adding/editing it, I try to 
> incorporate below guidelines and improve the existing code. But still few 
> test files are not up to the mark. Our final goal is to have good code in 
> every file.So writing this mail to consolidate few rules that should be 
> known/considered by everyone adding tests to Marvin. Also, if you touch a 
> file, feel free to remove any inconsistencies that are already present in the 
> file.
>
> *1. Import * should always be avoided*. When I started two years back, and 
> tried to understand the code flow/ test cases, I could not easily understand 
> from where the particular module is imported. The imports must be specific.
>
> When the imports are specific, it eliminates the possibility of test case 
> failure due to invalid import when specific import is removed from dependent 
> module.
>
> E.g. If your test case has following import.
>
> from A import *
>
> And it uses time module which is not imported explicitly in test case and 
> comes from module A. Then the test case will start failing when "import 
> time"is removed from module A. You certainly don't want this to happen.
>
> *2. Maintaining Pep8 standards for python code.*
>
> The code is read more often that it is written. Pep8 standards improve the 
> readability of the code making it consistent in style. There is a tool named 
> "*autopep8*" which you can install with pip install and then you can run 
> following command on your test file.
>
> autopep8 -i -a -a testFile.py
>
> This will make the file pep8 consistent and will also remove the white 
> spaces. But some issues need human intervention and can't be fixed with tool. 
> For fixing those, check the pep8 issues with "pep8 testFile.py" and fix 
> manually.
>
> *3. Keep only imports which are used* in the test suite and remove unwanted 
> imports.
>
> *4. Keep all the configuration parameters* (such as data which is passed to 
> API while creating Network offering, Service offering, account etc...) *in 
> tools/marvin/marvin/config/test_data.py file*. Don't include them in test 
> suite itself.
>
> Many of the dictionaries are reusable and if you are adding a new test, there 
> are only a few dictionaries you will have to add in the file.
>
> If any of the data contains URLs or any data which should be changed 
> according to setup/env, then include the dict in "*configurableData*"
> section in test_data.py file. This makes it easier to identify which data 
> needs to be dynamic according to the setup and which data doesn't need to be 
> touched when env is changed.
>
> *5. Before committing a test case, run it* with the latest branch against 
> which you are adding the test case and attach the results in Pull Request.
> If in case change is very small, and doesn't need to be run, then at least 
> check syntactical errors with python command and also with the help of tools 
> such as pyflakes.
>
> 6. If you add a new function in your test case and you think it can be used 
> in future by other test cases, then please *add that function to common or 
> utils file* in Marvin. Don't keep it local to test case. This will prevent 
> multiple contributors adding same functions in their test case to achieve a 
> particular goal.
>
> *7. Please make sure all the resources created through the test cases are 
> deleted *when test case execution completes, or even when the test case fails.
>
> 8. If same test case is to be run with different configuration or setting, 
> you can *make use of ddt library*. For example, if you have added test case 
> for isolated networks, and you need to run the same code for shared and VPC 
> networks, then you don't need to add 3 test cases. Just add relevant tags to 
> the test case and you are good to go. Although you will need to write code 
> for handling those tags. It is already used in few test cases. A simple grep 
> over c

Build failed in Jenkins: build-master-slowbuild #1130

[jenkins]

See 

--
[...truncated 23731 lines...]
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[INFO] Cobertura: Loaded information on 6393 classes.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostMountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartPartsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartUploadsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultipartMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/OfferingDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SAclDao.java.  Ensure this class was instrumented, 
and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SBucketDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SObjectDao.java.  Ensure this class was 
instrumented, and this data fi

Re: BUG: anybody addressing this one ?

[Andrija Panic]

Andrei, please comment the JIRA with same text if you have time :)
otherwise...no use here I guess

Thanks

On 18 March 2015 at 14:26, Andrei Mikhailovsky  wrote:

> Happened to me on several occasions as well. However, I am double careful
> now and I double check the volume names before deleting to make sure I do
> the right one.
>
> This little bug is annoying to say the least )))
>
> Andrei
>
> - Original Message -
>
> > From: "Andrija Panic" 
> > To: dev@cloudstack.apache.org
> > Sent: Wednesday, 18 March, 2015 11:58:53 AM
> > Subject: BUG: anybody addressing this one ?
>
> > Hi,
>
> > https://issues.apache.org/jira/browse/CLOUDSTACK-7926
>
> > Currently I have hit a bug, when I click on some instance, then on
> > View
> > Volumes, and then I get listed volumes that belong to some other VM -
> > it
> > already happened to me that I deleted the volumes - beacuse of ACS
> > bug in
> > GUI !
>
> > So, I suggest to consider maybe to implement purging volumes the same
> > way
> > it is implemented with VM-s - so the VM is not really deleted - and
> > the
> > purge thread in ACS will acually delete it when it runs...
>
> > --
>
> > Andrija Panić
>



-- 

Andrija Panić

Re: BUG: anybody addressing this one ?

[Andrei Mikhailovsky]

Happened to me on several occasions as well. However, I am double careful now 
and I double check the volume names before deleting to make sure I do the right 
one. 

This little bug is annoying to say the least ))) 

Andrei 

- Original Message -

> From: "Andrija Panic" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 18 March, 2015 11:58:53 AM
> Subject: BUG: anybody addressing this one ?

> Hi,

> https://issues.apache.org/jira/browse/CLOUDSTACK-7926

> Currently I have hit a bug, when I click on some instance, then on
> View
> Volumes, and then I get listed volumes that belong to some other VM -
> it
> already happened to me that I deleted the volumes - beacuse of ACS
> bug in
> GUI !

> So, I suggest to consider maybe to implement purging volumes the same
> way
> it is implemented with VM-s - so the VM is not really deleted - and
> the
> purge thread in ACS will acually delete it when it runs...

> --

> Andrija Panić

Re: Let's start 4.5.1 release process?

[Nux!]

+1

We should have done this the next day after 4.5. :-)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" , "David Nalley" 
> Sent: Wednesday, 18 March, 2015 09:18:04
> Subject: Let's start 4.5.1 release process?

> Hi all,
> 
> I've been testing and fixing issues in the past weeks on 4.5. I think
> 4.5 is in a better state and we've upgrade paths from 4.5.0 to 4.5.1 and
> 4.5.1 to 4.6.0 (master) as well. Has anyone found any blockers or issues
> that should be addressed on 4.5?
> 
> David - If we're all good, let's cut a RC soon and release 4.5.1?
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 8826230892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> PS. If you see any footer below, I did not add it :)
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software
> Engineering
> CloudStack Infrastructure
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely
> for the use of the individual to whom it is addressed. Any views or opinions
> expressed are solely those of the author and do not necessarily represent 
> those
> of Shape Blue Ltd or related companies. If you are not the intended recipient
> of this email, you must neither take any action based upon its contents, nor
> copy or show it to anyone. Please contact the sender if you believe you have
> received this email in error. Shape Blue Ltd is a company incorporated in
> England & Wales. ShapeBlue Services India LLP is a company incorporated in
> India and is operated under license from Shape Blue Ltd. Shape Blue Brasil
> Consultoria Ltda is a company incorporated in Brasil and is operated under
> license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by
> The Republic of South Africa and is traded under license from Shape Blue Ltd.
> ShapeBlue is a registered trademark.

RE: [PROPOSAL] Support management/storage traffic over VMware DVS in CloudStack deployments

[Paul Angus]

+1

We have had a few customers ask for this.
It would have been our preferred configuration in our lab, had it been possible.

Regards

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

-Original Message-
From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com]
Sent: 18 March 2015 04:35
To: dev@cloudstack.apache.org
Subject: [PROPOSAL] Support management/storage traffic over VMware DVS in 
CloudStack deployments

Hi,

I would like to extend the existing integration of VMware DVS with Apache 
CloudStack by adding support for management as well as storage traffic over 
VMware DVS.

Currently guest and public traffic are supported over VMware DVS in CloudStack 
deployments. There was discussion in dev mailing list earlier about the 
requirement to support management/storage traffic as well on VMware DVS, which 
can be found in [3]. Corresponding jira reference is [2].

Please review FS at [1] and let me know your comments.

Regards,
Sateesh

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+Management+and+Storage+traffic+over+VMware+DVS+in+CloudStack
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3317
[3] 
http://markmail.org/message/sz7xudwqod44awlf#query:+page:1+mid:7t2quwaxzycatfey+state:results


Find out more about ShapeBlue and our range of CloudStack related services

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

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

RE: Guidelines for test developers

[Paul Angus]

Thank you Gaurav,

It would great if the community developers could please express their support 
for these guidelines (or start a conversation if you feel differently).

This way, this initiative will get traction.

@Gaurav, are these guidelines in the developer section of the CloudStack wiki?

Regards

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

-Original Message-
From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com]
Sent: 18 March 2015 07:16
To: dev@cloudstack.apache.org
Subject: Guidelines for test developers

Hello all,

Last year after improving Marvin framework, we have been continuously spending 
time in improving old test cases which are written in old style or they don't 
abide to certain guidelines, also which don't use new functions available in 
marvin. Many times a test developer who is adding test case for the first time 
or feature developers adding Basic Validation Tests
(BVTs) tend to copy paste the code available in certain test case and try to 
modify it according to feature and commit it. This adds to inconsistencies.

As and when I touch a file for fixing an issue or adding/editing it, I try to 
incorporate below guidelines and improve the existing code. But still few test 
files are not up to the mark. Our final goal is to have good code in every 
file.So writing this mail to consolidate few rules that should be 
known/considered by everyone adding tests to Marvin. Also, if you touch a file, 
feel free to remove any inconsistencies that are already present in the file.

*1. Import * should always be avoided*. When I started two years back, and 
tried to understand the code flow/ test cases, I could not easily understand 
from where the particular module is imported. The imports must be specific.

When the imports are specific, it eliminates the possibility of test case 
failure due to invalid import when specific import is removed from dependent 
module.

E.g. If your test case has following import.

from A import *

And it uses time module which is not imported explicitly in test case and comes 
from module A. Then the test case will start failing when "import time"is 
removed from module A. You certainly don't want this to happen.

*2. Maintaining Pep8 standards for python code.*

The code is read more often that it is written. Pep8 standards improve the 
readability of the code making it consistent in style. There is a tool named 
"*autopep8*" which you can install with pip install and then you can run 
following command on your test file.

autopep8 -i -a -a testFile.py

This will make the file pep8 consistent and will also remove the white spaces. 
But some issues need human intervention and can't be fixed with tool. For 
fixing those, check the pep8 issues with "pep8 testFile.py" and fix manually.

*3. Keep only imports which are used* in the test suite and remove unwanted 
imports.

*4. Keep all the configuration parameters* (such as data which is passed to API 
while creating Network offering, Service offering, account etc...) *in 
tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite 
itself.

Many of the dictionaries are reusable and if you are adding a new test, there 
are only a few dictionaries you will have to add in the file.

If any of the data contains URLs or any data which should be changed according 
to setup/env, then include the dict in "*configurableData*"
section in test_data.py file. This makes it easier to identify which data needs 
to be dynamic according to the setup and which data doesn't need to be touched 
when env is changed.

*5. Before committing a test case, run it* with the latest branch against which 
you are adding the test case and attach the results in Pull Request.
If in case change is very small, and doesn't need to be run, then at least 
check syntactical errors with python command and also with the help of tools 
such as pyflakes.

6. If you add a new function in your test case and you think it can be used in 
future by other test cases, then please *add that function to common or utils 
file* in Marvin. Don't keep it local to test case. This will prevent multiple 
contributors adding same functions in their test case to achieve a particular 
goal.

*7. Please make sure all the resources created through the test cases are 
deleted *when test case execution completes, or even when the test case fails.

8. If same test case is to be run with different configuration or setting, you 
can *make use of ddt library*. For example, if you have added test case for 
isolated networks, and you need to run the same code for shared and VPC 
networks, then you don't need to add 3 test cases. Just add relevant tags to 
the test case and you are good to go. Although you will need to write code for 
handling those tags. It is already used in few test cases. A simple grep over 
component folder and you can see how it is used.

This blog explains how it works.

BUG: anybody addressing this one ?

[Andrija Panic]

Hi,

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

Currently I have hit a bug, when I click on some instance, then on View
Volumes, and then I get listed volumes that belong to some other VM - it
already happened to me that I deleted the volumes - beacuse of ACS bug in
GUI !

So, I suggest to consider maybe to implement purging volumes the same way
it is implemented with VM-s - so the VM is not really deleted - and the
purge thread in ACS will acually delete it when it runs...

-- 

Andrija Panić

BUG: Hide shared networks with no free IP, from GUI in "Add network to VM" dialog

[Andrija Panic]

Hi,

just filed the new bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-8333
Nothing critical, but should be fixes (if not done already in newer
releases)

When all IPs are consumed (no more IPs available) in the Shared Guest
network then folowing is true in 4.3.2

   - In the "Add Instance" wizard, this Guest netowrk is NOT displayed any
   more - FINE.
   - When editing existng VM, on the NIC tab, when clicking "Add network to
   VM" this Guest network IS available - and this results with an error since
   no free IPs in the pool.

For consistency reasons, the network should also not be displayed in the
"Add network to VM" dialog/popup.

-- 

Andrija Panić

Re: SNAT and remote IP problem

[Andrija Panic]

I reacall this was fine in clean 4.4.0 or 4.4.1/2cant remember any
more...

but anyone willing to share their VR output, as I asked, will I guess help
us greatly...

On 18 March 2015 at 12:28, Erik Weber  wrote:

> Has anyone checked if this is present in 4.5? If so we should aim to have a
> fix available with 4.5.1
>
> --
> Erik
>
> On Wed, Mar 18, 2015 at 10:47 AM, Paul Shadwell  wrote:
>
> > I also have this problem, it effects running vPBX/VoIP services behind a
> > VR.
> >
> > In fact any service that requires a view on incoming IPs and domain
> names.
> >
> > For example fail2ban will block ALL access to ssh because it only ever
> > sees the VR IP address.
> >
> > Upgrading to 4.3.2 did not fix it.
> >
> > This needs fixing urgently.
> >
> > Best regards
> >
> > Paul
> >
> >
> >
> > > On 17 Mar 2015, at 14:01, Andrija Panic 
> wrote:
> > >
> > > Hi,
> > >
> > > is anybody willing to share the result from the folowing command, run
> in
> > VR
> > > (VPC VR):
> > >
> > > iptables -t nat -nvL
> > >
> > > This should preferable be run from SSH-to-VR, instead of
> > > ConsoleProxy-to-VR, because of nice output over SSH.
> > >
> > >
> > > It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections,
> no
> > > matter to WHAT IP  the traffic from internet came - primary IP, or
> > > additional one that is used for i.e. Static NAT - so SNAT rules always
> > > replace remote cleint IP with MAIN IP of the VPC...
> > >
> > > Please share your examples - this is serious bug in my opinion, and I
> wil
> > > raise JIRA - but would like some examples from other guys first.
> > >
> > > THanks,
> > >
> > > --
> > >
> > > Andrija Panić
> >
> >
>



-- 

Andrija Panić

Re: SNAT and remote IP problem

[Erik Weber]

Has anyone checked if this is present in 4.5? If so we should aim to have a
fix available with 4.5.1

-- 
Erik

On Wed, Mar 18, 2015 at 10:47 AM, Paul Shadwell  wrote:

> I also have this problem, it effects running vPBX/VoIP services behind a
> VR.
>
> In fact any service that requires a view on incoming IPs and domain names.
>
> For example fail2ban will block ALL access to ssh because it only ever
> sees the VR IP address.
>
> Upgrading to 4.3.2 did not fix it.
>
> This needs fixing urgently.
>
> Best regards
>
> Paul
>
>
>
> > On 17 Mar 2015, at 14:01, Andrija Panic  wrote:
> >
> > Hi,
> >
> > is anybody willing to share the result from the folowing command, run in
> VR
> > (VPC VR):
> >
> > iptables -t nat -nvL
> >
> > This should preferable be run from SSH-to-VR, instead of
> > ConsoleProxy-to-VR, because of nice output over SSH.
> >
> >
> > It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections, no
> > matter to WHAT IP  the traffic from internet came - primary IP, or
> > additional one that is used for i.e. Static NAT - so SNAT rules always
> > replace remote cleint IP with MAIN IP of the VPC...
> >
> > Please share your examples - this is serious bug in my opinion, and I wil
> > raise JIRA - but would like some examples from other guys first.
> >
> > THanks,
> >
> > --
> >
> > Andrija Panić
>
>

Build failed in Jenkins: build-master-slowbuild #1129

[jenkins]

See 

Changes:

[Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces

--
[...truncated 23731 lines...]
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[INFO] Cobertura: Loaded information on 6393 classes.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostMountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartPartsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartUploadsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultipartMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/OfferingDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SAclDao.java.  Ensure this class was instrumented, 
and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SBucketDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/brid

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Sebastien Goasguen]

> On Mar 18, 2015, at 10:43 AM, Rohit Yadav  wrote:
> 
> Hi Diwas,
> 
> The idea is to support Docker in ACS, much like LXC since they are
> similar (containers). This of course would have some limitations wrt
> supporting various network models and disk operations such as taking
> snapshot and migrations across hosts.
> 
> ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
> community) in CloudStack using libvirt which is another interesting
> project.))
> 
> Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be,
> assume it will be at least Linux 3.16. Assume using barebone
> technologies instead of relying on other orchestration or high level
> systems to control Docker images unless what you're willing to use are
> stable enough.
> 
> While it's an open discussion on what the scope or the best way to do
> it; IMO, the basic things I'm looking for are:
> 
> - Support Basic networking (supporting at least Linux bridge or maybe
> OVS - I'm not sure the best way to do it)
> - SystemVMs can be Docker based or VMs running on KVM
> - Local or NFS based shared storage. Support basic operations such as -
> upload/register template, create VMs using template.
> - Console proxy support (if possible).
> 
> Since most players in the docker arena are still figuring out best way
> to deal with networking and storage, the expectation of the work is
> limited to producing an experimental hypervisor plugin.
> 
> For implementation details, read CloudStack 101 on the wiki, see how
> plugins are written and follow the LXC plugin implementation or see this
> commit:
> 
> https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157
> 

I understand why we you would like to do this, however I see Docker as a 
‘workload’. It is easy to setup in a VM or bare metal.
The Docker ecosystem is booming and there are a ton of Docker “orchestrator” 
being worked on. It seems to me it will be very difficult to keep up 
development of a proper docker management service in CloudStack.

Personally, I’d rather see us put efforts in properly supporting all the new 
Docker customized OS (making cloudstack templates for them), fixing our 
cloudinit support and extending our API to create clusters of machines. That 
way it will be easy for CloudStack users to start a Docker cluster and use 
their docker container orchestrator of choice.

Very much like if you want to deploy Mesos or the like in CloudStack, Docker 
orchestrators are really workloads in our clouds.

Our strategy for Docker support should be to make it extremely easy for folks 
to use Docker in CloudStack VMs. Do things like Docker machine support, Docker 
swarm support etc….and if we want a tighter integration we should look at the 
AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to 
support them.

my 2 cts.

> 
> On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote:
>> hello, I would like to work on the following issue for
>> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of
>> code 2015. It would be really helpful if someone can tell me more about the
>> idea and provide guidelines to get started with this.
>> 
>> regards
>> 
> 
> --
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 8826230892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> PS. If you see any footer below, I did not add it :)
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered 

Re: SNAT and remote IP problem

[Paul Shadwell]

I also have this problem, it effects running vPBX/VoIP services behind a VR.

In fact any service that requires a view on incoming IPs and domain names.

For example fail2ban will block ALL access to ssh because it only ever sees the 
VR IP address.

Upgrading to 4.3.2 did not fix it.

This needs fixing urgently.

Best regards

Paul



> On 17 Mar 2015, at 14:01, Andrija Panic  wrote:
> 
> Hi,
> 
> is anybody willing to share the result from the folowing command, run in VR
> (VPC VR):
> 
> iptables -t nat -nvL
> 
> This should preferable be run from SSH-to-VR, instead of
> ConsoleProxy-to-VR, because of nice output over SSH.
> 
> 
> It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections, no
> matter to WHAT IP  the traffic from internet came - primary IP, or
> additional one that is used for i.e. Static NAT - so SNAT rules always
> replace remote cleint IP with MAIN IP of the VPC...
> 
> Please share your examples - this is serious bug in my opinion, and I wil
> raise JIRA - but would like some examples from other guys first.
> 
> THanks,
> 
> -- 
> 
> Andrija Panić

Build failed in Jenkins: simulator-singlerun #1032

[jenkins]

See 

Changes:

[wrodrigues] CLOUDSTACK-7143: a better fix for kernel upgrade disk space 
problems

[wrodrigues] Make sure the location for the persistant configs exists

[wrodrigues] Switch ip associations to the new config file system

[wrodrigues] Removed useless array from SetStaticRoutesCmd.

[wrodrigues] Cherry-pick of 11c00977f77f45aa7b0c387dc88360eba0819e8a:

[wrodrigues] This file isn't used, so remove it

[wrodrigues] Add a placeholder for the trigger file

[wrodrigues] Vagrant virtualbox based testing suite

[wrodrigues] Added curl to the base install

[wrodrigues] Merged cookbooks from vpc branch

[wrodrigues] Remove scripts directory no longer necessary

[wrodrigues] Replace CreateGuestNetwork config script with a json file.

[wrodrigues] Tuning/reformatting/defensible-ing Vagrantfile

[wrodrigues] Add the Python bits

[wrodrigues] Added cs_ip module

[wrodrigues] Use json naming standards instead of camelCase

[wrodrigues] Changed from camelCase to json_case

[wrodrigues] Create a json file for SetNetworkACL

[wrodrigues] Only ip_association files for now

[wrodrigues] Can now read the ips out of the cmdline databag (if present)

[wrodrigues] Correct small typo in error message

[wrodrigues] Remove debug code

[wrodrigues] Include a type field in all json configuration objects

[wrodrigues] Switch ip associations to new model and update the recipes

[wrodrigues] Disable cmdline check until it's fixed

[wrodrigues] 1.  Completed provider for ip rules (fwmark)

[wrodrigues] Corrected a hole in my logic

[wrodrigues] Rewrite networkacl model to have separate entries for each rule

[wrodrigues] Add some debug logging to keep track of timing

[wrodrigues] Change vmdata to the new config system

[wrodrigues] A working test-kitchen setup for testing systemvm boxes.

[wrodrigues] Include the guestnetwork code

[wrodrigues] Split Databag in to separate class as I would now need this

[wrodrigues] junit report output for vagrant systemvm tests

[wrodrigues] Use bundler to exec test-kitchen

[wrodrigues] Commit missing .kitchen.yml

[wrodrigues] Massively simpler serverspec invocation

[wrodrigues] Missing gem for vagrant magic

[wrodrigues] Documentation and license headers for new systemvm testing tools.

[wrodrigues] Plan B

[wrodrigues] Test data for ipassociation

[wrodrigues] Added some lost lines back using Hugo witchcraft

[wrodrigues] Put a netmask in the netmask field

[wrodrigues] Moved bag location to /et/cloudstack

[wrodrigues] Pure python tests for systemvm

[wrodrigues] Replace serverspec with nose in systemvm test.sh

[wrodrigues] Attempt to get these tests working on python 2.6

[wrodrigues] Second Attempt to get these tests working on python 2.6.

[wrodrigues] Added guest network configuration

[wrodrigues] This was a good one

[wrodrigues] Move some static strings to constants and remove some duplicate 
code

[wrodrigues] New style save password command

[wrodrigues] Fancy line editor for Ian

[wrodrigues] Don't fail if you've logged into an older systemvm manually, 
before.

[wrodrigues] Set up rsync for systemvm patches.

[wrodrigues] Fix update_config.py use of subprocess.

[wrodrigues] Fix configure::waitForDevice when a device is missing.

[wrodrigues] Tests for update_config.py

[wrodrigues] Add forwarding rules to the new config format and do a little 
rewrite on

[wrodrigues] Removed merge_cline - no longer required

[wrodrigues] New style manage VPN user command 

[wrodrigues] Add more nics by default

[wrodrigues] Have Vagrantfile errors go to STDERR so output is 
machine-parseable.

[wrodrigues] Adding the Vagrant configuration that will build xen and db 
servers.

[wrodrigues] modified StaticNatRule to use the new style

[wrodrigues] iDo not do the post configure steps on a control interface

[wrodrigues] Removed chef as we will definitely not go this way

[wrodrigues] Migrate ip alias commands

[wrodrigues] Do not use eth0 or eth1 for random tests

[wrodrigues] Stop ignoring eth0

[wrodrigues] Fix on error reporting (null doesn't say much, so lets return the 
actual problem)

[wrodrigues] Adding new model for the Site2SiteVpn configuration.

[wrodrigues] Added some tests that test stuff

[wrodrigues] Change the location for the temporary json files to 
/var/cache/cloud

[wrodrigues] Staticroutes to new json style

[wrodrigues] New model for RemoteAccessVpn and moving into the new structure

[wrodrigues] Hotfix for lost control interface

[wrodrigues] Small fixes

[wrodrigues] Creating new model for the MonitorService

[wrodrigues] Added vmpassword type (does nothing yet)

[wrodrigues] New style dnsmasq configuration

[wrodrigues] Fixed test (assert in guest check was wrong way around)

[wrodrigues] Creating new model for the firewall rules

[wrodrigues] Some bug fixes

[wrodrigues] fixing the nullpointer on type which is null

[wrodrigues] Fixed bug in which every run of loadQueueFile would append to th

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[Rohit Yadav]

Hi Diwas,

The idea is to support Docker in ACS, much like LXC since they are
similar (containers). This of course would have some limitations wrt
supporting various network models and disk operations such as taking
snapshot and migrations across hosts.

((Btw, you may also consider supporting Bhyve (VMM from FreeBSD
community) in CloudStack using libvirt which is another interesting
project.))

Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be,
assume it will be at least Linux 3.16. Assume using barebone
technologies instead of relying on other orchestration or high level
systems to control Docker images unless what you're willing to use are
stable enough.

While it's an open discussion on what the scope or the best way to do
it; IMO, the basic things I'm looking for are:

- Support Basic networking (supporting at least Linux bridge or maybe
OVS - I'm not sure the best way to do it)
- SystemVMs can be Docker based or VMs running on KVM
- Local or NFS based shared storage. Support basic operations such as -
upload/register template, create VMs using template.
- Console proxy support (if possible).

Since most players in the docker arena are still figuring out best way
to deal with networking and storage, the expectation of the work is
limited to producing an experimental hypervisor plugin.

For implementation details, read CloudStack 101 on the wiki, see how
plugins are written and follow the LXC plugin implementation or see this
commit:

https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157


On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote:

hello, I would like to work on the following issue for
https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of
code 2015. It would be really helpful if someone can tell me more about the
idea and provide guidelines to get started with this.

regards



--
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 8826230892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
PS. If you see any footer below, I did not add it :)
Find out more about ShapeBlue and our range of CloudStack related services

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

This email and any attachments to it may be confidential and are intended solely 
for the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those of 
Shape Blue Ltd or related companies. If you are not the intended recipient of this 
email, you must neither take any action based upon its contents, nor copy or show 
it to anyone. Please contact the sender if you believe you have received this email 
in error. Shape Blue Ltd is a company incorporated in England & Wales. 
ShapeBlue Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue 
SA Pty Ltd is a company registered by The Republic of South Africa and is traded 
under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Let's start 4.5.1 release process?

[Rohit Yadav]

Hi all,

I've been testing and fixing issues in the past weeks on 4.5. I think
4.5 is in a better state and we've upgrade paths from 4.5.0 to 4.5.1 and
4.5.1 to 4.6.0 (master) as well. Has anyone found any blockers or issues
that should be addressed on 4.5?

David - If we're all good, let's cut a RC soon and release 4.5.1?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 8826230892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
PS. If you see any footer below, I did not add it :)
Find out more about ShapeBlue and our range of CloudStack related services

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

This email and any attachments to it may be confidential and are intended solely 
for the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those of 
Shape Blue Ltd or related companies. If you are not the intended recipient of this 
email, you must neither take any action based upon its contents, nor copy or show 
it to anyone. Please contact the sender if you believe you have received this email 
in error. Shape Blue Ltd is a company incorporated in England & Wales. 
ShapeBlue Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue 
SA Pty Ltd is a company registered by The Republic of South Africa and is traded 
under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Build failed in Jenkins: build-4.5 #404

[jenkins]

See 

Changes:

[Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-9ee 
(cloudstack-buildslave-centos6) in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/4.5^{commit} # timeout=400
 > /usr/bin/git rev-parse refs/remotes/origin/origin/4.5^{commit} # timeout=400
Checking out Revision b8192114767040ef4869a7e71886df5965dadb37 
(refs/remotes/origin/4.5)
 > /usr/bin/git config core.sparsecheckout # timeout=400
 > /usr/bin/git checkout -f b8192114767040ef4869a7e71886df5965dadb37
 > /usr/bin/git rev-list 3262b0bfd99528fd74a1693185544948f4d951ef # timeout=400
[copy-to-slave] Copying 'settings.xml', excluding nothing, from 
'file:/var/lib/jenkins/userContent/' on the master to 
' on 
'cloudstack-buildslave-centos6-9ee'.
[build-4.5] $ 
/jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn -s 
 
-Psystemvm,awsapi -T 2C clean test
Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread
Build step 'Invoke top-level Maven targets' marked build as failure
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
hudson.AbortException: Test reports were found but none of them are new. Did 
tests run? 
For example, 

 is 26 days old

at hudson.tasks.junit.TestResult.parse(TestResult.java:178)
at hudson.tasks.junit.TestResult.parse(TestResult.java:146)
at hudson.tasks.junit.TestResult.(TestResult.java:122)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)
at ..remote call to cloudstack-buildslave-centos6-9ee(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:970)
at hudson.FilePath.act(FilePath.java:959)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at 
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1784)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)

Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)

[cs user]

I'd really love to see this. CoreOS seems pretty well developed, with etcd
and fleet.

I envisage you would have clusters/pods of CoreOS machines with Cloudstack
managing etcd discovery.

Perhaps you could then define fleet unit files and have Cloudstack launch
these on the CoreOS cluster.




On Mon, Mar 16, 2015 at 8:45 AM, Nux!  wrote:

> I had a look at Atomic, the CentOS image should theoretically work with
> Cloudstack; but in practice it does not (cloud-init fails).
> When I'll get some more time I'll look more into it and perhaps we can get
> that fixed.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Sebastien Goasguen" 
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 16 March, 2015 07:33:34
> > Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack (
> CloudStack / CLOUDSTACK-8205)
>
> >> On Mar 16, 2015, at 6:43 AM, Kishan Kavala 
> wrote:
> >>
> >> CoreOS is supported on CS. Templates are available here:
> >> http://dl.openvm.eu/cloudstack/coreos/x86_64/
> >>
> >
> > There and on the official coreOS download site. It’s been available for
> a while
> > now.
> >
> > It would be very nice for someone to look at creating CS templates for
> Atomic,
> > Snappy and coreOS …
> >
> > We should have all docker minimal OS supported under CloudStack.
> >
> >> Still, I think it is working exploring Docker as a hypervisor also.
> >>
> >> Tuna stared some work on this earlier:
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Supporting+Docker+as+a+hypervisor
> >> http://ngtuna.blogspot.in/2013/12/docker-in-cloudstack.html
> >>
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-6664
> >>
> >>
> >> -Original Message-
> >> From: Koushik Das [mailto:koushik@citrix.com]
> >> Sent: Monday, March 16, 2015 10:49 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [DISCUSS] Support Docker as a hypervisor in CloudStack (
> CloudStack
> >> / CLOUDSTACK-8205)
> >>
> >> This is another alternate https://coreos.com/using-coreos/containers/.
> CS needs
> >> to support CoreOS.
> >>
> >> -Original Message-
> >> From: Diwas Joshi [mailto:dj.dij...@gmail.com]
> >> Sent: Monday, 16 March 2015 2:53
> >> To: dev@cloudstack.apache.org
> >> Subject: [DISCUSS] Support Docker as a hypervisor in CloudStack (
> CloudStack /
> >> CLOUDSTACK-8205)
> >>
> >> hello, I would like to work on the following issue for
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google
> summer of code
> >> 2015. It would be really helpful if someone can tell me more about the
> idea and
> >> provide guidelines to get started with this.
> >>
> > > regards
>

Re: [ASK] Is password server disabled in VPC?

[Nux!]

I was kidding, Rohit. Good job :)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 18 March, 2015 05:16:09
> Subject: Re: [ASK] Is password server disabled in VPC?

> Hi all,
> 
>> On 17-Mar-2015, at 6:25 pm, Nux!  wrote:
>>
>> Looks like Rohit managed to get us to panic. Again! :-)
> 
> Sorry for the issue, I did n’t mean to cause any panic :) It was a bug which
> caused the password server to not start. After Ian pointed out how it works 
> for
> VPCs I was able to fix it.
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software
> Engineering
> CloudStack Infrastructure
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely
> for the use of the individual to whom it is addressed. Any views or opinions
> expressed are solely those of the author and do not necessarily represent 
> those
> of Shape Blue Ltd or related companies. If you are not the intended recipient
> of this email, you must neither take any action based upon its contents, nor
> copy or show it to anyone. Please contact the sender if you believe you have
> received this email in error. Shape Blue Ltd is a company incorporated in
> England & Wales. ShapeBlue Services India LLP is a company incorporated in
> India and is operated under license from Shape Blue Ltd. Shape Blue Brasil
> Consultoria Ltda is a company incorporated in Brasil and is operated under
> license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by
> The Republic of South Africa and is traded under license from Shape Blue Ltd.
> ShapeBlue is a registered trademark.

Build failed in Jenkins: build-master-slowbuild #1128

[jenkins]

See 

Changes:

[Rohit Yadav] vpc_passwd_server: use the improved Python based password server

[Rohit Yadav] Add missing license headers from recent branch merge 3c429ee

--
[...truncated 23731 lines...]
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[INFO] Cobertura: Loaded information on 6393 classes.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MHostMountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartPartsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultiPartUploadsDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/MultipartMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/OfferingDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SAclDao.java.  Ensure this class was instrumented, 
and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SBucketDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SHostDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[INFO] Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/SMetaDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[IN

Guidelines for test developers

[Gaurav Aradhye]

Hello all,

Last year after improving Marvin framework, we have been continuously
spending time in improving old test cases which are written in old style or
they don't abide to certain guidelines, also which don't use new functions
available in marvin. Many times a test developer who is adding test case
for the first time or feature developers adding Basic Validation Tests
(BVTs) tend to copy paste the code available in certain test case and try
to modify it according to feature and commit it. This adds to
inconsistencies.

As and when I touch a file for fixing an issue or adding/editing it, I try
to incorporate below guidelines and improve the existing code. But still
few test files are not up to the mark. Our final goal is to have good code
in every file.So writing this mail to consolidate few rules that should be
known/considered by everyone adding tests to Marvin. Also, if you touch a
file, feel free to remove any inconsistencies that are already present in
the file.

*1. Import * should always be avoided*. When I started two years back, and
tried to understand the code flow/ test cases, I could not easily
understand from where the particular module is imported. The imports must
be specific.

When the imports are specific, it eliminates the possibility of test case
failure due to invalid import when specific import is removed from
dependent module.

E.g. If your test case has following import.

from A import *

And it uses time module which is not imported explicitly in test case and
comes from module A. Then the test case will start failing when "import
time"is removed from module A. You certainly don't want this to happen.

*2. Maintaining Pep8 standards for python code.*

The code is read more often that it is written. Pep8 standards improve the
readability of the code making it consistent in style. There is a tool
named "*autopep8*" which you can install with pip install and then you can
run following command on your test file.

autopep8 -i -a -a testFile.py

This will make the file pep8 consistent and will also remove the white
spaces. But some issues need human intervention and can't be fixed with
tool. For fixing those, check the pep8 issues with "pep8 testFile.py" and
fix manually.

*3. Keep only imports which are used* in the test suite and remove unwanted
imports.

*4. Keep all the configuration parameters* (such as data which is passed to
API while creating Network offering, Service offering, account etc...) *in
tools/marvin/marvin/config/test_data.py file*. Don't include them in test
suite itself.

Many of the dictionaries are reusable and if you are adding a new test,
there are only a few dictionaries you will have to add in the file.

If any of the data contains URLs or any data which should be changed
according to setup/env, then include the dict in "*configurableData*"
section in test_data.py file. This makes it easier to identify which data
needs to be dynamic according to the setup and which data doesn't need to
be touched when env is changed.

*5. Before committing a test case, run it* with the latest branch against
which you are adding the test case and attach the results in Pull Request.
If in case change is very small, and doesn't need to be run, then at least
check syntactical errors with python command and also with the help of
tools such as pyflakes.

6. If you add a new function in your test case and you think it can be used
in future by other test cases, then please *add that function to common or
utils file* in Marvin. Don't keep it local to test case. This will prevent
multiple contributors adding same functions in their test case to achieve a
particular goal.

*7. Please make sure all the resources created through the test cases are
deleted *when test case execution completes, or even when the test case
fails.

8. If same test case is to be run with different configuration or setting,
you can *make use of ddt library*. For example, if you have added test case
for isolated networks, and you need to run the same code for shared and VPC
networks, then you don't need to add 3 test cases. Just add relevant tags
to the test case and you are good to go. Although you will need to write
code for handling those tags. It is already used in few test cases. A
simple grep over component folder and you can see how it is used.

This blog explains how it works.
https://technomilk.wordpress.com/2012/02/12/multiplying-python-unit-test-cases-with-different-sets-of-data/

I will check if this is in any wiki page currently, and edit it. Or will
add a new page.
I hope everyone adding test cases follows above guidelines. Feel free to
add more.

Regards,
Gaurav