Re: New features

[Sebastien Goasguen]

On Sep 23, 2013, at 4:50 AM, nfoata@orange.com wrote:

> Hello Cloudstack,
> 
> Sometimes ago, I wrote and submitted two new features with the following 
> identifiers (see below) :
> 
> 1) JIRA
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3701 (VM instantiation: 
> Sending network information in an extra field)
> https://issues.apache.org/jira/browse/CLOUDSTACK-3702 (VM instantiation: 
> Specific information for hypervisors)
>  
> 2) Review board
>  
> Both Jira issues were also registered under review boards with a git diff and 
> submitted in august.
> However, I never received any comment on them.
> ( I would like to put the direct links, in that mail but review board is not 
> accessible this morning). 
> 
> Furthermore, I noticed and saw that there is a lot of demands under the 
> review boards which are not yet processed.
> Does it mean, that there is so many requests that is take a long time ? 

Hi Nicolas, and thanks for the ping.
Unfortunately it just means that we are behind.

> Do cloudstack reviewers need more people or help ?

Yes, this is community driven, so any help you can give is very much welcome. 
You can help review patches, file bugs, and submit more patches.

> Or simply that I did not well up (follow) the submission process somewhere ? 
> (Jira -> review board -> submit ).
> 
> At last, I asked if is it possible to open again a bug (CLOUDSTACK-3128) 
> because it was not totally fixed and
> I sent the solution in the comment of this one. (I can also do a git diff if 
> I have to submit it.) but no answer too.
> https://issues.apache.org/jira/browse/CLOUDSTACK-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> 

You should be able to re-open this bug. I am copying Alena to make sure she 
notices it and sees your comment in the bug.


> Thanks in advance for yours answers and please feel free to contact me if 
> need be,
> 
> Have a good day,
> 
> Best regards,
>  
> 
> 
> 
> Nicolas Foata
> Ingénieur
> DMGP/Portail/DOP/EnP/Advise
> Norsys pour Orange
> Sophia Antipolis
> nfoata@orange.com
> 
>  
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

com.cloud.exception.InsufficientServerCapacityException what wrong?

[Jake.liu]

com.cloud.exception.InsufficientServerCapacityException: Unable to create a 
deployment for VM[User|14e221fe-1285-49b7-b18f-4911bdfa2880]Scope=interface 
com.cloud.dc.DataCenter; id=1
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:186)
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:198)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3864)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3458)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3444)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:379)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
INFO  [cloud.vm.UserVmManagerImpl] (UserVm-Scavenger-1:) Found 1 vms to expunge.

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[ASF Subversion and Git Services]

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


Commit a0988780ad88bb56becb0a13efedcd79c1bee142 in branch 
refs/heads/4.2-forward from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a098878 ]

CLOUDSTACK-4405: change rpm and debian packaging to support automatic update 
(KVM upgrade)

Including following steps:
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
/etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart


- ASF Subversion and Git Services


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

com.cloud.exception.InsufficientServerCapacityException what wrong?

[Jake.liu]

   DeployDestination dest;
try {
dest = _dpMgr.planDeployment(vmProfile, plan, exclude);
} catch (AffinityConflictException e) {
throw new CloudRuntimeException("Unable to create deployment, 
affinity rules associted to the VM conflict");
}


if (dest != null) {
   //save destination with VMEntityVO
VMReservationVO vmReservation = new VMReservationVO(vm.getId(), 
dest.getDataCenter().getId(), dest.getPod().getId(), dest.getCluster().getId(), 
dest.getHost().getId());
Map volumeReservationMap = new HashMap();


if (vm.getHypervisorType() != HypervisorType.BareMetal) {
for(Volume vo : dest.getStorageForDisks().keySet()){
volumeReservationMap.put(vo.getId(), 
dest.getStorageForDisks().get(vo).getId());
}
vmReservation.setVolumeReservation(volumeReservationMap);
}


vmEntityVO.setVmReservation(vmReservation);
_vmEntityDao.persist(vmEntityVO);


return vmReservation.getUuid();
} else if (planChangedByReadyVolume) {
// we could not reserve in the Volume's cluster - let the deploy
// call retry it.
return UUID.randomUUID().toString();
}else{
throw new InsufficientServerCapacityException("Unable to create a 
deployment for " + vmProfile,
DataCenter.class, plan.getDataCenterId(), 
areAffinityGroupsAssociated(vmProfile));
}

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[ASF Subversion and Git Services]

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


Commit 258118efa67b426611dc87c66b4891924641772b in branch refs/heads/master 
from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=258118e ]

CLOUDSTACK-4405: additional patch for bridge name and firewall rules issues 
after KVM upgrade to 4.2

There still exist two issues after Edison's commits.
(1) Migration from new hosts to old hosts failed.
The bridge name on old host is set to cloudVirBr* if network.bridge.name.schema 
is set to 3.0 in /etc/cloudstack/agent/agent.properties, but the actual bridge 
name is breth*-* after running cloudstack-agent-upgrade.
(2) all ports of vms (Basic zone, or Advanced zone with security groups) on old 
hosts are open, because the iptables rules are binding to device (bridge) name 
which is changed by cloudstack-agent-upgrade.

After this, the KVM upgrade steps :
a. Install 4.2 cloudstack agent on each kvm host
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
/etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
c5. service cloudstack-agent restart

Signed-off-by: Wei Zhou 


- ASF Subversion and Git Services


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[ASF Subversion and Git Services]

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


Commit 7b4f84622051b532a7e272dc1ed87310ea119cbc in branch refs/heads/master 
from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b4f846 ]

CLOUDSTACK-4405: add a tool: cloudstack-agent-upgrade to upgrade bridge name on 
kvm host
(cherry picked from commit 0ef6084d2c838a78eda29d258b1af98df96451b3)

Signed-off-by: Wei Zhou 


- ASF Subversion and Git Services


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[ASF Subversion and Git Services]

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


Commit e325fb66ab1fa0796ade6b5d3d70c688b57e5409 in branch refs/heads/master 
from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e325fb6 ]

CLOUDSTACK-4405: fix vm migration during the upgrade to 4.2

Signed-off-by: Wei Zhou 


- ASF Subversion and Git Services


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request 13992: (CLOUDSTACK-4405) additional patch for bridge name and firewall rules issues after KVM upgrade to 4.2

[ASF Subversion and Git Services]

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


Commit 164e3e33b414861d4c49457df66dbd7a73830303 in branch refs/heads/master 
from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=164e3e3 ]

CLOUDSTACK-4405: change rpm and debian packaging to support automatic update 
(KVM upgrade)

Including following steps:
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
/etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
(cherry picked from commit a0988780ad88bb56becb0a13efedcd79c1bee142)

Signed-off-by: Wei Zhou 


- ASF Subversion and Git Services


On Sept. 9, 2013, 8:09 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13992/
> ---
> 
> (Updated Sept. 9, 2013, 8:09 a.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Bugs: CLOUDSTACK-4405
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There still exist two issues after Edison's commits.
> (1) Migration from new hosts to old hosts failed.
> The bridge name on old host is set to cloudVirBr* if 
> network.bridge.name.schema is set to 3.0 in 
> /etc/cloudstack/agent/agent.properties, but the actual bridge name is 
> breth*-* after running cloudstack-agent-upgrade.
> 
> (2) all ports of vms (Basic zone, or Advanced zone with security groups) on 
> old hosts are open, because the iptables rules are binding to device (bridge) 
> name which is changed by cloudstack-agent-upgrade.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloudstack-agent-upgrade.in 4972d39 
>   debian/cloudstack-agent.postinst 499ae6a 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec 2b814f8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  e3779a7 
>   scripts/vm/network/security_group.py 0ac8b74 
> 
> Diff: https://reviews.apache.org/r/13992/diff/
> 
> 
> Testing
> ---
> 
> tested ok on my environment.
> 
> After this, the KVM upgrade steps :
> a. Install 4.2 cloudstack agent on each kvm host 
> b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing 
> bridge name to new bridge name, and update related firewall rules.
>c. install a libvirt hook:
> c1. mkdir /etc/libvirt/hooks
> c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook 
> /etc/libvirt/hooks/qemu
> c3. chmod +x /etc/libvirt/hooks/qemu
> c4. service libvirtd restart
> c5. service cloudstack-agent restart
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

[ACS4.2.1] Moving 4.2 tickets to 4.2.1

[Abhinandan Prateek]

Animesh,
  Is there are quick way to move 4.2 tickets to 4.2.1, now that 4.2 is out ?

-abhi

Re: xenserver tools

[Abhinandan Prateek]

For including xstools in systemvm we will be modifying the scripts.
The gpl¹d binaries are not part of the distribution. That keeps us in
clear as far as licensing is concerned.


-abhi

On 19/09/13 6:41 pm, "Daan Hoogland"  wrote:

>
>yes, if someone can tell me if we can include gpl'd binaries in our
>git/distro I think we should. In that case I will file a bug.
>
>regards,

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Wido den Hollander]

On 09/24/2013 06:21 AM, Animesh Chaturvedi wrote:



  This vote has passed with no -1 votes.

  +1 votes were from (with * binding):
  Chiradeep*, Hugo*, Chip*, Milamber,  Amogh

  +0: Marcus*

  Marcus agreed to change his VOTE to +1 with a Release Note change that
  he will make.

  Wido can you build and publish  the .deb packages



They are being uploaded to the mirror while I'm typing this e-mail.

Wido


  Thanks
  Animesh


-Original Message-
From: Animesh Chaturvedi
Sent: Friday, September 20, 2013 8:36 PM
To: dev@cloudstack.apache.org
Subject: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)





I've created a 4.2.0 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.2
Commit: 69c459342c568e2400d57ee88572b301603d8686

List of changes:
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2

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

PGP release keys (signed using 94BE0D7C):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Testing instructions are here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
oc
edure

Vote will be open for 72 hours (Monday 9/23 PST EOD).

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)

Re: community testing

[Daan Hoogland]

due to lack of response, I might add.

On Mon, Sep 23, 2013 at 11:01 PM, Sebastien Goasguen  wrote:
>
> On Sep 23, 2013, at 4:22 PM, Animesh Chaturvedi 
>  wrote:
>
>>
>>
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com]
>>> Sent: Wednesday, September 11, 2013 11:58 PM
>>> To: Prasanna Santhanam
>>> Cc: Mike Tutkowski; Marcus Sorensen; dev@cloudstack.apache.org; Ahmad
>>> Emneina
>>> Subject: Re: community testing
>>>
>>>
>>> While everything happens on the mailing list, maybe we can setup a
>>> meeting to discuss this. Google hangout ?
>>> Anyone interested in testing could join.
>>>
>>> Mike is west coast I believe, Prasanna is in india. Scheduling might be
>>> tough but we should try ?
>>>
>>> -sebastien
>>>
 [Animesh>] Sebastien did this meeting happen? If so can you share the 
 discussion notes
>>
>
> no this was shutdown in another thread.
>

Re: [PROPOSAL] Modularize Spring

[Daan Hoogland]

touching on thread hijack but; How does this work relate to the css
modularization going on at the moment as well? It is proposed there to
do merging at build time. Try to beat me if I am to much off topic,
Daan

On Tue, Sep 24, 2013 at 12:43 AM, Darren Shepherd
 wrote:
> Ah right, okay.  So your talking about the order of the adapters.
> Currently that is maintained as the order in the AdapterList in the
> componentContext.xml.  So what I've done is that extensions get added
> to "Registries."  Registries that need to be ordered can specify an
> ordering configuration variable so that when the extensions are found
> they are added to the list in a specific order.  So the registry
> definition for the auth stuff looks something like
>
>  
> class="org.apache.cloudstack.spring.lifecycle.registry.ExtensionRegistry">
> 
> 
>  value="SHA256SALT,MD5,LDAP,PLAINTEXT" />
> 
>
> So one can use user.authenticators.order to change the order and
> user.authenticators.exclude to exclude certain extensions from being
> used.  The default value is also specified in that example.
>
> Darren
>
> On Mon, Sep 23, 2013 at 3:28 PM, Kelven Yang  wrote:
>> I understand that loading order can be completely solved by Spring with
>> dependency injection, either within flat context or hierarchy context
>> structure. But some sibling plugins in CloudStack do require a flexible
>> way to declare ordering for runtime. For example, allocator plugins or
>> authenticator plugins. The order itself is currently designated in their
>> parent manager to reference to a ordered adapter list.
>>
>> This order semantics has nothing to do with dependency injection, but
>> unfortunately in previous version of CloudStack, it does mix the
>> requirement into injection framework and there are business logic relying
>> on it. The fact for parent manager to compose ordering has made an
>> assumption at compile/load time binding to subject plugins, which we don't
>> want to see in the future since we want drop-in jar for plugins, what is
>> our answer for this?
>>
>> Kelven
>>
>>
>> On 9/23/13 1:40 PM, "Darren Shepherd"  wrote:
>>
>>>Siblings have no relationship to each other really.  The load order
>>>doesn't matter as one sibling has no visibility to another.  Child
>>>contexts are pretty much for plug-ins.  Core components of ACS will
>>>live in the core context as they are all interdependent.
>>>
>>>I will explain the whole Spring lifecycle though and how it works in the
>>>model.
>>>
>>>Contexts are initialized from parent to child.  So the top most parent
>>>context is initialized first, then its child, then its grandchildren.
>>>When a context is initialized the following happens in the below order
>>>
>>>1) All beans are instantiated
>>>2) Dependencies are wire up (@Inject)
>>>3) @PostConstruct is call for all beans in dependency graph order
>>>4) Extensions are discovered an registered (so NetworkElement for
>>>example will be discovered an registered as a NetworkElement)
>>>5) configure() on all ComponentLifecycle beans will be called in the
>>>getRunLevel() order
>>>
>>>Once all modules have been initialized in this fashion then in a
>>>parent first child last order start() on all ComponentLifecycle beans
>>>is called following the getRunLevel() order for the beans in the
>>>context.
>>>
>>>Darren
>>>
>>>
>>>On Mon, Sep 23, 2013 at 11:34 AM, Kelven Yang 
>>>wrote:
 Darren,

 Due to internal release work, I haven't got a chance to review it but
I'm
 planning to do so later today and tomorrow. Before that, I have one
 question about hierarchy-orginzated context structure, could you
elaborate
 an example to the ML on how two sibling plugins to declare their runtime
 load order? I'd like to get a feeling on how hard or easy for developers
 to do things that involve with structural change under the new hierarchy
 mode.

 Kelven


 On 9/23/13 12:19 AM, "Darren Shepherd" 
wrote:

>So how do I proceed forward on this?  I basically already have this all
>working.  I'd really like to get it all committed as soon as possible if
>there are no objections to the approach.  The sooner the better.
>
>I already have a bunch of patches pending on review board that change a
>bunch of random but related things.  I need all of those patches
>committed before I can submit the next round of patches.  I have about 4
>or 5 more.  What I'll do is that everything will get committed and then
>their will be one small patch that will be last that flips some config
>files to enable this all.  All changes to code will work in both a
>modular and monolithic spring context.  So it will be really easy to
>turn
>this off if suddenly something goes terribly wrong.
>
>So I need people to agree this is good and then start
>reviewing/committing my patches.  I really want to get this wrapped up
>this week if I

Re: xenserver tools

[Daan Hoogland]

meaning that we cannot solve this as proposed bu Joris. What should we
do about making sure hte xenserver tools are on the system vms. should
they go in the template or in the systemvm.iso? The question is kind
of rethorical, the real question is; Are they a standard requirement
that we want available for everyone?

regards,
Daan

On Tue, Sep 24, 2013 at 10:09 AM, Abhinandan Prateek
 wrote:
> For including xstools in systemvm we will be modifying the scripts.
> The gpl¹d binaries are not part of the distribution. That keeps us in
> clear as far as licensing is concerned.
>
>
> -abhi
>
> On 19/09/13 6:41 pm, "Daan Hoogland"  wrote:
>
>>
>>yes, if someone can tell me if we can include gpl'd binaries in our
>>git/distro I think we should. In that case I will file a bug.
>>
>>regards,
>

Re: xenserver tools

[Abhinandan Prateek]

The GPL binaries should be provisioned in the template (using
tools/appliance/ scripts) and should not be part of the systemvm.iso.
The scripts in the iso can be modified as per the provisioned binaries.

Xenserver tools can be made available for all and will facilitate features
like dynamic scaling out of the box.

On 24/09/13 3:15 pm, "Daan Hoogland"  wrote:

>meaning that we cannot solve this as proposed bu Joris. What should we
>do about making sure hte xenserver tools are on the system vms. should
>they go in the template or in the systemvm.iso? The question is kind
>of rethorical, the real question is; Are they a standard requirement
>that we want available for everyone?
>
>regards,
>Daan
>
>On Tue, Sep 24, 2013 at 10:09 AM, Abhinandan Prateek
> wrote:
>> For including xstools in systemvm we will be modifying the scripts.
>> The gpl¹d binaries are not part of the distribution. That keeps us in
>> clear as far as licensing is concerned.
>>
>>
>> -abhi
>>
>> On 19/09/13 6:41 pm, "Daan Hoogland"  wrote:
>>
>>>
>>>yes, if someone can tell me if we can include gpl'd binaries in our
>>>git/distro I think we should. In that case I will file a bug.
>>>
>>>regards,
>>

Configuration table changes and database update

[Hugo Trippaers]

Hey all,

Noticed an interesting problem today. I was trying to start a management server 
based on the latest sources in master, but failed. The reason was that the 
configuration threw an exception that a certain column in the database fit not 
exist. This column is added during the database upgrade sequence, but 
apparently the configuration is already accessed before the database upgrade 
takes place.

Seems like a chicken and egg problem to me.

Did anybody else run into this problem?

Cheers,

Hugo

Re: Configuration table changes and database update

[Wei ZHOU]

I ran a fresh installation on devcloud just now, it works.
some records in configuration table are introduced by sql files, and
ConfigurationServerImpl will check and insert the records if not exist.


2013/9/24 Hugo Trippaers 

> Hey all,
>
> Noticed an interesting problem today. I was trying to start a management
> server based on the latest sources in master, but failed. The reason was
> that the configuration threw an exception that a certain column in the
> database fit not exist. This column is added during the database upgrade
> sequence, but apparently the configuration is already accessed before the
> database upgrade takes place.
>
> Seems like a chicken and egg problem to me.
>
> Did anybody else run into this problem?
>
> Cheers,
>
> Hugo

[ANNOUNCE] A GCE interface to CloudStack

[sebgoa]

Hi,

I am quite pumped to announce a Google Compute Engine (GCE) interface to 
CloudStack.

Ian Duffy, Darren Brogan and myself worked on this on github over the last 
month. Our latest branch:

https://github.com/NOPping/cloudstack-gce/tree/refactor

Has been uploaded to pypi:

https://pypi.python.org/pypi/gcloud

A little virtualenv and a pip install gcloud will give you a Flask application, 
with OAuth2 provider and REST routes that map to the CloudStack API.
The routes are compliant with GCE API, which allows you to use the Google 
gcutil cli to talk to your CloudStack cloud.

Of course there are a few caveats that I will not mention, this is release 
0.0.1, feedback and pr welcome.

Congrats to our two 20 year olds in ireland who are taking names up in Dublin !

Have fun,

-Sebastien

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chip Childers]

Animesh,

I'm going to publish the current download page to include CloudMonkey
now.  I'll then stage a new version for the 4.2 release, which can be
published after you move the artifacts (today?) and we wait 24 hours for
the mirrors to sync.

-chip

On Tue, Sep 24, 2013 at 04:21:19AM +, Animesh Chaturvedi wrote:
> 
>  
>  This vote has passed with no -1 votes.
>  
>  +1 votes were from (with * binding):
>  Chiradeep*, Hugo*, Chip*, Milamber,  Amogh
>  
>  +0: Marcus*
>  
>  Marcus agreed to change his VOTE to +1 with a Release Note change that
>  he will make.
>  
>  Wido can you build and publish  the .deb packages
>  
>  Thanks
>  Animesh
>  
> > > -Original Message-
> > > From: Animesh Chaturvedi
> > > Sent: Friday, September 20, 2013 8:36 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> > >
> > >
> > >
> > >
> > >
> > > I've created a 4.2.0 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.2
> > > Commit: 69c459342c568e2400d57ee88572b301603d8686
> > >
> > > List of changes:
> > > https://git-wip-
> > > us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2
> > >
> > > Source release (checksums and signatures are available at the same
> > > location):
> > > https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> > >
> > > PGP release keys (signed using 94BE0D7C):
> > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > >
> > > Testing instructions are here:
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
> > > oc
> > > edure
> > >
> > > Vote will be open for 72 hours (Monday 9/23 PST EOD).
> > >
> > > 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)
> > >
> 
> 

[ANNOUNCE] Apache CloudStack CloudMonkey 5.0.0

[Chip Childers]

The Apache CloudStack project is pleased to announce the immediate
availability of the Apache CloudStack CloudMonkey 5.0.0 release.

Apache CloudStack's CloudMonkey is a Python-based command line utility
for interacting with Apache CloudStack IaaS clouds.  The software provides
an interactive shell environment that includes command discovery,
auto-completion and multiple output formats. CloudMonkey can also be
used as a simple command line utility, which can be easily integrated
into larger shell scripts.

This is the first independently released version of CloudMonkey provided
by the Apache CloudStack project community.  This release includes
pre-cached API command syntax for Apache CloudStack versions up to
and including CloudStack 4.2.0.

The release can be obtained from the CloudMonkey section of the Apache
CloudStack download page:
http://cloudstack.apache.org/downloads.html

Additionally, the 5.0.0 release is available via the Python Package
Index (https://pypi.python.org/pypi/cloudmonkey) and may be installed
via pip. Further instructions may be found on the Apache CloudStack
download page.

We welcome your help and feedback. For more information on how to report
problems, and to get involved, visit the project website at:

http://cloudstack.apache.org/


pgpDC7xS0a5qc.pgp
Description: PGP signature

[ANNOUNCE] Apache CloudStack CloudMonkey 5.0.0

[Chip Childers]

The Apache CloudStack project is pleased to announce the immediate availability
of the Apache CloudStack CloudMonkey 5.0.0 release.

Apache CloudStack's CloudMonkey is a Python-based command line utility for
interacting with Apache CloudStack IaaS clouds.  The software provides
an interactive shell environment that includes command discovery,
auto-completion and multiple output formats. CloudMonkey can also be
used as a simple command line utility, which can be easily integrated
into larger shell scripts.

This is the first independently released version of CloudMonkey provided
by the Apache CloudStack project community.  This release includes
pre-cached API command syntax for Apache CloudStack versions up to
and including CloudStack 4.2.0.

The release can be obtained from the CloudMonkey section of the Apache
CloudStack download page:
http://cloudstack.apache.org/downloads.html

Additionally, the 5.0.0 release is available via the Python Package
Index (https://pypi.python.org/pypi/cloudmonkey) and may be installed
via pip. Further instructions may be found on the Apache CloudStack
download page.

We welcome your help and feedback. For more information on how to report
problems, and to get involved, visit the project website at:

http://cloudstack.apache.org/


pgpg8yu6xXsvp.pgp
Description: PGP signature

Review Request 14319: CLOUDSTACK 2238: Automation - Non Contiguous VLAN Ranges

[Gaurav Aradhye]

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

Review request for cloudstack, Harikrishna Patnala, venkata swamy babu  
budumuru, and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

Adding Automation test cases for feature - Non Contiguous VLAN ranges
CLOUDSTACk 2238.


Diffs
-

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

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


Testing
---

Tested locally.


Thanks,

Gaurav Aradhye

Re: [GSoC] Pencil down on Sept 16th

[sebgoa]

Dear Nguyen, Ian, Meng and Shiva,

Firm pencil down was yesterday. So make sure that all your last patches have 
been submitted, even if there are issues with them we can look at them on 
review board.

Final evaluations are due now and the deadline is Sept 27th. Mentors submit 
evaluations but you do too, so make sure to enter them. 

You also need to submit code samples according to the guidelines:
 
https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/codeguidelines

You can choose what to upload but I believe uploading your patches makes sense.

Once we are done with the code uploads and evaluation I will send a final wrap 
up email with results from the projects.

Cheers,

-Sebastien


On Sep 16, 2013, at 6:44 AM, Nguyen Anh Tu  wrote:

> @Sebgoa: could you please apply my pending patch? So I can upload another
> patches, because they use files from that pending patch
> 
> 
> 2013/9/16 Abhinandan Prateek 
> 
>> Though the heading says code sample the google-melange site specifically
>> asks you to upload the full work even it partially includes bits and
>> pieces of other code as in a big project.
>> 
>> -abhi
>> 
>> On 16/09/13 8:49 am, "Nguyen Anh Tu"  wrote:
>> 
>>> Hi guys,
>>> 
>>> Today is the deadline of uploading code template. What parts of code do
>>> you
>>> decide to upload to code template? only patches/diffs or whole of source
>>> tree?
>>> 
>>> Thanks,
>>> 
>>> 
>>> 2013/9/6 Sebastien Goasguen 
>>> 
 
 On Sep 3, 2013, at 6:08 PM, Ian Duffy  wrote:
 
> Cool, I don't have any more code to submit unless somebody finds an
 issue
> between now and then.
> 
> Any idea what is required within the code samples? Do we just pick
 sections
> of code we're proud of or Š
 
 they just posted this:
 
 
 
 
>> http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc
 2013/codeguidelines
 
 
> ?
> 
 
> 
> On 3 September 2013 09:38, sebgoa  wrote:
> 
>> Hi guys,
>> 
>> GsoC pencil down date is Sept 16th, with firm pencil down on Sept
 23rd
 and
>> Final evaluation on September 27th.
>> It seems that Google will require you to submit code samples on Sept
 27th.
>> 
>> So there is still time to send your patches.
>> Ian has been made committer and can commit on his own, the others can
>> still use review board.
>> 
>> I will send another email this week about final report, another
 docbook
>> exercise :)
>> 
>> keep it up, this is the last stretch, join IRC for questions, email
 the
>> listŠ
>> 
>> cheers,
>> 
>> -Sebastien
 
 
>>> 
>>> 
>>> --
>>> 
>>> N.g.U.y.e.N.A.n.H.t.U
>> 
>> 
> 
> 
> -- 
> 
> N.g.U.y.e.N.A.n.H.t.U

Re: Configuration table changes and database update

[Daan Hoogland]

I ran into this as well, As I did some change to schema-420-430.sql I
was my primary suspect. It does not have to do with my field though.
Still looking,
Daan

On Tue, Sep 24, 2013 at 2:17 PM, Wei ZHOU  wrote:
> I ran a fresh installation on devcloud just now, it works.
> some records in configuration table are introduced by sql files, and
> ConfigurationServerImpl will check and insert the records if not exist.
>
>
> 2013/9/24 Hugo Trippaers 
>
>> Hey all,
>>
>> Noticed an interesting problem today. I was trying to start a management
>> server based on the latest sources in master, but failed. The reason was
>> that the configuration threw an exception that a certain column in the
>> database fit not exist. This column is added during the database upgrade
>> sequence, but apparently the configuration is already accessed before the
>> database upgrade takes place.
>>
>> Seems like a chicken and egg problem to me.
>>
>> Did anybody else run into this problem?
>>
>> Cheers,
>>
>> Hugo

Re: Configuration table changes and database update

[Daan Hoogland]

works in the latest version

On Tue, Sep 24, 2013 at 4:09 PM, Daan Hoogland  wrote:
> I ran into this as well, As I did some change to schema-420-430.sql I
> was my primary suspect. It does not have to do with my field though.
> Still looking,
> Daan
>
> On Tue, Sep 24, 2013 at 2:17 PM, Wei ZHOU  wrote:
>> I ran a fresh installation on devcloud just now, it works.
>> some records in configuration table are introduced by sql files, and
>> ConfigurationServerImpl will check and insert the records if not exist.
>>
>>
>> 2013/9/24 Hugo Trippaers 
>>
>>> Hey all,
>>>
>>> Noticed an interesting problem today. I was trying to start a management
>>> server based on the latest sources in master, but failed. The reason was
>>> that the configuration threw an exception that a certain column in the
>>> database fit not exist. This column is added during the database upgrade
>>> sequence, but apparently the configuration is already accessed before the
>>> database upgrade takes place.
>>>
>>> Seems like a chicken and egg problem to me.
>>>
>>> Did anybody else run into this problem?
>>>
>>> Cheers,
>>>
>>> Hugo

RE: community testing

[Musayev, Ilya]

I'm certainly interested.

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Tuesday, September 24, 2013 5:12 AM
> To: dev
> Subject: Re: community testing
> 
> due to lack of response, I might add.
> 
> On Mon, Sep 23, 2013 at 11:01 PM, Sebastien Goasguen
>  wrote:
> >
> > On Sep 23, 2013, at 4:22 PM, Animesh Chaturvedi
>  wrote:
> >
> >>
> >>
> >>> -Original Message-
> >>> From: sebgoa [mailto:run...@gmail.com]
> >>> Sent: Wednesday, September 11, 2013 11:58 PM
> >>> To: Prasanna Santhanam
> >>> Cc: Mike Tutkowski; Marcus Sorensen; dev@cloudstack.apache.org;
> >>> Ahmad Emneina
> >>> Subject: Re: community testing
> >>>
> >>>
> >>> While everything happens on the mailing list, maybe we can setup a
> >>> meeting to discuss this. Google hangout ?
> >>> Anyone interested in testing could join.
> >>>
> >>> Mike is west coast I believe, Prasanna is in india. Scheduling might
> >>> be tough but we should try ?
> >>>
> >>> -sebastien
> >>>
>  [Animesh>] Sebastien did this meeting happen? If so can you share
>  the discussion notes
> >>
> >
> > no this was shutdown in another thread.
> >

RE: Volunteers to Complete the 4.2 Release Notes

[Abhinav Roy]

Yes Indra, It is confirmed. We have tested using below names only. It was my 
fault that I overlooked it during documentation.

Thanks and regards,
Abhinav

-Original Message-
From: Indra Pramana [mailto:in...@sg.or.id] 
Sent: Tuesday, September 24, 2013 12:12 PM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org; Radhika Puthiyetath; Harikrishna Patnala
Subject: Re: Volunteers to Complete the 4.2 Release Notes

Hi Abhinav and all,

So is it confirmed that the correct system VM template name should be below?

1) systemvm-xenserver-4.2
2) systemvm-kvm-4.2
3) systemvm-vmware-4.2
4) systemvm-hyperv-4.2
5) systemvm-lxc-4.2

