Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount

[Rohit Yadav]

Hi Min, Prachi,

Thanks for your comments. I see your point, the use case is to list VMs for a 
user_id (uuid, not name). I’m going to add the arg/option the listVM api to 
accept user_id and return the list of VMs for that user, and add option in the 
UI to do the same. Note, this is not for auditing purposes (for that we have 
events).

But, since we allow impersonation of account while deploying a VM by the same 
logic we should allow impersonation at the user_id as well which we only accept 
in the deploy VM API if an account/domain is mentioned along with the user_id. 
If I only use logged-in user ID, it makes implementation very simple but at the 
same time but sort of breaks impersonation semantics. Note: the fix will be 
simple, won’t change IAM and this is just to add capability to list VMs for a 
user ID.

> On 21-Nov-2014, at 11:57 pm, Prachi Damle  wrote:
>
> Hi Rohit,
> The accountId in deployVm API is serving the purpose of impersonation and can 
> be passed typically by admin accounts to deploy VM on behalf of other User.
> So Ideally with IAM, this parameter should be removed from the API and 
> impersonation should be handled separately.
> Keeping this goal, I think let's not add userID parameter in the API.
>
> We should default the value to the logged in user - this will prevent 
> usecases around cross-account/cross-user scenarios.
> Thanks,
> Prachi
>
>
> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Friday, November 21, 2014 8:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to 
> UserAccount
>
> If I understood correctly, (account, domainId) passed into deployVMCmd is 
> used for impersonation-like behavior, that is, caller is deploying a VM on 
> behalf of an account. Personally I don't like this kind of putting so many 
> parameters in one API to perform several different functionalities, 
> impersonation should be done through IAM separately. Too many parameters will 
> just make our API semantics very hard to understand and maintain.
> Along this line, I will not like to see this user_id added here.
>
> Thanks
> -min
>
> On 11/21/14 5:20 AM, "Rohit Yadav"  wrote:
>
>> Hi Prachi,
>>
>> Since we¹re already allowing users to specific account and list VMs by
>> account, following the same pattern I added the case so as to allow
>> users to specify user_id in both list/deploy VM commands. In case the
>> userid is not specified, in that case the logged in user¹s ID will be used.
>>
>> It¹s open for discussion of course, let me know if it¹s a good idea to
>> follow the same pattern or strictly use the logged-in user¹s ID?
>>
>>> On 21-Nov-2014, at 1:41 am, Prachi Damle 
>>> wrote:
>>>
>>> Rohit,
>>>
>>> I checked the code here
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
>>> ref s/heads/useraccount-refactoring and I don't understand why we need
>>> to expose the userId parameter in the deployVm API.
>>> I think we should be using the userId of the logged in user always.
>>> Exposing the parameter at the API allows it to be set by a user to
>>> the ID of another user . Also we need validation around it to make
>>> sure it belongs to the passed account etc.
>>>
>>> +//Owner userId
>>> +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID,
>>> entityType = UserResponse.class, required = true, description = "the
>>> user ID of the owner, optional to use with account and domainId. If
>>> not provided logged in user's ID is used.")
>>> +private Long userId;
>>>
>>>
>>> Prachi
>>>
>>> -Original Message-
>>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>>> Sent: Sunday, November 16, 2014 6:06 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [DISCUSS] Major business logic refactoring: Move from
>>> Account to UserAccount
>>>
>>> Only one table will be affected.
>>>
 On 16-Nov-2014, at 3:14 am, Amogh Vasekar 
 wrote:

 Question - What happens to the already existing VMs with entries in
 the DB? Do we keep it NULL?
>>>
>>> NULL will be and not useful. I think it should be okay to have a db
>>> migration path that sets user_id to the first user in account_id
>>> (which usually has the same name as account) for existing VMs. The
>>> amount of code change will be minimal.
>>>
>>> Checkout some code in this branch (has the db migration code and API
>>> layer changes);
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
>>> ref
>>> s/heads/useraccount-refactoring
>>>
>>> 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
>>> CloudSt

Jenkins build is still unstable: simulator-singlerun #684

[jenkins]

See 

Jenkins build is still unstable: simulator-singlerun #683

[jenkins]

See 

Re: Review Request 28300: CLOUDSTACK-7956 : Fixed the script 'test_project_usage.py' - Register Template in the Project to test the Template limits on the project

[sangeetha hariharan]

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

Ship it!


Ship It!

- sangeetha hariharan


On Nov. 20, 2014, 9:49 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28300/
> ---
> 
> (Updated Nov. 20, 2014, 9:49 p.m.)
> 
> 
> Review request for cloudstack and sangeetha hariharan.
> 
> 
> Bugs: CLOUDSTACK-7956
> https://issues.apache.org/jira/browse/CLOUDSTACK-7956
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating 
> template from snapshot/volume. This requires the test case 
> test_01_template_usage to be changed. The test case should test the limits by 
> registering the template in the project instead of creating templates from 
> Volumes.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_project_usage.py 2627504 
> 
> Diff: https://reviews.apache.org/r/28300/diff/
> 
> 
> Testing
> ---
> 
> Test Upload/ delete a template and verify correct usage is generated ... === 
> TestName: test_01_template_usage | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 312.740s
> 
> OK
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

Re: Review Request 28292: CLOUDSTACK-7955 : Fixed the script 'test_project_limits.py' - Register Template in the Project to test the Template limits on the project

[sangeetha hariharan]

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

Ship it!


Ship It!

- sangeetha hariharan


On Nov. 20, 2014, 7:26 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28292/
> ---
> 
> (Updated Nov. 20, 2014, 7:26 p.m.)
> 
> 
> Review request for cloudstack and sangeetha hariharan.
> 
> 
> Bugs: CLOUDSTACK-7955
> https://issues.apache.org/jira/browse/CLOUDSTACK-7955
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Based on Fix for CLOUDSTACK-7394, Caller should be owner after creating 
> template from snapshot/volume. This requires the test case 
> test_07_templates_per_project to be changed. The test case should test the 
> limits by registering the template in the project instead of creating 
> templates from Volumes.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_project_limits.py 5d37f0b 
> 
> Diff: https://reviews.apache.org/r/28292/diff/
> 
> 
> Testing
> ---
> 
> Test Limit number of guest account specific networks ... === TestName: 
> test_maxAccountNetworks | Status : SUCCESS ===
> ok
> Test project limits for domain admin ... === TestName: test_01_project_limits 
> | Status : SUCCESS ===
> ok
> Test project limits for normal user ... === TestName: 
> test_02_project_limits_normal_user | Status : SUCCESS ===
> ok
> Test VM limit per project ... === TestName: test_03_vm_per_project | Status : 
> SUCCESS ===
> ok
> Test Public IP limit per project ... === TestName: 
> test_04_publicip_per_project | Status : SUCCESS ===
> ok
> Test Snapshot limit per project ... === TestName: 
> test_05_snapshots_per_project | Status : SUCCESS ===
> ok
> Test Volumes limit per project ... === TestName: test_06_volumes_per_project 
> | Status : SUCCESS ===
> ok
> Test Templates limit per project ... === TestName: 
> test_07_templates_per_project | Status : SUCCESS ===
> ok
> 
> --
> Ran 8 tests in 1103.761s
> 
> OK
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

Jenkins build is still unstable: simulator-singlerun #682

[jenkins]

See 

Jenkins build became unstable: simulator-singlerun #681

[jenkins]

See 

RE: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount

[Prachi Damle]

Hi Rohit,
The accountId in deployVm API is serving the purpose of impersonation and can 
be passed typically by admin accounts to deploy VM on behalf of other User.
So Ideally with IAM, this parameter should be removed from the API and 
impersonation should be handled separately.
Keeping this goal, I think let's not add userID parameter in the API.

We should default the value to the logged in user - this will prevent usecases 
around cross-account/cross-user scenarios.
Thanks,
Prachi


-Original Message-
From: Min Chen [mailto:min.c...@citrix.com] 
Sent: Friday, November 21, 2014 8:16 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to 
UserAccount

If I understood correctly, (account, domainId) passed into deployVMCmd is used 
for impersonation-like behavior, that is, caller is deploying a VM on behalf of 
an account. Personally I don't like this kind of putting so many parameters in 
one API to perform several different functionalities, impersonation should be 
done through IAM separately. Too many parameters will just make our API 
semantics very hard to understand and maintain.
Along this line, I will not like to see this user_id added here.

Thanks
-min

On 11/21/14 5:20 AM, "Rohit Yadav"  wrote:

>Hi Prachi,
>
>Since we¹re already allowing users to specific account and list VMs by 
>account, following the same pattern I added the case so as to allow 
>users to specify user_id in both list/deploy VM commands. In case the 
>userid is not specified, in that case the logged in user¹s ID will be used.
>
>It¹s open for discussion of course, let me know if it¹s a good idea to 
>follow the same pattern or strictly use the logged-in user¹s ID?
>
>> On 21-Nov-2014, at 1:41 am, Prachi Damle 
>>wrote:
>>
>> Rohit,
>>
>> I checked the code here
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
>>ref s/heads/useraccount-refactoring and I don't understand why we need 
>>to expose the userId parameter in the deployVm API.
>> I think we should be using the userId of the logged in user always.
>> Exposing the parameter at the API allows it to be set by a user to 
>>the ID of another user . Also we need validation around it to make 
>>sure it belongs to the passed account etc.
>>
>> +//Owner userId
>> +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID,
>>entityType = UserResponse.class, required = true, description = "the 
>>user ID of the owner, optional to use with account and domainId. If 
>>not provided logged in user's ID is used.")
>> +private Long userId;
>>
>>
>> Prachi
>>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Sunday, November 16, 2014 6:06 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Major business logic refactoring: Move from 
>>Account to UserAccount
>>
>> Only one table will be affected.
>>
>>> On 16-Nov-2014, at 3:14 am, Amogh Vasekar 
>>>wrote:
>>>
>>> Question - What happens to the already existing VMs with entries in 
>>> the DB? Do we keep it NULL?
>>
>> NULL will be and not useful. I think it should be okay to have a db 
>>migration path that sets user_id to the first user in account_id 
>>(which usually has the same name as account) for existing VMs. The 
>>amount of code change will be minimal.
>>
>> Checkout some code in this branch (has the db migration code and API 
>>layer changes); 
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=
>>ref
>>s/heads/useraccount-refactoring
>>
>> 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 S

Jenkins build is back to stable : simulator-singlerun #680

[jenkins]

See 

Build failed in Jenkins: cloudstack-4.3-maven-build #641

[jenkins]

See 

Changes:

[Rohit Yadav] Revert "Revert "Bump release version to 4.3.2-SNAPSHOT and add 
empty db upgrade path""

[Rohit Yadav] fixed CLOUDSTACK-6261: remove the forceful timeout setting when 
login to NetScaler.

[Rohit Yadav] CLOUDSTACK-7954:ListTags API is ignoring the resourceID and 
displaying

[Rohit Yadav] travis: run jetty using IPv4 stack only