Looking forward to your reply, thank you.

Cheers.


On Tue, Sep 24, 2013 at 1:47 AM, Abhinav Roy  wrote:

> Yes , that's true Milamber. It's my fault, Somehow I overlooked it.
> But, the check for 8096 API port is already there for 4.1.x to 4.2 
> upgrades.
>
> Thanks and regards,
> Abhinav
>
> -Original Message-
> From: Milamber [mailto:milam...@apache.org]
> Sent: Monday, September 23, 2013 10:53 PM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Radhika 
> Puthiyetath; Harikrishna Patnala
> Subject: Re: Volunteers to Complete the 4.2 Release Notes
>
>
> Le 23/09/2013 10:48, Abhinav Roy a ecrit :
> > Hi,
> >
> > Here are some of the steps which are missing from the release notes,
> >
> > 1. Before upgrading from any version to 4.2 we need to register the 
> > new
> 4.2 systemvm templates .
> >  This step is there in section 3.3 i.e for upgrade from 2.2.14 
> > to
> 4.2, but it is missing in section 3.1 and 3.2 .
>
> > +  Name: systemvm-kvm-4.2.0
> > +Description: 
> > + systemvm-kvm-4.2.0
>
> My upgrade test (from 4.1.1 to 4.2) have failed, because I used 
> "systemvm-kvm-4.2.0" for the name of new system vm... (my system vms 
> still in debian 6.0)
>
> Please Note:
> The name for the new system vms (xen, kvm, vmware, etc) must be only "4.2"
> (not "4.2.0) at the end.
>
> 1) systemvm-xenserver-4.2
> 2) systemvm-kvm-4.2
> 3) systemvm-vmware-4.2
> 4) systemvm-hyperv-4.2
> 5) systemvm-lxc-4.2
>
> Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-3355
> (close this issue?)
>
>
> > Have you enabled the "integration.api.port" under Global Settings 
> > menu
> in CS management GUI? If not, set it to 8096, restart management and 
> see if the problem goes away.
>
> Add some lines to check if the key intergration.api.port is set to 
> 8096 before the upgrade seems important too. (for section 4.1.x to 
> 4.2)
>
>
> Milamber
>
>
>
>
> >
> > 2. Section 3.1
> >
> >  Step 3&4 : it should be cloudstack-management and 
> > cloudstack-usage
> as the naming conventions have been changed from 4.1 onwards.
> >
> >  Step 6 : The cloudstack 4.2 repo has not been published yet,
> currently at http://cloudstack.apt-get.eu/ the repo is available only 
> for 4.0.x and 4.1.x
> >   What Indira pointed to, needs to be removed, 
> > step
> 6.g) and 6.h) and step 8 also need to be removed
> >  In step 6.f) It should be service 
> > cloudstack-agent
>  stop
> >
> >  Step 9.b) : It should be sudo yum upgrade cloudstack-client
> >
> >  Step 9.c) : it should be sudo yum upgrade cloudstack-agent   and
> the following line is not required [[" During the installation of 
> cloudstack-agent, the RPM will copy your 
> agent.properties,log4j-cloud.xml, and environment.properties from 
> /etc/cloud/agent to /etc/cloudstack/agent"
> ]]
> >
> > Step 9.d.ii) : it should be sudo yum upgrade cloudstack-usage
> >
> >
> > 3. Section 3.2
> >
> >  Step 1.e) :  The URL of the vmware systemvm template is wrong. 
> > It
> should be
> http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova .
> > The OSType should be [[Debian GNU/Linux 
> > 7.0
> (32-bit) (or the highestDebian release number available in the 
> dropdown)]]
> >   Similarly, add templates for xenserver and kvm also.
> >
> >  Step 7 : Delete this step, it's not needed.
> >
> > Step 16 : It should be cloudstack-sysvmadm
> >
> > 4. Section 3.3
> >
> >   Step 4.d) : For all the newly registered templates, make the
> OStype as [[Debian GNU/Linux 7.0 (32-bit) (or the highest Debian 
> release number available in the dropdown)]]
> >
> >   Step 13.c) :  It should be
> /etc/cloudstack/management/components.xml
> >
> >   Step 15.c) : It should be 
> > /etc/cloudstack/management/db.properties
> >
> >   Step 20 :  Remove this step, it's not needed
> >
> >   Step 21.e) : It should be 
> > /etc/cloudstack/agent/agent.properties
> >
> >  Step 23.a) :  It should be cloudstack-sysvmadm
> >
> > 5. In addition to all this,  If we are using KVM hosts as 
> > rhel6.0/6.1
> then these extra steps need to be documented for each section, 3.2 and 
> 3.3
> >
> > (KVM on RHEL 6.0/6.1 only) If your existing CloudStack deployment
> includes one or more
> > clusters of KV

RE: Volunteers to Complete the 4.2 Release Notes

[Abhinav Roy]

Hi Indra,

Yes this steps are not needed for 4.1.x to 4.2 upgrades, they are needed only 
during upgrade from previous versions.

Thanks and regards,
Abhinav

-Original Message-
From: Indra Pramana [mailto:in...@sg.or.id] 
Sent: Tuesday, September 24, 2013 12:14 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org; Radhika Puthiyetath
Subject: Re: Volunteers to Complete the 4.2 Release Notes

Hi Abhinav,

May I know if whether below steps are required for upgrade from 4.1.x to 4.2.0? 
Because you mention that below is only applicable on sections 3.2 and 3.3, 
which are the sections for the earlier version to 4.2.0?

===
6.  Also, in all the sections 3.2 and 3.3 , add this step for agent upgrades

After running this ,
Edit /etc/cloudstack/agent/agent.
properties to change the resource parameter from 
com.cloud.agent.resource.computing.LibvirtComputingResource to 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource

We need to run the following too,

Upgrade all the existing bridge names to new bridge names by running this
script:

# cloudstack-agent-upgrade

. Install a libvirt hook with the following commands:
# mkdir /etc/libvirt/hooks
# cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu # 
chmod +x /etc/libvirt/hooks/qemu

. Restart libvirtd.
# service libvirtd restart

. Start the agent.
# service cloudstack-agent start
===

Looking forward to your reply, thank you.

Cheers.



On Mon, Sep 23, 2013 at 5:48 PM, Abhinav Roy  wrote:

> Hi,
>
> Here are some of the steps which are missing from the release notes,
>
> 1. Before upgrading from any version to 4.2 we need to register the 
> new
> 4.2 systemvm templates .
> This step is there in section 3.3 i.e for upgrade from 2.2.14 to 
> 4.2, but it is missing in section 3.1 and 3.2 .
>
> 2. Section 3.1
>
> Step 3&4 : it should be cloudstack-management and cloudstack-usage 
> as the naming conventions have been changed from 4.1 onwards.
>
> Step 6 : The cloudstack 4.2 repo has not been published yet, 
> currently at http://cloudstack.apt-get.eu/ the repo is available only 
> for 4.0.x and 4.1.x
>  What Indira pointed to, needs to be removed, step
> 6.g) and 6.h) and step 8 also need to be removed
> In step 6.f) It should be service cloudstack-agent  
> stop
>
> Step 9.b) : It should be sudo yum upgrade cloudstack-client
>
> Step 9.c) : it should be sudo yum upgrade cloudstack-agent   and the
> following line is not required [[" During the installation of 
> cloudstack-agent, the RPM will copy your 
> agent.properties,log4j-cloud.xml, and environment.properties from 
> /etc/cloud/agent to /etc/cloudstack/agent"
> ]]
>
>Step 9.d.ii) : it should be sudo yum upgrade cloudstack-usage
>
>
> 3. Section 3.2
>
> Step 1.e) :  The URL of the vmware systemvm template is wrong. It 
> should be 
> http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova .
>The OSType should be [[Debian GNU/Linux 7.0
> (32-bit) (or the highestDebian release number available in the dropdown)]]
> Similarly, add templates for xenserver and kvm also.
>
> Step 7 : Delete this step, it's not needed.
>
>Step 16 : It should be cloudstack-sysvmadm
>
> 4. Section 3.3
>
>  Step 4.d) : For all the newly registered templates, make the 
> OStype as [[Debian GNU/Linux 7.0 (32-bit) (or the highest Debian 
> release number available in the dropdown)]]
>
>  Step 13.c) :  It should be 
> /etc/cloudstack/management/components.xml
>
>  Step 15.c) : It should be 
> /etc/cloudstack/management/db.properties
>
>  Step 20 :  Remove this step, it's not needed
>
>  Step 21.e) : It should be /etc/cloudstack/agent/agent.properties
>
> Step 23.a) :  It should be cloudstack-sysvmadm
>
> 5. In addition to all this,  If we are using KVM hosts as rhel6.0/6.1 
> then these extra steps need to be documented for each section, 3.2 and 
> 3.3
>
> (KVM on RHEL 6.0/6.1 only) If your existing CloudStack deployment 
> includes one or more clusters of KVM hosts running RHEL 6.0 or RHEL 
> 6.1, you must first upgrade the operating system version on those 
> hosts before upgrading CloudStack itself.
> The first order of business will be to change the yum repository for 
> each system with CloudStack packages. This means all management 
> servers, and any hosts that have the KVM agent. (No changes should be 
> necessary for hosts that are running VMware or Xen.) Start by opening 
> /etc/yum.repos.d/cloudstack.repo on any systems that have CloudStack 
> packages installed.
>
> [upgrade]
> name=rhel63
> baseurl=url-of-your-rhel6.3-repo
> enabled=1
> gpgcheck=0
> [apache CloudStack]
> name= Apache CloudStack
> baseurl= http://cloudstack.apt-get.eu/rhel/4.0/
> enabled=1
> gpgcheck=0
>
> If you are using the community provided package repository, change the 
> baseurl to http:// cloudstack.apt-get.eu/rhel/4.2/
>
> If you're using your own package r

Re: Review Request 14299: fix rpm/deb build error caused by moving systemvm to its own maven project

[Chip Childers]

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

Ship it!


Applied to master.  Thanks for the patch!

commit 91aee8bc98ca2fa7ae62ab70fc2f30c69e321ddb
Author: ynojima 
Date:   Mon Sep 23 17:47:14 2013 -0600

fix rpm/deb build error caused by moving systemvm to its own maven project

- Chip Childers


On Sept. 24, 2013, 2:21 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14299/
> ---
> 
> (Updated Sept. 24, 2013, 2:21 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> By moving systemvm to its own maven project 
> (6c261042821c5597dab8d6be85dc59c948424e13), systemvm.iso's file path was 
> changed, but the rpm/deb build script don't follow this change.
> http://jenkins.buildacloud.org/view/master/job/package-deb-master/3677/
> 
> This patch solve this problem.
> 
> 
> Diffs
> -
> 
>   debian/rules 5e3d58c 
>   packaging/centos63/cloud.spec fba2b1a 
> 
> Diff: https://reviews.apache.org/r/14299/diff/
> 
> 
> Testing
> ---
> 
> 
> tail of deb build log
> 
> 
> dh_builddeb
>   dpkg-deb --build debian/cloudstack-common ..
> dpkg-deb: building package `cloudstack-common' in 
> `../cloudstack-common_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-management ..
> dpkg-deb: building package `cloudstack-management' in 
> `../cloudstack-management_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-agent ..
> dpkg-deb: building package `cloudstack-agent' in 
> `../cloudstack-agent_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-usage ..
> dpkg-deb: building package `cloudstack-usage' in 
> `../cloudstack-usage_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-awsapi ..
> dpkg-deb: building package `cloudstack-awsapi' in 
> `../cloudstack-awsapi_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-cli ..
> dpkg-deb: building package `cloudstack-cli' in 
> `../cloudstack-cli_4.3.0_all.deb'.
>   dpkg-deb --build debian/cloudstack-docs ..
> dpkg-deb: building package `cloudstack-docs' in 
> `../cloudstack-docs_4.3.0_all.deb'.
>  dpkg-genchanges  >../cloudstack_4.3.0_amd64.changes
> dpkg-genchanges: including full source code in upload
>  dpkg-source --after-build cloudstack-4.3.0-SNAPSHOT
> dpkg-buildpackage: full upload; Debian-native package (full source is 
> included)
> + cd 
> /var/lib/jenkins-slave/workspace/verio-cloudstack-deb-pull-request/dists/debian
> + mkdir -p 
> /var/lib/jenkins-slave/workspace/verio-cloudstack-deb-pull-request/dists/debian/main/binary-amd64
> + mv cloudstack-agent_4.3.0_all.deb cloudstack-awsapi_4.3.0_all.deb 
> cloudstack-cli_4.3.0_all.deb cloudstack-common_4.3.0_all.deb 
> cloudstack-docs_4.3.0_all.deb cloudstack-management_4.3.0_all.deb 
> cloudstack-usage_4.3.0_all.deb cloudstack_4.3.0_amd64.changes 
> cloudstack_4.3.0.dsc main/binary-amd64
> + cd /var/lib/jenkins-slave/workspace/verio-cloudstack-deb-pull-request
> + dpkg-scanpackages+  dists/debian/main/binary-amd64 /dev/null
> tee 
> /var/lib/jenkins-slave/workspace/verio-cloudstack-deb-pull-request/dists/debian/main/binary-amd64/Packages
> + gzip -9
> dpkg-scanpackages: warning: Packages in archive but missing from override 
> file:
> dpkg-scanpackages: warning:   cloudstack-agent cloudstack-awsapi 
> cloudstack-cli cloudstack-common cloudstack-docs cloudstack-management 
> cloudstack-usage
> dpkg-scanpackages: info: Wrote 7 entries to output Packages file.
> Finished: SUCCESS
> 
> 
> 
> tail of rpm build log
> 
> Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/BUILDROOT/cloudstack-4.3.0-SNAPSHOT.el6.x86_64
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_64/cloudstack-management-4.3.0-SNAPSHOT.el6.x86_64.rpm
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_64/cloudstack-common-4.3.0-SNAPSHOT.el6.x86_64.rpm
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_64/cloudstack-agent-4.3.0-SNAPSHOT.el6.x86_64.rpm
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_64/cloudstack-usage-4.3.0-SNAPSHOT.el6.x86_64.rpm
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_64/cloudstack-cli-4.3.0-SNAPSHOT.el6.x86_64.rpm
> Wrote: 
> /var/lib/jenkins/jobs/verio-cloudstack-rpm-pull-request/workspace/dist/rpmbuild/RPMS/x86_6

Re: Managed storage with KVM

[Marcus Sorensen]

I stull haven't seen your agent.properties. This would tell me if your
setup succeeded.  At this point my best guess is that
"cloudstack-setup-agent  -m 192.168.233.1 -z 1 -p 1 -c 1 -g
6b4aa1c2-2ac9-3c60-aabe-704aed40c684 -a --pubNic=cloudbr0
--prvNic=cloudbr0 --guestNic=cloudbr0" failed in some fashion. You can
run it manually at any time to see. Once that is run, then the agent
should come up. The resource name in your code is pulled from
agent.properties (I believe) and is usually
"resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".

On Tue, Sep 24, 2013 at 12:12 AM, Mike Tutkowski
 wrote:
> I've been narrowing it down by putting in a million print-to-log statements.
>
> Do you know if it is a problem that value ends up null (in a constructor
> for Agent)?
>
> String value = _shell.getPersistentProperty(getResourceName(), "id");
>
> In that same constructor, this line never finishes:
>
> if (!_resource.configure(getResourceName(), params)) {
>
> I need to dig into the configure method to see what's going on there.
>
>
> On Mon, Sep 23, 2013 at 5:45 PM, Marcus Sorensen wrote:
>
>> It might be a centos specific thing. These are created by the init scripts.
>> Check your agent init script on Ubuntu and see I'd you can decipher where
>> it sends stdout.
>> On Sep 23, 2013 5:21 PM, "Mike Tutkowski" 
>> wrote:
>>
>> > Weird...no such file exists.
>> >
>> >
>> > On Mon, Sep 23, 2013 at 4:54 PM, Marcus Sorensen > > >wrote:
>> >
>> > > maybe cloudstack-agent.out
>> > >
>> > > On Mon, Sep 23, 2013 at 4:44 PM, Mike Tutkowski
>> > >  wrote:
>> > > > OK, so, nothing is screaming out in the logs. I did notice the
>> > following:
>> > > >
>> > > > From setup.log:
>> > > >
>> > > > DEBUG:root:execute:apparmor_status |grep libvirt
>> > > >
>> > > > DEBUG:root:Failed to execute:
>> > > >
>> > > >
>> > > > DEBUG:root:execute:sudo /usr/sbin/service cloudstack-agent status
>> > > >
>> > > > DEBUG:root:Failed to execute: * could not access PID file for
>> > > > cloudstack-agent
>> > > >
>> > > >
>> > > > This is the final line in this log file:
>> > > >
>> > > > DEBUG:root:execute:sudo /usr/sbin/service cloudstack-agent start
>> > > >
>> > > >
>> > > > This is from agent.log:
>> > > >
>> > > > 2013-09-23 15:30:55,549 DEBUG [cloud.agent.AgentShell] (main:null)
>> > > Checking
>> > > > to see if agent.pid exists.
>> > > >
>> > > > 2013-09-23 15:30:55,655 DEBUG [cloud.utils.ProcessUtil] (main:null)
>> > > > Executing: bash -c echo $PPID
>> > > >
>> > > > 2013-09-23 15:30:55,742 DEBUG [cloud.utils.ProcessUtil] (main:null)
>> > > > Execution is successful.
>> > > >
>> > > > 2013-09-23 15:30:56,000 INFO  [cloud.agent.Agent] (main:null) id is
>> > > >
>> > > > 2013-09-23 15:30:56,000 DEBUG [cloud.resource.ServerResourceBase]
>> > > > (main:null) Retrieving network interface: cloudbr0
>> > > >
>> > > > 2013-09-23 15:30:56,016 DEBUG [cloud.resource.ServerResourceBase]
>> > > > (main:null) Retrieving network interface: cloudbr0
>> > > >
>> > > > 2013-09-23 15:30:56,016 DEBUG [cloud.resource.ServerResourceBase]
>> > > > (main:null) Retrieving network interface: null
>> > > >
>> > > > 2013-09-23 15:30:56,017 DEBUG [cloud.resource.ServerResourceBase]
>> > > > (main:null) Retrieving network interface: null
>> > > >
>> > > >
>> > > > The following kinds of lines are repeated for a bunch of different
>> .sh
>> > > > files. I think they often end up being found here:
>> > > > /usr/share/cloudstack-common/scripts/network/domr, so this is
>> probably
>> > > not
>> > > > an issue.
>> > > >
>> > > >
>> > > > 2013-09-23 15:30:56,111 DEBUG [utils.script.Script] (main:null)
>> Looking
>> > > for
>> > > > call_firewall.sh in the classpath
>> > > >
>> > > > 2013-09-23 15:30:56,112 DEBUG [utils.script.Script] (main:null)
>> System
>> > > > resource: null
>> > > >
>> > > > 2013-09-23 15:30:56,113 DEBUG [utils.script.Script] (main:null)
>> > Classpath
>> > > > resource: null
>> > > >
>> > > > 2013-09-23 15:30:56,123 DEBUG [utils.script.Script] (main:null)
>> Looking
>> > > for
>> > > > call_firewall.sh
>> > > >
>> > > >
>> > > > Is there a log file for the Java code that I could write stuff out to
>> > and
>> > > > see how far we get?
>> > > >
>> > > >
>> > > > On Mon, Sep 23, 2013 at 3:17 PM, Mike Tutkowski <
>> > > > mike.tutkow...@solidfire.com> wrote:
>> > > >
>> > > >> Thanks, Marcus
>> > > >>
>> > > >> I've been developing on Windows for most of my time, so a bunch of
>> > these
>> > > >> Linux-type commands are new to me and I don't always interpret the
>> > > output
>> > > >> correctly. Getting there. :)
>> > > >>
>> > > >>
>> > > >> On Mon, Sep 23, 2013 at 2:37 PM, Marcus Sorensen <
>> shadow...@gmail.com
>> > > >wrote:
>> > > >>
>> > > >>> Nope, not running. That's just your grep process. It would look
>> like:
>> > > >>>
>> > > >>> root 24429 24428  1 14:25 ?00:00:08 jsvc.exec -cp
>> > > >>>
>> > > >>>
>> > >
>> >
>> /usr/share/java/commons-daemon.jar:/usr/share/java/jna.jar:/usr/share/cloudstack-agent/lib/activa

[ANNOUNCE] New committer: Rajesh Battala

[Chip Childers]

The Project Management Committee (PMC) for Apache CloudStack
has asked Rajesh Battala to become a committer and we are pleased to
announce that they have accepted.

Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch
submission process. Whether contributions are development-related or
otherwise, it is a recognition of a contributor's participation in the
project and commitment to the project and the Apache Way.

Please join me in congratulating Rajesh!

-chip
on behalf of the CloudStack PMC

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Alex Ough]

For a resolution without breaking possible flows, I'd like to add the value
of 'executeInSequence' to the global setting.
Is there any reason not to do this?

Thanks
Alex Ough


On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough  wrote:

> All,
>
> After a little more investigation, I found that the 'MigrateCommand'
> defined its 'executeInSequence' method to return 'FALSE', which seems to
> make the vm migrations as serial even if the migration requests are
> dispatched to ha_worker in parallel.
> You can confirm this in line 56 of
> '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
>
> So my question is if there is any reason why the method have been
> defined to return 'FALSE' always?
> And do we expect any side effects and/or malfunctioning if we change it to
> returning 'TRUE'?
>
> Any answers/comments will be very appreciated.
> Thanks
> Alex Ough
>
>
> On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough  wrote:
>
>> I checked the vm migration when their host is set to a maintenance mode
>> and found that even if the orchestration layer fires the each vm migration
>> at the same time using a ha_worker thread, the actual migration seems to be
>> executed serially.
>>
>> Is this what we expect? And if so, any chance to make the actual
>> migrations in parallel?
>>
>> Thanks
>> Alex Ough
>>
>
>

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Chip Childers]

Hey Kelven - This topic was discussed briefly in the past [1].  Are you
able to provide any thoughts on Alex's ideas below?

-chip


[1] http://markmail.org/message/fznrszaswruvlmuy



On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
> For a resolution without breaking possible flows, I'd like to add the value
> of 'executeInSequence' to the global setting.
> Is there any reason not to do this?
> 
> Thanks
> Alex Ough
> 
> 
> On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough  wrote:
> 
> > All,
> >
> > After a little more investigation, I found that the 'MigrateCommand'
> > defined its 'executeInSequence' method to return 'FALSE', which seems to
> > make the vm migrations as serial even if the migration requests are
> > dispatched to ha_worker in parallel.
> > You can confirm this in line 56 of
> > '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
> >
> > So my question is if there is any reason why the method have been
> > defined to return 'FALSE' always?
> > And do we expect any side effects and/or malfunctioning if we change it to
> > returning 'TRUE'?
> >
> > Any answers/comments will be very appreciated.
> > Thanks
> > Alex Ough
> >
> >
> > On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough  wrote:
> >
> >> I checked the vm migration when their host is set to a maintenance mode
> >> and found that even if the orchestration layer fires the each vm migration
> >> at the same time using a ha_worker thread, the actual migration seems to be
> >> executed serially.
> >>
> >> Is this what we expect? And if so, any chance to make the actual
> >> migrations in parallel?
> >>
> >> Thanks
> >> Alex Ough
> >>
> >
> >

RE: [ANNOUNCE] New committer: Rajesh Battala

[Musayev, Ilya]

Congrats Rajesh!

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, September 24, 2013 11:30 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New committer: Rajesh Battala
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Rajesh Battala to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Rajesh!
> 
> -chip
> on behalf of the CloudStack PMC

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Marcus Sorensen]

On Mon, Sep 23, 2013 at 1:55 PM, Animesh Chaturvedi
 wrote:
>
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Monday, September 23, 2013 12:25 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [PROPOSAL] move away from time-based releases and/or revamp
>> release process
>>
>> On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi"
>> 
>> wrote:
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> > > Sent: Monday, September 23, 2013 11:38 AM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: [PROPOSAL] move away from time-based releases and/or revamp
>> > > release process
>> > >
>> > > Guys,  I think we are not currently in a state to handle time-based
>> > > releases.  Until we can cut master at any time and have it
>> > > releasable, or at least at a reasonable RC-level matching minimum
>> > > tested requirements, it's just going to continue to be an exercise
>> > > in frustration to cut RCs simply because we hit a deadline.
>> > [Animesh>] David is going to propose Release Criterion up for
>> > discussion
>> as per his thread [1]
>>
>> I see that thread more about defining what minimum bar we should always
>> have master at in order to meet time-based releases. Its where we want
>> to go, but not what to do in the meantime.
> [Animesh>] His proposal is not just for master, but also for deciding the 
> release exit criterion and IMO is something we should follow for 4.3.0 and 
> onwards

Yes, I know. What I meant was that it will be a step toward
stabilizing master, until we do that I'm not convinced we can adhere
to any time-based expectation). It still doesn't fix our issue if
we're going to insist on time-based releases, it just (from my
undertanding) sets a bar for what is acceptable and what isn't, for
any release. It stops the argument of "should we release with this
bug".

>>
>> > >
>> > > Maybe we can get away with sticking to time-based if we revamp our
>> > > schedule and procedures, I don't know, but in light of how 4.1
>> > > (dragged on so long that some were seriously considering
>> > > skipping/not releasing it with 4.2 on its heels) and 4.2 (six rounds
>> > > of votes so
>> > > far) have worked it's probably worth discussing.
>> > >
>> > > Any suggestions on what might be better? It's been mentioned in the
>> > > past that it's a chicken-egg thing, many really don't try it until
>> > > we hit an RC, which causes multiple iterations. I do agree that many
>> > > don't take it seriously until we start cutting artifacts, but maybe
>> > > we do this in a more deliberate fashion instead of jumping right to
>> > > the vote. After feature/code freeze, cut some alpha artifacts, wait
>> > > a week, cut alpha2 or some beta artifacts, etc, and then at some
>> > > point anyone can propose that certain artifacts (or a new set of
>> > > artifacts) be put up for a vote as an RC. This gives us a way to
>> > > signal that we're gearing up for release and gives plenty of time
>> > > for people to test their components, or see the [PROPOSAL] and say
>> > > 'oh crap, I had better test my stuff', prior to cutting an RC.
>> > > Maybe this wouldn't help in practice, but I think right now we go
>> > > from telling the community "code is frozen, don't check anything in
>> > > unless its a bug fix" to "here's our RC, try it out", without a
>> formal testing window.
>> > > I realize the whole thing should be a testing window, but I don't
>> > > think it's conveyed well.
>> >
>> > [Animesh>] After the code freeze is all the stabilization and
>> > integration
>> testing phase and has been documented at [2].  No one should be waiting
>> until the RC to test their components for the first time. It should be
>> happening after code freeze.
>>
>> >
>> > [1] http://markmail.org/thread/wlaq4zg36xnpgsjm
>> > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
>> >
>>
>> Got it. As mentioned I realize that the whole time there is supposed to
>> be testing, but its not really working that way in practice. People are
>> volunteers, they forget where things are, or they dont want to mess with
>> it unless there is an indication that its semi-stable, and then suddenly
>> an RC is thrown over the fence and we go through iterations of RC. By
>> the time the RC comes through we should be done testing and just verify
>> that someone's last minute bug fix didn't cause a regression or
>> something.
> [Animesh>] RC is not thrown in it is discussed as part of the release 
> schedule.  After the code-freeze date everyone is expected to complete their 
> integration testing by RC date. In fact I had sent numerous reminders prior 
> to the first RC starting from 2 weeks before the proposed RC date.

That's not the point. The code is changing at a rapid pace. Mike, for
example, commented on tons of critical fixes going in right up until
the RC is cut. Then we cut some artifacts and give people 72 hours to
test and buy off.   Wh

Re: Managed storage with KVM

[Mike Tutkowski]

This is what a fresh agent.properties file looks like on my system.

I expect if I try to add it to a cluster, the empty, localhost, and default
values below should be filled in.

I plan to try to add it to a cluster in a bit.

# The GUID to identify the agent with, this is mandatory!
# Generate with "uuidgen"
guid=

#resource= the java class, which agent load to execute
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource

#workers= number of threads running in agent
workers=5

#host= The IP address of management server
host=localhost

#port = The port management server listening on, default is 8250
port=8250

#cluster= The cluster which the agent belongs to
cluster=default

#pod= The pod which the agent belongs to
pod=default

#zone= The zone which the agent belongs to
zone=default



On Tue, Sep 24, 2013 at 8:55 AM, Marcus Sorensen wrote:

> I stull haven't seen your agent.properties. This would tell me if your
> setup succeeded.  At this point my best guess is that
> "cloudstack-setup-agent  -m 192.168.233.1 -z 1 -p 1 -c 1 -g
> 6b4aa1c2-2ac9-3c60-aabe-704aed40c684 -a --pubNic=cloudbr0
> --prvNic=cloudbr0 --guestNic=cloudbr0" failed in some fashion. You can
> run it manually at any time to see. Once that is run, then the agent
> should come up. The resource name in your code is pulled from
> agent.properties (I believe) and is usually
> "resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
>
> On Tue, Sep 24, 2013 at 12:12 AM, Mike Tutkowski
>  wrote:
> > I've been narrowing it down by putting in a million print-to-log
> statements.
> >
> > Do you know if it is a problem that value ends up null (in a constructor
> > for Agent)?
> >
> > String value = _shell.getPersistentProperty(getResourceName(), "id");
> >
> > In that same constructor, this line never finishes:
> >
> > if (!_resource.configure(getResourceName(), params)) {
> >
> > I need to dig into the configure method to see what's going on there.
> >
> >
> > On Mon, Sep 23, 2013 at 5:45 PM, Marcus Sorensen  >wrote:
> >
> >> It might be a centos specific thing. These are created by the init
> scripts.
> >> Check your agent init script on Ubuntu and see I'd you can decipher
> where
> >> it sends stdout.
> >> On Sep 23, 2013 5:21 PM, "Mike Tutkowski"  >
> >> wrote:
> >>
> >> > Weird...no such file exists.
> >> >
> >> >
> >> > On Mon, Sep 23, 2013 at 4:54 PM, Marcus Sorensen  >> > >wrote:
> >> >
> >> > > maybe cloudstack-agent.out
> >> > >
> >> > > On Mon, Sep 23, 2013 at 4:44 PM, Mike Tutkowski
> >> > >  wrote:
> >> > > > OK, so, nothing is screaming out in the logs. I did notice the
> >> > following:
> >> > > >
> >> > > > From setup.log:
> >> > > >
> >> > > > DEBUG:root:execute:apparmor_status |grep libvirt
> >> > > >
> >> > > > DEBUG:root:Failed to execute:
> >> > > >
> >> > > >
> >> > > > DEBUG:root:execute:sudo /usr/sbin/service cloudstack-agent status
> >> > > >
> >> > > > DEBUG:root:Failed to execute: * could not access PID file for
> >> > > > cloudstack-agent
> >> > > >
> >> > > >
> >> > > > This is the final line in this log file:
> >> > > >
> >> > > > DEBUG:root:execute:sudo /usr/sbin/service cloudstack-agent start
> >> > > >
> >> > > >
> >> > > > This is from agent.log:
> >> > > >
> >> > > > 2013-09-23 15:30:55,549 DEBUG [cloud.agent.AgentShell] (main:null)
> >> > > Checking
> >> > > > to see if agent.pid exists.
> >> > > >
> >> > > > 2013-09-23 15:30:55,655 DEBUG [cloud.utils.ProcessUtil]
> (main:null)
> >> > > > Executing: bash -c echo $PPID
> >> > > >
> >> > > > 2013-09-23 15:30:55,742 DEBUG [cloud.utils.ProcessUtil]
> (main:null)
> >> > > > Execution is successful.
> >> > > >
> >> > > > 2013-09-23 15:30:56,000 INFO  [cloud.agent.Agent] (main:null) id
> is
> >> > > >
> >> > > > 2013-09-23 15:30:56,000 DEBUG [cloud.resource.ServerResourceBase]
> >> > > > (main:null) Retrieving network interface: cloudbr0
> >> > > >
> >> > > > 2013-09-23 15:30:56,016 DEBUG [cloud.resource.ServerResourceBase]
> >> > > > (main:null) Retrieving network interface: cloudbr0
> >> > > >
> >> > > > 2013-09-23 15:30:56,016 DEBUG [cloud.resource.ServerResourceBase]
> >> > > > (main:null) Retrieving network interface: null
> >> > > >
> >> > > > 2013-09-23 15:30:56,017 DEBUG [cloud.resource.ServerResourceBase]
> >> > > > (main:null) Retrieving network interface: null
> >> > > >
> >> > > >
> >> > > > The following kinds of lines are repeated for a bunch of different
> >> .sh
> >> > > > files. I think they often end up being found here:
> >> > > > /usr/share/cloudstack-common/scripts/network/domr, so this is
> >> probably
> >> > > not
> >> > > > an issue.
> >> > > >
> >> > > >
> >> > > > 2013-09-23 15:30:56,111 DEBUG [utils.script.Script] (main:null)
> >> Looking
> >> > > for
> >> > > > call_firewall.sh in the classpath
> >> > > >
> >> > > > 2013-09-23 15:30:56,112 DEBUG [utils.script.Script] (main:null)
> >> System
> >> > > > resource: null
> >> > > >
> >> > > > 2013-09-23 15:30:56,113 DEBUG [utils.script.Script] (main:null)
> >> > Classp

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Chip Childers]

On Tue, Sep 24, 2013 at 10:00:32AM -0600, Marcus Sorensen wrote:
> I guess I'm in the minority though, since we're the
> only ones discussing it.

No you are not.  Personally, I'm thinking about this problem a bit
before adding my 2 cents.  Don't take that silence as thinking we are
"ok".

Short version of my thoughts:

1 - a schedule is really important to a project like this
2 - not releasing crap quality is really really important to a project
like this

Note the "really" vs. "really really".

-chip

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Marcus Sorensen]

I thought executeInSequence of 'true' made it go serially, or
sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
August of 2010:

2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends Command {
2010-08-11 09:13:29 -0700 20) String vmName;
2010-08-11 09:13:29 -0700 21) String destIp;
2011-08-10 10:26:04 -0700 22) String hostGuid;
2010-08-11 09:13:29 -0700 23) boolean isWindows;
2010-08-11 09:13:29 -0700 24)
2010-08-11 09:13:29 -0700 25)
2010-08-11 09:13:29 -0700 26) protected MigrateCommand() {
2010-08-11 09:13:29 -0700 27) }
2012-12-03 22:06:41 -0800 28)
2010-08-11 09:13:29 -0700 29) public MigrateCommand(String vmName,
String destIp, boolean isWindows)
2010-08-11 09:13:29 -0700 30) this.vmName = vmName;
2010-08-11 09:13:29 -0700 31) this.destIp = destIp;
2010-08-11 09:13:29 -0700 32) this.isWindows = isWindows;
2010-08-11 09:13:29 -0700 33) }
2012-12-03 22:06:41 -0800 34)
2010-08-11 09:13:29 -0700 35) public boolean isWindows() {
2010-08-11 09:13:29 -0700 36) return isWindows;
2010-08-11 09:13:29 -0700 37) }
2012-12-03 22:06:41 -0800 38)
2010-08-11 09:13:29 -0700 39) public String getDestinationIp() {
2010-08-11 09:13:29 -0700 40) return destIp;
2010-08-11 09:13:29 -0700 41) }
2012-12-03 22:06:41 -0800 42)
2010-08-11 09:13:29 -0700 43) public String getVmName() {
2010-08-11 09:13:29 -0700 44) return vmName;
2010-08-11 09:13:29 -0700 45) }
2012-12-03 22:06:41 -0800 46)
2011-08-10 10:26:04 -0700 47) public void setHostGuid(String guid)
{
2011-08-10 10:26:04 -0700 48) this.hostGuid = guid;
2011-08-10 10:26:04 -0700 49) }
2012-12-03 22:06:41 -0800 50)
2011-08-10 10:26:04 -0700 51) public String getHostGuid() {
2011-08-10 10:26:04 -0700 52) return this.hostGuid;
2011-08-10 10:26:04 -0700 53) }
2010-08-11 09:13:29 -0700 54)
2010-08-11 09:13:29 -0700 55) @Override
2010-08-11 09:13:29 -0700 56) public boolean executeInSequence() {
2010-08-11 09:13:29 -0700 57) return true;
2010-08-11 09:13:29 -0700 58) }
2010-08-11 09:13:29 -0700 59) }

On Tue, Sep 24, 2013 at 9:58 AM, Chip Childers
 wrote:
> Hey Kelven - This topic was discussed briefly in the past [1].  Are you
> able to provide any thoughts on Alex's ideas below?
>
> -chip
>
>
> [1] http://markmail.org/message/fznrszaswruvlmuy
>
>
>
> On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
>> For a resolution without breaking possible flows, I'd like to add the value
>> of 'executeInSequence' to the global setting.
>> Is there any reason not to do this?
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough  wrote:
>>
>> > All,
>> >
>> > After a little more investigation, I found that the 'MigrateCommand'
>> > defined its 'executeInSequence' method to return 'FALSE', which seems to
>> > make the vm migrations as serial even if the migration requests are
>> > dispatched to ha_worker in parallel.
>> > You can confirm this in line 56 of
>> > '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
>> >
>> > So my question is if there is any reason why the method have been
>> > defined to return 'FALSE' always?
>> > And do we expect any side effects and/or malfunctioning if we change it to
>> > returning 'TRUE'?
>> >
>> > Any answers/comments will be very appreciated.
>> > Thanks
>> > Alex Ough
>> >
>> >
>> > On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough  wrote:
>> >
>> >> I checked the vm migration when their host is set to a maintenance mode
>> >> and found that even if the orchestration layer fires the each vm migration
>> >> at the same time using a ha_worker thread, the actual migration seems to 
>> >> be
>> >> executed serially.
>> >>
>> >> Is this what we expect? And if so, any chance to make the actual
>> >> migrations in parallel?
>> >>
>> >> Thanks
>> >> Alex Ough
>> >>
>> >
>> >

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chip Childers]

On Tue, Sep 24, 2013 at 04:21:19AM +, Animesh Chaturvedi wrote:
> 
>  
>  This vote has passed with no -1 votes.
>  
>  +1 votes were from (with * binding):
>  Chiradeep*, Hugo*, Chip*, Milamber,  Amogh
>  
>  +0: Marcus*
>  
>  Marcus agreed to change his VOTE to +1 with a Release Note change that
>  he will make.
>  
>  Wido can you build and publish  the .deb packages

Animesh,

Just to help get things clearly listed, here are the todo's that I see
for 4.2:

1 - Finish the docs (release notes especially) and publish them to
cloudstack.apache.org/docs

  *We need someone to own this*

2 - Build the DEB packages

  Wido has this one

3 - Build the RPM packages

  *We need someone to own this one*

4 - Move the source artifacts from dist/dev to dist/release and stage
the download page changes

  A PMC member needs to do this.  I'll take this one.

5 - Finish the release announcement

  This was started by Mathias here:
  
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Announcement

  It should really be finished. 
  
  *Someone needs to own finalizing this.*

6 - Publish the website and announce the release (using the finished 
announcement) after 1
through 5 are done.

  This can be any committer, but Animesh you'd probably want the honors!


There are also other marketing related things to get done, but that
thread started on marketing@ and can happen after / in parallel to the
work listed above.

-chip

RE: [ANNOUNCE] New committer: Rajesh Battala

[Sailaja Mada]

Congratulations Rajesh.

Best Regards,
Sailaja.M

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, September 24, 2013 9:00 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] New committer: Rajesh Battala

The Project Management Committee (PMC) for Apache CloudStack has asked Rajesh 
Battala to become a committer and we are pleased to announce that they have 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Rajesh!

-chip
on behalf of the CloudStack PMC

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Daan Hoogland]

is this work a workshop to get at least a core group of us in line. We
all have ideas and a lot of good ones are buried under an ton weighing
archive of mails.

Daan

On Tue, Sep 24, 2013 at 6:06 PM, Chip Childers
 wrote:
> On Tue, Sep 24, 2013 at 10:00:32AM -0600, Marcus Sorensen wrote:
>> I guess I'm in the minority though, since we're the
>> only ones discussing it.
>
> No you are not.  Personally, I'm thinking about this problem a bit
> before adding my 2 cents.  Don't take that silence as thinking we are
> "ok".
>
> Short version of my thoughts:
>
> 1 - a schedule is really important to a project like this
> 2 - not releasing crap quality is really really important to a project
> like this
>
> Note the "really" vs. "really really".
>
> -chip

Re: [ANNOUNCE] New committer: Rajesh Battala

[Wei ZHOU]

Congratulations!


2013/9/24 Chip Childers 

> The Project Management Committee (PMC) for Apache CloudStack
> has asked Rajesh Battala to become a committer and we are pleased to
> announce that they have accepted.
>
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the
> project and commitment to the project and the Apache Way.
>
> Please join me in congratulating Rajesh!
>
> -chip
> on behalf of the CloudStack PMC
>

Re: Review Request 14231: Don't check implementation verion of Object for DatabaseUpgradeChecker

[daan Hoogland]

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



engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java


Could we check for an interface, allowing an ancestor between this and 
Object to supply the version? your argument makes sense, your solution seems 
drastic given that womeone took the trouble to write this code.


- daan Hoogland


On Sept. 19, 2013, 5:03 p.m., Darren Shepherd wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14231/
> ---
> 
> (Updated Sept. 19, 2013, 5:03 p.m.)
> 
> 
> Review request for cloudstack, Alex Huang and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently DatabaseUpgradeChecker determines the code version by doing 
> this.getClass().getPackage().getImplementationVersion().  If it can't find 
> the version it will eventually just give up and not do the database check.  
> The problem currently is if it doesn't find the version, it will also check 
> its parent's class version.  The parent is java.lang.Object which will return 
> the java version (for example 1.6.0_43).  It doesn't seem like we would 
> really want to ever try the JDK version as our code version, so this patch it 
> to just effectively remove that check.
>  
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java f001bf7 
> 
> Diff: https://reviews.apache.org/r/14231/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Darren Shepherd
> 
>

Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[daan Hoogland]

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

Review request for cloudstack.


Bugs: CLOUDSTACK-4328


Repository: cloudstack-git


Description
---

add boolean option httpModeEnabled to the service offering for use in haproxy 
conf


Diffs
-

  api/src/com/cloud/offering/NetworkOffering.java 6c5573e 
  api/src/org/apache/cloudstack/api/ApiConstants.java f85784b 
  
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
 bdad904 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOfferingCmd.java
 c9c4c8a 
  core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java ee29290 
  core/src/com/cloud/network/HAProxyConfigurator.java 2309125 
  core/test/com/cloud/network/HAProxyConfiguratorTest.java PRE-CREATION 
  engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java eefdc94 
  
plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
 ecd6006 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
 587ae99 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
7c026a4 
  setup/db/db/schema-420to430.sql 44a884d 

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


Testing
---

created unit test.


Thanks,

daan Hoogland

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[David Nalley]

On Tue, Sep 24, 2013 at 12:06 PM, Chip Childers
 wrote:
> On Tue, Sep 24, 2013 at 10:00:32AM -0600, Marcus Sorensen wrote:
>> I guess I'm in the minority though, since we're the
>> only ones discussing it.
>
> No you are not.  Personally, I'm thinking about this problem a bit
> before adding my 2 cents.  Don't take that silence as thinking we are
> "ok".
>
> Short version of my thoughts:
>
> 1 - a schedule is really important to a project like this
> 2 - not releasing crap quality is really really important to a project
> like this
>
> Note the "really" vs. "really really".
>
> -chip

I agree with the sentiment in the above two points.
I, personally, do not think that the problem is with a time-based
release. I don't think that hurts or helps us in the quality
department.
I do think that we have to get to a point where we can unequivocally
verify the status of 'master' or a 'release' branch. I'd prefer that
we be able to do this before code gets pushed to it. The network
effect of even small changes in CloudStack can be profound. I am
almost to the point that I'd prefer us to focus the 4.3 release cycle
on nothing but building out QA infrastructure so that we can 'prove'
that proposed changes don't cause harm, and that the software is
actually releasable.

--David

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[David Nalley]

>
> 1 - Finish the docs (release notes especially) and publish them to
> cloudstack.apache.org/docs
>
>   *We need someone to own this*

I can do this, but it may be tomorrow before it gets done.

>
> 2 - Build the DEB packages
>
>   Wido has this one
>
> 3 - Build the RPM packages
>
>   *We need someone to own this one*

I'll take care of RPMs.

>
> 4 - Move the source artifacts from dist/dev to dist/release and stage
> the download page changes
>
>   A PMC member needs to do this.  I'll take this one.
>
> 5 - Finish the release announcement
>
>   This was started by Mathias here:
>   
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Announcement
>
>   It should really be finished.
>
>   *Someone needs to own finalizing this.*
>
> 6 - Publish the website and announce the release (using the finished 
> announcement) after 1
> through 5 are done.
>
>   This can be any committer, but Animesh you'd probably want the honors!
>
>
> There are also other marketing related things to get done, but that
> thread started on marketing@ and can happen after / in parallel to the
> work listed above.
>
> -chip

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chip Childers]

On Tue, Sep 24, 2013 at 12:21:36PM -0400, Chip Childers wrote:
> 4 - Move the source artifacts from dist/dev to dist/release and stage
> the download page changes
> 
>   A PMC member needs to do this.  I'll take this one.

Done: http://cloudstack.staging.apache.org/downloads.html

And Done: 

svn mv -m "Publishing 4.2.0 CloudStack release"
https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
https://dist.apache.org/repos/dist/release/cloudstack/releases/

Committed revision 2973.

RE: [ANNOUNCE] New committer: Rajesh Battala

[Sateesh Chodapuneedi]

Hearty Congratulations Rajesh:)

Regards,
Sateesh
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: 24 September 2013 21:00
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] New committer: Rajesh Battala
> 
> The Project Management Committee (PMC) for Apache CloudStack has asked Rajesh 
> Battala to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission 
> process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the 
> project and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Rajesh!
> 
> -chip
> on behalf of the CloudStack PMC

Re: New features

[Alena Prokharchyk]

I did reopen the https://issues.apache.org/jira/browse/CLOUDSTACK-3128. Will 
get fixed for the next release, thanks Nicolas and Sebastien for following up.

-Alena.

From: Sebastien Goasguen mailto:run...@gmail.com>>
Date: Tuesday, September 24, 2013 12:13 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Subject: Re: New features


On Sep 23, 2013, at 4:50 AM, 
nfoata@orange.com wrote:

Hello Cloudstack,
Sometimes ago, I wrote and submitted two new features with the following 
identifiers (see below) :
1) JIRA
https://issues.apache.org/jira/browse/CLOUDSTACK-3701 (VM instantiation: 
Sending network information in an extra field)
https://issues.apache.org/jira/browse/CLOUDSTACK-3702 (VM instantiation: 
Specific information for hypervisors)

2) Review board

Both Jira issues were also registered under review boards with a git diff and 
submitted in august.
However, I never received any comment on them.
( I would like to put the direct links, in that mail but review board is not 
accessible this morning).
Furthermore, I noticed and saw that there is a lot of demands under the review 
boards which are not yet processed.
Does it mean, that there is so many requests that is take a long time ?

Hi Nicolas, and thanks for the ping.
Unfortunately it just means that we are behind.

Do cloudstack reviewers need more people or help ?

Yes, this is community driven, so any help you can give is very much welcome. 
You can help review patches, file bugs, and submit more patches.

Or simply that I did not well up (follow) the submission process somewhere ? 
(Jira -> review board -> submit ).
At last, I asked if is it possible to open again a bug (CLOUDSTACK-3128) 
because it was not totally fixed and
I sent the solution in the comment of this one. (I can also do a git diff if I 
have to submit it.) but no answer too.
https://issues.apache.org/jira/browse/CLOUDSTACK-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

You should be able to re-open this bug. I am copying Alena to make sure she 
notices it and sees your comment in the bug.


Thanks in advance for yours answers and please feel free to contact me if need 
be,
Have a good day,
Best regards,


Nicolas Foata
Ingénieur
DMGP/Portail/DOP/EnP/Advise
Norsys pour Orange
Sophia Antipolis
nfoata@orange.com

_
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.
This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [ANNOUNCE] New committer: Rajesh Battala

[Min Chen]

Congrats, Rajesh.

-min

On 9/24/13 9:40 AM, "Sateesh Chodapuneedi"
 wrote:

>Hearty Congratulations Rajesh:)
>
>Regards,
>Sateesh
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: 24 September 2013 21:00
>> To: dev@cloudstack.apache.org
>> Subject: [ANNOUNCE] New committer: Rajesh Battala
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>>Rajesh Battala to become a committer and we are pleased to
>> announce that they have accepted.
>> 
>> Being a committer allows many contributors to contribute more
>>autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>>submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the
>>project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Rajesh!
>> 
>> -chip
>> on behalf of the CloudStack PMC