--
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-3a0 
(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 git://git.apache.org/cloudstack.git # 
 > timeout=400
Fetching upstream changes from git://git.apache.org/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse origin/4.3^{commit} # timeout=400
Checking out Revision df9fe7817c17b045f2f293bd238bf4982eebd7b5 (origin/4.3)
 > /usr/bin/git config core.sparsecheckout # timeout=400
 > /usr/bin/git checkout -f df9fe7817c17b045f2f293bd238bf4982eebd7b5
 > /usr/bin/git rev-list 59ce63918e227f93d64642e881551c25738de3b3 # timeout=400
FATAL: Couldn’t find any executable in /opt/apache-maven-3.0.5
Build step 'Invoke top-level Maven targets' marked build as failure

Build failed in Jenkins: cloudstack-4.3-maven-build #640

[jenkins]

See 

Changes:

[Rohit Yadav] Revert "Bump release version to 4.3.2-SNAPSHOT and add empty db 
upgrade path"

[Rohit Yadav] CLOUDSTACK-7415. Host remains in Alert after vCenter restart.

--
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-3a0 
(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 git://git.apache.org/cloudstack.git # 
 > timeout=400
Fetching upstream changes from git://git.apache.org/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse origin/4.3^{commit} # timeout=400
Checking out Revision 59ce63918e227f93d64642e881551c25738de3b3 (origin/4.3)
 > /usr/bin/git config core.sparsecheckout # timeout=400
 > /usr/bin/git checkout -f 59ce63918e227f93d64642e881551c25738de3b3
 > /usr/bin/git rev-list 57f28f1085b519d67c58b8c7e08c83821635a4f9 # timeout=400
FATAL: Couldn’t find any executable in /opt/apache-maven-3.0.5
Build step 'Invoke top-level Maven targets' marked build as failure

Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount

[Min Chen]

If I understood correctly, (account, domainId) passed into deployVMCmd is
used for impersonation-like behavior, that is, caller is deploying a VM on
behalf of an account. Personally I don't like this kind of putting so many
parameters in one API to perform several different functionalities,
impersonation should be done through IAM separately. Too many parameters
will just make our API semantics very hard to understand and maintain.
Along this line, I will not like to see this user_id added here.

Thanks
-min

On 11/21/14 5:20 AM, "Rohit Yadav"  wrote:

>Hi Prachi,
>
>Since we¹re already allowing users to specific account and list VMs by
>account, following the same pattern I added the case so as to allow users
>to specify user_id in both list/deploy VM commands. In case the userid is
>not specified, in that case the logged in user¹s ID will be used.
>
>It¹s open for discussion of course, let me know if it¹s a good idea to
>follow the same pattern or strictly use the logged-in user¹s ID?
>
>> On 21-Nov-2014, at 1:41 am, Prachi Damle 
>>wrote:
>>
>> Rohit,
>>
>> I checked the code here
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=ref
>>s/heads/useraccount-refactoring and I don't understand why we need to
>>expose the userId parameter in the deployVm API.
>> I think we should be using the userId of the logged in user always.
>> Exposing the parameter at the API allows it to be set by a user to the
>>ID of another user . Also we need validation around it to make sure it
>>belongs to the passed account etc.
>>
>> +//Owner userId
>> +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID,
>>entityType = UserResponse.class, required = true, description = "the
>>user ID of the owner, optional to use with account and domainId. If not
>>provided logged in user's ID is used.")
>> +private Long userId;
>>
>>
>> Prachi
>>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Sunday, November 16, 2014 6:06 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Major business logic refactoring: Move from
>>Account to UserAccount
>>
>> Only one table will be affected.
>>
>>> On 16-Nov-2014, at 3:14 am, Amogh Vasekar 
>>>wrote:
>>>
>>> Question - What happens to the already existing VMs with entries in
>>> the DB? Do we keep it NULL?
>>
>> NULL will be and not useful. I think it should be okay to have a db
>>migration path that sets user_id to the first user in account_id (which
>>usually has the same name as account) for existing VMs. The amount of
>>code change will be minimal.
>>
>> Checkout some code in this branch (has the db migration code and API
>>layer changes); 
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=ref
>>s/heads/useraccount-refactoring
>>
>> 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.
>
>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

Build failed in Jenkins: cloudstack-4.3-maven-build #639

[jenkins]

See 

--
[...truncated 3684 lines...]
remote: Counting objects: 68009   
remote: Counting objects: 68024   
remote: Counting objects: 68029   
remote: Counting objects: 68037   
remote: Counting objects: 68055   
remote: Counting objects: 68070   
remote: Counting objects: 68255   
remote: Counting objects: 68258   
remote: Counting objects: 68269   
remote: Counting objects: 68279   
remote: Counting objects: 68285   
remote: Counting objects: 68291   
remote: Counting objects: 68307   
remote: Counting objects: 68314   
remote: Counting objects: 68317   
remote: Counting objects: 68318   
remote: Counting objects: 68319   
remote: Counting objects: 68320   
remote: Counting objects: 68323   
remote: Counting objects: 68571   
remote: Counting objects: 68573   
remote: Counting objects: 68579   
remote: Counting objects: 68586   
remote: Counting objects: 68595   
remote: Counting objects: 68597   
remote: Counting objects: 68612   
remote: Counting objects: 68623   
remote: Counting objects: 68627   
remote: Counting objects: 68633   
remote: Counting objects: 68637   
remote: Counting objects: 68648   
remote: Counting objects: 68651   
remote: Counting objects: 68664   
remote: Counting objects: 68669   
remote: Counting objects: 68673   
remote: Counting objects: 68677   
remote: Counting objects: 68680   
remote: Counting objects: 68681   
remote: Counting objects: 68682   
remote: Counting objects: 68685   
remote: Counting objects: 68686   
remote: Counting objects: 68687   
remote: Counting objects: 68688   
remote: Counting objects: 68692   
remote: Counting objects: 68694   
remote: Counting objects: 68702   
remote: Counting objects: 68703   
remote: Counting objects: 68707   
remote: Counting objects: 68712   
remote: Counting objects: 68715   
remote: Counting objects: 68717   
remote: Counting objects: 68723   
remote: Counting objects: 68741   
remote: Counting objects: 68756   
remote: Counting objects: 68757   
remote: Counting objects: 68764   
remote: Counting objects: 68770   
remote: Counting objects: 68776   
remote: Counting objects: 68786   
remote: Counting objects: 68793   
remote: Counting objects: 68794   
remote: Counting objects: 68808   
remote: Counting objects: 68817   
remote: Counting objects: 68839   
remote: Counting objects: 68840   
remote: Counting objects: 68843   
remote: Counting objects: 68847   
remote: Counting objects: 68848   
remote: Counting objects: 68849   
remote: Counting objects: 68851   
remote: Counting objects: 68855   
remote: Counting objects: 68856   
remote: Counting objects: 68862   
remote: Counting objects: 68863   
remote: Counting objects: 68868   
remote: Counting objects: 68874   
remote: Counting objects: 68884   
remote: Counting objects: 68892   
remote: Counting objects: 68897   
remote: Counting objects: 68900   
remote: Counting objects: 68907   
remote: Counting objects: 68910   
remote: Counting objects: 68912   
remote: Counting objects: 68913   
remote: Counting objects: 68915   
remote: Counting objects: 68916   
remote: Counting objects: 68917   
remote: Counting objects: 68918   
remote: Counting objects: 68920   
remote: Counting objects: 68925   
remote: Counting objects: 68929   
remote: Counting objects: 68933   
remote: Counting objects: 68943   
remote: Counting objects: 68948   
remote: Counting objects: 68949   
remote: Counting objects: 68950   
remote: Counting objects: 68952   
remote: Counting objects: 68954   
remote: Counting objects: 68955   
remote: Counting objects: 68960   
remote: Counting objects: 68973   
remote: Counting objects: 68980   
remote: Counting objects: 68981   
remote: Counting objects: 68984   
remote: Counting objects: 69045   
remote: Counting objects: 69289   
remote: Counting objects: 69357   
remote: Counting objects: 69974   
remote: Counting objects: 70250   
remote: Counting objects: 70382   
remote: Counting objects: 70383   
remote: Counting objects: 70448   
remote: Counting objects: 70450  

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Pierre-Yves Ritschard]

It would be interesting to have usage stats on the AWS cloud bridge.
It is very hard to get working right correctly (especially when compared to
something like ec2stack) so I'd be very surprised if:

- There were a large number of users
- They had upgrade path issues

I think the idea of chunking out awsapi in its own repo has some merit,
even though it will most likely ending up being bitrot.

As far as packaging is concerned, this PR still builds packages correctly
for debian, someone should do a test build for RPM packages (i did the spec
changes but didn't build).



On Fri, Nov 21, 2014 at 3:50 PM, Ian Duffy  wrote:

> +1 on ec2stack working well (bias view).
>
> I've used it via vagrant-aws, boto and eucalyptus eutester without issue.
>
> It could use some documentation on deployment for production purposes, the
> embedded webserver it exposes is OK but I'd feel safer with it bring behind
> nginx/Apache.
> On 21 Nov 2014 14:31, "Hugo Trippaers"  wrote:
>
> > Let’s start by getting this on a feature branch.
> >
> > I would like to make sure that everything works before we remove the code
> > and that includes deb and rpm packaging. We also need to think about the
> > upgrade path. If a user is currently using awsapi, he needs an upgrade
> path
> > the start using the replacement.
> >
> > Cheers,
> >
> > Hugo
> >
> > > On 21 nov. 2014, at 14:39, Sebastien Goasguen 
> wrote:
> > >
> > >
> > > On Nov 21, 2014, at 8:33 AM, Nux!  wrote:
> > >
> > >> +1 what Daan said.
> > >>
> > >> Once ec2stack works well, then nuke awsapi.
> > >>
> > >
> > > it works well.
> > >
> > > where can we see test about awsapi ?
> > >
> > >> my 2 pence
> > >>
> > >> --
> > >> Sent from the Delta quadrant using Borg technology!
> > >>
> > >> Nux!
> > >> www.nux.ro
> > >>
> > >> - Original Message -
> > >>> From: "Daan Hoogland" 
> > >>> To: "dev" 
> > >>> Sent: Friday, 21 November, 2014 13:16:25
> > >>> Subject: Re: [GitHub] cloudstack pull request: Remove AWS api bridge
> > >>
> > >>> As Seb mentioned on list there is an alternative. I don't think we
> > >>> should remove this before the factored out version is working as well
> > >>> (or the alternative he mentions is at least as complete) The idea of
> > >>> isolating this bit is appealing though.
> > >>>
> > >>> Daan
> > >>>
> > >>> On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
> >  Hello,
> > 
> >  EC2 compatibility is an essential feature for potential ACS
> adopters.
> >  What alternatives are there for the AWSAPI component?
> > 
> >  Lucian
> > 
> >  --
> >  Sent from the Delta quadrant using Borg technology!
> > 
> >  Nux!
> >  www.nux.ro
> > 
> >  - Original Message -
> > > From: "pyr" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Friday, 21 November, 2014 10:18:58
> > > Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
> > 
> > > GitHub user pyr opened a pull request:
> > >
> > >  https://github.com/apache/cloudstack/pull/44
> > >
> > >  Remove AWS api bridge
> > >
> > >  This has been a discussion point for a while. The (mostly
> generated)
> > >  code for the AWS api bridge is by far the largest source component
> > in
> > >  Cloudstack, while seldomly used.
> > >
> > >  Now that alternate options exist to provide EC2 compatibility, it
> > >  makes sense to remove it for the few users who cannot directly
> > >  talk to the cloudstack API.
> > >
> > > You can merge this pull request into a Git repository by running:
> > >
> > >  $ git pull https://github.com/pyr/cloudstack feature/no-dead-code
> > >
> > > Alternatively you can review and apply these changes as the patch
> at:
> > >
> > >  https://github.com/apache/cloudstack/pull/44.patch
> > >
> > > To close this pull request, make a commit to your master/trunk
> branch
> > > with (at least) the following in the commit message:
> > >
> > >  This closes #44
> > >
> > > 
> > > commit 84042f2c3259203b1ea1956cd239b9122079bae9
> > > Author: Pierre-Yves Ritschard 
> > > Date:   2014-11-21T10:17:18Z
> > >
> > >  Remove AWS api bridge
> > >
> > >  This has been a discussion point for a while. The (mostly
> generated)
> > >  code for the AWS api bridge is by far the largest source component
> > in
> > >  Cloudstack, while seldomly used.
> > >
> > >  Now that alternate options exist to provide EC2 compatibility, it
> > >  makes sense to remove it for the few users who cannot directly
> > >  talk to the cloudstack API.
> > >
> > > 
> > >
> > >
> > > ---
> > > If your project is set up for it, you can reply to this email and
> > have your
> > > reply appear on GitHub as well. If your project does not have this
> > feature
> > > enabled and wishes so, or if the feature is enabled but not
> working,
> > please
> > > c

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

[jenkins]

See 

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Ian Duffy]

+1 on ec2stack working well (bias view).

I've used it via vagrant-aws, boto and eucalyptus eutester without issue.

It could use some documentation on deployment for production purposes, the
embedded webserver it exposes is OK but I'd feel safer with it bring behind
nginx/Apache.
On 21 Nov 2014 14:31, "Hugo Trippaers"  wrote:

> Let’s start by getting this on a feature branch.
>
> I would like to make sure that everything works before we remove the code
> and that includes deb and rpm packaging. We also need to think about the
> upgrade path. If a user is currently using awsapi, he needs an upgrade path
> the start using the replacement.
>
> Cheers,
>
> Hugo
>
> > On 21 nov. 2014, at 14:39, Sebastien Goasguen  wrote:
> >
> >
> > On Nov 21, 2014, at 8:33 AM, Nux!  wrote:
> >
> >> +1 what Daan said.
> >>
> >> Once ec2stack works well, then nuke awsapi.
> >>
> >
> > it works well.
> >
> > where can we see test about awsapi ?
> >
> >> my 2 pence
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >>> From: "Daan Hoogland" 
> >>> To: "dev" 
> >>> Sent: Friday, 21 November, 2014 13:16:25
> >>> Subject: Re: [GitHub] cloudstack pull request: Remove AWS api bridge
> >>
> >>> As Seb mentioned on list there is an alternative. I don't think we
> >>> should remove this before the factored out version is working as well
> >>> (or the alternative he mentions is at least as complete) The idea of
> >>> isolating this bit is appealing though.
> >>>
> >>> Daan
> >>>
> >>> On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
>  Hello,
> 
>  EC2 compatibility is an essential feature for potential ACS adopters.
>  What alternatives are there for the AWSAPI component?
> 
>  Lucian
> 
>  --
>  Sent from the Delta quadrant using Borg technology!
> 
>  Nux!
>  www.nux.ro
> 
>  - Original Message -
> > From: "pyr" 
> > To: dev@cloudstack.apache.org
> > Sent: Friday, 21 November, 2014 10:18:58
> > Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
> 
> > GitHub user pyr opened a pull request:
> >
> >  https://github.com/apache/cloudstack/pull/44
> >
> >  Remove AWS api bridge
> >
> >  This has been a discussion point for a while. The (mostly generated)
> >  code for the AWS api bridge is by far the largest source component
> in
> >  Cloudstack, while seldomly used.
> >
> >  Now that alternate options exist to provide EC2 compatibility, it
> >  makes sense to remove it for the few users who cannot directly
> >  talk to the cloudstack API.
> >
> > You can merge this pull request into a Git repository by running:
> >
> >  $ git pull https://github.com/pyr/cloudstack feature/no-dead-code
> >
> > Alternatively you can review and apply these changes as the patch at:
> >
> >  https://github.com/apache/cloudstack/pull/44.patch
> >
> > To close this pull request, make a commit to your master/trunk branch
> > with (at least) the following in the commit message:
> >
> >  This closes #44
> >
> > 
> > commit 84042f2c3259203b1ea1956cd239b9122079bae9
> > Author: Pierre-Yves Ritschard 
> > Date:   2014-11-21T10:17:18Z
> >
> >  Remove AWS api bridge
> >
> >  This has been a discussion point for a while. The (mostly generated)
> >  code for the AWS api bridge is by far the largest source component
> in
> >  Cloudstack, while seldomly used.
> >
> >  Now that alternate options exist to provide EC2 compatibility, it
> >  makes sense to remove it for the few users who cannot directly
> >  talk to the cloudstack API.
> >
> > 
> >
> >
> > ---
> > If your project is set up for it, you can reply to this email and
> have your
> > reply appear on GitHub as well. If your project does not have this
> feature
> > enabled and wishes so, or if the feature is enabled but not working,
> please
> > contact infrastructure at infrastruct...@apache.org or file a JIRA
> ticket
> > with INFRA.
> > ---
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >
>
>

Jenkins build is still unstable: simulator-singlerun #679

[jenkins]

See 

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Hugo Trippaers]