Re: [ANNOUNCE] New committer: Rajesh Battala

[Kelcey Jamison Damage]

Congratulations!

- Original Message -
From: "Min Chen" 
To: dev@cloudstack.apache.org
Sent: Tuesday, September 24, 2013 9:46:43 AM
Subject: Re: [ANNOUNCE] New committer: Rajesh Battala

Congrats, Rajesh.

-min

On 9/24/13 9:40 AM, "Sateesh Chodapuneedi"
 wrote:

>Hearty Congratulations Rajesh:)
>
>Regards,
>Sateesh
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: 24 September 2013 21:00
>> To: dev@cloudstack.apache.org
>> Subject: [ANNOUNCE] New committer: Rajesh Battala
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>>Rajesh Battala to become a committer and we are pleased to
>> announce that they have accepted.
>> 
>> Being a committer allows many contributors to contribute more
>>autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>>submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the
>>project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Rajesh!
>> 
>> -chip
>> on behalf of the CloudStack PMC

CloudMonkey Release Process now documented

[Chip Childers]

FWIW - I created this page:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudMonkey+Release+Procedure

To document the process of releasing a new cloudmonkey version.

Re: [ANNOUNCE] New committer: Rajesh Battala

[Alena Prokharchyk]

Rajesh, congratulations!

-Alena.

From: Kelcey Jamison Damage 
mailto:kel...@backbonetechnology.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, September 24, 2013 9:50 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: [ANNOUNCE] New committer: Rajesh Battala

Congratulations!

- Original Message -
From: "Min Chen" mailto:min.c...@citrix.com>>
To: dev@cloudstack.apache.org
Sent: Tuesday, September 24, 2013 9:46:43 AM
Subject: Re: [ANNOUNCE] New committer: Rajesh Battala

Congrats, Rajesh.

-min

On 9/24/13 9:40 AM, "Sateesh Chodapuneedi"
mailto:sateesh.chodapune...@citrix.com>> wrote:

Hearty Congratulations Rajesh:)

Regards,
Sateesh
-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: 24 September 2013 21:00
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] New committer: Rajesh Battala
The Project Management Committee (PMC) for Apache CloudStack has asked
Rajesh Battala to become a committer and we are pleased to
announce that they have accepted.
Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch
submission process. Whether contributions are development-related or
otherwise, it is a recognition of a contributor's participation in the
project and commitment to the project and the Apache Way.
Please join me in congratulating Rajesh!
-chip
on behalf of the CloudStack PMC

Re: [ANNOUNCE] A GCE interface to CloudStack

[Chiradeep Vittal]

Wow. Nice!

On 9/24/13 6:04 AM, "sebgoa"  wrote:

>Hi,
>
>I am quite pumped to announce a Google Compute Engine (GCE) interface to
>CloudStack.
>
>Ian Duffy, Darren Brogan and myself worked on this on github over the
>last month. Our latest branch:
>
>https://github.com/NOPping/cloudstack-gce/tree/refactor
>
>Has been uploaded to pypi:
>
>https://pypi.python.org/pypi/gcloud
>
>A little virtualenv and a pip install gcloud will give you a Flask
>application, with OAuth2 provider and REST routes that map to the
>CloudStack API.
>The routes are compliant with GCE API, which allows you to use the Google
>gcutil cli to talk to your CloudStack cloud.
>
>Of course there are a few caveats that I will not mention, this is
>release 0.0.1, feedback and pr welcome.
>
>Congrats to our two 20 year olds in ireland who are taking names up in
>Dublin !
>
>Have fun,
>
>-Sebastien

Re: A question on vm migrations when hosts are set into a maintenance mode.

[Alex Ough]

Oh, sorry for the confusion. I must have reversed the flags.
As Kelven pointed, it is set as 'TRUE', which makes the process as
sequential.

So my questions are
1. If there is any reason why the method have been defined to return '*TRUE*'
always?
2. Do we expect any side effects and/or malfunctioning if we change it to
returning *'FALSE*'?
3. For a resolution without breaking possible flows, can we add the value
of 'executeInSequence' to the global setting if #2 answers YES?


On Tue, Sep 24, 2013 at 11:19 AM, Marcus Sorensen wrote:

> I thought executeInSequence of 'true' made it go serially, or
> sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
> August of 2010:
>
> 2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends Command {
> 2010-08-11 09:13:29 -0700 20) String vmName;
> 2010-08-11 09:13:29 -0700 21) String destIp;
> 2011-08-10 10:26:04 -0700 22) String hostGuid;
> 2010-08-11 09:13:29 -0700 23) boolean isWindows;
> 2010-08-11 09:13:29 -0700 24)
> 2010-08-11 09:13:29 -0700 25)
> 2010-08-11 09:13:29 -0700 26) protected MigrateCommand() {
> 2010-08-11 09:13:29 -0700 27) }
> 2012-12-03 22:06:41 -0800 28)
> 2010-08-11 09:13:29 -0700 29) public MigrateCommand(String vmName,
> String destIp, boolean isWindows)
> 2010-08-11 09:13:29 -0700 30) this.vmName = vmName;
> 2010-08-11 09:13:29 -0700 31) this.destIp = destIp;
> 2010-08-11 09:13:29 -0700 32) this.isWindows = isWindows;
> 2010-08-11 09:13:29 -0700 33) }
> 2012-12-03 22:06:41 -0800 34)
> 2010-08-11 09:13:29 -0700 35) public boolean isWindows() {
> 2010-08-11 09:13:29 -0700 36) return isWindows;
> 2010-08-11 09:13:29 -0700 37) }
> 2012-12-03 22:06:41 -0800 38)
> 2010-08-11 09:13:29 -0700 39) public String getDestinationIp() {
> 2010-08-11 09:13:29 -0700 40) return destIp;
> 2010-08-11 09:13:29 -0700 41) }
> 2012-12-03 22:06:41 -0800 42)
> 2010-08-11 09:13:29 -0700 43) public String getVmName() {
> 2010-08-11 09:13:29 -0700 44) return vmName;
> 2010-08-11 09:13:29 -0700 45) }
> 2012-12-03 22:06:41 -0800 46)
> 2011-08-10 10:26:04 -0700 47) public void setHostGuid(String guid)
> {
> 2011-08-10 10:26:04 -0700 48) this.hostGuid = guid;
> 2011-08-10 10:26:04 -0700 49) }
> 2012-12-03 22:06:41 -0800 50)
> 2011-08-10 10:26:04 -0700 51) public String getHostGuid() {
> 2011-08-10 10:26:04 -0700 52) return this.hostGuid;
> 2011-08-10 10:26:04 -0700 53) }
> 2010-08-11 09:13:29 -0700 54)
> 2010-08-11 09:13:29 -0700 55) @Override
> 2010-08-11 09:13:29 -0700 56) public boolean executeInSequence() {
> 2010-08-11 09:13:29 -0700 57) return true;
> 2010-08-11 09:13:29 -0700 58) }
> 2010-08-11 09:13:29 -0700 59) }
>
> On Tue, Sep 24, 2013 at 9:58 AM, Chip Childers
>  wrote:
> > Hey Kelven - This topic was discussed briefly in the past [1].  Are you
> > able to provide any thoughts on Alex's ideas below?
> >
> > -chip
> >
> >
> > [1] http://markmail.org/message/fznrszaswruvlmuy
> >
> >
> >
> > On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
> >> For a resolution without breaking possible flows, I'd like to add the
> value
> >> of 'executeInSequence' to the global setting.
> >> Is there any reason not to do this?
> >>
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough 
> wrote:
> >>
> >> > All,
> >> >
> >> > After a little more investigation, I found that the 'MigrateCommand'
> >> > defined its 'executeInSequence' method to return 'FALSE', which seems
> to
> >> > make the vm migrations as serial even if the migration requests are
> >> > dispatched to ha_worker in parallel.
> >> > You can confirm this in line 56 of
> >> > '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
> >> >
> >> > So my question is if there is any reason why the method have been
> >> > defined to return 'FALSE' always?
> >> > And do we expect any side effects and/or malfunctioning if we change
> it to
> >> > returning 'TRUE'?
> >> >
> >> > Any answers/comments will be very appreciated.
> >> > Thanks
> >> > Alex Ough
> >> >
> >> >
> >> > On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough 
> wrote:
> >> >
> >> >> I checked the vm migration when their host is set to a maintenance
> mode
> >> >> and found that even if the orchestration layer fires the each vm
> migration
> >> >> at the same time using a ha_worker thread, the actual migration
> seems to be
> >> >> executed serially.
> >> >>
> >> >> Is this what we expect? And if so, any chance to make the actual
> >> >> migrations in parallel?
> >> >>
> >> >> Thanks
> >> >> Alex Ough
> >> >>
> >> >
> >> >
>
>

RE: [ANNOUNCE] New committer: Rajesh Battala

[Saksham Srivastava]

Congrats Rajesh.

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, September 24, 2013 9:00 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] New committer: Rajesh Battala

The Project Management Committee (PMC) for Apache CloudStack has asked Rajesh 
Battala to become a committer and we are pleased to announce that they have 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Rajesh!

-chip
on behalf of the CloudStack PMC

RE: [ANNOUNCE] A GCE interface to CloudStack

[Musayev, Ilya]

This looks awesome :)

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Tuesday, September 24, 2013 12:59 PM
> To: dev@cloudstack.apache.org
> Cc: Ian Duffy; Darren Brogan
> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
> 
> Wow. Nice!
> 
> On 9/24/13 6:04 AM, "sebgoa"  wrote:
> 
> >Hi,
> >
> >I am quite pumped to announce a Google Compute Engine (GCE) interface
> >to CloudStack.
> >
> >Ian Duffy, Darren Brogan and myself worked on this on github over the
> >last month. Our latest branch:
> >
> >https://github.com/NOPping/cloudstack-gce/tree/refactor
> >
> >Has been uploaded to pypi:
> >
> >https://pypi.python.org/pypi/gcloud
> >
> >A little virtualenv and a pip install gcloud will give you a Flask
> >application, with OAuth2 provider and REST routes that map to the
> >CloudStack API.
> >The routes are compliant with GCE API, which allows you to use the
> >Google gcutil cli to talk to your CloudStack cloud.
> >
> >Of course there are a few caveats that I will not mention, this is
> >release 0.0.1, feedback and pr welcome.
> >
> >Congrats to our two 20 year olds in ireland who are taking names up in
> >Dublin !
> >
> >Have fun,
> >
> >-Sebastien
> 

RE: [ANNOUNCE] A GCE interface to CloudStack

[Frank Zhang]

Take a look at source. Clean and lightweight implementation. Awesome.
I hope our AWS someday can go this way someday, a separate web server in 
separate repo and using some dynamically language which makes smaller code


> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Tuesday, September 24, 2013 11:23 AM
> To: dev@cloudstack.apache.org
> Cc: Ian Duffy; Darren Brogan
> Subject: RE: [ANNOUNCE] A GCE interface to CloudStack
> 
> This looks awesome :)
> 
> > -Original Message-
> > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > Sent: Tuesday, September 24, 2013 12:59 PM
> > To: dev@cloudstack.apache.org
> > Cc: Ian Duffy; Darren Brogan
> > Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
> >
> > Wow. Nice!
> >
> > On 9/24/13 6:04 AM, "sebgoa"  wrote:
> >
> > >Hi,
> > >
> > >I am quite pumped to announce a Google Compute Engine (GCE) interface
> > >to CloudStack.
> > >
> > >Ian Duffy, Darren Brogan and myself worked on this on github over the
> > >last month. Our latest branch:
> > >
> > >https://github.com/NOPping/cloudstack-gce/tree/refactor
> > >
> > >Has been uploaded to pypi:
> > >
> > >https://pypi.python.org/pypi/gcloud
> > >
> > >A little virtualenv and a pip install gcloud will give you a Flask
> > >application, with OAuth2 provider and REST routes that map to the
> > >CloudStack API.
> > >The routes are compliant with GCE API, which allows you to use the
> > >Google gcutil cli to talk to your CloudStack cloud.
> > >
> > >Of course there are a few caveats that I will not mention, this is
> > >release 0.0.1, feedback and pr welcome.
> > >
> > >Congrats to our two 20 year olds in ireland who are taking names up
> > >in Dublin !
> > >
> > >Have fun,
> > >
> > >-Sebastien
> >
> 

Re: VmWare SDK to vijava

[Kelven Yang]

We have commercial releases on top of existing code base and there are
lots of testing efforts behind it, dramatic switch means $ cost, the major
concern for me is not about how beautiful vijava is or how bad a direct
wsdl approach would be. it is about to get things move smoothly.

It looks like that we should have VMware layer on its own to have a plugin
structure so that we can replace underlying binding easier, it should
solve the balance between developer's motivation and carrying on the
legacy with minimal impacts to the rest of others.


Kelven

On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:

>Heya,
>
>This biggest advantage i see in using vijava is that a lot of the
>functionality that we now have in the vmware-base project is already
>supplied with vijava.
>
>There is a lot of code that facilitates calling tasks and other stuff in
>our MO classes. These classes are available in vijava and could be used
>instead of our classes. Basically when using vijava correctly you hardly
>have to work with the ManagedObjectReferences anymore. For me this would
>be a big benefit as it makes programming against vmware a lot easier. We
>also have a lot of duplicate code currently in the vmware class and i
>wouldn't mind getting rid of it, which i think is easier with the vijava
>libraries.
>
>That said, the main driver is getting it into the main build so any other
>efforts towards that goal are ok with me.
>
>I would propose that somebody else puts up a branch with our own wdsl
>wrapper and we open a discussion thread when both branches are ready to
>see which we want to merge in master. Anybody who wants to pick that up?
>
>I'm stubbornly going to continue with converting to vijava, I put some
>effort into it and i want at least to see it running once ;-)  And the
>more i work with it the more i'm seeing to benefits of the library so i
>might be able to be more convincing in the end :-)
>
>Cheers,
>
>Hugo
>
>
>On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
>
>> Prior to 5.1, VMware provides java binding in its SDK and this is where
>> CloudStack VMware integration began with. Starting from 5.1, VMware no
>> longer provides the java binding in binary form and recommends its
>> customers to generate directly from its WS WSDL.
>> 
>> Since we are not sure if we can distribute VMware wsdl legally or not,
>> therefore, we ended up to generate and distribute the java binding in
>> binary form. If we can get this cleared in lebal, as Darren pointed, we
>> can solve our non-dist issue easily in matter of adding couple of lines
>>in
>> maven.
>> 
>> As of vijava, yes, I think it may add some value from developer's point
>>of
>> view, but on the other hand, I don't see immediate benefits to having
>> another layer on top of VMware official WS API, vijava is an open source
>> project for providing convenient java binding to vmware WS API, maybe
>>I'm
>> wrong, but I think VMware vSphere WS API is the only official published
>> API from VMware, and the testing result of the API is endorsed by VMware
>> as an commercial entity. So I see more business value to stick with the
>> official WS API directly. If we can clear the legal concern of
>> redistributing VMware wsdl. I would +1 to add a build step of generating
>> VMware java binding from wsdl.
>> 
>> Kelven
>> 
>> 
>> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
>> 
>>> We have been having this discussion on moving vmware out of noredist
>>> since i joined the project. So no real need to rush this suddenly.
>>>Still
>>> it would be nice to get this in for the next release. The feature
>>>freeze
>>> of 4.3 is october 31st for the 4.3 release. This change (or any sdk
>>> change to vmware) should be considered an architecture change so it
>>> should come in at the start of the new release cycle.
>>> 
>>> So this is currently my main activity on CloudStack meaning i can work
>>> pretty much dedicated on this. With a bit of luck i can have the
>>>changes
>>> finished this week. Then it's up to the test results if we can make it
>>> into the 4.3 release or the 4.4 release. Of course all pending a
>>> successful merge vote.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> On Sep 23, 2013, at 3:10 PM, Darren Shepherd
>>>  wrote:
>>> 
 It's seems there could be some good merit to adopting vijava.  I hate
 to belabor this point, but we could get vmware plugin out of noredist
 real fast if we just generate bindings (I think)
 
 Do you know if legally we can add the vmware wsdl to git?  We wouldn't
 redistribute it in the binary builds.  If we could add the wsdl to
git,
 I could add a couple lines to the Pom and it will generate the
bindings
 as part of the build.  Then vmware will be fully redistributable and
 there is no change to existing code.  At runtime everything should be
 the same too.  We could make that change real fast and then
additionally
 continue to look at vijava.
 
 Personal I want to get rid of noredist.  If 

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Mike Tutkowski]

I was a bit hesitant to keep pushing this because there doesn't seem to be
a lot of support for it, but - as Marcus pointed out - I was quite alarmed
by the number and criticality of bugs checked in right before we cut our
first RC for 4.2. We simply were not ready.

To me, it felt like something one might do before one gets out a decent
beta release.

I certainly don't claim to have all the answers for this, but I do think we
need to develop some kind of a process whereby very few changes are made
immediately prior (like a month) to the first cut of a RC. We might even
need to discuss such changes as a community before they get checked in
(after a certain point).

As far as master not always being usable, this is a serious problem, as
well.

For example, I've been having trouble getting KVM to work and - in the
meanwhile - my code has fallen out of date with master over the past week
or so. However, I'm always afraid if I update from master while in the
middle of solving one problem that I'll have more problems to deal with
before I can get back to the initial problem (because something didn't work
in master).

Again, I don't claim to have any solution for this problem, but I am happy
to help brainstorm.


On Tue, Sep 24, 2013 at 10:00 AM, Marcus Sorensen wrote:

> On Mon, Sep 23, 2013 at 1:55 PM, Animesh Chaturvedi
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >> Sent: Monday, September 23, 2013 12:25 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [PROPOSAL] move away from time-based releases and/or revamp
> >> release process
> >>
> >> On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi"
> >> 
> >> wrote:
> >> >
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >> > > Sent: Monday, September 23, 2013 11:38 AM
> >> > > To: dev@cloudstack.apache.org
> >> > > Subject: [PROPOSAL] move away from time-based releases and/or revamp
> >> > > release process
> >> > >
> >> > > Guys,  I think we are not currently in a state to handle time-based
> >> > > releases.  Until we can cut master at any time and have it
> >> > > releasable, or at least at a reasonable RC-level matching minimum
> >> > > tested requirements, it's just going to continue to be an exercise
> >> > > in frustration to cut RCs simply because we hit a deadline.
> >> > [Animesh>] David is going to propose Release Criterion up for
> >> > discussion
> >> as per his thread [1]
> >>
> >> I see that thread more about defining what minimum bar we should always
> >> have master at in order to meet time-based releases. Its where we want
> >> to go, but not what to do in the meantime.
> > [Animesh>] His proposal is not just for master, but also for deciding
> the release exit criterion and IMO is something we should follow for 4.3.0
> and onwards
>
> Yes, I know. What I meant was that it will be a step toward
> stabilizing master, until we do that I'm not convinced we can adhere
> to any time-based expectation). It still doesn't fix our issue if
> we're going to insist on time-based releases, it just (from my
> undertanding) sets a bar for what is acceptable and what isn't, for
> any release. It stops the argument of "should we release with this
> bug".
>
> >>
> >> > >
> >> > > Maybe we can get away with sticking to time-based if we revamp our
> >> > > schedule and procedures, I don't know, but in light of how 4.1
> >> > > (dragged on so long that some were seriously considering
> >> > > skipping/not releasing it with 4.2 on its heels) and 4.2 (six rounds
> >> > > of votes so
> >> > > far) have worked it's probably worth discussing.
> >> > >
> >> > > Any suggestions on what might be better? It's been mentioned in the
> >> > > past that it's a chicken-egg thing, many really don't try it until
> >> > > we hit an RC, which causes multiple iterations. I do agree that many
> >> > > don't take it seriously until we start cutting artifacts, but maybe
> >> > > we do this in a more deliberate fashion instead of jumping right to
> >> > > the vote. After feature/code freeze, cut some alpha artifacts, wait
> >> > > a week, cut alpha2 or some beta artifacts, etc, and then at some
> >> > > point anyone can propose that certain artifacts (or a new set of
> >> > > artifacts) be put up for a vote as an RC. This gives us a way to
> >> > > signal that we're gearing up for release and gives plenty of time
> >> > > for people to test their components, or see the [PROPOSAL] and say
> >> > > 'oh crap, I had better test my stuff', prior to cutting an RC.
> >> > > Maybe this wouldn't help in practice, but I think right now we go
> >> > > from telling the community "code is frozen, don't check anything in
> >> > > unless its a bug fix" to "here's our RC, try it out", without a
> >> formal testing window.
> >> > > I realize the whole thing should be a testing window, but I don't
> >> > > think it's conveyed well.
> >> >
> >> > [Animesh>] After the code freeze is

RE: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Tuesday, September 24, 2013 9:32 AM
> To: dev@cloudstack.apache.org
> Cc: Animesh Chaturvedi
> Subject: Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth
> round)
> 
> >
> > 1 - Finish the docs (release notes especially) and publish them to
> > cloudstack.apache.org/docs
> >
> >   *We need someone to own this*
> 
> I can do this, but it may be tomorrow before it gets done.
[Animesh>] I updated the RN yesterday. David what needs to be done to publish 
to cloudstack.apache.org/docs
> 
> >
> > 2 - Build the DEB packages
> >
> >   Wido has this one
> >
> > 3 - Build the RPM packages
> >
> >   *We need someone to own this one*
> 
> I'll take care of RPMs.
> 
> >
> > 4 - Move the source artifacts from dist/dev to dist/release and stage
> > the download page changes
> >
> >   A PMC member needs to do this.  I'll take this one.
> >
> > 5 - Finish the release announcement
> >
> >   This was started by Mathias here:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Release+Ann
> > ouncement
> >
> >   It should really be finished.
> >
> >   *Someone needs to own finalizing this.*
> >
> > 6 - Publish the website and announce the release (using the finished
> > announcement) after 1 through 5 are done.
> >
> >   This can be any committer, but Animesh you'd probably want the
> honors!
[Animesh>] Chip for 6 can you clarify on what needs to be done to publish the 
website?
> >
> >
> > There are also other marketing related things to get done, but that
> > thread started on marketing@ and can happen after / in parallel to the
> > work listed above.
> >
> > -chip

RE: [Merge] Minimal Hyper-V Plugin

[Donal Lafferty]

On paternity leave, so I don't get to these emails right away...

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: 20 September 2013 06:40
> To: dev@cloudstack.apache.org
> Subject: Re: [Merge] Minimal Hyper-V Plugin
> 
> Thanks for the preliminary testing.
> Questions:
> 1. More for the community: should the C# code be in a separate repo?
> According to the merge request, mono and maven can be used to build the
> agent.

Silence == acceptance?

> 2. Packaging: how is the C# agent installed?

The agent is implemented to as a self-contained Windows Service, which is the 
Microsoft Windows equivalent of a Linux daemon.

To make the agent distributable, package the agent and an app.config consistent 
with your data center in an MSI.  WiX is the preferred tool 
(http://en.wikipedia.org/wiki/WiX ).  When executed, the MSI will add the agent 
to set of Windows Services.

To distribute and run this MSI, use Active Directory's GPO (global policy 
object) service.  In typical deployments machines running Hyper-V will be 
domain joined.  Where machines are not domain joined, look at something like 
puppet. 

> 3. What does minimal mean? What works? What doesn't? Local storage?
> Shared storage? Networking modes? Are the hypervisors supposed to be
> clustered?

Minimal = create / start / stop / destroy a local storage VM in a QuickCloud 
network offering and CIFS secondary storage.

No clustering required.

> 4. How does one extend the "minimal" plugin?

Each CloudStack command has a corresponding an HTTP URI served by the agent.  
These are written in ASP.NET MVC4.  Data received by the agent is kept in a 
JSON object graph.  

E.g.

// POST api/HypervResource/ReadyCommand
[HttpPost]
[ActionName(CloudStackTypes.ReadyCommand)]
public JContainer ReadyCommand([FromBody]dynamic cmd)
{
using (log4net.NDC.Push(Guid.NewGuid().ToString()))
{
logger.Info(CloudStackTypes.ReadyCommand + cmd.ToString());
object ansContent = new
{
result = true,
details = (string)null
};
return ReturnCloudStackTypedJArray(ansContent, 
CloudStackTypes.ReadyAnswer);
}

}

Therefore, to extend the plugin, add new HTTP URIs corresponding to missing 
commands, or extend the capabilities of existing commands.

I can follow up with an explanation in a blog entry.

> 5. Can the unit tests (at least those that test the agent API) be run in a 
> non-
> hyper-v environment?

Unit tests start the agent in a local process.  Provided Mono is installed on 
your system, the unit tests will run.  However, they will complain of bad 
output.

> 6. Is the RDP console you had earlier mentioned included in the merge?

Yes, but it serves no purpose at the moment.  

If there is an IP clearance protocol to follow for this console, I would prefer 
to remove the console from the submission.

> 7. Any known issues?
> 

There seems to be a bug with local paths that include spaces.  I've asked 
Rajesh to provide a bug report, but it's unclear where to put this.  Can we use 
JIRA for code not merged, or should the bug appear in the comments.

 
> On 9/11/13 8:00 AM, "Donal Lafferty"  wrote:
> 
> >Hi Rajesh,
> >
> >Thanks for spotting this problem with the Hyper-V Agent.  Sounds like
> >it should first URL decode the field.
> >
> >Can you update the review with details of your testing?
> >
> >I would need to know the command and which incoming field is causing
> >problems.  Also, can you add a serialised example of the instruction
> >that fails?  There should be an example in the agent's log file.  By
> >default, the log file is in the same folder as the agent executable.  I
> >will use this to update the automated tests.
> >
> >If you want to go ahead and made the fixes from a git clone, send a
> >Pull Request.  As long as there is an appropriate automated test, I'll
> >update the feature branch with your changes.
> >
> >
> >DL
> >
> >> -Original Message-
> >> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> >> Sent: 11 September 2013 09:08
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [Merge] Minimal Hyper-V Plugin
> >>
> >> Hi Donal,
> >> I had figured out the issue why "+" is coming in the path value.
> >> The root cause is while encoding the URI, we use
> >> URLEncoder.encode(path)
> >>
> >> The encode method is converting/replace "space" with "+".
> >>
> >> API doc:
> >> When encoding a String, the following rules apply:
> >>
> >> The alphanumeric characters "a" through "z", "A" through "Z" and "0"
> >> through "9" remain the same.
> >> The special characters ".", "-", "*", and "_" remain the same.
> >> The space character " " is converted into a plus sign "+".
> >> All other characters are unsafe and are first converted into one or
> >>more  bytes using some encoding scheme. Then each byte is rep

Re: Review Request 14290: KVMFencer cleanup

[Laszlo Hornyak]

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

(Updated Sept. 24, 2013, 7:51 p.m.)


Review request for cloudstack, FrankXH FrankXH and Kelven Yang.


Repository: cloudstack-git


Description
---

- start and stop removed, they do the same as the original method
- host filtering logic moved to a the condition of the if statement
- single default constructor removed


Diffs
-

  server/src/com/cloud/ha/KVMFencer.java 517209e 

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


Testing
---

see https://reviews.apache.org/r/14289/


Thanks,

Laszlo Hornyak

Re: Review Request 14289: unit test for KVMFencer

[Laszlo Hornyak]

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

(Updated Sept. 24, 2013, 7:52 p.m.)


Review request for cloudstack, FrankXH FrankXH and Kelven Yang.


Repository: cloudstack-git


Description
---

A few cases covered with unit tests.


Diffs
-

  server/test/com/cloud/ha/KVMFencerTest.java PRE-CREATION 

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


Testing
---

yes


Thanks,

Laszlo Hornyak

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chip Childers]

On Tue, Sep 24, 2013 at 07:12:15PM +, Animesh Chaturvedi wrote:
> > > 6 - Publish the website and announce the release (using the finished
> > > announcement) after 1 through 5 are done.
> > >
> > >   This can be any committer, but Animesh you'd probably want the
> > honors!
> [Animesh>] Chip for 6 can you clarify on what needs to be done to publish the 
> website?

Yep - you need to log into this:

https://cms.apache.org/cloudstack/

The download page has already been altered in the source, and staged.

We just need to click "Publish cloudstack site".

-chip

RE: VmWare SDK to vijava

[Frank Zhang]

Agree. Given current CloudStack code base changing something to another thing 
is really not a good way.
As Darren is working on modular spring, why not construct a new VMWare plugin 
separately using vijava?
Then we can reduce the risk of surprising existing customer and switch to new 
module when it finally gets mature.


> -Original Message-
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: Tuesday, September 24, 2013 11:59 AM
> To: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> We have commercial releases on top of existing code base and there are lots of
> testing efforts behind it, dramatic switch means $ cost, the major concern for
> me is not about how beautiful vijava is or how bad a direct wsdl approach
> would be. it is about to get things move smoothly.
> 
> It looks like that we should have VMware layer on its own to have a plugin
> structure so that we can replace underlying binding easier, it should solve 
> the
> balance between developer's motivation and carrying on the legacy with
> minimal impacts to the rest of others.
> 
> 
> Kelven
> 
> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> 
> >Heya,
> >
> >This biggest advantage i see in using vijava is that a lot of the
> >functionality that we now have in the vmware-base project is already
> >supplied with vijava.
> >
> >There is a lot of code that facilitates calling tasks and other stuff
> >in our MO classes. These classes are available in vijava and could be
> >used instead of our classes. Basically when using vijava correctly you
> >hardly have to work with the ManagedObjectReferences anymore. For me
> >this would be a big benefit as it makes programming against vmware a
> >lot easier. We also have a lot of duplicate code currently in the
> >vmware class and i wouldn't mind getting rid of it, which i think is
> >easier with the vijava libraries.
> >
> >That said, the main driver is getting it into the main build so any
> >other efforts towards that goal are ok with me.
> >
> >I would propose that somebody else puts up a branch with our own wdsl
> >wrapper and we open a discussion thread when both branches are ready to
> >see which we want to merge in master. Anybody who wants to pick that up?
> >
> >I'm stubbornly going to continue with converting to vijava, I put some
> >effort into it and i want at least to see it running once ;-)  And the
> >more i work with it the more i'm seeing to benefits of the library so i
> >might be able to be more convincing in the end :-)
> >
> >Cheers,
> >
> >Hugo
> >
> >
> >On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
> >
> >> Prior to 5.1, VMware provides java binding in its SDK and this is
> >> where CloudStack VMware integration began with. Starting from 5.1,
> >> VMware no longer provides the java binding in binary form and
> >> recommends its customers to generate directly from its WS WSDL.
> >>
> >> Since we are not sure if we can distribute VMware wsdl legally or
> >>not,  therefore, we ended up to generate and distribute the java
> >>binding in  binary form. If we can get this cleared in lebal, as
> >>Darren pointed, we  can solve our non-dist issue easily in matter of
> >>adding couple of lines in  maven.
> >>
> >> As of vijava, yes, I think it may add some value from developer's
> >>point of  view, but on the other hand, I don't see immediate benefits
> >>to having  another layer on top of VMware official WS API, vijava is
> >>an open source  project for providing convenient java binding to
> >>vmware WS API, maybe I'm  wrong, but I think VMware vSphere WS API is
> >>the only official published  API from VMware, and the testing result
> >>of the API is endorsed by VMware  as an commercial entity. So I see
> >>more business value to stick with the  official WS API directly. If we
> >>can clear the legal concern of  redistributing VMware wsdl. I would +1
> >>to add a build step of generating  VMware java binding from wsdl.
> >>
> >> Kelven
> >>
> >>
> >> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
> >>
> >>> We have been having this discussion on moving vmware out of noredist
> >>>since i joined the project. So no real need to rush this suddenly.
> >>>Still
> >>> it would be nice to get this in for the next release. The feature
> >>>freeze  of 4.3 is october 31st for the 4.3 release. This change (or
> >>>any sdk  change to vmware) should be considered an architecture
> >>>change so it  should come in at the start of the new release cycle.
> >>>
> >>> So this is currently my main activity on CloudStack meaning i can
> >>>work  pretty much dedicated on this. With a bit of luck i can have
> >>>the changes  finished this week. Then it's up to the test results if
> >>>we can make it  into the 4.3 release or the 4.4 release. Of course
> >>>all pending a  successful merge vote.
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
> >>> On Sep 23, 2013, at 3:10 PM, Darren Shepherd
> >>>  wrote:
> >>>
>  It's seems there could be some good merit to adopting vijava.  I

looks like listConfigurations by zoneid is broken in 4.2

[Darren Shepherd]

Alex,

If you do a listConfigurations passing a zoneId you get the following NPE

rver] (ApiServer-7:ctx-c8cdd77a ctx-bdeb07fe) unhandled exception 
executing api command: listConfigurations

java.lang.NullPointerException
	at 
com.cloud.server.ConfigurationServerImpl.getConfigListByScope(ConfigurationServerImpl.java:693)
	at 
com.cloud.server.ManagementServerImpl.searchForConfigurations(ManagementServerImpl.java:1662)


I tracked it down to commit 435e74e9.  If the value of the configuration 
is null you hit this situation.  Its a simple null check needed, but I 
though since that was a larger commit maybe you'd realize something else.


Darren

Re: looks like listConfigurations by zoneid is broken in 4.3

[Darren Shepherd]

Sorry, I meant to say 4.3.  I don't think this change is in 4.2.  Alex 
can confirm.


Darren

Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Marcus Sorensen]

Someone please check this, as I'm not familiar with the doc layout,
especially trying to decipher it in xml.

commit to 4.2 branch: da56b6212bbcf9e363ba1add180516584a3d695b

On Mon, Sep 23, 2013 at 4:35 PM, Marcus Sorensen  wrote:
> I think I'll wait until the vote passes, just to be sure that it won't
> need to be backed out.
>
> On Mon, Sep 23, 2013 at 3:47 PM, Animesh Chaturvedi
>  wrote:
>>
>>
>>> -Original Message-
>>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>>> Sent: Monday, September 23, 2013 2:44 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
>>>
>>> I can change my vote to +1 if we include instructions similar to the
>>> following in the upgrade notes:
>>>
>>> If using local storage on KVM, the local storage path needs to be
>>> changed in order to pass new validation. Remove any trailing slashes in
>>> the path column of the storage_pool table before starting agents.
>>> e.g.:
>>>
>>> mysql -e 'update cloud.storage_pool set path="/var/lib/libvirt/images"
>>> where path="/var/lib/libvirt/images/"';
>>>
>>> If using a custom path, insert your path in place of
>>> "/var/lib/libvirt/images/". If your custom path did not contain a
>>> trailing "/", there's no need to do this procedure.
>>
>>
>> [Animesh>] Marcus do you want to go ahead and update the Release Notes in 
>> 4.2 branch  in file docs/en-US/Release_Notes.xml. I just finished making few 
>> other changes that were discussed.
>>
>>>
>>> On Mon, Sep 23, 2013 at 3:00 PM, Chiradeep Vittal
>>>  wrote:
>>> > +1 (binding)
>>> >
>>> > On 9/20/13 8:36 PM, "Animesh Chaturvedi"
>>> > 
>>> > wrote:
>>> >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>I've created a 4.2.0 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.2
>>> >>Commit: 69c459342c568e2400d57ee88572b301603d8686
>>> >>
>>> >>List of changes:
>>> >>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;
>>> >>f=CH
>>> >>ANGES;hb=4.2
>>> >>
>>> >>Source release (checksums and signatures are available at the same
>>> >>location):
>>> >>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
>>> >>
>>> >>PGP release keys (signed using 94BE0D7C):
>>> >>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>> >>
>>> >>Testing instructions are here:
>>> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
>>> >>oced
>>> >>ure
>>> >>
>>> >>Vote will be open for 72 hours (Monday 9/23 PST EOD).
>>> >>
>>> >>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)
>>> >>
>>> >>
>>> >

Re: New features

[Alena Prokharchyk]

I've closed the 
CLOUDSTACK-3128. There 
is no need to add more fixes in addition to what was done originally. Nicolas, 
please see my latest comments.

-Alena.

From: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Date: Tuesday, September 24, 2013 9:44 AM
To: Sebastien Goasguen mailto:run...@gmail.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: New features

I did reopen the https://issues.apache.org/jira/browse/CLOUDSTACK-3128. Will 
get fixed for the next release, thanks Nicolas and Sebastien for following up.

-Alena.

From: Sebastien Goasguen mailto:run...@gmail.com>>
Date: Tuesday, September 24, 2013 12:13 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Subject: Re: New features


On Sep 23, 2013, at 4:50 AM, 
nfoata@orange.com wrote:

Hello Cloudstack,
Sometimes ago, I wrote and submitted two new features with the following 
identifiers (see below) :
1) JIRA
https://issues.apache.org/jira/browse/CLOUDSTACK-3701 (VM instantiation: 
Sending network information in an extra field)
https://issues.apache.org/jira/browse/CLOUDSTACK-3702 (VM instantiation: 
Specific information for hypervisors)

2) Review board

Both Jira issues were also registered under review boards with a git diff and 
submitted in august.
However, I never received any comment on them.
( I would like to put the direct links, in that mail but review board is not 
accessible this morning).
Furthermore, I noticed and saw that there is a lot of demands under the review 
boards which are not yet processed.
Does it mean, that there is so many requests that is take a long time ?

Hi Nicolas, and thanks for the ping.
Unfortunately it just means that we are behind.

Do cloudstack reviewers need more people or help ?

Yes, this is community driven, so any help you can give is very much welcome. 
You can help review patches, file bugs, and submit more patches.

Or simply that I did not well up (follow) the submission process somewhere ? 
(Jira -> review board -> submit ).
At last, I asked if is it possible to open again a bug (CLOUDSTACK-3128) 
because it was not totally fixed and
I sent the solution in the comment of this one. (I can also do a git diff if I 
have to submit it.) but no answer too.
https://issues.apache.org/jira/browse/CLOUDSTACK-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

You should be able to re-open this bug. I am copying Alena to make sure she 
notices it and sees your comment in the bug.


Thanks in advance for yours answers and please feel free to contact me if need 
be,
Have a good day,
Best regards,


Nicolas Foata
Ingénieur
DMGP/Portail/DOP/EnP/Advise
Norsys pour Orange
Sophia Antipolis
nfoata@orange.com

_
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.
This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Review Request 14324: basic test for ApiDispatcher

[Laszlo Hornyak]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

basic test for ApiDispatcher


Diffs
-

  api/src/org/apache/cloudstack/context/CallContext.java a62a3da 
  server/test/com/cloud/api/ApiDispatcherTest.java PRE-CREATION 

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


Testing
---


Thanks,

Laszlo Hornyak

RE: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Tuesday, September 24, 2013 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> 
> Someone please check this, as I'm not familiar with the doc layout,
> especially trying to decipher it in xml.
> 
> commit to 4.2 branch: da56b6212bbcf9e363ba1add180516584a3d695b
> 
[Animesh>] I kicked off a new Release Note build on Jenkins, looking at the 
diff it should be fine

> On Mon, Sep 23, 2013 at 4:35 PM, Marcus Sorensen 
> wrote:
> > I think I'll wait until the vote passes, just to be sure that it won't
> > need to be backed out.
> >

Re: VmWare SDK to vijava

[Kelven Yang]

It is about the interface layer between CloudStack and VMware, Spring can
only help to what it can, ultimately, we need to refactor the interface
layer to take in vijava as one of its implementations.

We also need to consider of another situation, with the latest vSphere 5.1
API, although VMware claims to support all previous vSphere versions with
it, we actually found that this is not true. We may have to face the fact
that we will need to support two versions of vSphere APIs at run time
side-by-side. I'm leaning towards for us to to have some control in
generating the API stub for this(the direct WSDL way), if it is to vijava,
it depends on whether or not it has built-in side-by-side VMware API
support. and we will have more things to worry and test about it.

Kelven  
 

On 9/24/13 1:10 PM, "Frank Zhang"  wrote:

>Agree. Given current CloudStack code base changing something to another
>thing is really not a good way.
>As Darren is working on modular spring, why not construct a new VMWare
>plugin separately using vijava?
>Then we can reduce the risk of surprising existing customer and switch to
>new module when it finally gets mature.
>
>
>> -Original Message-
>> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> Sent: Tuesday, September 24, 2013 11:59 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: VmWare SDK to vijava
>> 
>> We have commercial releases on top of existing code base and there are
>>lots of
>> testing efforts behind it, dramatic switch means $ cost, the major
>>concern for
>> me is not about how beautiful vijava is or how bad a direct wsdl
>>approach
>> would be. it is about to get things move smoothly.
>> 
>> It looks like that we should have VMware layer on its own to have a
>>plugin
>> structure so that we can replace underlying binding easier, it should
>>solve the
>> balance between developer's motivation and carrying on the legacy with
>> minimal impacts to the rest of others.
>> 
>> 
>> Kelven
>> 
>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>> 
>> >Heya,
>> >
>> >This biggest advantage i see in using vijava is that a lot of the
>> >functionality that we now have in the vmware-base project is already
>> >supplied with vijava.
>> >
>> >There is a lot of code that facilitates calling tasks and other stuff
>> >in our MO classes. These classes are available in vijava and could be
>> >used instead of our classes. Basically when using vijava correctly you
>> >hardly have to work with the ManagedObjectReferences anymore. For me
>> >this would be a big benefit as it makes programming against vmware a
>> >lot easier. We also have a lot of duplicate code currently in the
>> >vmware class and i wouldn't mind getting rid of it, which i think is
>> >easier with the vijava libraries.
>> >
>> >That said, the main driver is getting it into the main build so any
>> >other efforts towards that goal are ok with me.
>> >
>> >I would propose that somebody else puts up a branch with our own wdsl
>> >wrapper and we open a discussion thread when both branches are ready to
>> >see which we want to merge in master. Anybody who wants to pick that
>>up?
>> >
>> >I'm stubbornly going to continue with converting to vijava, I put some
>> >effort into it and i want at least to see it running once ;-)  And the
>> >more i work with it the more i'm seeing to benefits of the library so i
>> >might be able to be more convincing in the end :-)
>> >
>> >Cheers,
>> >
>> >Hugo
>> >
>> >
>> >On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>>wrote:
>> >
>> >> Prior to 5.1, VMware provides java binding in its SDK and this is
>> >> where CloudStack VMware integration began with. Starting from 5.1,
>> >> VMware no longer provides the java binding in binary form and
>> >> recommends its customers to generate directly from its WS WSDL.
>> >>
>> >> Since we are not sure if we can distribute VMware wsdl legally or
>> >>not,  therefore, we ended up to generate and distribute the java
>> >>binding in  binary form. If we can get this cleared in lebal, as
>> >>Darren pointed, we  can solve our non-dist issue easily in matter of
>> >>adding couple of lines in  maven.
>> >>
>> >> As of vijava, yes, I think it may add some value from developer's
>> >>point of  view, but on the other hand, I don't see immediate benefits
>> >>to having  another layer on top of VMware official WS API, vijava is
>> >>an open source  project for providing convenient java binding to
>> >>vmware WS API, maybe I'm  wrong, but I think VMware vSphere WS API is
>> >>the only official published  API from VMware, and the testing result
>> >>of the API is endorsed by VMware  as an commercial entity. So I see
>> >>more business value to stick with the  official WS API directly. If we
>> >>can clear the legal concern of  redistributing VMware wsdl. I would +1
>> >>to add a build step of generating  VMware java binding from wsdl.
>> >>
>> >> Kelven
>> >>
>> >>
>> >> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
>> >>
>> >>> We have been having this discussion

RE: VmWare SDK to vijava

[Frank Zhang]

Emm, I am saying totally creating new VMWare resource/discover/manager/guru
as a plugin where each component for example VMWareResource is a module in 
plugin.
This matches Darren's plugin proposal. and you (Kelven) could continue 
maintaining current
implementation for backward compatibility. And community who is interested in 
vijava could
develop own stuff with little concerns about current customers. 
   

> -Original Message-
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: Tuesday, September 24, 2013 2:06 PM
> To: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> It is about the interface layer between CloudStack and VMware, Spring can only
> help to what it can, ultimately, we need to refactor the interface layer to 
> take
> in vijava as one of its implementations.
> 
> We also need to consider of another situation, with the latest vSphere 5.1 
> API,
> although VMware claims to support all previous vSphere versions with it, we
> actually found that this is not true. We may have to face the fact that we 
> will
> need to support two versions of vSphere APIs at run time side-by-side. I'm
> leaning towards for us to to have some control in generating the API stub for
> this(the direct WSDL way), if it is to vijava, it depends on whether or not 
> it has
> built-in side-by-side VMware API support. and we will have more things to
> worry and test about it.
> 
> Kelven
> 
> 
> On 9/24/13 1:10 PM, "Frank Zhang"  wrote:
> 
> >Agree. Given current CloudStack code base changing something to another
> >thing is really not a good way.
> >As Darren is working on modular spring, why not construct a new VMWare
> >plugin separately using vijava?
> >Then we can reduce the risk of surprising existing customer and switch
> >to new module when it finally gets mature.
> >
> >
> >> -Original Message-
> >> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> >> Sent: Tuesday, September 24, 2013 11:59 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: VmWare SDK to vijava
> >>
> >> We have commercial releases on top of existing code base and there
> >>are lots of  testing efforts behind it, dramatic switch means $ cost,
> >>the major concern for  me is not about how beautiful vijava is or how
> >>bad a direct wsdl approach  would be. it is about to get things move
> >>smoothly.
> >>
> >> It looks like that we should have VMware layer on its own to have a
> >>plugin  structure so that we can replace underlying binding easier, it
> >>should solve the  balance between developer's motivation and carrying
> >>on the legacy with  minimal impacts to the rest of others.
> >>
> >>
> >> Kelven
> >>
> >> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> >>
> >> >Heya,
> >> >
> >> >This biggest advantage i see in using vijava is that a lot of the
> >> >functionality that we now have in the vmware-base project is already
> >> >supplied with vijava.
> >> >
> >> >There is a lot of code that facilitates calling tasks and other
> >> >stuff in our MO classes. These classes are available in vijava and
> >> >could be used instead of our classes. Basically when using vijava
> >> >correctly you hardly have to work with the ManagedObjectReferences
> >> >anymore. For me this would be a big benefit as it makes programming
> >> >against vmware a lot easier. We also have a lot of duplicate code
> >> >currently in the vmware class and i wouldn't mind getting rid of it,
> >> >which i think is easier with the vijava libraries.
> >> >
> >> >That said, the main driver is getting it into the main build so any
> >> >other efforts towards that goal are ok with me.
> >> >
> >> >I would propose that somebody else puts up a branch with our own
> >> >wdsl wrapper and we open a discussion thread when both branches are
> >> >ready to see which we want to merge in master. Anybody who wants to
> >> >pick that
> >>up?
> >> >
> >> >I'm stubbornly going to continue with converting to vijava, I put
> >> >some effort into it and i want at least to see it running once ;-)
> >> >And the more i work with it the more i'm seeing to benefits of the
> >> >library so i might be able to be more convincing in the end :-)
> >> >
> >> >Cheers,
> >> >
> >> >Hugo
> >> >
> >> >
> >> >On Sep 24, 2013, at 2:18 AM, Kelven Yang 
> >>wrote:
> >> >
> >> >> Prior to 5.1, VMware provides java binding in its SDK and this is
> >> >> where CloudStack VMware integration began with. Starting from 5.1,
> >> >> VMware no longer provides the java binding in binary form and
> >> >> recommends its customers to generate directly from its WS WSDL.
> >> >>
> >> >> Since we are not sure if we can distribute VMware wsdl legally or
> >> >>not,  therefore, we ended up to generate and distribute the java
> >> >>binding in  binary form. If we can get this cleared in lebal, as
> >> >>Darren pointed, we  can solve our non-dist issue easily in matter
> >> >>of adding couple of lines in  maven.
> >> >>
> >> >> As of vijava, yes, I think it may add some value from devel

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Daan Hoogland]

Mike, rest assured you and Marcus are not the only ones. More guarantee on
a stable master is a general concern. Personally I don't feel we need more
control on what is in the next release, if we make unit tests and automated
integration tests a priority. That is kind of a claim I do have 'the'
solution, though not well cooked ;) It's going to take a while (a colleague
said four or five releases) before we have a good enough test set and a
smoothly running continuous integration test engine. I think we at least
need the distributed Jenkins setup where you can run your own integration
tests to make sure your invested logic remains intact. This of course being
only part of 'all the' answers.

regards,


On Tue, Sep 24, 2013 at 9:09 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I was a bit hesitant to keep pushing this because there doesn't seem to be
> a lot of support for it, but - as Marcus pointed out - I was quite alarmed
> by the number and criticality of bugs checked in right before we cut our
> first RC for 4.2. We simply were not ready.
>
> To me, it felt like something one might do before one gets out a decent
> beta release.
>
> I certainly don't claim to have all the answers for this, but I do think we
> need to develop some kind of a process whereby very few changes are made
> immediately prior (like a month) to the first cut of a RC. We might even
> need to discuss such changes as a community before they get checked in
> (after a certain point).
>
> As far as master not always being usable, this is a serious problem, as
> well.
>
> For example, I've been having trouble getting KVM to work and - in the
> meanwhile - my code has fallen out of date with master over the past week
> or so. However, I'm always afraid if I update from master while in the
> middle of solving one problem that I'll have more problems to deal with
> before I can get back to the initial problem (because something didn't work
> in master).
>
> Again, I don't claim to have any solution for this problem, but I am happy
> to help brainstorm.
>
>
> On Tue, Sep 24, 2013 at 10:00 AM, Marcus Sorensen  >wrote:
>
> > On Mon, Sep 23, 2013 at 1:55 PM, Animesh Chaturvedi
> >  wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > >> Sent: Monday, September 23, 2013 12:25 PM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: [PROPOSAL] move away from time-based releases and/or
> revamp
> > >> release process
> > >>
> > >> On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi"
> > >> 
> > >> wrote:
> > >> >
> > >> >
> > >> >
> > >> > > -Original Message-
> > >> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > >> > > Sent: Monday, September 23, 2013 11:38 AM
> > >> > > To: dev@cloudstack.apache.org
> > >> > > Subject: [PROPOSAL] move away from time-based releases and/or
> revamp
> > >> > > release process
> > >> > >
> > >> > > Guys,  I think we are not currently in a state to handle
> time-based
> > >> > > releases.  Until we can cut master at any time and have it
> > >> > > releasable, or at least at a reasonable RC-level matching minimum
> > >> > > tested requirements, it's just going to continue to be an exercise
> > >> > > in frustration to cut RCs simply because we hit a deadline.
> > >> > [Animesh>] David is going to propose Release Criterion up for
> > >> > discussion
> > >> as per his thread [1]
> > >>
> > >> I see that thread more about defining what minimum bar we should
> always
> > >> have master at in order to meet time-based releases. Its where we want
> > >> to go, but not what to do in the meantime.
> > > [Animesh>] His proposal is not just for master, but also for deciding
> > the release exit criterion and IMO is something we should follow for
> 4.3.0
> > and onwards
> >
> > Yes, I know. What I meant was that it will be a step toward
> > stabilizing master, until we do that I'm not convinced we can adhere
> > to any time-based expectation). It still doesn't fix our issue if
> > we're going to insist on time-based releases, it just (from my
> > undertanding) sets a bar for what is acceptable and what isn't, for
> > any release. It stops the argument of "should we release with this
> > bug".
> >
> > >>
> > >> > >
> > >> > > Maybe we can get away with sticking to time-based if we revamp our
> > >> > > schedule and procedures, I don't know, but in light of how 4.1
> > >> > > (dragged on so long that some were seriously considering
> > >> > > skipping/not releasing it with 4.2 on its heels) and 4.2 (six
> rounds
> > >> > > of votes so
> > >> > > far) have worked it's probably worth discussing.
> > >> > >
> > >> > > Any suggestions on what might be better? It's been mentioned in
> the
> > >> > > past that it's a chicken-egg thing, many really don't try it until
> > >> > > we hit an RC, which causes multiple iterations. I do agree that
> many
> > >> > > don't take it seriously until we start cutting artifacts, but
> maybe
> > >> > > we do t

Re: [PROPOSAL] move away from time-based releases and/or revamp release process

[Mike Tutkowski]

I think a distributed Jenkins setup would be great.

If we had really awesome test coverage, I would be less frightened of
last-minute checkins, as well. :)


On Tue, Sep 24, 2013 at 3:17 PM, Daan Hoogland wrote:

> Mike, rest assured you and Marcus are not the only ones. More guarantee on
> a stable master is a general concern. Personally I don't feel we need more
> control on what is in the next release, if we make unit tests and automated
> integration tests a priority. That is kind of a claim I do have 'the'
> solution, though not well cooked ;) It's going to take a while (a colleague
> said four or five releases) before we have a good enough test set and a
> smoothly running continuous integration test engine. I think we at least
> need the distributed Jenkins setup where you can run your own integration
> tests to make sure your invested logic remains intact. This of course being
> only part of 'all the' answers.
>
> regards,
>
>
> On Tue, Sep 24, 2013 at 9:09 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I was a bit hesitant to keep pushing this because there doesn't seem to
> be
> > a lot of support for it, but - as Marcus pointed out - I was quite
> alarmed
> > by the number and criticality of bugs checked in right before we cut our
> > first RC for 4.2. We simply were not ready.
> >
> > To me, it felt like something one might do before one gets out a decent
> > beta release.
> >
> > I certainly don't claim to have all the answers for this, but I do think
> we
> > need to develop some kind of a process whereby very few changes are made
> > immediately prior (like a month) to the first cut of a RC. We might even
> > need to discuss such changes as a community before they get checked in
> > (after a certain point).
> >
> > As far as master not always being usable, this is a serious problem, as
> > well.
> >
> > For example, I've been having trouble getting KVM to work and - in the
> > meanwhile - my code has fallen out of date with master over the past week
> > or so. However, I'm always afraid if I update from master while in the
> > middle of solving one problem that I'll have more problems to deal with
> > before I can get back to the initial problem (because something didn't
> work
> > in master).
> >
> > Again, I don't claim to have any solution for this problem, but I am
> happy
> > to help brainstorm.
> >
> >
> > On Tue, Sep 24, 2013 at 10:00 AM, Marcus Sorensen  > >wrote:
> >
> > > On Mon, Sep 23, 2013 at 1:55 PM, Animesh Chaturvedi
> > >  wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > >> Sent: Monday, September 23, 2013 12:25 PM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: RE: [PROPOSAL] move away from time-based releases and/or
> > revamp
> > > >> release process
> > > >>
> > > >> On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi"
> > > >> 
> > > >> wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > > -Original Message-
> > > >> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > >> > > Sent: Monday, September 23, 2013 11:38 AM
> > > >> > > To: dev@cloudstack.apache.org
> > > >> > > Subject: [PROPOSAL] move away from time-based releases and/or
> > revamp
> > > >> > > release process
> > > >> > >
> > > >> > > Guys,  I think we are not currently in a state to handle
> > time-based
> > > >> > > releases.  Until we can cut master at any time and have it
> > > >> > > releasable, or at least at a reasonable RC-level matching
> minimum
> > > >> > > tested requirements, it's just going to continue to be an
> exercise
> > > >> > > in frustration to cut RCs simply because we hit a deadline.
> > > >> > [Animesh>] David is going to propose Release Criterion up for
> > > >> > discussion
> > > >> as per his thread [1]
> > > >>
> > > >> I see that thread more about defining what minimum bar we should
> > always
> > > >> have master at in order to meet time-based releases. Its where we
> want
> > > >> to go, but not what to do in the meantime.
> > > > [Animesh>] His proposal is not just for master, but also for deciding
> > > the release exit criterion and IMO is something we should follow for
> > 4.3.0
> > > and onwards
> > >
> > > Yes, I know. What I meant was that it will be a step toward
> > > stabilizing master, until we do that I'm not convinced we can adhere
> > > to any time-based expectation). It still doesn't fix our issue if
> > > we're going to insist on time-based releases, it just (from my
> > > undertanding) sets a bar for what is acceptable and what isn't, for
> > > any release. It stops the argument of "should we release with this
> > > bug".
> > >
> > > >>
> > > >> > >
> > > >> > > Maybe we can get away with sticking to time-based if we revamp
> our
> > > >> > > schedule and procedures, I don't know, but in light of how 4.1
> > > >> > > (dragged on so long that some were seriously considering
> > > >> > > skipping/not releasing it with 4.2 on its heels) and 4.2 (six
>

Re: VmWare SDK to vijava

[Kelven Yang]

I'm fine with that, but I'd say that modular boundary like this is too
blurring that may end up to too much code divergency. If we can't state
clearly about the boundary, then the cut will drag other pieces along with
it. there are other logic being built between CloudStack and VMware API in
resource level, we only want to cut at the place we really want and be
able to share common work.

Kelven

On 9/24/13 2:16 PM, "Frank Zhang"  wrote:

>Emm, I am saying totally creating new VMWare
>resource/discover/manager/guru
>as a plugin where each component for example VMWareResource is a module
>in plugin.
>This matches Darren's plugin proposal. and you (Kelven) could continue
>maintaining current
>implementation for backward compatibility. And community who is
>interested in vijava could
>develop own stuff with little concerns about current customers.
>   
>
>> -Original Message-
>> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> Sent: Tuesday, September 24, 2013 2:06 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: VmWare SDK to vijava
>> 
>> It is about the interface layer between CloudStack and VMware, Spring
>>can only
>> help to what it can, ultimately, we need to refactor the interface
>>layer to take
>> in vijava as one of its implementations.
>> 
>> We also need to consider of another situation, with the latest vSphere
>>5.1 API,
>> although VMware claims to support all previous vSphere versions with
>>it, we
>> actually found that this is not true. We may have to face the fact that
>>we will
>> need to support two versions of vSphere APIs at run time side-by-side.
>>I'm
>> leaning towards for us to to have some control in generating the API
>>stub for
>> this(the direct WSDL way), if it is to vijava, it depends on whether or
>>not it has
>> built-in side-by-side VMware API support. and we will have more things
>>to
>> worry and test about it.
>> 
>> Kelven
>> 
>> 
>> On 9/24/13 1:10 PM, "Frank Zhang"  wrote:
>> 
>> >Agree. Given current CloudStack code base changing something to another
>> >thing is really not a good way.
>> >As Darren is working on modular spring, why not construct a new VMWare
>> >plugin separately using vijava?
>> >Then we can reduce the risk of surprising existing customer and switch
>> >to new module when it finally gets mature.
>> >
>> >
>> >> -Original Message-
>> >> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> >> Sent: Tuesday, September 24, 2013 11:59 AM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Re: VmWare SDK to vijava
>> >>
>> >> We have commercial releases on top of existing code base and there
>> >>are lots of  testing efforts behind it, dramatic switch means $ cost,
>> >>the major concern for  me is not about how beautiful vijava is or how
>> >>bad a direct wsdl approach  would be. it is about to get things move
>> >>smoothly.
>> >>
>> >> It looks like that we should have VMware layer on its own to have a
>> >>plugin  structure so that we can replace underlying binding easier, it
>> >>should solve the  balance between developer's motivation and carrying
>> >>on the legacy with  minimal impacts to the rest of others.
>> >>
>> >>
>> >> Kelven
>> >>
>> >> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>> >>
>> >> >Heya,
>> >> >
>> >> >This biggest advantage i see in using vijava is that a lot of the
>> >> >functionality that we now have in the vmware-base project is already
>> >> >supplied with vijava.
>> >> >
>> >> >There is a lot of code that facilitates calling tasks and other
>> >> >stuff in our MO classes. These classes are available in vijava and
>> >> >could be used instead of our classes. Basically when using vijava
>> >> >correctly you hardly have to work with the ManagedObjectReferences
>> >> >anymore. For me this would be a big benefit as it makes programming
>> >> >against vmware a lot easier. We also have a lot of duplicate code
>> >> >currently in the vmware class and i wouldn't mind getting rid of it,
>> >> >which i think is easier with the vijava libraries.
>> >> >
>> >> >That said, the main driver is getting it into the main build so any
>> >> >other efforts towards that goal are ok with me.
>> >> >
>> >> >I would propose that somebody else puts up a branch with our own
>> >> >wdsl wrapper and we open a discussion thread when both branches are
>> >> >ready to see which we want to merge in master. Anybody who wants to
>> >> >pick that
>> >>up?
>> >> >
>> >> >I'm stubbornly going to continue with converting to vijava, I put
>> >> >some effort into it and i want at least to see it running once ;-)
>> >> >And the more i work with it the more i'm seeing to benefits of the
>> >> >library so i might be able to be more convincing in the end :-)
>> >> >
>> >> >Cheers,
>> >> >
>> >> >Hugo
>> >> >
>> >> >
>> >> >On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>> >>wrote:
>> >> >
>> >> >> Prior to 5.1, VMware provides java binding in its SDK and this is
>> >> >> where CloudStack VMware integration began with. Starting from 5.1,
>> >> >> VM

Re: Libvirt-java 0.5.0 has been released

[Yoshikazu Nojima]

Hi,
libvirt-java 0.5.1 is released, and I tried to upgrade it to 0.5.1,

diff --git a/pom.xml b/pom.xml
index a8778f1..1c85bc4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -81,7 +81,7 @@
 0.9.8
 0.10
 build/replace.properties
-0.5.0
+0.5.1
 0.1.3
 target
 1.0.10
--
1.8.3.msysgit.0

but I faced another error.

24/09/2013 05:27:12 28923 jsvc.exec error: Cannot start daemon
24/09/2013 05:27:12 28922 jsvc.exec error: Service exit with a return value of 5
log4j:WARN No appenders could be found for logger
(org.apache.commons.httpclient.params.DefaultHttpParams).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
for more info.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
Caused by: java.lang.NoSuchMethodError:
com.sun.jna.Pointer.nativeValue(Lcom/sun/jna/Pointer;)J
at org.libvirt.Library.free(Unknown Source)
at org.libvirt.Connect.getCapabilities(Unknown Source)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4509)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:747)
at com.cloud.agent.Agent.(Agent.java:161)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:421)
at 
com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:376)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
at com.cloud.agent.AgentShell.start(AgentShell.java:454)
... 5 more

with libvirt 0.5.1, I received following error:

24/09/2013 05:26:13 28823 jsvc.exec error: Cannot start daemon
24/09/2013 05:26:13 28822 jsvc.exec error: Service exit with a return value of 5
log4j:WARN No appenders could be found for logger
(org.apache.commons.httpclient.params.DefaultHttpParams).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
for more info.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
Caused by: java.lang.UnsupportedClassVersionError:
org/libvirt/LibvirtException : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:188)
at 
com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:370)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
at com.cloud.agent.AgentShell.start(AgentShell.java:454)
... 5 more



2013/9/22 Wido den Hollander :
>
>
> On 09/21/2013 09:38 AM, Hugo Trippaers wrote:
>>
>> Ahh ok.
>>
>> Any idea how long that is going to take? At the moment our automated build
>> are basically non functional as they all fail to build and thus also don't
>> kickoff the downstream builds like the noredist build. Can we revert to an
>> older version of libvirt in the meantime to work around this issue?
>>
>
> I hope to get it done this week, but it is out of my hands.
>
> Reverting to libvirt-java 0.4.9 would be possible, but we would also have to
> revert my VNC listen port patch since that already uses the new 0.5.0 API.
>
> Wido
>
>
>> Cheers,
>>
>> Hugo
>>
>>
>> On Sep 21, 2013, at 3:28 PM, Wido den Hollander  wrote:
>>
>>>
>>>
>>> On 09/21/2013 09:15 AM, Hugo Trippaers wrote:

 Hey Wido,

 Did they publish the updated jar with the same version number? If that

Re: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

java 7 is needed.

you can get the maven/java information by "mvn -v"

RE: VmWare SDK to vijava

[Alex Huang]

So this discussion took a big turn that I did not expect.  I am very strongly 
against creating a "plugin" layer just to interface with VmWare.  I appreciate 
both the effort from Darren and Hugo and each hold some merit.  I think we 
should discuss this out and drive a consensus rather than spending time to 
create "plugin" layers and such.

For me, I prefer going directly to wsdl because the helper layer (both vim25 
and vijava) is so thin that it's not a lot of effort to reproduce.  Going 
directly to wsdl has the following advantages:
  - We don't have to worry about upgrades in the helper libraries.  Look at 
what happened on 4.2 vim25 upgrade and the change in hidden behavior changes 
that caused lots of bugs.  It just doesn't seem to be worth the time to deal 
with third party helper libraries for the small amount of code gain.
  - With wsdl, we can generate with different package names so that using two 
different versions of wsdls can have two different set of stub classes so we 
avoid using java class loaders to distinguish between the two. 

Please, let's discuss on this and drive a consensus together rather than try to 
accommodate all. 

--Alex

> -Original Message-
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: Tuesday, September 24, 2013 2:06 PM
> To: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> It is about the interface layer between CloudStack and VMware, Spring can
> only help to what it can, ultimately, we need to refactor the interface layer 
> to
> take in vijava as one of its implementations.
> 
> We also need to consider of another situation, with the latest vSphere 5.1
> API, although VMware claims to support all previous vSphere versions with it,
> we actually found that this is not true. We may have to face the fact that we
> will need to support two versions of vSphere APIs at run time side-by-side.
> I'm leaning towards for us to to have some control in generating the API stub
> for this(the direct WSDL way), if it is to vijava, it depends on whether or 
> not it
> has built-in side-by-side VMware API support. and we will have more things
> to worry and test about it.
> 
> Kelven
> 
> 
> On 9/24/13 1:10 PM, "Frank Zhang"  wrote:
> 
> >Agree. Given current CloudStack code base changing something to another
> >thing is really not a good way.
> >As Darren is working on modular spring, why not construct a new VMWare
> >plugin separately using vijava?
> >Then we can reduce the risk of surprising existing customer and switch
> >to new module when it finally gets mature.
> >
> >
> >> -Original Message-
> >> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> >> Sent: Tuesday, September 24, 2013 11:59 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: VmWare SDK to vijava
> >>
> >> We have commercial releases on top of existing code base and there
> >>are lots of  testing efforts behind it, dramatic switch means $ cost,
> >>the major concern for  me is not about how beautiful vijava is or how
> >>bad a direct wsdl approach  would be. it is about to get things move
> >>smoothly.
> >>
> >> It looks like that we should have VMware layer on its own to have a
> >>plugin  structure so that we can replace underlying binding easier, it
> >>should solve the  balance between developer's motivation and carrying
> >>on the legacy with  minimal impacts to the rest of others.
> >>
> >>
> >> Kelven
> >>
> >> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> >>
> >> >Heya,
> >> >
> >> >This biggest advantage i see in using vijava is that a lot of the
> >> >functionality that we now have in the vmware-base project is already
> >> >supplied with vijava.
> >> >
> >> >There is a lot of code that facilitates calling tasks and other
> >> >stuff in our MO classes. These classes are available in vijava and
> >> >could be used instead of our classes. Basically when using vijava
> >> >correctly you hardly have to work with the ManagedObjectReferences
> >> >anymore. For me this would be a big benefit as it makes programming
> >> >against vmware a lot easier. We also have a lot of duplicate code
> >> >currently in the vmware class and i wouldn't mind getting rid of it,
> >> >which i think is easier with the vijava libraries.
> >> >
> >> >That said, the main driver is getting it into the main build so any
> >> >other efforts towards that goal are ok with me.
> >> >
> >> >I would propose that somebody else puts up a branch with our own
> >> >wdsl wrapper and we open a discussion thread when both branches are
> >> >ready to see which we want to merge in master. Anybody who wants to
> >> >pick that
> >>up?
> >> >
> >> >I'm stubbornly going to continue with converting to vijava, I put
> >> >some effort into it and i want at least to see it running once ;-)
> >> >And the more i work with it the more i'm seeing to benefits of the
> >> >library so i might be able to be more convincing in the end :-)
> >> >
> >> >Cheers,
> >> >
> >> >Hugo
> >> >
> >> >
> >> >On Sep 24, 2

Re: VmWare SDK to vijava

[Kelven Yang]

On 9/24/13 4:22 PM, "Alex Huang"  wrote:

>So this discussion took a big turn that I did not expect.  I am very
>strongly against creating a "plugin" layer just to interface with VmWare.
> I appreciate both the effort from Darren and Hugo and each hold some
>merit.  I think we should discuss this out and drive a consensus rather
>than spending time to create "plugin" layers and such.
>
>For me, I prefer going directly to wsdl because the helper layer (both
>vim25 and vijava) is so thin that it's not a lot of effort to reproduce.
>Going directly to wsdl has the following advantages:
>  - We don't have to worry about upgrades in the helper libraries.  Look
>at what happened on 4.2 vim25 upgrade and the change in hidden behavior
>changes that caused lots of bugs.  It just doesn't seem to be worth the
>time to deal with third party helper libraries for the small amount of
>code gain.
>  - With wsdl, we can generate with different package names so that using
>two different versions of wsdls can have two different set of stub
>classes so we avoid using java class loaders to distinguish between the
>two.

+1, although I don't want to disappoint developer's motivations. The wsdl
approach makes more business sense to me.

-kelven

> 
>
>Please, let's discuss on this and drive a consensus together rather than
>try to accommodate all.
>
>--Alex
>
>> -Original Message-
>> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> Sent: Tuesday, September 24, 2013 2:06 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: VmWare SDK to vijava
>> 
>> It is about the interface layer between CloudStack and VMware, Spring
>>can
>> only help to what it can, ultimately, we need to refactor the interface
>>layer to
>> take in vijava as one of its implementations.
>> 
>> We also need to consider of another situation, with the latest vSphere
>>5.1
>> API, although VMware claims to support all previous vSphere versions
>>with it,
>> we actually found that this is not true. We may have to face the fact
>>that we
>> will need to support two versions of vSphere APIs at run time
>>side-by-side.
>> I'm leaning towards for us to to have some control in generating the
>>API stub
>> for this(the direct WSDL way), if it is to vijava, it depends on
>>whether or not it
>> has built-in side-by-side VMware API support. and we will have more
>>things
>> to worry and test about it.
>> 
>> Kelven
>> 
>> 
>> On 9/24/13 1:10 PM, "Frank Zhang"  wrote:
>> 
>> >Agree. Given current CloudStack code base changing something to another
>> >thing is really not a good way.
>> >As Darren is working on modular spring, why not construct a new VMWare
>> >plugin separately using vijava?
>> >Then we can reduce the risk of surprising existing customer and switch
>> >to new module when it finally gets mature.
>> >
>> >
>> >> -Original Message-
>> >> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> >> Sent: Tuesday, September 24, 2013 11:59 AM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Re: VmWare SDK to vijava
>> >>
>> >> We have commercial releases on top of existing code base and there
>> >>are lots of  testing efforts behind it, dramatic switch means $ cost,
>> >>the major concern for  me is not about how beautiful vijava is or how
>> >>bad a direct wsdl approach  would be. it is about to get things move
>> >>smoothly.
>> >>
>> >> It looks like that we should have VMware layer on its own to have a
>> >>plugin  structure so that we can replace underlying binding easier, it
>> >>should solve the  balance between developer's motivation and carrying
>> >>on the legacy with  minimal impacts to the rest of others.
>> >>
>> >>
>> >> Kelven
>> >>
>> >> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>> >>
>> >> >Heya,
>> >> >
>> >> >This biggest advantage i see in using vijava is that a lot of the
>> >> >functionality that we now have in the vmware-base project is already
>> >> >supplied with vijava.
>> >> >
>> >> >There is a lot of code that facilitates calling tasks and other
>> >> >stuff in our MO classes. These classes are available in vijava and
>> >> >could be used instead of our classes. Basically when using vijava
>> >> >correctly you hardly have to work with the ManagedObjectReferences
>> >> >anymore. For me this would be a big benefit as it makes programming
>> >> >against vmware a lot easier. We also have a lot of duplicate code
>> >> >currently in the vmware class and i wouldn't mind getting rid of it,
>> >> >which i think is easier with the vijava libraries.
>> >> >
>> >> >That said, the main driver is getting it into the main build so any
>> >> >other efforts towards that goal are ok with me.
>> >> >
>> >> >I would propose that somebody else puts up a branch with our own
>> >> >wdsl wrapper and we open a discussion thread when both branches are
>> >> >ready to see which we want to merge in master. Anybody who wants to
>> >> >pick that
>> >>up?
>> >> >
>> >> >I'm stubbornly going to continue with converting to vijava, I put
>> >> >some e

Review Request 14325: Contrail network virtualization plugin.

[Pedro Marques]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

Plugin for contrail virtual network controller.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+network+plugin


Diffs
-

  api/src/com/cloud/network/Network.java 49f380b 
  client/pom.xml 119c96e 
  client/tomcatconf/applicationContext.xml.in 9b6636a 
  client/tomcatconf/commands.properties.in 58c770d 
  client/tomcatconf/componentContext.xml.in 315c95b 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 6b81c25 
  plugins/network-elements/juniper-contrail/pom.xml PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/command/CreateServiceInstanceCmd.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/response/ServiceInstanceResponse.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailElement.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailElementImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailGuru.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailManager.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailManagerImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/DBSyncGeneric.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/EventUtils.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ManagementNetworkGuru.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ModelDatabase.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerDBSync.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerDBSyncImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerEventHandler.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerEventHandlerImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceManager.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceManagerImpl.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceVirtualMachine.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/FloatingIpModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/FloatingIpPoolModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/InstanceIpModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ModelController.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ModelObject.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ModelObjectBase.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ServiceInstanceModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/VMInterfaceModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/VirtualMachineModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/VirtualNetworkModel.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/net/juniper/contrail/management/MockAccountManager.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/net/juniper/contrail/management/NetworkProviderTest.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/net/juniper/contrail/management/TestConfiguration.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/net/juniper/contrail/management/TestDbSetup.java
 PRE-CREATION 
  
plugins/network-elements/juniper-contrail/test/net/juniper/contrail/management/VirtualNetworkModelTest.java
 PRE-CREATION 
  plugins/network-elements/juniper-contrail/test/resources/contrail.properties 
PRE-CREATION 
  plugins/network-elements/juniper-contrail/test/resources/db.properties 
PRE-CREATION 
  plugins/network-elements/juniper-contrail/test/resources/log4j.properties 
PRE-CREATION 
 

Re: Libvirt-java 0.5.0 has been released

[Yoshikazu Nojima]

Sorry,
'with libvirt 0.5.1, I received following error:' I wrote in the last
mail is incorrect. It was with libvirt 0.5.0.


Wei,

I thought libvirt-java 0.5.1 fixed the java 1.6 compatibility problem.
http://www.libvirt.org/git/?p=libvirt-java.git;a=commit;h=5d84874d99ee399276873fb52625303ec3a3f396

Do you mean another thing?

2013/9/24 Wei ZHOU :
> java 7 is needed.
>
> you can get the maven/java information by "mvn -v"

RE: VmWare SDK to vijava

[Alex Huang]

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Tuesday, September 24, 2013 4:23 PM
> To: dev@cloudstack.apache.org
> Subject: RE: VmWare SDK to vijava
> 
> So this discussion took a big turn that I did not expect.  I am very strongly
> against creating a "plugin" layer just to interface with VmWare.  I appreciate
> both the effort from Darren and Hugo and each hold some merit.  I think we
> should discuss this out and drive a consensus rather than spending time to
> create "plugin" layers and such.
> 
> For me, I prefer going directly to wsdl because the helper layer (both vim25
> and vijava) is so thin that it's not a lot of effort to reproduce.  Going 
> directly
> to wsdl has the following advantages:
>   - We don't have to worry about upgrades in the helper libraries.  Look at
> what happened on 4.2 vim25 upgrade and the change in hidden behavior
> changes that caused lots of bugs.  It just doesn't seem to be worth the time
> to deal with third party helper libraries for the small amount of code gain.
>   - With wsdl, we can generate with different package names so that using
> two different versions of wsdls can have two different set of stub classes so
> we avoid using java class loaders to distinguish between the two.

I want to elaborate specifically on this point a little bit.  In a production 
deployed cloud that has been around, there's bound to be hypervisors of 
different versions.  We have that problem with XenServer because it is version 
that's been supported by CloudStack the longest.  CloudStack deals with the 
different versions of the same Hypervisor by writing two different 
ServerResources (they might share a common base of course).  However, if the 
client stubs the different ServerResources talk to are also of different 
versions but with the same name, then we have to work on confining different 
versions of the client stubs to different class loaders.  That's a lot of 
effort to do something simple.  Instead, we can simply designate a different 
package name when  generating from the wsdl (assuming the different versions of 
client stubs is due to wsdl versioning differences when interfacing with 
different versions of hypervisor) and have the ServerResources just refer to 
the different client stubs generated.  Hence, I prefer generation directly from 
wsdl.

--Alex

Problem creating VirtualRouter on XenServer 6.2 due to problem with copy_vhd_from_secondarystorage.sh

[Soheil Eizadi]

Environment:
- 4.3 master (synced with master 08/28/2013 08:43 AM)
- XenServer 6.2

I have a problem creating a Virtual Router on XenServer 6.2, here are the 
symptoms, vmops.log and SMlog don't tell you much, but when I run the copy 
command native I get an error like the copy_vhd_from_secondarystorage.sh shell 
is not compatible with XenServer 6.2. I cleared the XenServer host tag to make 
sure the latest scripts were downloaded from my build. If someone thinks this 
problem is fixed on the top of the trunk, I can do another pull, otherwise I 
guess I need chase this some more in my enviroment?
-Soheil

[root@cloudstackxenserver1 log]# 
/opt/xensource/bin/copy_vhd_from_secondarystorage.sh 
10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd
 1cca28ee-886a-6d52-5461-662b33f1d8d8 cloud-0230b187-29c2-4060-826c-7f697cceea35
Syntax error: Unknown switch: -22MiB
For usage run: 'xe help'
9#can not create vdi in sr 1cca28ee-886a-6d52-5461-662b33f1d8d8

vmops.log:

INFO  [o.a.c.n.e.InfobloxElement] (Job-Executor-5:ctx-e6414bc5) 
InfobloxDeviceElement Host Record created for VM r-9-VM
WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-382:null) 
destoryVDIbyNameLabel failed due to there are 0 VDIs with name 
cloud-0230b187-29c2-4060-826c-7f697cceea35
WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-382:null) can not 
create vdi in sr 1cca28ee-886a-6d52-5461-662b33f1d8d8
.

SMlog:
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]  VMOPS enter  
copy_vhd_from_secondarystorage 
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919] ['bash', 
'/opt/xensource/bin/copy_vhd_from_secondarystorage.sh', 
'10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd',
 '1cca28ee-886a-6d52-5461-662b33f1d8d8', 
'cloud-0230b187-29c2-4060-826c-7f697cceea35']
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]   pread SUCCESS
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]  VMOPS exit  
copy_vhd_from_secondarystorage 
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]  VMOPS enter  
kill_copy_process 
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955] ['bash', 
'/opt/xensource/bin/kill_copy_process.sh', 
'34b74283-916e-4562-82fd-082b387b51c5.vhd']
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]   pread SUCCESS
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]  VMOPS exit  
kill_copy_process 