Let’s start by getting this on a feature branch.

I would like to make sure that everything works before we remove the code and 
that includes deb and rpm packaging. We also need to think about the upgrade 
path. If a user is currently using awsapi, he needs an upgrade path the start 
using the replacement.

Cheers,

Hugo

> On 21 nov. 2014, at 14:39, Sebastien Goasguen  wrote:
> 
> 
> On Nov 21, 2014, at 8:33 AM, Nux!  wrote:
> 
>> +1 what Daan said. 
>> 
>> Once ec2stack works well, then nuke awsapi.
>> 
> 
> it works well.
> 
> where can we see test about awsapi ?
> 
>> my 2 pence
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "Daan Hoogland" 
>>> To: "dev" 
>>> Sent: Friday, 21 November, 2014 13:16:25
>>> Subject: Re: [GitHub] cloudstack pull request: Remove AWS api bridge
>> 
>>> As Seb mentioned on list there is an alternative. I don't think we
>>> should remove this before the factored out version is working as well
>>> (or the alternative he mentions is at least as complete) The idea of
>>> isolating this bit is appealing though.
>>> 
>>> Daan
>>> 
>>> On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
 Hello,
 
 EC2 compatibility is an essential feature for potential ACS adopters.
 What alternatives are there for the AWSAPI component?
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 - Original Message -
> From: "pyr" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 21 November, 2014 10:18:58
> Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
 
> GitHub user pyr opened a pull request:
> 
>  https://github.com/apache/cloudstack/pull/44
> 
>  Remove AWS api bridge
> 
>  This has been a discussion point for a while. The (mostly generated)
>  code for the AWS api bridge is by far the largest source component in
>  Cloudstack, while seldomly used.
> 
>  Now that alternate options exist to provide EC2 compatibility, it
>  makes sense to remove it for the few users who cannot directly
>  talk to the cloudstack API.
> 
> You can merge this pull request into a Git repository by running:
> 
>  $ git pull https://github.com/pyr/cloudstack feature/no-dead-code
> 
> Alternatively you can review and apply these changes as the patch at:
> 
>  https://github.com/apache/cloudstack/pull/44.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
>  This closes #44
> 
> 
> commit 84042f2c3259203b1ea1956cd239b9122079bae9
> Author: Pierre-Yves Ritschard 
> Date:   2014-11-21T10:17:18Z
> 
>  Remove AWS api bridge
> 
>  This has been a discussion point for a while. The (mostly generated)
>  code for the AWS api bridge is by far the largest source component in
>  Cloudstack, while seldomly used.
> 
>  Now that alternate options exist to provide EC2 compatibility, it
>  makes sense to remove it for the few users who cannot directly
>  talk to the cloudstack API.
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have 
> your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, 
> please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>>> 
>>> 
>>> 
>>> --
>>> Daan
> 

Re: git commit: updated refs/heads/master to 8e689b1

[Rohit Yadav]

> On 21-Nov-2014, at 6:43 pm, Will Stevens  wrote:
>
> I created an issue for this:
> https://issues.apache.org/jira/browse/CLOUDSTACK-7959
>
> How do we deal with the fact that the system vm build machines do not
> support this option?  By removing this, the master system vms now build
> again.  If this is required for RHEL 6, do we have to update our system vm
> build systems so we can pass this flag without it completely breaking the
> builds?

+1

Good idea. I’ll see if Hugo, Talluri or someone with access on jenkins.b.o can 
help us explore/fix this.
At the same time, let’s wait for Edison’s reply on this.



>
> Will
>
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Fri, Nov 21, 2014 at 7:58 AM, Rohit Yadav  wrote:
>
>> Hi,
>>
>> On Fri, Nov 21, 2014 at 4:29 PM,  wrote:
>>
>>> Repository: cloudstack
>>> Updated Branches:
>>>  refs/heads/master 83656a6ea -> 8e689b114
>>>
>>>
>>> Updated the system vm build to remove incompatible qemu-img 'compat'
>> option
>>>
>>>
>> This sort of reverts the following fix from Edison; (should we do it as the
>> following commit mentions not using compatibility breaks the systemvm in
>> some environment?)
>>
>> commit 05bec59c1498dbcfb8a1089c86855fd3b433ea58
>> Author: Edison Su 
>> Date:   Thu Nov 6 15:09:31 2014 -0800
>>
>>CS-27148 system vm image build process, needs to build an old version
>> of qemu image, otherwise, it won't work on RHEL 6 Reviewed-by:Frank
>>
>>
>>
>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
>>> Commit:
>> http://git-wip-us.apache.org/repos/asf/cloudstack/commit/8e689b11
>>> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/8e689b11
>>> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/8e689b11
>>>
>>> Branch: refs/heads/master
>>> Commit: 8e689b1148e07d98378bb87f54528a92f79acedd
>>> Parents: 83656a6
>>> Author: Will Stevens 
>>> Authored: Fri Nov 21 05:59:06 2014 -0500
>>> Committer: Will Stevens 
>>> Committed: Fri Nov 21 05:59:06 2014 -0500
>>>
>>> --
>>> tools/appliance/build.sh | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> --
>>>
>>>
>>>
>>>
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/8e689b11/tools/appliance/build.sh
>>> --
>>> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
>>> index afbae50..4ff99b8 100755
>>> --- a/tools/appliance/build.sh
>>> +++ b/tools/appliance/build.sh
>>> @@ -427,7 +427,7 @@ function kvm_export() {
>>> log INFO "creating kvm export"
>>> local hdd_path="${1}"
>>> vboxmanage internalcommands converttoraw -format vdi "${hdd_path}"
>>> raw.img
>>> -qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
>>> "${appliance_build_name}-kvm.qcow2"
>>> +qemu-img convert -f raw -c -O qcow2 raw.img
>>> "${appliance_build_name}-kvm.qcow2"
>>> add_on_exit rm -f raw.img
>>> bzip2 "${appliance_build_name}-kvm.qcow2"
>>> mv "${appliance_build_name}-kvm.qcow2.bz2" dist/
>>>
>>>
>>

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.

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Sebastien Goasguen]

On Nov 21, 2014, at 8:33 AM, Nux!  wrote:

> +1 what Daan said. 
> 
> Once ec2stack works well, then nuke awsapi.
> 

it works well.

where can we see test about awsapi ?