Re: VmWare SDK to vijava

[Hugo Trippaers]

So at this moment we have the following tally,

Darren, Alex, Kelven opt for the wsdl route
Hugo opts for the vijava route

I'm perfectly ok with ditching my work on the vijava in favour of the wsdl 
route. The arguments presented in the last few mails make a lot of sense. So i 
say the wsdl route is the way to go.

I do think however that we need to revisit the vmware code anyway. There is 
dead code in there, formatting issues and a general duplication of code. Parts 
of my plan to switch to vijava was to simplify the code as well, but i can 
still do that with the WSDL layer. 

Darren, did you run your wsdl branch through the BVT test suite? If you did we 
can merge it on short notice and get on with it. If you didn't can you take 
care of that and give an overview of the testing done on that branch besides 
the BVT?

Cheers,

Hugo


On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:

> We have commercial releases on top of existing code base and there are
> lots of testing efforts behind it, dramatic switch means $ cost, the major
> concern for me is not about how beautiful vijava is or how bad a direct
> wsdl approach would be. it is about to get things move smoothly.
> 
> It looks like that we should have VMware layer on its own to have a plugin
> structure so that we can replace underlying binding easier, it should
> solve the balance between developer's tho motivation and carrying on the
> legacy with minimal impacts to the rest of others.
> 
> 
> Kelven
> 
> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> 
>> Heya,
>> 
>> This biggest advantage i see in using vijava is that a lot of the
>> functionality that we now have in the vmware-base project is already
>> supplied with vijava.
>> 
>> There is a lot of code that facilitates calling tasks and other stuff in
>> our MO classes. These classes are available in vijava and could be used
>> instead of our classes. Basically when using vijava correctly you hardly
>> have to work with the ManagedObjectReferences anymore. For me this would
>> be a big benefit as it makes programming against vmware a lot easier. We
>> also have a lot of duplicate code currently in the vmware class and i
>> wouldn't mind getting rid of it, which i think is easier with the vijava
>> libraries.
>> 
>> That said, the main driver is getting it into the main build so any other
>> efforts towards that goal are ok with me.
>> 
>> I would propose that somebody else puts up a branch with our own wdsl
>> wrapper and we open a discussion thread when both branches are ready to
>> see which we want to merge in master. Anybody who wants to pick that up?
>> 
>> I'm stubbornly going to continue with converting to vijava, I put some
>> effort into it and i want at least to see it running once ;-)  And the
>> more i work with it the more i'm seeing to benefits of the library so i
>> might be able to be more convincing in the end :-)
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>> On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
>> 
>>> Prior to 5.1, VMware provides java binding in its SDK and this is where
>>> CloudStack VMware integration began with. Starting from 5.1, VMware no
>>> longer provides the java binding in binary form and recommends its
>>> customers to generate directly from its WS WSDL.
>>> 
>>> Since we are not sure if we can distribute VMware wsdl legally or not,
>>> therefore, we ended up to generate and distribute the java binding in
>>> binary form. If we can get this cleared in lebal, as Darren pointed, we
>>> can solve our non-dist issue easily in matter of adding couple of lines
>>> in
>>> maven.
>>> 
>>> As of vijava, yes, I think it may add some value from developer's point
>>> of
>>> view, but on the other hand, I don't see immediate benefits to having
>>> another layer on top of VMware official WS API, vijava is an open source
>>> project for providing convenient java binding to vmware WS API, maybe
>>> I'm
>>> wrong, but I think VMware vSphere WS API is the only official published
>>> API from VMware, and the testing result of the API is endorsed by VMware
>>> as an commercial entity. So I see more business value to stick with the
>>> official WS API directly. If we can clear the legal concern of
>>> redistributing VMware wsdl. I would +1 to add a build step of generating
>>> VMware java binding from wsdl.
>>> 
>>> Kelven
>>> 
>>> 
>>> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
>>> 
 We have been having this discussion on moving vmware out of noredist
 since i joined the project. So no real need to rush this suddenly.
 Still
 it would be nice to get this in for the next release. The feature
 freeze
 of 4.3 is october 31st for the 4.3 release. This change (or any sdk
 change to vmware) should be considered an architecture change so it
 should come in at the start of the new release cycle.
 
 So this is currently my main activity on CloudStack meaning i can work
 pretty much dedicated on this. With a bit of luck i can have the

Re: VmWare SDK to vijava

[Kelven Yang]

On 9/24/13 4:54 PM, "Alex Huang"  wrote:

>
>
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Tuesday, September 24, 2013 4:23 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: VmWare SDK to vijava
>> 
>> So this discussion took a big turn that I did not expect.  I am very
>>strongly
>> against creating a "plugin" layer just to interface with VmWare.  I
>>appreciate
>> both the effort from Darren and Hugo and each hold some merit.  I think
>>we
>> should discuss this out and drive a consensus rather than spending time
>>to
>> create "plugin" layers and such.
>> 
>> For me, I prefer going directly to wsdl because the helper layer (both
>>vim25
>> and vijava) is so thin that it's not a lot of effort to reproduce.
>>Going directly
>> to wsdl has the following advantages:
>>   - We don't have to worry about upgrades in the helper libraries.
>>Look at
>> what happened on 4.2 vim25 upgrade and the change in hidden behavior
>> changes that caused lots of bugs.  It just doesn't seem to be worth the
>>time
>> to deal with third party helper libraries for the small amount of code
>>gain.
>>   - With wsdl, we can generate with different package names so that
>>using
>> two different versions of wsdls can have two different set of stub
>>classes so
>> we avoid using java class loaders to distinguish between the two.
>
>I want to elaborate specifically on this point a little bit.  In a
>production deployed cloud that has been around, there's bound to be
>hypervisors of different versions.  We have that problem with XenServer
>because it is version that's been supported by CloudStack the longest.
>CloudStack deals with the different versions of the same Hypervisor by
>writing two different ServerResources (they might share a common base of
>course).  However, if the client stubs the different ServerResources talk
>to are also of different versions but with the same name, then we have to
>work on confining different versions of the client stubs to different
>class loaders.  That's a lot of effort to do something simple.  Instead,
>we can simply designate a different package name when  generating from
>the wsdl (assuming the different versions of client stubs is due to wsdl
>versioning differences when interfacing with different versions of
>hypervisor) and have the ServerResources just refer to the different
>client stubs generated.  Hence, I prefer generation directly from wsdl.

This is my major point as well. VMware API itself is already complex and
we already have wrapped it into isolated MO class layer, it may not be as
complete as what vijava has but it pretty-much has served the needs for
CloudStack, and as far as CloudStack concerns, we really don't need a
full-around API wrapper. I would rather to refactor our MO class layer to
not leak VMware low-level objects first and make the isolation layer fully
neutral to wsdl/xyz wrapper, than to make a dramatic switch right now. The
time should be spent for what is more worth.

The less dependency in the middle, the more flexible we will gain in cases
like the one we elaborate.

-Kelven



>
>--Alex
>

Re: VmWare SDK to vijava

[Kelven Yang]

On 9/24/13 5:27 PM, "Hugo Trippaers"  wrote:

>So at this moment we have the following tally,
>
>Darren, Alex, Kelven opt for the wsdl route
>Hugo opts for the vijava route
>
>I'm perfectly ok with ditching my work on the vijava in favour of the
>wsdl route. The arguments presented in the last few mails make a lot of
>sense. So i say the wsdl route is the way to go.

Great we have reached to a common point.

>
>I do think however that we need to revisit the vmware code anyway. There
>is dead code in there, formatting issues and a general duplication of
>code. Parts of my plan to switch to vijava was to simplify the code as
>well, but i can still do that with the WSDL layer.

I'm +1 for this. When I originally put vmware-base, it was intent to be a
VMware API wrapper layer, used for CloudStack but not limited to or
specific to CloudStack. But as time went by, it has been off from that
goal due to many other reasons (i.e, rush in or paste code in to catch up
release schedule). As I mentioned in one of my replies, I think it will be
worth to clean it up for good for the future. But the priority of doing so
is also low compared to other things we need to work on.

-Kelven

>
>Darren, did you run your wsdl branch through the BVT test suite? If you
>did we can merge it on short notice and get on with it. If you didn't can
>you take care of that and give an overview of the testing done on that
>branch besides the BVT?
>
>Cheers,
>
>Hugo
>
>
>On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:
>
>> We have commercial releases on top of existing code base and there are
>> lots of testing efforts behind it, dramatic switch means $ cost, the
>>major
>> concern for me is not about how beautiful vijava is or how bad a direct
>> wsdl approach would be. it is about to get things move smoothly.
>> 
>> It looks like that we should have VMware layer on its own to have a
>>plugin
>> structure so that we can replace underlying binding easier, it should
>> solve the balance between developer's tho motivation and carrying on the
>> legacy with minimal impacts to the rest of others.
>> 
>> 
>> Kelven
>> 
>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>> 
>>> Heya,
>>> 
>>> This biggest advantage i see in using vijava is that a lot of the
>>> functionality that we now have in the vmware-base project is already
>>> supplied with vijava.
>>> 
>>> There is a lot of code that facilitates calling tasks and other stuff
>>>in
>>> our MO classes. These classes are available in vijava and could be used
>>> instead of our classes. Basically when using vijava correctly you
>>>hardly
>>> have to work with the ManagedObjectReferences anymore. For me this
>>>would
>>> be a big benefit as it makes programming against vmware a lot easier.
>>>We
>>> also have a lot of duplicate code currently in the vmware class and i
>>> wouldn't mind getting rid of it, which i think is easier with the
>>>vijava
>>> libraries.
>>> 
>>> That said, the main driver is getting it into the main build so any
>>>other
>>> efforts towards that goal are ok with me.
>>> 
>>> I would propose that somebody else puts up a branch with our own wdsl
>>> wrapper and we open a discussion thread when both branches are ready to
>>> see which we want to merge in master. Anybody who wants to pick that
>>>up?
>>> 
>>> I'm stubbornly going to continue with converting to vijava, I put some
>>> effort into it and i want at least to see it running once ;-)  And the
>>> more i work with it the more i'm seeing to benefits of the library so i
>>> might be able to be more convincing in the end :-)
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
>>> On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>>>wrote:
>>> 
 Prior to 5.1, VMware provides java binding in its SDK and this is
where
 CloudStack VMware integration began with. Starting from 5.1, VMware no
 longer provides the java binding in binary form and recommends its
 customers to generate directly from its WS WSDL.
 
 Since we are not sure if we can distribute VMware wsdl legally or not,
 therefore, we ended up to generate and distribute the java binding in
 binary form. If we can get this cleared in lebal, as Darren pointed,
we
 can solve our non-dist issue easily in matter of adding couple of
lines
 in
 maven.
 
 As of vijava, yes, I think it may add some value from developer's
point
 of
 view, but on the other hand, I don't see immediate benefits to having
 another layer on top of VMware official WS API, vijava is an open
source
 project for providing convenient java binding to vmware WS API, maybe
 I'm
 wrong, but I think VMware vSphere WS API is the only official
published
 API from VMware, and the testing result of the API is endorsed by
VMware
 as an commercial entity. So I see more business value to stick with
the
 official WS API directly. If we can clear the legal concern of
 redistributing VMware wsdl. I would +1 to add

Re: VmWare SDK to vijava

[Darren Shepherd]

My extensive testing consisted of "it compiles!"  So somebody needs to validate 
it, I don't have a vmware setup handy.  The wsdl generation route is not 
feasible unless legal says it's okay.  Somebody want to email legal@?

Darren

> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
> 
> So at this moment we have the following tally,
> 
> Darren, Alex, Kelven opt for the wsdl route
> Hugo opts for the vijava route
> 
> I'm perfectly ok with ditching my work on the vijava in favour of the wsdl 
> route. The arguments presented in the last few mails make a lot of sense. So 
> i say the wsdl route is the way to go.
> 
> I do think however that we need to revisit the vmware code anyway. There is 
> dead code in there, formatting issues and a general duplication of code. 
> Parts of my plan to switch to vijava was to simplify the code as well, but i 
> can still do that with the WSDL layer. 
> 
> Darren, did you run your wsdl branch through the BVT test suite? If you did 
> we can merge it on short notice and get on with it. If you didn't can you 
> take care of that and give an overview of the testing done on that branch 
> besides the BVT?
> 
> Cheers,
> 
> Hugo
> 
> 
>> On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:
>> 
>> We have commercial releases on top of existing code base and there are
>> lots of testing efforts behind it, dramatic switch means $ cost, the major
>> concern for me is not about how beautiful vijava is or how bad a direct
>> wsdl approach would be. it is about to get things move smoothly.
>> 
>> It looks like that we should have VMware layer on its own to have a plugin
>> structure so that we can replace underlying binding easier, it should
>> solve the balance between developer's tho motivation and carrying on the
>> legacy with minimal impacts to the rest of others.
>> 
>> 
>> Kelven
>> 
>>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>>> 
>>> Heya,
>>> 
>>> This biggest advantage i see in using vijava is that a lot of the
>>> functionality that we now have in the vmware-base project is already
>>> supplied with vijava.
>>> 
>>> There is a lot of code that facilitates calling tasks and other stuff in
>>> our MO classes. These classes are available in vijava and could be used
>>> instead of our classes. Basically when using vijava correctly you hardly
>>> have to work with the ManagedObjectReferences anymore. For me this would
>>> be a big benefit as it makes programming against vmware a lot easier. We
>>> also have a lot of duplicate code currently in the vmware class and i
>>> wouldn't mind getting rid of it, which i think is easier with the vijava
>>> libraries.
>>> 
>>> That said, the main driver is getting it into the main build so any other
>>> efforts towards that goal are ok with me.
>>> 
>>> I would propose that somebody else puts up a branch with our own wdsl
>>> wrapper and we open a discussion thread when both branches are ready to
>>> see which we want to merge in master. Anybody who wants to pick that up?
>>> 
>>> I'm stubbornly going to continue with converting to vijava, I put some
>>> effort into it and i want at least to see it running once ;-)  And the
>>> more i work with it the more i'm seeing to benefits of the library so i
>>> might be able to be more convincing in the end :-)
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
 On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
 
 Prior to 5.1, VMware provides java binding in its SDK and this is where
 CloudStack VMware integration began with. Starting from 5.1, VMware no
 longer provides the java binding in binary form and recommends its
 customers to generate directly from its WS WSDL.
 
 Since we are not sure if we can distribute VMware wsdl legally or not,
 therefore, we ended up to generate and distribute the java binding in
 binary form. If we can get this cleared in lebal, as Darren pointed, we
 can solve our non-dist issue easily in matter of adding couple of lines
 in
 maven.
 
 As of vijava, yes, I think it may add some value from developer's point
 of
 view, but on the other hand, I don't see immediate benefits to having
 another layer on top of VMware official WS API, vijava is an open source
 project for providing convenient java binding to vmware WS API, maybe
 I'm
 wrong, but I think VMware vSphere WS API is the only official published
 API from VMware, and the testing result of the API is endorsed by VMware
 as an commercial entity. So I see more business value to stick with the
 official WS API directly. If we can clear the legal concern of
 redistributing VMware wsdl. I would +1 to add a build step of generating
 VMware java binding from wsdl.
 
 Kelven
 
 
> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
> 
> We have been having this discussion on moving vmware out of noredist
> since i joined the project. So no real need to rush this suddenly.
> Still
> it wo

RE: Problem creating VirtualRouter on XenServer 6.2 due to problem with copy_vhd_from_secondarystorage.sh

[Soheil Eizadi]

The error with copy_vhd_from_secondarystorage.sh is due to a problem with 
secondary storage, vhd_util returning a negative number to a query as the file 
does not exist. I am not sure why 34b74283-916e-4562-82fd-082b387b51c5.vhd 
versus 170c3425-6078-479e-8843-3f8fdc02aaf3.vhd is referenced, that is the next 
step to chase down.
-Soheil

[root@cloudstackxenserver1 bin]# ./vhd-util query -v -n 
10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd
error opening 
10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd:
 -2

root@nfs-server-10-48-15-21:/opt/storage/secondary# find
.
./template
./template/tmpl
./template/tmpl/1
./template/tmpl/1/1
./template/tmpl/1/1/170c3425-6078-479e-8843-3f8fdc02aaf3.vhd
./template/tmpl/1/1/template.properties
./template/tmpl/1/5
./template/tmpl/1/5/0911ae22-350f-38f5-ad3e-423e7e5d6539.vhd
./template/tmpl/1/5/template.properties
./template/tmpl/2
./volumes
./snapshots


From: Soheil Eizadi [seiz...@infoblox.com]
Sent: Tuesday, September 24, 2013 5:11 PM
To: dev@cloudstack.apache.org
Subject: Problem creating VirtualRouter on XenServer 6.2 due to problem with 
copy_vhd_from_secondarystorage.sh

Environment:
- 4.3 master (synced with master 08/28/2013 08:43 AM)
- XenServer 6.2

I have a problem creating a Virtual Router on XenServer 6.2, here are the 
symptoms, vmops.log and SMlog don't tell you much, but when I run the copy 
command native I get an error like the copy_vhd_from_secondarystorage.sh shell 
is not compatible with XenServer 6.2. I cleared the XenServer host tag to make 
sure the latest scripts were downloaded from my build. If someone thinks this 
problem is fixed on the top of the trunk, I can do another pull, otherwise I 
guess I need chase this some more in my enviroment?
-Soheil

[root@cloudstackxenserver1 log]# 
/opt/xensource/bin/copy_vhd_from_secondarystorage.sh 
10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd
 1cca28ee-886a-6d52-5461-662b33f1d8d8 cloud-0230b187-29c2-4060-826c-7f697cceea35
Syntax error: Unknown switch: -22MiB
For usage run: 'xe help'
9#can not create vdi in sr 1cca28ee-886a-6d52-5461-662b33f1d8d8

vmops.log:

INFO  [o.a.c.n.e.InfobloxElement] (Job-Executor-5:ctx-e6414bc5) 
InfobloxDeviceElement Host Record created for VM r-9-VM
WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-382:null) 
destoryVDIbyNameLabel failed due to there are 0 VDIs with name 
cloud-0230b187-29c2-4060-826c-7f697cceea35
WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-382:null) can not 
create vdi in sr 1cca28ee-886a-6d52-5461-662b33f1d8d8
.

SMlog:
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]  VMOPS enter  
copy_vhd_from_secondarystorage 
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919] ['bash', 
'/opt/xensource/bin/copy_vhd_from_secondarystorage.sh', 
'10.48.15.22:/home/nfs/secondary/template/tmpl/1/1/34b74283-916e-4562-82fd-082b387b51c5.vhd',
 '1cca28ee-886a-6d52-5461-662b33f1d8d8', 
'cloud-0230b187-29c2-4060-826c-7f697cceea35']
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]   pread SUCCESS
Sep 24 16:39:41 cloudstackxenserver1 SM: [28919]  VMOPS exit  
copy_vhd_from_secondarystorage 
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]  VMOPS enter  
kill_copy_process 
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955] ['bash', 
'/opt/xensource/bin/kill_copy_process.sh', 
'34b74283-916e-4562-82fd-082b387b51c5.vhd']
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]   pread SUCCESS
Sep 24 16:39:42 cloudstackxenserver1 SM: [28955]  VMOPS exit  
kill_copy_process 

RE: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Tuesday, September 24, 2013 1:47 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> 
> Someone please check this, as I'm not familiar with the doc layout,
> especially trying to decipher it in xml.
> 
> commit to 4.2 branch: da56b6212bbcf9e363ba1add180516584a3d695b
[Animesh>] Marcus a minor xml closing tag was missed, I fixed and kicked off a 
new build. 
> 
> On Mon, Sep 23, 2013 at 4:35 PM, Marcus Sorensen 
> wrote:
> > I think I'll wait until the vote passes, just to be sure that it won't
> > need to be backed out.
> >
> > On Mon, Sep 23, 2013 at 3:47 PM, Animesh Chaturvedi
> >  wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >>> Sent: Monday, September 23, 2013 2:44 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)
> >>>
> >>> I can change my vote to +1 if we include instructions similar to the
> >>> following in the upgrade notes:
> >>>
> >>> If using local storage on KVM, the local storage path needs to be
> >>> changed in order to pass new validation. Remove any trailing slashes
> >>> in the path column of the storage_pool table before starting agents.
> >>> e.g.:
> >>>
> >>> mysql -e 'update cloud.storage_pool set
> path="/var/lib/libvirt/images"
> >>> where path="/var/lib/libvirt/images/"';
> >>>
> >>> If using a custom path, insert your path in place of
> >>> "/var/lib/libvirt/images/". If your custom path did not contain a
> >>> trailing "/", there's no need to do this procedure.
> >>
> >>
> >> [Animesh>] Marcus do you want to go ahead and update the Release
> Notes in 4.2 branch  in file docs/en-US/Release_Notes.xml. I just
> finished making few other changes that were discussed.
> >>
> >>>
> >>> On Mon, Sep 23, 2013 at 3:00 PM, Chiradeep Vittal
> >>>  wrote:
> >>> > +1 (binding)
> >>> >
> >>> > On 9/20/13 8:36 PM, "Animesh Chaturvedi"
> >>> > 
> >>> > wrote:
> >>> >
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>I've created a 4.2.0 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=shortlo
> >>> >>g;h=
> >>> >>refs
> >>> >>/heads/4.2
> >>> >>Commit: 69c459342c568e2400d57ee88572b301603d8686
> >>> >>
> >>> >>List of changes:
> >>> >>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_pl
> >>> >>ain;
> >>> >>f=CH
> >>> >>ANGES;hb=4.2
> >>> >>
> >>> >>Source release (checksums and signatures are available at the same
> >>> >>location):
> >>> >>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
> >>> >>
> >>> >>PGP release keys (signed using 94BE0D7C):
> >>> >>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >>> >>
> >>> >>Testing instructions are here:
> >>> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+tes
> >>> >>t+pr
> >>> >>oced
> >>> >>ure
> >>> >>
> >>> >>Vote will be open for 72 hours (Monday 9/23 PST EOD).
> >>> >>
> >>> >>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)
> >>> >>
> >>> >>
> >>> >

Re: VmWare SDK to vijava

[Hugo Trippaers]

Darren, you can probably work with Prussians to get it through the bvt suite. 
That would be a nice start.

Cheers,

Hugo

Sent from my iPhone

> On 25 sep. 2013, at 09:06, Darren Shepherd  
> wrote:
> 
> My extensive testing consisted of "it compiles!"  So somebody needs to 
> validate it, I don't have a vmware setup handy.  The wsdl generation route is 
> not feasible unless legal says it's okay.  Somebody want to email legal@?
> 
> Darren
> 
>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
>> 
>> So at this moment we have the following tally,
>> 
>> Darren, Alex, Kelven opt for the wsdl route
>> Hugo opts for the vijava route
>> 
>> I'm perfectly ok with ditching my work on the vijava in favour of the wsdl 
>> route. The arguments presented in the last few mails make a lot of sense. So 
>> i say the wsdl route is the way to go.
>> 
>> I do think however that we need to revisit the vmware code anyway. There is 
>> dead code in there, formatting issues and a general duplication of code. 
>> Parts of my plan to switch to vijava was to simplify the code as well, but i 
>> can still do that with the WSDL layer. 
>> 
>> Darren, did you run your wsdl branch through the BVT test suite? If you did 
>> we can merge it on short notice and get on with it. If you didn't can you 
>> take care of that and give an overview of the testing done on that branch 
>> besides the BVT?
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>>> On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:
>>> 
>>> We have commercial releases on top of existing code base and there are
>>> lots of testing efforts behind it, dramatic switch means $ cost, the major
>>> concern for me is not about how beautiful vijava is or how bad a direct
>>> wsdl approach would be. it is about to get things move smoothly.
>>> 
>>> It looks like that we should have VMware layer on its own to have a plugin
>>> structure so that we can replace underlying binding easier, it should
>>> solve the balance between developer's tho motivation and carrying on the
>>> legacy with minimal impacts to the rest of others.
>>> 
>>> 
>>> Kelven
>>> 
 On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
 
 Heya,
 
 This biggest advantage i see in using vijava is that a lot of the
 functionality that we now have in the vmware-base project is already
 supplied with vijava.
 
 There is a lot of code that facilitates calling tasks and other stuff in
 our MO classes. These classes are available in vijava and could be used
 instead of our classes. Basically when using vijava correctly you hardly
 have to work with the ManagedObjectReferences anymore. For me this would
 be a big benefit as it makes programming against vmware a lot easier. We
 also have a lot of duplicate code currently in the vmware class and i
 wouldn't mind getting rid of it, which i think is easier with the vijava
 libraries.
 
 That said, the main driver is getting it into the main build so any other
 efforts towards that goal are ok with me.
 
 I would propose that somebody else puts up a branch with our own wdsl
 wrapper and we open a discussion thread when both branches are ready to
 see which we want to merge in master. Anybody who wants to pick that up?
 
 I'm stubbornly going to continue with converting to vijava, I put some
 effort into it and i want at least to see it running once ;-)  And the
 more i work with it the more i'm seeing to benefits of the library so i
 might be able to be more convincing in the end :-)
 
 Cheers,
 
 Hugo
 
 
> On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
> 
> Prior to 5.1, VMware provides java binding in its SDK and this is where
> CloudStack VMware integration began with. Starting from 5.1, VMware no
> longer provides the java binding in binary form and recommends its
> customers to generate directly from its WS WSDL.
> 
> Since we are not sure if we can distribute VMware wsdl legally or not,
> therefore, we ended up to generate and distribute the java binding in
> binary form. If we can get this cleared in lebal, as Darren pointed, we
> can solve our non-dist issue easily in matter of adding couple of lines
> in
> maven.
> 
> As of vijava, yes, I think it may add some value from developer's point
> of
> view, but on the other hand, I don't see immediate benefits to having
> another layer on top of VMware official WS API, vijava is an open source
> project for providing convenient java binding to vmware WS API, maybe
> I'm
> wrong, but I think VMware vSphere WS API is the only official published
> API from VMware, and the testing result of the API is endorsed by VMware
> as an commercial entity. So I see more business value to stick with the
> official WS API directly. If we can clear the legal concern of
> redistributing VMware wsdl. I would +1 to add a build 

RE: VmWare SDK to vijava

[Alex Huang]

Agreed.  If we can do it is the big question.  Although, AFAIK, vijava is also 
generated from the same set of wsdl.  So if we can't get the license, I have to 
wonder how did vijava get their BSD license?

--Alex

> -Original Message-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Tuesday, September 24, 2013 6:07 PM
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> My extensive testing consisted of "it compiles!"  So somebody needs to
> validate it, I don't have a vmware setup handy.  The wsdl generation route is
> not feasible unless legal says it's okay.  Somebody want to email legal@?
> 
> Darren
> 
> > On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
> >
> > So at this moment we have the following tally,
> >
> > Darren, Alex, Kelven opt for the wsdl route Hugo opts for the vijava
> > route
> >
> > I'm perfectly ok with ditching my work on the vijava in favour of the wsdl
> route. The arguments presented in the last few mails make a lot of sense. So
> i say the wsdl route is the way to go.
> >
> > I do think however that we need to revisit the vmware code anyway. There
> is dead code in there, formatting issues and a general duplication of code.
> Parts of my plan to switch to vijava was to simplify the code as well, but i 
> can
> still do that with the WSDL layer.
> >
> > Darren, did you run your wsdl branch through the BVT test suite? If you did
> we can merge it on short notice and get on with it. If you didn't can you take
> care of that and give an overview of the testing done on that branch besides
> the BVT?
> >
> > Cheers,
> >
> > Hugo
> >
> >
> >> On Sep 25, 2013, at 2:58 AM, Kelven Yang 
> wrote:
> >>
> >> We have commercial releases on top of existing code base and there
> >> are lots of testing efforts behind it, dramatic switch means $ cost,
> >> the major concern for me is not about how beautiful vijava is or how
> >> bad a direct wsdl approach would be. it is about to get things move
> smoothly.
> >>
> >> It looks like that we should have VMware layer on its own to have a
> >> plugin structure so that we can replace underlying binding easier, it
> >> should solve the balance between developer's tho motivation and
> >> carrying on the legacy with minimal impacts to the rest of others.
> >>
> >>
> >> Kelven
> >>
> >>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> >>>
> >>> Heya,
> >>>
> >>> This biggest advantage i see in using vijava is that a lot of the
> >>> functionality that we now have in the vmware-base project is already
> >>> supplied with vijava.
> >>>
> >>> There is a lot of code that facilitates calling tasks and other
> >>> stuff in our MO classes. These classes are available in vijava and
> >>> could be used instead of our classes. Basically when using vijava
> >>> correctly you hardly have to work with the ManagedObjectReferences
> >>> anymore. For me this would be a big benefit as it makes programming
> >>> against vmware a lot easier. We also have a lot of duplicate code
> >>> currently in the vmware class and i wouldn't mind getting rid of it,
> >>> which i think is easier with the vijava libraries.
> >>>
> >>> That said, the main driver is getting it into the main build so any
> >>> other efforts towards that goal are ok with me.
> >>>
> >>> I would propose that somebody else puts up a branch with our own
> >>> wdsl wrapper and we open a discussion thread when both branches are
> >>> ready to see which we want to merge in master. Anybody who wants to
> pick that up?
> >>>
> >>> I'm stubbornly going to continue with converting to vijava, I put
> >>> some effort into it and i want at least to see it running once ;-)
> >>> And the more i work with it the more i'm seeing to benefits of the
> >>> library so i might be able to be more convincing in the end :-)
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
> >>>
>  On Sep 24, 2013, at 2:18 AM, Kelven Yang 
> wrote:
> 
>  Prior to 5.1, VMware provides java binding in its SDK and this is
>  where CloudStack VMware integration began with. Starting from 5.1,
>  VMware no longer provides the java binding in binary form and
>  recommends its customers to generate directly from its WS WSDL.
> 
>  Since we are not sure if we can distribute VMware wsdl legally or
>  not, therefore, we ended up to generate and distribute the java
>  binding in binary form. If we can get this cleared in lebal, as
>  Darren pointed, we can solve our non-dist issue easily in matter of
>  adding couple of lines in maven.
> 
>  As of vijava, yes, I think it may add some value from developer's
>  point of view, but on the other hand, I don't see immediate
>  benefits to having another layer on top of VMware official WS API,
>  vijava is an open source project for providing convenient java
>  binding to vmware WS API, maybe I'm wrong, but I think VMware
>  vSphere WS API is the only official published

Re: VmWare SDK to vijava

[Chiradeep Vittal]

Ha! Prussians == Prasanna?
Godawful autocorrect.

On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:

>Darren, you can probably work with Prussians to get it through the bvt
>suite. That would be a nice start.
>
>Cheers,
>
>Hugo
>
>Sent from my iPhone
>
>> On 25 sep. 2013, at 09:06, Darren Shepherd
>> wrote:
>> 
>> My extensive testing consisted of "it compiles!"  So somebody needs to
>>validate it, I don't have a vmware setup handy.  The wsdl generation
>>route is not feasible unless legal says it's okay.  Somebody want to
>>email legal@?
>> 
>> Darren
>> 
>>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
>>> 
>>> So at this moment we have the following tally,
>>> 
>>> Darren, Alex, Kelven opt for the wsdl route
>>> Hugo opts for the vijava route
>>> 
>>> I'm perfectly ok with ditching my work on the vijava in favour of the
>>>wsdl route. The arguments presented in the last few mails make a lot of
>>>sense. So i say the wsdl route is the way to go.
>>> 
>>> I do think however that we need to revisit the vmware code anyway.
>>>There is dead code in there, formatting issues and a general
>>>duplication of code. Parts of my plan to switch to vijava was to
>>>simplify the code as well, but i can still do that with the WSDL layer.
>>> 
>>> Darren, did you run your wsdl branch through the BVT test suite? If
>>>you did we can merge it on short notice and get on with it. If you
>>>didn't can you take care of that and give an overview of the testing
>>>done on that branch besides the BVT?
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
 On Sep 25, 2013, at 2:58 AM, Kelven Yang 
wrote:
 
 We have commercial releases on top of existing code base and there are
 lots of testing efforts behind it, dramatic switch means $ cost, the
major
 concern for me is not about how beautiful vijava is or how bad a
direct
 wsdl approach would be. it is about to get things move smoothly.
 
 It looks like that we should have VMware layer on its own to have a
plugin
 structure so that we can replace underlying binding easier, it should
 solve the balance between developer's tho motivation and carrying on
the
 legacy with minimal impacts to the rest of others.
 
 
 Kelven
 
> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> 
> Heya,
> 
> This biggest advantage i see in using vijava is that a lot of the
> functionality that we now have in the vmware-base project is already
> supplied with vijava.
> 
> There is a lot of code that facilitates calling tasks and other
>stuff in
> our MO classes. These classes are available in vijava and could be
>used
> instead of our classes. Basically when using vijava correctly you
>hardly
> have to work with the ManagedObjectReferences anymore. For me this
>would
> be a big benefit as it makes programming against vmware a lot
>easier. We
> also have a lot of duplicate code currently in the vmware class and i
> wouldn't mind getting rid of it, which i think is easier with the
>vijava
> libraries.
> 
> That said, the main driver is getting it into the main build so any
>other
> efforts towards that goal are ok with me.
> 
> I would propose that somebody else puts up a branch with our own wdsl
> wrapper and we open a discussion thread when both branches are ready
>to
> see which we want to merge in master. Anybody who wants to pick that
>up?
> 
> I'm stubbornly going to continue with converting to vijava, I put
>some
> effort into it and i want at least to see it running once ;-)  And
>the
> more i work with it the more i'm seeing to benefits of the library
>so i
> might be able to be more convincing in the end :-)
> 
> Cheers,
> 
> Hugo
> 
> 
>> On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>>wrote:
>> 
>> Prior to 5.1, VMware provides java binding in its SDK and this is
>>where
>> CloudStack VMware integration began with. Starting from 5.1, VMware
>>no
>> longer provides the java binding in binary form and recommends its
>> customers to generate directly from its WS WSDL.
>> 
>> Since we are not sure if we can distribute VMware wsdl legally or
>>not,
>> therefore, we ended up to generate and distribute the java binding
>>in
>> binary form. If we can get this cleared in lebal, as Darren
>>pointed, we
>> can solve our non-dist issue easily in matter of adding couple of
>>lines
>> in
>> maven.
>> 
>> As of vijava, yes, I think it may add some value from developer's
>>point
>> of
>> view, but on the other hand, I don't see immediate benefits to
>>having
>> another layer on top of VMware official WS API, vijava is an open
>>source
>> project for providing convenient java binding to vmware WS API,
>>maybe
>> I'm
>> wrong, but I think VMwar

Re: VmWare SDK to vijava

[Hugo Trippaers]

Hahah,

Yeah indeed, awful autocorrect.

Sent from my iPhone

> On 25 sep. 2013, at 10:01, Chiradeep Vittal  
> wrote:
> 
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
> 
>> On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:
>> 
>> Darren, you can probably work with Prussians to get it through the bvt
>> suite. That would be a nice start.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> Sent from my iPhone
>> 
>>> On 25 sep. 2013, at 09:06, Darren Shepherd
>>>  wrote:
>>> 
>>> My extensive testing consisted of "it compiles!"  So somebody needs to
>>> validate it, I don't have a vmware setup handy.  The wsdl generation
>>> route is not feasible unless legal says it's okay.  Somebody want to
>>> email legal@?
>>> 
>>> Darren
>>> 
 On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
 
 So at this moment we have the following tally,
 
 Darren, Alex, Kelven opt for the wsdl route
 Hugo opts for the vijava route
 
 I'm perfectly ok with ditching my work on the vijava in favour of the
 wsdl route. The arguments presented in the last few mails make a lot of
 sense. So i say the wsdl route is the way to go.
 
 I do think however that we need to revisit the vmware code anyway.
 There is dead code in there, formatting issues and a general
 duplication of code. Parts of my plan to switch to vijava was to
 simplify the code as well, but i can still do that with the WSDL layer.
 
 Darren, did you run your wsdl branch through the BVT test suite? If
 you did we can merge it on short notice and get on with it. If you
 didn't can you take care of that and give an overview of the testing
 done on that branch besides the BVT?
 
 Cheers,
 
 Hugo
 
 
> On Sep 25, 2013, at 2:58 AM, Kelven Yang 
> wrote:
> 
> We have commercial releases on top of existing code base and there are
> lots of testing efforts behind it, dramatic switch means $ cost, the
> major
> concern for me is not about how beautiful vijava is or how bad a
> direct
> wsdl approach would be. it is about to get things move smoothly.
> 
> It looks like that we should have VMware layer on its own to have a
> plugin
> structure so that we can replace underlying binding easier, it should
> solve the balance between developer's tho motivation and carrying on
> the
> legacy with minimal impacts to the rest of others.
> 
> 
> Kelven
> 
>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>> 
>> Heya,
>> 
>> This biggest advantage i see in using vijava is that a lot of the
>> functionality that we now have in the vmware-base project is already
>> supplied with vijava.
>> 
>> There is a lot of code that facilitates calling tasks and other
>> stuff in
>> our MO classes. These classes are available in vijava and could be
>> used
>> instead of our classes. Basically when using vijava correctly you
>> hardly
>> have to work with the ManagedObjectReferences anymore. For me this
>> would
>> be a big benefit as it makes programming against vmware a lot
>> easier. We
>> also have a lot of duplicate code currently in the vmware class and i
>> wouldn't mind getting rid of it, which i think is easier with the
>> vijava
>> libraries.
>> 
>> That said, the main driver is getting it into the main build so any
>> other
>> efforts towards that goal are ok with me.
>> 
>> I would propose that somebody else puts up a branch with our own wdsl
>> wrapper and we open a discussion thread when both branches are ready
>> to
>> see which we want to merge in master. Anybody who wants to pick that
>> up?
>> 
>> I'm stubbornly going to continue with converting to vijava, I put
>> some
>> effort into it and i want at least to see it running once ;-)  And
>> the
>> more i work with it the more i'm seeing to benefits of the library
>> so i
>> might be able to be more convincing in the end :-)
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>>> On Sep 24, 2013, at 2:18 AM, Kelven Yang 
>>> wrote:
>>> 
>>> Prior to 5.1, VMware provides java binding in its SDK and this is
>>> where
>>> CloudStack VMware integration began with. Starting from 5.1, VMware
>>> no
>>> longer provides the java binding in binary form and recommends its
>>> customers to generate directly from its WS WSDL.
>>> 
>>> Since we are not sure if we can distribute VMware wsdl legally or
>>> not,
>>> therefore, we ended up to generate and distribute the java binding
>>> in
>>> binary form. If we can get this cleared in lebal, as Darren
>>> pointed, we
>>> can solve our non-dist issue easily in matter of adding couple of
>>> lines
>>> in
>>> maven.
>>> 
>>> As of vijava, yes, I think it may add some value from developer's

Re: [ANNOUNCE] A GCE interface to CloudStack

[Darren Shepherd]

I got this running earlier today and was really impressed with it, good job!  

Our current AWS is just SOAP right?  How about when we do the query api we do 
it as a separate python project just like this.

Darren

> On Sep 24, 2013, at 11:40 AM, Frank Zhang  wrote:
> 
> Take a look at source. Clean and lightweight implementation. Awesome.
> I hope our AWS someday can go this way someday, a separate web server in 
> separate repo and using some dynamically language which makes smaller code
> 
> 
>> -Original Message-
>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>> Sent: Tuesday, September 24, 2013 11:23 AM
>> To: dev@cloudstack.apache.org
>> Cc: Ian Duffy; Darren Brogan
>> Subject: RE: [ANNOUNCE] A GCE interface to CloudStack
>> 
>> This looks awesome :)
>> 
>>> -Original Message-
>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>> Sent: Tuesday, September 24, 2013 12:59 PM
>>> To: dev@cloudstack.apache.org
>>> Cc: Ian Duffy; Darren Brogan
>>> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
>>> 
>>> Wow. Nice!
>>> 
 On 9/24/13 6:04 AM, "sebgoa"  wrote:
 
 Hi,
 
 I am quite pumped to announce a Google Compute Engine (GCE) interface
 to CloudStack.
 
 Ian Duffy, Darren Brogan and myself worked on this on github over the
 last month. Our latest branch:
 
 https://github.com/NOPping/cloudstack-gce/tree/refactor
 
 Has been uploaded to pypi:
 
 https://pypi.python.org/pypi/gcloud
 
 A little virtualenv and a pip install gcloud will give you a Flask
 application, with OAuth2 provider and REST routes that map to the
 CloudStack API.
 The routes are compliant with GCE API, which allows you to use the
 Google gcutil cli to talk to your CloudStack cloud.
 
 Of course there are a few caveats that I will not mention, this is
 release 0.0.1, feedback and pr welcome.
 
 Congrats to our two 20 year olds in ireland who are taking names up
 in Dublin !
 
 Have fun,
 
 -Sebastien
> 

Re: VmWare SDK to vijava

[Darren Shepherd]

That clears up a lot, I didn't know how to get in touch with Prussia.  

Darren

> On Sep 24, 2013, at 7:09 PM, Hugo Trippaers  wrote:
> 
> Hahah,
> 
> Yeah indeed, awful autocorrect.
> 
> Sent from my iPhone
> 
>> On 25 sep. 2013, at 10:01, Chiradeep Vittal  
>> wrote:
>> 
>> Ha! Prussians == Prasanna?
>> Godawful autocorrect.
>> 
>>> On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:
>>> 
>>> Darren, you can probably work with Prussians to get it through the bvt
>>> suite. That would be a nice start.
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> Sent from my iPhone
>>> 
 On 25 sep. 2013, at 09:06, Darren Shepherd
  wrote:
 
 My extensive testing consisted of "it compiles!"  So somebody needs to
 validate it, I don't have a vmware setup handy.  The wsdl generation
 route is not feasible unless legal says it's okay.  Somebody want to
 email legal@?
 
 Darren
 
> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
> 
> So at this moment we have the following tally,
> 
> Darren, Alex, Kelven opt for the wsdl route
> Hugo opts for the vijava route
> 
> I'm perfectly ok with ditching my work on the vijava in favour of the
> wsdl route. The arguments presented in the last few mails make a lot of
> sense. So i say the wsdl route is the way to go.
> 
> I do think however that we need to revisit the vmware code anyway.
> There is dead code in there, formatting issues and a general
> duplication of code. Parts of my plan to switch to vijava was to
> simplify the code as well, but i can still do that with the WSDL layer.
> 
> Darren, did you run your wsdl branch through the BVT test suite? If
> you did we can merge it on short notice and get on with it. If you
> didn't can you take care of that and give an overview of the testing
> done on that branch besides the BVT?
> 
> Cheers,
> 
> Hugo
> 
> 
>> On Sep 25, 2013, at 2:58 AM, Kelven Yang 
>> wrote:
>> 
>> We have commercial releases on top of existing code base and there are
>> lots of testing efforts behind it, dramatic switch means $ cost, the
>> major
>> concern for me is not about how beautiful vijava is or how bad a
>> direct
>> wsdl approach would be. it is about to get things move smoothly.
>> 
>> It looks like that we should have VMware layer on its own to have a
>> plugin
>> structure so that we can replace underlying binding easier, it should
>> solve the balance between developer's tho motivation and carrying on
>> the
>> legacy with minimal impacts to the rest of others.
>> 
>> 
>> Kelven
>> 
>>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>>> 
>>> Heya,
>>> 
>>> This biggest advantage i see in using vijava is that a lot of the
>>> functionality that we now have in the vmware-base project is already
>>> supplied with vijava.
>>> 
>>> There is a lot of code that facilitates calling tasks and other
>>> stuff in
>>> our MO classes. These classes are available in vijava and could be
>>> used
>>> instead of our classes. Basically when using vijava correctly you
>>> hardly
>>> have to work with the ManagedObjectReferences anymore. For me this
>>> would
>>> be a big benefit as it makes programming against vmware a lot
>>> easier. We
>>> also have a lot of duplicate code currently in the vmware class and i
>>> wouldn't mind getting rid of it, which i think is easier with the
>>> vijava
>>> libraries.
>>> 
>>> That said, the main driver is getting it into the main build so any
>>> other
>>> efforts towards that goal are ok with me.
>>> 
>>> I would propose that somebody else puts up a branch with our own wdsl
>>> wrapper and we open a discussion thread when both branches are ready
>>> to
>>> see which we want to merge in master. Anybody who wants to pick that
>>> up?
>>> 
>>> I'm stubbornly going to continue with converting to vijava, I put
>>> some
>>> effort into it and i want at least to see it running once ;-)  And
>>> the
>>> more i work with it the more i'm seeing to benefits of the library
>>> so i
>>> might be able to be more convincing in the end :-)
>>> 
>>> Cheers,
>>> 
>>> Hugo
>>> 
>>> 
 On Sep 24, 2013, at 2:18 AM, Kelven Yang 
 wrote:
 
 Prior to 5.1, VMware provides java binding in its SDK and this is
 where
 CloudStack VMware integration began with. Starting from 5.1, VMware
 no
 longer provides the java binding in binary form and recommends its
 customers to generate directly from its WS WSDL.
 
 Since we are not sure if we can distribute VMware wsdl legally or
 not,
 therefore, we ended up to generate and distribute the java binding
 in
>>

RE: VmWare SDK to vijava

[Alex Huang]

Wow good guess...Hugo had me scratching my head on that oneIs Prussian some 
code name for Apache legalShould I askWould it make me look stupid if I 
askedall sorts of doubts going through my mind.

--Alex

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Tuesday, September 24, 2013 7:01 PM
> To: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
> 
> On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:
> 
> >Darren, you can probably work with Prussians to get it through the bvt
> >suite. That would be a nice start.
> >
> >Cheers,
> >
> >Hugo
> >
> >Sent from my iPhone
> >
> >> On 25 sep. 2013, at 09:06, Darren Shepherd
> >> wrote:
> >>
> >> My extensive testing consisted of "it compiles!"  So somebody needs
> >>to validate it, I don't have a vmware setup handy.  The wsdl
> >>generation route is not feasible unless legal says it's okay.
> >>Somebody want to email legal@?
> >>
> >> Darren
> >>
> >>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
> >>>
> >>> So at this moment we have the following tally,
> >>>
> >>> Darren, Alex, Kelven opt for the wsdl route Hugo opts for the vijava
> >>> route
> >>>
> >>> I'm perfectly ok with ditching my work on the vijava in favour of
> >>>the wsdl route. The arguments presented in the last few mails make a
> >>>lot of sense. So i say the wsdl route is the way to go.
> >>>
> >>> I do think however that we need to revisit the vmware code anyway.
> >>>There is dead code in there, formatting issues and a general
> >>>duplication of code. Parts of my plan to switch to vijava was to
> >>>simplify the code as well, but i can still do that with the WSDL layer.
> >>>
> >>> Darren, did you run your wsdl branch through the BVT test suite? If
> >>>you did we can merge it on short notice and get on with it. If you
> >>>didn't can you take care of that and give an overview of the testing
> >>>done on that branch besides the BVT?
> >>>
> >>> Cheers,
> >>>
> >>> Hugo
> >>>
> >>>
>  On Sep 25, 2013, at 2:58 AM, Kelven Yang 
> wrote:
> 
>  We have commercial releases on top of existing code base and there
> are  lots of testing efforts behind it, dramatic switch means $
> cost, the major  concern for me is not about how beautiful vijava is
> or how bad a direct  wsdl approach would be. it is about to get
> things move smoothly.
> 
>  It looks like that we should have VMware layer on its own to have a
> plugin  structure so that we can replace underlying binding easier,
> it should  solve the balance between developer's tho motivation and
> carrying on the  legacy with minimal impacts to the rest of others.
> 
> 
>  Kelven
> 
> > On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> >
> > Heya,
> >
> > This biggest advantage i see in using vijava is that a lot of the
> > functionality that we now have in the vmware-base project is
> > already supplied with vijava.
> >
> > There is a lot of code that facilitates calling tasks and other
> >stuff in  our MO classes. These classes are available in vijava and
> >could be used  instead of our classes. Basically when using vijava
> >correctly you hardly  have to work with the
> ManagedObjectReferences
> >anymore. For me this would  be a big benefit as it makes
> >programming against vmware a lot easier. We  also have a lot of
> >duplicate code currently in the vmware class and i  wouldn't mind
> >getting rid of it, which i think is easier with the vijava
> >libraries.
> >
> > That said, the main driver is getting it into the main build so
> >any other  efforts towards that goal are ok with me.
> >
> > I would propose that somebody else puts up a branch with our own
> >wdsl  wrapper and we open a discussion thread when both branches
> >are ready to  see which we want to merge in master. Anybody who
> >wants to pick that up?
> >
> > I'm stubbornly going to continue with converting to vijava, I put
> >some  effort into it and i want at least to see it running once ;-)
> >And the  more i work with it the more i'm seeing to benefits of the
> >library so i  might be able to be more convincing in the end :-)
> >
> > Cheers,
> >
> > Hugo
> >
> >
> >> On Sep 24, 2013, at 2:18 AM, Kelven Yang 
> >>wrote:
> >>
> >> Prior to 5.1, VMware provides java binding in its SDK and this is
> >>where  CloudStack VMware integration began with. Starting from
> >>5.1, VMware no  longer provides the java binding in binary form
> >>and recommends its  customers to generate directly from its WS
> >>WSDL.
> >>
> >> Since we are not sure if we can distribute VMware wsdl legally or
> >>not,  therefore, we ended up to generate and distribute the java
> >>binding in  binary form. If we can get this cle

Re: Cloud Bar Camp in San Francisco

[Lakmal Warusawithana]

Hi All,

Is there anyone who would like to join?


On Fri, Sep 20, 2013 at 4:50 PM, Lakmal Warusawithana wrote:

> Hi Devs,
>
> I am from Apache Stratos project. we are in the process of organizing a
> Cloud Bar camp in San Francisco @ Mission Bay Conference Center on October
> 28th, 2013. There's no written agenda, we are planning to start at 2pm and
> go till approx. 5pm and have some drinks in a nearby bar afterwards.
>
> The main purpose is cloud people to get together in a relaxed barcamp
> style atmosphere and hang out. Many Stratos Commiters and PPMC members will
> coming for this. We would be delighted to have cloudstack community over
> there.
>
> So if you are in the bay area, and willing to join this, please reply to
> this mail. It will helpful us to arrange the logistics.
>
> thanks
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>


-- 
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/

RE: [ANNOUNCE] A GCE interface to CloudStack

[Likitha Shetty]

Nice work you guys !

Darren, our current AWS has support for both query and SOAP.

Thanks,
Likitha

>-Original Message-
>From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>Sent: Wednesday, September 25, 2013 8:08 AM
>To: dev@cloudstack.apache.org
>Cc: dev@cloudstack.apache.org; Ian Duffy; Darren Brogan
>Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
>
>I got this running earlier today and was really impressed with it, good job!
>
>Our current AWS is just SOAP right?  How about when we do the query api we do
>it as a separate python project just like this.
>
>Darren
>
>> On Sep 24, 2013, at 11:40 AM, Frank Zhang  wrote:
>>
>> Take a look at source. Clean and lightweight implementation. Awesome.
>> I hope our AWS someday can go this way someday, a separate web server
>> in separate repo and using some dynamically language which makes
>> smaller code
>>
>>
>>> -Original Message-
>>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>>> Sent: Tuesday, September 24, 2013 11:23 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Ian Duffy; Darren Brogan
>>> Subject: RE: [ANNOUNCE] A GCE interface to CloudStack
>>>
>>> This looks awesome :)
>>>
 -Original Message-
 From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
 Sent: Tuesday, September 24, 2013 12:59 PM
 To: dev@cloudstack.apache.org
 Cc: Ian Duffy; Darren Brogan
 Subject: Re: [ANNOUNCE] A GCE interface to CloudStack

 Wow. Nice!

> On 9/24/13 6:04 AM, "sebgoa"  wrote:
>
> Hi,
>
> I am quite pumped to announce a Google Compute Engine (GCE)
> interface to CloudStack.
>
> Ian Duffy, Darren Brogan and myself worked on this on github over
> the last month. Our latest branch:
>
> https://github.com/NOPping/cloudstack-gce/tree/refactor
>
> Has been uploaded to pypi:
>
> https://pypi.python.org/pypi/gcloud
>
> A little virtualenv and a pip install gcloud will give you a Flask
> application, with OAuth2 provider and REST routes that map to the
> CloudStack API.
> The routes are compliant with GCE API, which allows you to use the
> Google gcutil cli to talk to your CloudStack cloud.
>
> Of course there are a few caveats that I will not mention, this is
> release 0.0.1, feedback and pr welcome.
>
> Congrats to our two 20 year olds in ireland who are taking names up
> in Dublin !
>
> Have fun,
>
> -Sebastien
>>