> my 2 pence
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Friday, 21 November, 2014 13:16:25
>> Subject: Re: [GitHub] cloudstack pull request: Remove AWS api bridge
> 
>> As Seb mentioned on list there is an alternative. I don't think we
>> should remove this before the factored out version is working as well
>> (or the alternative he mentions is at least as complete) The idea of
>> isolating this bit is appealing though.
>> 
>> Daan
>> 
>> On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
>>> Hello,
>>> 
>>> EC2 compatibility is an essential feature for potential ACS adopters.
>>> What alternatives are there for the AWSAPI component?
>>> 
>>> Lucian
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>>> 
>>> - Original Message -
 From: "pyr" 
 To: dev@cloudstack.apache.org
 Sent: Friday, 21 November, 2014 10:18:58
 Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
>>> 
 GitHub user pyr opened a pull request:
 
   https://github.com/apache/cloudstack/pull/44
 
   Remove AWS api bridge
 
   This has been a discussion point for a while. The (mostly generated)
   code for the AWS api bridge is by far the largest source component in
   Cloudstack, while seldomly used.
 
   Now that alternate options exist to provide EC2 compatibility, it
   makes sense to remove it for the few users who cannot directly
   talk to the cloudstack API.
 
 You can merge this pull request into a Git repository by running:
 
   $ git pull https://github.com/pyr/cloudstack feature/no-dead-code
 
 Alternatively you can review and apply these changes as the patch at:
 
   https://github.com/apache/cloudstack/pull/44.patch
 
 To close this pull request, make a commit to your master/trunk branch
 with (at least) the following in the commit message:
 
   This closes #44
 
 
 commit 84042f2c3259203b1ea1956cd239b9122079bae9
 Author: Pierre-Yves Ritschard 
 Date:   2014-11-21T10:17:18Z
 
   Remove AWS api bridge
 
   This has been a discussion point for a while. The (mostly generated)
   code for the AWS api bridge is by far the largest source component in
   Cloudstack, while seldomly used.
 
   Now that alternate options exist to provide EC2 compatibility, it
   makes sense to remove it for the few users who cannot directly
   talk to the cloudstack API.
 
 
 
 
 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---
>> 
>> 
>> 
>> --
>> Daan

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Nux!]

+1 what Daan said. 

Once ec2stack works well, then nuke awsapi.

my 2 pence

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Sent: Friday, 21 November, 2014 13:16:25
> Subject: Re: [GitHub] cloudstack pull request: Remove AWS api bridge

> As Seb mentioned on list there is an alternative. I don't think we
> should remove this before the factored out version is working as well
> (or the alternative he mentions is at least as complete) The idea of
> isolating this bit is appealing though.
> 
> Daan
> 
> On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
>> Hello,
>>
>> EC2 compatibility is an essential feature for potential ACS adopters.
>> What alternatives are there for the AWSAPI component?
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "pyr" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Friday, 21 November, 2014 10:18:58
>>> Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
>>
>>> GitHub user pyr opened a pull request:
>>>
>>>https://github.com/apache/cloudstack/pull/44
>>>
>>>Remove AWS api bridge
>>>
>>>This has been a discussion point for a while. The (mostly generated)
>>>code for the AWS api bridge is by far the largest source component in
>>>Cloudstack, while seldomly used.
>>>
>>>Now that alternate options exist to provide EC2 compatibility, it
>>>makes sense to remove it for the few users who cannot directly
>>>talk to the cloudstack API.
>>>
>>> You can merge this pull request into a Git repository by running:
>>>
>>>$ git pull https://github.com/pyr/cloudstack feature/no-dead-code
>>>
>>> Alternatively you can review and apply these changes as the patch at:
>>>
>>>https://github.com/apache/cloudstack/pull/44.patch
>>>
>>> To close this pull request, make a commit to your master/trunk branch
>>> with (at least) the following in the commit message:
>>>
>>>This closes #44
>>>
>>> 
>>> commit 84042f2c3259203b1ea1956cd239b9122079bae9
>>> Author: Pierre-Yves Ritschard 
>>> Date:   2014-11-21T10:17:18Z
>>>
>>>Remove AWS api bridge
>>>
>>>This has been a discussion point for a while. The (mostly generated)
>>>code for the AWS api bridge is by far the largest source component in
>>>Cloudstack, while seldomly used.
>>>
>>>Now that alternate options exist to provide EC2 compatibility, it
>>>makes sense to remove it for the few users who cannot directly
>>>talk to the cloudstack API.
>>>
>>> 
>>>
>>>
>>> ---
>>> If your project is set up for it, you can reply to this email and have your
>>> reply appear on GitHub as well. If your project does not have this feature
>>> enabled and wishes so, or if the feature is enabled but not working, please
>>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>>> with INFRA.
>>> ---
> 
> 
> 
> --
> Daan

Jenkins build is still unstable: simulator-singlerun #678

[jenkins]

See 

Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount

[Rohit Yadav]

Hi Prachi,

Since we’re already allowing users to specific account and list VMs by account, 
following the same pattern I added the case so as to allow users to specify 
user_id in both list/deploy VM commands. In case the userid is not specified, 
in that case the logged in user’s ID will be used.

It’s open for discussion of course, let me know if it’s a good idea to follow 
the same pattern or strictly use the logged-in user’s ID?

> On 21-Nov-2014, at 1:41 am, Prachi Damle  wrote:
>
> Rohit,
>
> I checked the code here 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring
>  and I don't understand why we need to expose the userId parameter in the 
> deployVm API.
> I think we should be using the userId of the logged in user always.
> Exposing the parameter at the API allows it to be set by a user to the ID of 
> another user . Also we need validation around it to make sure it belongs to 
> the passed account etc.
>
> +//Owner userId
> +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, 
> entityType = UserResponse.class, required = true, description = "the user ID 
> of the owner, optional to use with account and domainId. If not provided 
> logged in user's ID is used.")
> +private Long userId;
>
>
> Prachi
>
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Sunday, November 16, 2014 6:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to 
> UserAccount
>
> Only one table will be affected.
>
>> On 16-Nov-2014, at 3:14 am, Amogh Vasekar  wrote:
>>
>> Question - What happens to the already existing VMs with entries in
>> the DB? Do we keep it NULL?
>
> NULL will be and not useful. I think it should be okay to have a db migration 
> path that sets user_id to the first user in account_id (which usually has the 
> same name as account) for existing VMs. The amount of code change will be 
> minimal.
>
> Checkout some code in this branch (has the db migration code and API layer 
> changes); 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring
>
> 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.

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

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

[jenkins]

See 

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Daan Hoogland]

As Seb mentioned on list there is an alternative. I don't think we
should remove this before the factored out version is working as well
(or the alternative he mentions is at least as complete) The idea of
isolating this bit is appealing though.

Daan

On Fri, Nov 21, 2014 at 12:23 PM, Nux!  wrote:
> Hello,
>
> EC2 compatibility is an essential feature for potential ACS adopters.
> What alternatives are there for the AWSAPI component?
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "pyr" 
>> To: dev@cloudstack.apache.org
>> Sent: Friday, 21 November, 2014 10:18:58
>> Subject: [GitHub] cloudstack pull request: Remove AWS api bridge
>
>> GitHub user pyr opened a pull request:
>>
>>https://github.com/apache/cloudstack/pull/44
>>
>>Remove AWS api bridge
>>
>>This has been a discussion point for a while. The (mostly generated)
>>code for the AWS api bridge is by far the largest source component in
>>Cloudstack, while seldomly used.
>>
>>Now that alternate options exist to provide EC2 compatibility, it
>>makes sense to remove it for the few users who cannot directly
>>talk to the cloudstack API.
>>
>> You can merge this pull request into a Git repository by running:
>>
>>$ git pull https://github.com/pyr/cloudstack feature/no-dead-code
>>
>> Alternatively you can review and apply these changes as the patch at:
>>
>>https://github.com/apache/cloudstack/pull/44.patch
>>
>> To close this pull request, make a commit to your master/trunk branch
>> with (at least) the following in the commit message:
>>
>>This closes #44
>>
>> 
>> commit 84042f2c3259203b1ea1956cd239b9122079bae9
>> Author: Pierre-Yves Ritschard 
>> Date:   2014-11-21T10:17:18Z
>>
>>Remove AWS api bridge
>>
>>This has been a discussion point for a while. The (mostly generated)
>>code for the AWS api bridge is by far the largest source component in
>>Cloudstack, while seldomly used.
>>
>>Now that alternate options exist to provide EC2 compatibility, it
>>makes sense to remove it for the few users who cannot directly
>>talk to the cloudstack API.
>>
>> 
>>
>>
>> ---
>> If your project is set up for it, you can reply to this email and have your
>> reply appear on GitHub as well. If your project does not have this feature
>> enabled and wishes so, or if the feature is enabled but not working, please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---



-- 
Daan

Re: git commit: updated refs/heads/master to 8e689b1

[Will Stevens]

I created an issue for this:
https://issues.apache.org/jira/browse/CLOUDSTACK-7959

How do we deal with the fact that the system vm build machines do not
support this option?  By removing this, the master system vms now build
again.  If this is required for RHEL 6, do we have to update our system vm
build systems so we can pass this flag without it completely breaking the
builds?

Will


*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Fri, Nov 21, 2014 at 7:58 AM, Rohit Yadav  wrote:

> Hi,
>
> On Fri, Nov 21, 2014 at 4:29 PM,  wrote:
>
> > Repository: cloudstack
> > Updated Branches:
> >   refs/heads/master 83656a6ea -> 8e689b114
> >
> >
> > Updated the system vm build to remove incompatible qemu-img 'compat'
> option
> >
> >
> This sort of reverts the following fix from Edison; (should we do it as the
> following commit mentions not using compatibility breaks the systemvm in
> some environment?)
>
> commit 05bec59c1498dbcfb8a1089c86855fd3b433ea58
> Author: Edison Su 
> Date:   Thu Nov 6 15:09:31 2014 -0800
>
> CS-27148 system vm image build process, needs to build an old version
> of qemu image, otherwise, it won't work on RHEL 6 Reviewed-by:Frank
>
>
>
>
> >
> > Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> > Commit:
> http://git-wip-us.apache.org/repos/asf/cloudstack/commit/8e689b11
> > Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/8e689b11
> > Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/8e689b11
> >
> > Branch: refs/heads/master
> > Commit: 8e689b1148e07d98378bb87f54528a92f79acedd
> > Parents: 83656a6
> > Author: Will Stevens 
> > Authored: Fri Nov 21 05:59:06 2014 -0500
> > Committer: Will Stevens 
> > Committed: Fri Nov 21 05:59:06 2014 -0500
> >
> > --
> >  tools/appliance/build.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > --
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/8e689b11/tools/appliance/build.sh
> > --
> > diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
> > index afbae50..4ff99b8 100755
> > --- a/tools/appliance/build.sh
> > +++ b/tools/appliance/build.sh
> > @@ -427,7 +427,7 @@ function kvm_export() {
> >  log INFO "creating kvm export"
> >  local hdd_path="${1}"
> >  vboxmanage internalcommands converttoraw -format vdi "${hdd_path}"
> > raw.img
> > -qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
> > "${appliance_build_name}-kvm.qcow2"
> > +qemu-img convert -f raw -c -O qcow2 raw.img
> > "${appliance_build_name}-kvm.qcow2"
> >  add_on_exit rm -f raw.img
> >  bzip2 "${appliance_build_name}-kvm.qcow2"
> >  mv "${appliance_build_name}-kvm.qcow2.bz2" dist/
> >
> >
>

Re: git commit: updated refs/heads/4.5 to 50d756e

[Rohit Yadav]

Hi Edison,

On Fri, Nov 21, 2014 at 12:30 AM,  wrote:

> Repository: cloudstack
> Updated Branches:
>   refs/heads/4.5 1d6ca5eac -> 50d756e87
>
>
> Occasionally the while loop can exit with no data (Probably recieving an
> EOF) before receiveing CMDline data from the certial port. Continue looping
> until cmdline is populated
>

Should we port/cherry-pick/merge this to master as well?


>
> Signed-off-by: Edison Su 
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/50d756e8
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/50d756e8
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/50d756e8
>
> Branch: refs/heads/4.5
> Commit: 50d756e87d26f0ac86e7897505ad2747735c4d5c
> Parents: 1d6ca5e
> Author: David Bierce 
> Authored: Fri Sep 12 10:52:29 2014 -0500
> Committer: Edison Su 
> Committed: Thu Nov 20 10:58:35 2014 -0800
>
> --
>  .../debian/config/etc/init.d/cloud-early-config | 22 +++-
>  1 file changed, 12 insertions(+), 10 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/50d756e8/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> --
> diff --git a/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> b/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> index 11d0612..294ae5f 100755
> --- a/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> +++ b/systemvm/patches/debian/config/etc/init.d/cloud-early-config
> @@ -117,16 +117,18 @@ get_boot_params() {
>if [ ! -e /dev/vport0p1 ]; then
>  log_it "/dev/vport0p1 not loaded, perhaps guest kernel is too
> old." && exit 2
>fi
> -  while read line; do
> -if [[ $line == cmdline:* ]]; then
> -  cmd=${line//cmdline:/}
> -  echo $cmd > /var/cache/cloud/cmdline
> -elif [[ $line == pubkey:* ]]; then
> -  pubkey=${line//pubkey:/}
> -  echo $pubkey > /var/cache/cloud/authorized_keys
> -  echo $pubkey > /root/.ssh/authorized_keys
> -fi
> -  done < /dev/vport0p1
> + while [$cmd -eq ""]; do
> +while read line; do
> +  if [[ $line == cmdline:* ]]; then
> +cmd=${line//cmdline:/}
> +echo $cmd > /var/cache/cloud/cmdline
> +  elif [[ $line == pubkey:* ]]; then
> +pubkey=${line//pubkey:/}
> +echo $pubkey > /var/cache/cloud/authorized_keys
> +echo $pubkey > /root/.ssh/authorized_keys
> +  fi
> +done < /dev/vport0p1
> + done
>chmod go-rwx /root/.ssh/authorized_keys
>;;
>   vmware)
>
>

Re: git commit: updated refs/heads/master to 8e689b1

[Rohit Yadav]

Hi,

On Fri, Nov 21, 2014 at 4:29 PM,  wrote:

> Repository: cloudstack
> Updated Branches:
>   refs/heads/master 83656a6ea -> 8e689b114
>
>
> Updated the system vm build to remove incompatible qemu-img 'compat' option
>
>
This sort of reverts the following fix from Edison; (should we do it as the
following commit mentions not using compatibility breaks the systemvm in
some environment?)

commit 05bec59c1498dbcfb8a1089c86855fd3b433ea58
Author: Edison Su 
Date:   Thu Nov 6 15:09:31 2014 -0800

CS-27148 system vm image build process, needs to build an old version
of qemu image, otherwise, it won't work on RHEL 6 Reviewed-by:Frank




>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/8e689b11
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/8e689b11
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/8e689b11
>
> Branch: refs/heads/master
> Commit: 8e689b1148e07d98378bb87f54528a92f79acedd
> Parents: 83656a6
> Author: Will Stevens 
> Authored: Fri Nov 21 05:59:06 2014 -0500
> Committer: Will Stevens 
> Committed: Fri Nov 21 05:59:06 2014 -0500
>
> --
>  tools/appliance/build.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/8e689b11/tools/appliance/build.sh
> --
> diff --git a/tools/appliance/build.sh b/tools/appliance/build.sh
> index afbae50..4ff99b8 100755
> --- a/tools/appliance/build.sh
> +++ b/tools/appliance/build.sh
> @@ -427,7 +427,7 @@ function kvm_export() {
>  log INFO "creating kvm export"
>  local hdd_path="${1}"
>  vboxmanage internalcommands converttoraw -format vdi "${hdd_path}"
> raw.img
> -qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
> "${appliance_build_name}-kvm.qcow2"
> +qemu-img convert -f raw -c -O qcow2 raw.img
> "${appliance_build_name}-kvm.qcow2"
>  add_on_exit rm -f raw.img
>  bzip2 "${appliance_build_name}-kvm.qcow2"
>  mv "${appliance_build_name}-kvm.qcow2.bz2" dist/
>
>

[GitHub] cloudstack pull request: Remove AWS api bridge

[runseb]

Github user runseb commented on the pull request:

https://github.com/apache/cloudstack/pull/44#issuecomment-63965999
  
This is green on travis, so let's discuss on the list. I am asking asf 
infra to create a cloudstack-awsapi repo.
One alternative is https://github.com/BroganD1993/ec2stack/commits/master 
but it will need more work. 


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

Jenkins build is still unstable: simulator-singlerun #677

[jenkins]

See 

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

[jenkins]

See 

Changes:

[Will Stevens] CLOUDSTACK-7822: Fixed SSL Cert Tests and relaxed chain 
validation

[Will Stevens] CLOUDSTACK-7952: Remove private key from SslCertResponse 
(listSslCerts)

--
[...truncated 924 lines...]
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-core 
---
[INFO] Compiling 331 source files to 

[INFO] 
[INFO] --- license-maven-plugin:2.5:check (cloudstack-checklicence) @ 
cloud-core ---
[INFO] Checking licenses...
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-core ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-core ---
[INFO] Compiling 21 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-core ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running com.cloud.network.HAProxyConfiguratorTest
log4j:WARN No appenders could be found for logger 
(com.cloud.network.HAProxyConfigurator).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.792 sec
Running com.cloud.agent.resource.virtualnetwork.VirtualRoutingResourceTest
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.116 sec
Running com.cloud.agent.transport.RequestTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.13 sec
Running org.apache.cloudstack.api.agent.test.BackupSnapshotAnswerTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.161 sec
Running org.apache.cloudstack.api.agent.test.AttachVolumeCommandTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec
Running org.apache.cloudstack.api.agent.test.ChangeAgentCommandTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.cloudstack.api.agent.test.BackupSnapshotCommandTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.083 sec
Running org.apache.cloudstack.api.agent.test.CheckOnHostCommandTest
Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.185 sec
Running org.apache.cloudstack.api.agent.test.AnswerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec
Running org.apache.cloudstack.api.agent.test.CheckNetworkAnswerTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec
Running org.apache.cloudstack.api.agent.test.ChangeAgentAnswerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.cloudstack.api.agent.test.CheckNetworkCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec
Running org.apache.cloudstack.api.agent.test.SnapshotCommandTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
Running org.apache.cloudstack.api.agent.test.CancelCommandTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.cloudstack.api.agent.test.CheckHealthCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.cloudstack.api.agent.test.BumpUpPriorityCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec
Running org.apache.cloudstack.api.agent.test.CheckHealthAnswerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.cloudstack.api.agent.test.AgentControlCommandTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.cloudstack.api.agent.test.AgentControlAnswerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.cloudstack.api.agent.test.AttachVolumeAnswerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.cloudstack.api.agent.test.AttachIsoCommandTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec

Results :

Tests run: 139, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Agents 4.5.0-SNAPSHOT

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

[jenkins]

See 

Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates

[Stephen Turner]

I didn't even realise we still support XS 5.6. I would advocate not supporting 
that any more, independent of this tools discussion, because Citrix won't fix 
any bugs on it now, even security bugs. Can't we move to a model where we only 
support hypervisor versions that the hypervisor vendor supports?

--
Stephen Turner




From: Tim Mackey 
Date: 21 November 2014 09:38:21 CET
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates

The big problem I recall with the 5.6 Linux tools happened during live
migration.  I don't recall the specific circumstances, but if the VM was
migrated, it could cause either the guest or the host to crash.  I've never
paid attention to the specific Linux version in the system VMs, but the
tools themselves aren't supported for installation on a newer version of an
operating system than what was originally certified.  XenCenter when faced
with 5.6 tools on a 6.2 host would actually say that the tools are there
but need to be upgraded for optimal performance.

This also opens the question of XCP and the tools since XenServer tools
were never designed to work with XCP.  They probably do work just fine, but
if there was an issue we'd be challenged to get it sorted.

If the option of automatically having the tools installed isn't viable, the
next things I'd look at would be:

- removing support for XenServer versions prior to 6.0
- removing support for XCP (or at least only supporting 1.6)
- having the rpm/deb packages for each version of hypervisor pre-loaded
(assuming redist EULA) and when a systemVM starts having a first boot which
installs the correct package and then reboots the system VM

At least that way the tools would be there, and we'd have better system VM
performance while still locking ourselves to specific supported hypervisor
versions.  No idea what impact removal of support for older XenServer
versions might have on the install base, but I'd hope those on 5.6 would at
least be planning an upgrade given 5.6 went EOL from Citrix a while back.

-tim

On Fri, Nov 21, 2014 at 3:15 AM, Rohit Yadav 
wrote:

> Tim, during 4.0/4.1 we used to install a very old xstools 5.6, can we just
> use that and if we do will that cause any (potential) issue since you
> mentioned it has few bugs in it?
>
> Regards.
>
> > On 20-Nov-2014, at 10:23 pm, Tim Mackey  wrote:
> >
> > It's the other way around.  Newer XenServer works with older tools, not
> the
> > other way.
> > On Nov 20, 2014 4:57 PM, "Rohit Yadav" 
> wrote:
> >
> >> If XenServer tools are backward compatible then we can perhaps install
> the
> >> latest xs-tools (6.2)? Will that cause issue if the underlying
> >> Xen/XenServer hypervisor version is not 6.2?
> >>
> >>> On 20-Nov-2014, at 9:12 pm, Tim Mackey  wrote:
> >>>
> >>> From the XenServer perspective, we have a small problem.  The XenServer
> >>> tools are backward compatible, but not guaranteed forward compatible.
> >> What
> >>> that means is we'd need to include the XenServer 5.6 tools, and those
> >> have
> >>> a commercial license.  The XenServer 5.6 tools also have a few bugs
> which
> >>> were fixed in later versions.
> >>>
> >>> I'm certain we could define a minimum version which would work, and
> could
> >>> solve any commercial license concerns, but what about having the system
> >> VMs
> >>> automatically download and apply the correct tools?  Since we know the
> >>> hypervisor version, could we even go so far as automatically update the
> >>> tools should the hypervisor be upgraded?
> >>>
> >>> -tim
> >>>
> >>> On Thu, Nov 20, 2014 at 10:19 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com
> >>>
> >>> wrote:
> >>>
>  Hi,
> 
>  During the CCCEU conference, I’ve been in some discussions with few
> >> people
>  on whether we should install/bundle xenserver tools (and vmware tools
>  and/or virtio-modules).
> 
>  I think we can easily do this, but let’s discuss the following;
> 
>  - Which version of xs-tools etc. we should install? For the build
> >> system,
>  is a publicly available source (iso etc)?
>  - Will installing these tools cause any issue?
>  - If we install all these tools on a single template, could that cause
> >> any
>  issue?
> 
>  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<
>  http://shapeblue.com/iaas-cloud-design-and-build//>
>  CSForge – rapid IaaS deployment framework<
> http://shapeblue.com/csforge/
> >>>
>  CloudStack Consulting
>  CloudStack Software Engineering<
>  http://shapeblue.com/cloudstack-software-engineering/>
>  CloudStack Infrastructure Support<
>  http://sh

Build failed in Jenkins: build-master-noredist #3836

[jenkins]

See 

Changes:

[Will Stevens] Updated the system vm build to remove incompatible qemu-img 
'compat' option

--
[...truncated 14255 lines...]
221/509 KB   150/166 KB   51/51 KB   394/441 KB   
221/509 KB   150/166 KB   51/51 KB   398/441 KB   
221/509 KB   150/166 KB   51/51 KB   402/441 KB   
221/509 KB   150/166 KB   51/51 KB   406/441 KB   
221/509 KB   150/166 KB   51/51 KB   410/441 KB   
221/509 KB   150/166 KB   51/51 KB   414/441 KB   
221/509 KB   150/166 KB   51/51 KB   418/441 KB   
221/509 KB   150/166 KB   51/51 KB   422/441 KB   
221/509 KB   150/166 KB   51/51 KB   426/441 KB   
221/509 KB   150/166 KB   51/51 KB   430/441 KB   
221/509 KB   150/166 KB   51/51 KB   434/441 KB   
221/509 KB   150/166 KB   51/51 KB   438/441 KB   
221/509 KB   150/166 KB   51/51 KB   441/441 KB   
224/509 KB   150/166 KB   51/51 KB   441/441 KB   
225/509 KB   150/166 KB   51/51 KB   441/441 KB   
226/509 KB   150/166 KB   51/51 KB   441/441 KB   
229/509 KB   150/166 KB   51/51 KB   441/441 KB   
232/509 KB   150/166 KB   51/51 KB   441/441 KB   
236/509 KB   150/166 KB   51/51 KB   441/441 KB   
240/509 KB   150/166 KB   51/51 KB   441/441 KB   
244/509 KB   150/166 KB   51/51 KB   441/441 KB   
248/509 KB   150/166 KB   51/51 KB   441/441 KB   
249/509 KB   150/166 KB   51/51 KB   441/441 KB   
  
Downloaded: 
http://repo.maven.apache.org/maven2/com/mycila/mycila-xmltool/4.0.ga/mycila-xmltool-4.0.ga.jar
 (51 KB at 1293.0 KB/sec)
252/509 KB   150/166 KB   441/441 KB  
255/509 KB   150/166 KB   441/441 KB   
257/509 KB   150/166 KB   441/441 KB   
260/509 KB   150/166 KB   441/441 KB   
262/509 KB   150/166 KB   441/441 KB   
266/509 KB   150/166 KB   441/441 KB   
270/509 KB   150/166 KB   441/441 KB   
274/509 KB   150/166 KB   441/441 KB   
277/509 KB   150/166 KB   441/441 KB   
   
Downloaded: 
http://repo.maven.apache.org/maven2/org/springframework/spring-core/3.1.3.RELEASE/spring-core-3.1.3.RELEASE.jar
 (441 KB at 6293.2 KB/sec)
280/509 KB   150/166 KB
283/509 KB   150/166 KB   
284/509 KB   150/166 KB   
288/509 KB   150/166 KB   
292/509 KB   150/166 KB   
296/509 KB   150/166 KB   
300/509 KB   150/166 KB   
304/509 KB   150/166 KB   
307/509 KB   150/166 KB   
310/509 KB   150/166 KB   
313/509 KB   150/166 KB   
315/509 KB   150/166 KB   
318/509 KB   150/166 KB   
322/509 KB   150/166 KB   
326/509 KB   150/166 KB   
330/509 KB   150/166 KB   
334/509 KB   150/166 KB   
337/509 KB   150/166 KB   
339/509 KB   150/166 KB   
341/509 KB   150/166 KB   
342/509 KB   150/166 KB   
345/509 KB   150/166 KB   
348/509 KB   150/166 KB   
351/509 KB   150/166 KB   
354/509 KB   150/166 KB   
356/509 KB   150/166 KB   
359/509 KB   150/166 KB   
361/509 KB   150/166 KB   
365/509 KB   150/166 KB   
365/509 KB   150/166 KB   
368/509 KB   150/166 KB   
371/509 KB   150/166 KB   
373/509 KB   150/166 KB   
376/509 KB   150/166 KB   
379/509 KB   150/166 KB   
383/509 KB   150/166 KB   
385/509 KB   150/166 KB   
388/509 KB   150/166 KB   
392/509 KB   150/166 KB   
393/509 KB   150/166 KB   
396/509 KB   150/166 KB   
400/509 KB   150/166 KB   
403/509 KB   150/166 KB   
406/509 KB   150/166 KB   
410/509 KB   150/166 KB   
414/509 KB   150/166 KB   
418/509 KB   150/166 KB   
422/509 KB   150/166 KB   
423/509 KB   150/166 KB   
426/509 KB   150/166 KB   
430/509 KB   150/166 KB   
434/509 KB   150/166 KB   
434/509 KB   150/166 KB   
438/509 KB   150/166 KB   
442/509 KB   150/166 KB   
446/509 KB   150/166 KB   
450/509 KB   150/166 KB   
454/509 KB   150/166 KB   
457/509 KB   150/166 KB   
461/509 KB   150/166 KB   
465/509 KB   150/166 KB   
465/509 KB   150/166 KB   
467/509 KB   150/166 KB   
471/509 KB   150/166 KB   
475/509 KB   150/166 KB   
479/509 KB   150/166 KB   
483/509 KB   150/166 KB   
485/509 KB   150/166 KB   
488/509 KB   150/166 KB   
492/509 KB   150/166 KB   
496/509 KB   150/166 KB   
500/509 KB   150/166 KB   
504/509 KB   150/166 KB   
508/509 KB   150/166 KB   
509/509 KB   150/166 KB   
  
Downloaded: 
http://repo.maven.apache.org/maven2/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar
 (509 KB at 2807.7 KB/sec)
151/166 KB
154/166 KB   
157/166 KB   
160/166 KB   
164/166 KB   
166/166 KB   
 
Downloaded: 
http://repo.maven.apache.org/maven2/org/apache/maven/maven-project-builder/3.0-alpha-2/maven-project-builder-3.0-alpha-2.jar
 (166 KB at 587.6 KB/sec)
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration  SUCCESS 
[4.059s]
[INFO] Apache CloudStack . SUCCESS [8.584s]
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [2.341s]
[I

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Nux!]

Oh, roger that, thanks.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Sent: Friday, 21 November, 2014 10:18:18
> Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

> Lucian, the non oss deps need to be added to the repository by hand.
> They can not be downloaded automatically. This is basically why there
> is a separate build (from a tech point of view).
> 
> On Fri, Nov 21, 2014 at 10:42 AM, Nux!  wrote:
>> Hi,
>>
>> Built OSS rpms here http://tmp.nux.ro/acs442/
>>
>> The jenkins build are they oss or noredist? I could not build noredist:
>>
>> Could not resolve dependencies for project
>> org.apache.cloudstack:cloud-plugin-netapp:jar:4.4.2: Could not find artifact
>> com.cloud.com.netapp:manageontap:jar:4.0 in central
>> (http://repo.maven.apache.org/maven2
>>
>> http://fpaste.org/152729/62916141/raw/
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Wido den Hollander" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Friday, 21 November, 2014 09:27:44
>>> Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
>>
>>> On 11/21/2014 10:23 AM, Tomasz Zięba wrote:
 Is there available RPM Repository with ACS 4.4.2 ?

>>>
>>> You can find those on Jenkins:
>>> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/
>>>
 2014-11-21 3:59 GMT+01:00 Daan Hoogland :

> Hi All,
>
> I've created a 4.4.2 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
> Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
>
> List of changes:
> `CLOUDSTACK-7887
> `_  fail to
> push snapshot to secondary storage if using multipart using swift...
>
> `CLOUDSTACK-7883
> `_  Allow
> infrastructure to handle delete of volume from DB...
>
> `CLOUDSTACK-7871
> `_  Fix update
> VirtualMachine/Template API to allow nic/disk controller details for
> ...
>
> `CLOUDSTACK-7855
> `_  Sec
> storage/network MTU should be on nic3 and not nic1...
>
> `CLOUDSTACK-7826
> `_  UI - dialog
> widget - dependent dropdown field (dependsOn property specified) -
> f...
>
> `CLOUDSTACK-7822
> `_  test SSL
> cert expired...
>
> `CLOUDSTACK-7752
> `_  Management
> Server goes in infinite loop while creating a vm with tagged local
> da...
>
> `CLOUDSTACK-7722
> `_  add.label:
> Add button for tags show the label not "Add" text...
>
> `CLOUDSTACK-7246
> `_  VM
> deployment failed due to wrong in  script name createipalias.sh...
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2
>
> PGP release keys (signed using 4096R/AA4736F3):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> --
> Daan
>


> 
> 
> 
> --
> Daan

Re: [GitHub] cloudstack pull request: Remove AWS api bridge

[Nux!]

Hello,

EC2 compatibility is an essential feature for potential ACS adopters. 
What alternatives are there for the AWSAPI component?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "pyr" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 21 November, 2014 10:18:58
> Subject: [GitHub] cloudstack pull request: Remove AWS api bridge

> GitHub user pyr opened a pull request:
> 
>https://github.com/apache/cloudstack/pull/44
> 
>Remove AWS api bridge
> 
>This has been a discussion point for a while. The (mostly generated)
>code for the AWS api bridge is by far the largest source component in
>Cloudstack, while seldomly used.
>
>Now that alternate options exist to provide EC2 compatibility, it
>makes sense to remove it for the few users who cannot directly
>talk to the cloudstack API.
> 
> You can merge this pull request into a Git repository by running:
> 
>$ git pull https://github.com/pyr/cloudstack feature/no-dead-code
> 
> Alternatively you can review and apply these changes as the patch at:
> 
>https://github.com/apache/cloudstack/pull/44.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
>This closes #44
>
> 
> commit 84042f2c3259203b1ea1956cd239b9122079bae9
> Author: Pierre-Yves Ritschard 
> Date:   2014-11-21T10:17:18Z
> 
>Remove AWS api bridge
>
>This has been a discussion point for a while. The (mostly generated)
>code for the AWS api bridge is by far the largest source component in
>Cloudstack, while seldomly used.
>
>Now that alternate options exist to provide EC2 compatibility, it
>makes sense to remove it for the few users who cannot directly
>talk to the cloudstack API.
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Re: NetScaler 10.5

[Chiradeep Vittal]

Looks like it was fixed
https://issues.apache.org/jira/browse/CLOUDSTACK-6261

From: Francois Gaudreault 
mailto:fgaudrea...@cloudops.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, 
"fgaudrea...@cloudops.com" 
mailto:fgaudrea...@cloudops.com>>
Date: Thursday, November 20, 2014 at 6:29 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: NetScaler 10.5

Guys,

Is NetScaler 10.5 supposed to work on the 4.4.x branch? I was under to
impression there was a bug with the way ACS uses the API of 10.5,
correct? Is that bug fixed in 4.5? If its the case, can we merge back
that commit in 4.4?

Thanks!

--
Francois Gaudreault
Gestionnaire de Produit | Product Manager - Cloud Platform & Services
t:514-629-6775

CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w: cloudops.com | tw: @CloudOps_

Build failed in Jenkins: build-4.5 #159

[jenkins]

See 

--
[...truncated 6018 lines...]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-storage-image-default ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Surefire report directory: 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-storage-image-default ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-storage-image-default ---

---
 T E S T S
---
[INFO] Tests are skipped.
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Storage Volume SolidFire Provider 
4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-storage-volume-solidfire ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-storage-volume-solidfire ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-storage-image-sample ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-storage-image-sample ---
[INFO] Compiling 3 source files to 

[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-storage-volume-solidfire ---
Running com.cloud.network.element.MidoNetElementTest
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-storage-volume-solidfire ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-storage-volume-solidfire ---
[INFO] Compiling 9 source files to 

log4j:WARN No appenders could be found for logger 
(com.cloud.network.element.MidoNetElement).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.378 sec

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Storage Volume CloudByte Provider 
4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-storage-volume-cloudbyte ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-storage-volume-cloudbyte ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-storage-image-sample ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-storage-image-sample ---
[INFO] No sources to compile
[INFO] 
[I

Review Request 28325: Two "VOLUME.DELETE" Events are being registered instead of one - On Destroying a User VM belonging to a Project

[Damodar Reddy Talakanti]

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

Review request for cloudstack and Kishan Kavala.


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


Repository: cloudstack-git


Description
---

When we destroy a VM it is publishing two VOLUME DELETE events into usage 
events for ROOT VOLUME.


Diffs
-

  server/src/com/cloud/storage/listener/VolumeStateListener.java 9fd1423 

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


Testing
---

Tested as a normal user
Tested as a admin (With and with out pasing expunge flag)
Tested by attaching Data disks


Thanks,

Damodar Reddy Talakanti

Build failed in Jenkins: build-4.5 #158

[jenkins]

See 

--
[...truncated 3522 lines...]
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-user-authenticator-sha256salted ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-user-authenticator-sha256salted ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-user-authenticator-plaintext ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-user-authenticator-plaintext ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-user-authenticator-plaintext ---
[INFO] Surefire report directory: 


---
 T E S T S
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-user-authenticator-sha256salted ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-user-authenticator-sha256salted ---
[INFO] Compiling 1 source file to 


Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Dns Notifier Example 4.5.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-example-dns-notifier ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-example-dns-notifier ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-example-dns-notifier ---
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-user-authenticator-md5 ---
[INFO] Surefire report directory: 


---
 T E S T S
---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-example-dns-notifier ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-example-dns-notifier ---
[INFO] Compiling 1 source file to 

Running com.cloud.server.auth.MD5UserAuthenticatorTest
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-user-authenticator-saml2 ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-user-authenticator-saml2 ---
[INFO] Compiling 4 source files to 

Build timed out (after 11 minutes). Marking the build as failed.
Build was aborted
Recording test results
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugi

[GitHub] cloudstack pull request: Remove AWS api bridge

[pyr]

GitHub user pyr opened a pull request:

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

Remove AWS api bridge

This has been a discussion point for a while. The (mostly generated)
code for the AWS api bridge is by far the largest source component in
Cloudstack, while seldomly used.

Now that alternate options exist to provide EC2 compatibility, it
makes sense to remove it for the few users who cannot directly
talk to the cloudstack API.

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

$ git pull https://github.com/pyr/cloudstack feature/no-dead-code

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

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

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

This closes #44


commit 84042f2c3259203b1ea1956cd239b9122079bae9
Author: Pierre-Yves Ritschard 
Date:   2014-11-21T10:17:18Z

Remove AWS api bridge

This has been a discussion point for a while. The (mostly generated)
code for the AWS api bridge is by far the largest source component in
Cloudstack, while seldomly used.

Now that alternate options exist to provide EC2 compatibility, it
makes sense to remove it for the few users who cannot directly
talk to the cloudstack API.




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

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Daan Hoogland]

Lucian, the non oss deps need to be added to the repository by hand.
They can not be downloaded automatically. This is basically why there
is a separate build (from a tech point of view).

On Fri, Nov 21, 2014 at 10:42 AM, Nux!  wrote:
> Hi,
>
> Built OSS rpms here http://tmp.nux.ro/acs442/
>
> The jenkins build are they oss or noredist? I could not build noredist:
>
> Could not resolve dependencies for project 
> org.apache.cloudstack:cloud-plugin-netapp:jar:4.4.2: Could not find artifact 
> com.cloud.com.netapp:manageontap:jar:4.0 in central 
> (http://repo.maven.apache.org/maven2
>
> http://fpaste.org/152729/62916141/raw/
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Wido den Hollander" 
>> To: dev@cloudstack.apache.org
>> Sent: Friday, 21 November, 2014 09:27:44
>> Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
>
>> On 11/21/2014 10:23 AM, Tomasz Zięba wrote:
>>> Is there available RPM Repository with ACS 4.4.2 ?
>>>
>>
>> You can find those on Jenkins:
>> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/
>>
>>> 2014-11-21 3:59 GMT+01:00 Daan Hoogland :
>>>
 Hi All,

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

 Git Branch and Commit SH:

 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
 Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb

 List of changes:
 `CLOUDSTACK-7887
 `_  fail to
 push snapshot to secondary storage if using multipart using swift...

 `CLOUDSTACK-7883
 `_  Allow
 infrastructure to handle delete of volume from DB...

 `CLOUDSTACK-7871
 `_  Fix update
 VirtualMachine/Template API to allow nic/disk controller details for
 ...

 `CLOUDSTACK-7855
 `_  Sec
 storage/network MTU should be on nic3 and not nic1...

 `CLOUDSTACK-7826
 `_  UI - dialog
 widget - dependent dropdown field (dependsOn property specified) -
 f...

 `CLOUDSTACK-7822
 `_  test SSL
 cert expired...

 `CLOUDSTACK-7752
 `_  Management
 Server goes in infinite loop while creating a vm with tagged local
 da...

 `CLOUDSTACK-7722
 `_  add.label:
 Add button for tags show the label not "Add" text...

 `CLOUDSTACK-7246
 `_  VM
 deployment failed due to wrong in  script name createipalias.sh...

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

 PGP release keys (signed using 4096R/AA4736F3):
 https://dist.apache.org/repos/dist/release/cloudstack/KEYS

 Vote will be open for 72 hours.

 For sanity in tallying the vote, can PMC members please be sure to
 indicate "(binding)" with their vote?

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)


 --
 Daan

>>>
>>>



-- 
Daan

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Nux!]

Hi,

Built OSS rpms here http://tmp.nux.ro/acs442/

The jenkins build are they oss or noredist? I could not build noredist:

Could not resolve dependencies for project 
org.apache.cloudstack:cloud-plugin-netapp:jar:4.4.2: Could not find artifact 
com.cloud.com.netapp:manageontap:jar:4.0 in central 
(http://repo.maven.apache.org/maven2

http://fpaste.org/152729/62916141/raw/

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Wido den Hollander" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 21 November, 2014 09:27:44
> Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

> On 11/21/2014 10:23 AM, Tomasz Zięba wrote:
>> Is there available RPM Repository with ACS 4.4.2 ?
>>
> 
> You can find those on Jenkins:
> http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/
> 
>> 2014-11-21 3:59 GMT+01:00 Daan Hoogland :
>> 
>>> Hi All,
>>>
>>> I've created a 4.4.2 release, with the following artifacts up for a vote:
>>>
>>> Git Branch and Commit SH:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
>>> Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
>>>
>>> List of changes:
>>> `CLOUDSTACK-7887
>>> `_  fail to
>>> push snapshot to secondary storage if using multipart using swift...
>>>
>>> `CLOUDSTACK-7883
>>> `_  Allow
>>> infrastructure to handle delete of volume from DB...
>>>
>>> `CLOUDSTACK-7871
>>> `_  Fix update
>>> VirtualMachine/Template API to allow nic/disk controller details for
>>> ...
>>>
>>> `CLOUDSTACK-7855
>>> `_  Sec
>>> storage/network MTU should be on nic3 and not nic1...
>>>
>>> `CLOUDSTACK-7826
>>> `_  UI - dialog
>>> widget - dependent dropdown field (dependsOn property specified) -
>>> f...
>>>
>>> `CLOUDSTACK-7822
>>> `_  test SSL
>>> cert expired...
>>>
>>> `CLOUDSTACK-7752
>>> `_  Management
>>> Server goes in infinite loop while creating a vm with tagged local
>>> da...
>>>
>>> `CLOUDSTACK-7722
>>> `_  add.label:
>>> Add button for tags show the label not "Add" text...
>>>
>>> `CLOUDSTACK-7246
>>> `_  VM
>>> deployment failed due to wrong in  script name createipalias.sh...
>>>
>>> Source release (checksums and signatures are available at the same
>>> location):
>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2
>>>
>>> PGP release keys (signed using 4096R/AA4736F3):
>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>>
>>> Vote will be open for 72 hours.
>>>
>>> For sanity in tallying the vote, can PMC members please be sure to
>>> indicate "(binding)" with their vote?
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>>
>>> --
>>> Daan
>>>
>> 
>> 

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Daan Hoogland]

Tomasz,


On Fri, Nov 21, 2014 at 10:23 AM, Tomasz Zięba  wrote:
> Is there available RPM Repository with ACS 4.4.2 ?
No there isn't one, but the jenkins.buildacloud.org jobs for 4.4
should have some artifacts. I will prepare a set soon. You won't want
to wait on me on this occasion.

regards

>
> 2014-11-21 3:59 GMT+01:00 Daan Hoogland :
>
>> Hi All,
>>
>> I've created a 4.4.2 release, with the following artifacts up for a vote:
>>
>> Git Branch and Commit SH:
>>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
>> Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
>>
>> List of changes:
>> `CLOUDSTACK-7887
>> `_  fail to
>> push snapshot to secondary storage if using multipart using swift...
>>
>> `CLOUDSTACK-7883
>> `_  Allow
>> infrastructure to handle delete of volume from DB...
>>
>> `CLOUDSTACK-7871
>> `_  Fix update
>> VirtualMachine/Template API to allow nic/disk controller details for
>> ...
>>
>> `CLOUDSTACK-7855
>> `_  Sec
>> storage/network MTU should be on nic3 and not nic1...
>>
>> `CLOUDSTACK-7826
>> `_  UI - dialog
>> widget - dependent dropdown field (dependsOn property specified) -
>> f...
>>
>> `CLOUDSTACK-7822
>> `_  test SSL
>> cert expired...
>>
>> `CLOUDSTACK-7752
>> `_  Management
>> Server goes in infinite loop while creating a vm with tagged local
>> da...
>>
>> `CLOUDSTACK-7722
>> `_  add.label:
>> Add button for tags show the label not "Add" text...
>>
>> `CLOUDSTACK-7246
>> `_  VM
>> deployment failed due to wrong in  script name createipalias.sh...
>>
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2
>>
>> PGP release keys (signed using 4096R/AA4736F3):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>
>> Vote will be open for 72 hours.
>>
>> For sanity in tallying the vote, can PMC members please be sure to
>> indicate "(binding)" with their vote?
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>>
>> --
>> Daan
>>
>
>
>
> --
> Regards,
> Tomasz Zięba
> Twitter: @TZieba
> LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/
> 



-- 
Daan

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Wido den Hollander]

On 11/21/2014 10:23 AM, Tomasz Zięba wrote:
> Is there available RPM Repository with ACS 4.4.2 ?
>

You can find those on Jenkins:
http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/

> 2014-11-21 3:59 GMT+01:00 Daan Hoogland :
> 
>> Hi All,
>>
>> I've created a 4.4.2 release, with the following artifacts up for a vote:
>>
>> Git Branch and Commit SH:
>>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
>> Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
>>
>> List of changes:
>> `CLOUDSTACK-7887
>> `_  fail to
>> push snapshot to secondary storage if using multipart using swift...
>>
>> `CLOUDSTACK-7883
>> `_  Allow
>> infrastructure to handle delete of volume from DB...
>>
>> `CLOUDSTACK-7871
>> `_  Fix update
>> VirtualMachine/Template API to allow nic/disk controller details for
>> ...
>>
>> `CLOUDSTACK-7855
>> `_  Sec
>> storage/network MTU should be on nic3 and not nic1...
>>
>> `CLOUDSTACK-7826
>> `_  UI - dialog
>> widget - dependent dropdown field (dependsOn property specified) -
>> f...
>>
>> `CLOUDSTACK-7822
>> `_  test SSL
>> cert expired...
>>
>> `CLOUDSTACK-7752
>> `_  Management
>> Server goes in infinite loop while creating a vm with tagged local
>> da...
>>
>> `CLOUDSTACK-7722
>> `_  add.label:
>> Add button for tags show the label not "Add" text...
>>
>> `CLOUDSTACK-7246
>> `_  VM
>> deployment failed due to wrong in  script name createipalias.sh...
>>
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2
>>
>> PGP release keys (signed using 4096R/AA4736F3):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>
>> Vote will be open for 72 hours.
>>
>> For sanity in tallying the vote, can PMC members please be sure to
>> indicate "(binding)" with their vote?
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>>
>> --
>> Daan
>>
> 
> 
> 

Re: Debian packaging discussed during CCCEU2014

[Wido den Hollander]

On 11/20/2014 07:50 PM, Marcus wrote:
> For RPMs, the package.sh script that sets things up for rpmbuild could do
> the mvn if we wanted to keep the RPM build process from downloading.
> Something similar could be done from DEB, perhaps.
> 

Debian has helpers for that, so that hopefully smooths it out.

> The dependencies thing though will be interesting to work out. It's a bit
> unfortunate, IMO, because it reduces cross-platform compatibility and
> compromises portability to have to target platform versions of libraries.
> Inevitably we'll run into issues (as we have with libvirt jars, for
> example).
> 

I'm not convinced yet either. Although the way we do it right now isn't
the best, it does work for us and our users.

I'm afraid that we will run into a lot of deployment issues due to all
the OS dependencies.

Wido

> On Wed, Nov 19, 2014 at 3:29 AM, Wido den Hollander  wrote:
> 
>> I've sat down with some peope who are better in Debian packaging then I
>> am and this is what we came up with:
>>
>> For Debian packages it is forbidden that during build it downloads
>> external resources. Maven does this and that prevents CloudStack from
>> ever going into the Debian repositories.
>>
>> We should not package all the JAR dependencies we have, but we should
>> try to depend on packages available in Debian.
>>
>> Debian has a Wiki available for this:
>> https://wiki.debian.org/Java/Packaging
>>
>> With some helpers we can make sure that Maven does not use external
>> resources for dependencies, but uses locally available JAR files from
>> the Debian repo.
>>
>> That is a thing which will take some serious time and we will run into
>> problems there. Don't expect this to be done tomorrow.
>>
>> Our debian/rules file isn't really clean. They are going to look into
>> this to make better use of debhelper.
>>
>> We might want to reach out to the packaging teams inside Debian to see
>> if we can form a (small) team which can maintain the Debian packages for
>> CloudStack.
>>
>> As a project we should watch for the RPM and DEB packages not drifting
>> apart, since the user experience on both platforms should be equal.
>>
>> Wido
>>
> 

Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)

[Tomasz Zięba]

Is there available RPM Repository with ACS 4.4.2 ?

2014-11-21 3:59 GMT+01:00 Daan Hoogland :

> Hi All,
>
> I've created a 4.4.2 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4
> Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb
>
> List of changes:
> `CLOUDSTACK-7887
> `_  fail to
> push snapshot to secondary storage if using multipart using swift...
>
> `CLOUDSTACK-7883
> `_  Allow
> infrastructure to handle delete of volume from DB...
>
> `CLOUDSTACK-7871
> `_  Fix update
> VirtualMachine/Template API to allow nic/disk controller details for
> ...
>
> `CLOUDSTACK-7855
> `_  Sec
> storage/network MTU should be on nic3 and not nic1...
>
> `CLOUDSTACK-7826
> `_  UI - dialog
> widget - dependent dropdown field (dependsOn property specified) -
> f...
>
> `CLOUDSTACK-7822
> `_  test SSL
> cert expired...
>
> `CLOUDSTACK-7752
> `_  Management
> Server goes in infinite loop while creating a vm with tagged local
> da...
>
> `CLOUDSTACK-7722
> `_  add.label:
> Add button for tags show the label not "Add" text...
>
> `CLOUDSTACK-7246
> `_  VM
> deployment failed due to wrong in  script name createipalias.sh...
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2
>
> PGP release keys (signed using 4096R/AA4736F3):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> --
> Daan
>



-- 
Regards,
Tomasz Zięba
Twitter: @TZieba
LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/

Build failed in Jenkins: build-4.5 #157

[jenkins]

See 

Changes:

[wstevens] CLOUDSTACK-7822: Fixed SSL Cert Tests and relaxed chain validation

[wstevens] CLOUDSTACK-7952: Remove private key from SslCertResponse 
(listSslCerts)

--
[...truncated 2860 lines...]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-network-internallb ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-network-internallb ---
[INFO] Compiling 3 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-hypervisor-hyperv ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-hypervisor-hyperv ---
[INFO] Compiling 1 source file to 

Build timed out (after 11 minutes). Marking the build as failed.
Build was aborted
Recording test results
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Palo Alto
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Network Netscaler
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Network Nicira NVP
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - BigSwitch Virtual Network Segment
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Network Brocade VCS
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Stratosphere SSP
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - Network Opendaylight
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - User Authenticator LDAP
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] 
[INFO] Skipping Apache CloudStack Plugin - User Authenticator MD5
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO]   

Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates

[Tim Mackey]

The big problem I recall with the 5.6 Linux tools happened during live
migration.  I don't recall the specific circumstances, but if the VM was
migrated, it could cause either the guest or the host to crash.  I've never
paid attention to the specific Linux version in the system VMs, but the
tools themselves aren't supported for installation on a newer version of an
operating system than what was originally certified.  XenCenter when faced
with 5.6 tools on a 6.2 host would actually say that the tools are there
but need to be upgraded for optimal performance.

This also opens the question of XCP and the tools since XenServer tools
were never designed to work with XCP.  They probably do work just fine, but
if there was an issue we'd be challenged to get it sorted.

If the option of automatically having the tools installed isn't viable, the
next things I'd look at would be:

- removing support for XenServer versions prior to 6.0
- removing support for XCP (or at least only supporting 1.6)
- having the rpm/deb packages for each version of hypervisor pre-loaded
(assuming redist EULA) and when a systemVM starts having a first boot which
installs the correct package and then reboots the system VM

At least that way the tools would be there, and we'd have better system VM
performance while still locking ourselves to specific supported hypervisor
versions.  No idea what impact removal of support for older XenServer
versions might have on the install base, but I'd hope those on 5.6 would at
least be planning an upgrade given 5.6 went EOL from Citrix a while back.

-tim

On Fri, Nov 21, 2014 at 3:15 AM, Rohit Yadav 
wrote:

> Tim, during 4.0/4.1 we used to install a very old xstools 5.6, can we just
> use that and if we do will that cause any (potential) issue since you
> mentioned it has few bugs in it?
>
> Regards.
>
> > On 20-Nov-2014, at 10:23 pm, Tim Mackey  wrote:
> >
> > It's the other way around.  Newer XenServer works with older tools, not
> the
> > other way.
> > On Nov 20, 2014 4:57 PM, "Rohit Yadav" 
> wrote:
> >
> >> If XenServer tools are backward compatible then we can perhaps install
> the
> >> latest xs-tools (6.2)? Will that cause issue if the underlying
> >> Xen/XenServer hypervisor version is not 6.2?
> >>
> >>> On 20-Nov-2014, at 9:12 pm, Tim Mackey  wrote:
> >>>
> >>> From the XenServer perspective, we have a small problem.  The XenServer
> >>> tools are backward compatible, but not guaranteed forward compatible.
> >> What
> >>> that means is we'd need to include the XenServer 5.6 tools, and those
> >> have
> >>> a commercial license.  The XenServer 5.6 tools also have a few bugs
> which
> >>> were fixed in later versions.
> >>>
> >>> I'm certain we could define a minimum version which would work, and
> could
> >>> solve any commercial license concerns, but what about having the system
> >> VMs
> >>> automatically download and apply the correct tools?  Since we know the
> >>> hypervisor version, could we even go so far as automatically update the
> >>> tools should the hypervisor be upgraded?
> >>>
> >>> -tim
> >>>
> >>> On Thu, Nov 20, 2014 at 10:19 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com
> >>>
> >>> wrote:
> >>>
>  Hi,
> 
>  During the CCCEU conference, I’ve been in some discussions with few
> >> people
>  on whether we should install/bundle xenserver tools (and vmware tools
>  and/or virtio-modules).
> 
>  I think we can easily do this, but let’s discuss the following;
> 
>  - Which version of xs-tools etc. we should install? For the build
> >> system,
>  is a publicly available source (iso etc)?
>  - Will installing these tools cause any issue?
>  - If we install all these tools on a single template, could that cause
> >> any
>  issue?
> 
>  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<
>  http://shapeblue.com/iaas-cloud-design-and-build//>
>  CSForge – rapid IaaS deployment framework<
> http://shapeblue.com/csforge/
> >>>
>  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 

Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates

[Rohit Yadav]

Tim, during 4.0/4.1 we used to install a very old xstools 5.6, can we just use 
that and if we do will that cause any (potential) issue since you mentioned it 
has few bugs in it?

Regards.

> On 20-Nov-2014, at 10:23 pm, Tim Mackey  wrote:
>
> It's the other way around.  Newer XenServer works with older tools, not the
> other way.
> On Nov 20, 2014 4:57 PM, "Rohit Yadav"  wrote:
>
>> If XenServer tools are backward compatible then we can perhaps install the
>> latest xs-tools (6.2)? Will that cause issue if the underlying
>> Xen/XenServer hypervisor version is not 6.2?
>>
>>> On 20-Nov-2014, at 9:12 pm, Tim Mackey  wrote:
>>>
>>> From the XenServer perspective, we have a small problem.  The XenServer
>>> tools are backward compatible, but not guaranteed forward compatible.
>> What
>>> that means is we'd need to include the XenServer 5.6 tools, and those
>> have
>>> a commercial license.  The XenServer 5.6 tools also have a few bugs which
>>> were fixed in later versions.
>>>
>>> I'm certain we could define a minimum version which would work, and could
>>> solve any commercial license concerns, but what about having the system
>> VMs
>>> automatically download and apply the correct tools?  Since we know the
>>> hypervisor version, could we even go so far as automatically update the
>>> tools should the hypervisor be upgraded?
>>>
>>> -tim
>>>
>>> On Thu, Nov 20, 2014 at 10:19 AM, Rohit Yadav >>
>>> wrote:
>>>
 Hi,

 During the CCCEU conference, I’ve been in some discussions with few
>> people
 on whether we should install/bundle xenserver tools (and vmware tools
 and/or virtio-modules).

 I think we can easily do this, but let’s discuss the following;

 - Which version of xs-tools etc. we should install? For the build
>> system,
 is a publicly available source (iso etc)?
 - Will installing these tools cause any issue?
 - If we install all these tools on a single template, could that cause
>> any
 issue?

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

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