Review Request 22544: CLOUDSTACK-6793: Fixed the issue in master
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22544/ --- Review request for cloudstack and daan Hoogland. Repository: cloudstack-git Description --- This issue fix was missing in master, adding it to master now. Diffs - engine/schema/src/com/cloud/user/dao/AccountDao.java 2f737cd engine/schema/src/com/cloud/user/dao/AccountDaoImpl.java 4bc23ed server/src/com/cloud/tags/TaggedResourceManagerImpl.java c4c003e Diff: https://reviews.apache.org/r/22544/diff/ Testing --- Ran the build and tested the changes. Thanks, Santhosh Edukulla
Re: Review Request 22544: CLOUDSTACK-6793: Fixed the issue in master
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22544/ --- (Updated June 13, 2014, 6:21 a.m.) Review request for cloudstack and daan Hoogland. Repository: cloudstack-git Description --- This issue fix was missing in master, adding it to master now. Diffs - engine/schema/src/com/cloud/user/dao/AccountDao.java 2f737cd engine/schema/src/com/cloud/user/dao/AccountDaoImpl.java 4bc23ed server/src/com/cloud/tags/TaggedResourceManagerImpl.java c4c003e Diff: https://reviews.apache.org/r/22544/diff/ Testing --- Ran the build and tested the changes. Thanks, Santhosh Edukulla
Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)
Hi Silvano, I really liked what you did. I'm curious if this DNS provider will work with non-isolated/shared advanced network zones as well. Otherwise, great approach to solving the last DNS puzzle. I now wonder how easy it would be to add other DNS Providers support into CloudStack besides Bind. Can you share the changes you've made to your cloudstack env to support DNSApis? Also noticed DBaaS-CloudStack in github, sounds interesting, what is it based on? If you can, please kindly explain. Regards ilya On 6/12/14, 10:21 PM, Silvano Nogueira Buback wrote: Hi there, I work at Globo.com, a media company in Brazil. Here we use a cloudstack private network with an advanced zone setup (isolated vlans). For some couple of reasons, the name of virtual machine needs to be available not only on virtual router network context, but on our internal DNS servers. Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server) thru an open source API written by globo.com called DNSAPI. More info at https://github.com/globocom/Dns-Api. To make this implementation of DNS provider, we based our plugin on dns-notifier, but we had to add more classes for our implementation. * DnsAPINetworkDAO to manage the networkDomain for each network. * DnsAPIVirtualMachineDAO to manage DNS records for vms. * DnsAPIElement, this class implements the provider itself. * DnsAPIResource, implements all communications with DNSAPI (ServerResource). Besides this classes, another one was necessary to the call to DnsAPIResource and return the answer, and one API command was created to configure the provider in Zone. Above a video that show you how everything was integrated. https://www.youtube.com/watch?v=fAB53T_NZMI We really appreciate all your comments about our implementation, thanks in advance PS: Sorry about duplicated e-mail in mailing list, but I forget to use DISCUSS and send using company e-mail)
Re: Review Request 22525: Fixed few reported resource leak issues
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22525/ --- (Updated June 13, 2014, 6:35 a.m.) Review request for cloudstack and daan Hoogland. Repository: cloudstack-git Description --- Fixed few coverity issues reported. Diffs - engine/schema/src/com/cloud/vm/dao/UserVmDaoImpl.java f72690e Diff: https://reviews.apache.org/r/22525/diff/ Testing --- Built the CS, ran deploy data center post the change. Thanks, Santhosh Edukulla
Re: Implementation of DNS Provider for Bind
On Fri, Jun 13, 2014 at 7:08 AM, Silvano Buback snbub...@gmail.com wrote: Hi there, I work at Globo.com, a media company in Brazil. Here we use a cloudstack private network with an advanced zone setup (isolated vlans). For some couple of reasons, the name of virtual machine needs to be available not only on virtual router network context, but on our internal DNS servers. Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server) thru an open source API written by globo.com called DNSAPI. More info at https://github.com/globocom/Dns-Api. To make this implementation of DNS provider, we based our plugin on dns-notifier, but we had to add more classes for our implementation. * DnsAPINetworkDAO to manage the networkDomain for each network. * DnsAPIVirtualMachineDAO to manage DNS records for vms. * DnsAPIElement, this class implements the provider itself. * DnsAPIResource, implements all communications with DNSAPI (ServerResource). Besides this classes, another one was necessary to the call to DnsAPIResource and return the answer, and one API command was created to configure the provider in Zone. Above a video that show you how everything was integrated. https://www.youtube.com/watch?v=fAB53T_NZMI I like it, and it seems to be rather straight forward to add other DNS providers as well, if they are based on your DNS API. -- Erik Weber
Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)
On Fri, Jun 13, 2014 at 7:21 AM, Silvano Nogueira Buback silv...@corp.globo.com wrote: Hi there, I work at Globo.com, a media company in Brazil. Here we use a cloudstack private network with an advanced zone setup (isolated vlans). For some couple of reasons, the name of virtual machine needs to be available not only on virtual router network context, but on our internal DNS servers. Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server) thru an open source API written by globo.com called DNSAPI. More info at https://github.com/globocom/Dns-Api. To make this implementation of DNS provider, we based our plugin on dns-notifier, but we had to add more classes for our implementation. * DnsAPINetworkDAO to manage the networkDomain for each network. * DnsAPIVirtualMachineDAO to manage DNS records for vms. * DnsAPIElement, this class implements the provider itself. * DnsAPIResource, implements all communications with DNSAPI (ServerResource). Besides this classes, another one was necessary to the call to DnsAPIResource and return the answer, and one API command was created to configure the provider in Zone. Above a video that show you how everything was integrated. https://www.youtube.com/watch?v=fAB53T_NZMI We really appreciate all your comments about our implementation, replying in the right thread this time :-) I like the idea and the fact that the backend is available as open source. That should make it pretty straight forward to convert it to other DNS solutions (PowerDNS for me). - What happens if there is a conflict? - Does it require / assume that the domain is non-existant on the DNS servers? - How does cleanup handle additional records added outside of CloudStack? -- Erik Weber
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45581 --- Commit ebff469b46551f8613013e80aa0386203a9c7912 in cloudstack's branch refs/heads/4.4-forward from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebff469 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/#review45584 --- Commit cef29948a708fbbae1261dbd8b6a13e4da19c703 in cloudstack's branch refs/heads/4.4-forward from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cef2994 ] CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, DisconnectRemote methods which in turn fixes this bug. connectToRemote was used to connect to share, but once the share is domain joined we don't need this method as we already have required permissions - ASF Subversion and Git Services On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/ --- (Updated June 11, 2014, 7:31 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6872 https://issues.apache.org/jira/browse/CLOUDSTACK-6872 Repository: cloudstack-git Description --- Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need this method as share is domain joined so it has all the required permissions. Removal of this method fixes this bug also. Diffs - plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs 0ad95b8 plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs c8e951e plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 372f848 Diff: https://reviews.apache.org/r/22452/diff/ Testing --- tested that volume operations are working fine after removal of this method Thanks, Anshul Gangwar
Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/#review45585 --- Commit 2dc9e2c530b36efc4c4684e13ae0412103925d05 in cloudstack's branch refs/heads/4.4-forward from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2dc9e2c ] CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later - ASF Subversion and Git Services On June 12, 2014, 8:36 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/ --- (Updated June 12, 2014, 8:36 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6897 https://issues.apache.org/jira/browse/CLOUDSTACK-6897 Repository: cloudstack-git Description --- when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 5bc788e Diff: https://reviews.apache.org/r/22500/diff/ Testing --- tested by uploading a volume and attaching it to vm on zwps in multi cluster setup Thanks, Anshul Gangwar
Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/#review45583 --- Commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150 in cloudstack's branch refs/heads/4.4-forward from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2e49ef7 ] CLOUDSTACK-6867: Added option to upload the volume in VHDX format - ASF Subversion and Git Services On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/ --- (Updated June 11, 2014, 5:20 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6867 https://issues.apache.org/jira/browse/CLOUDSTACK-6867 Repository: cloudstack-git Description --- added the option for vhdx image format in upload volume Diffs - ui/scripts/storage.js 604f09d Diff: https://reviews.apache.org/r/22415/diff/ Testing --- verified by opening the upload volume dialog in UI Thanks, Anshul Gangwar
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45582 --- Commit ebff469b46551f8613013e80aa0386203a9c7912 in cloudstack's branch refs/heads/4.4-forward from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebff469 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/ --- Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-6887 https://issues.apache.org/jira/browse/CLOUDSTACK-6887 Repository: cloudstack-git Description --- Fixing account cleanup issues across multiple test cases. This patch contains test cases fixes in 8 test suites. Will put up new patch for remaining test suites as and when I fix them. Diffs - test/integration/component/test_add_remove_network.py 20aefe4 test/integration/component/test_persistent_networks.py ab1e2c2 test/integration/component/test_projects.py c593fb6 test/integration/component/test_snapshot_gc.py 42c361c test/integration/component/test_snapshot_limits.py 95c6432 test/integration/component/test_usage.py 03823be test/integration/component/test_volumes.py b5b08e2 test/integration/smoke/test_affinity_groups.py 4f3f9ec Diff: https://reviews.apache.org/r/22549/diff/ Testing --- Tested on VMware. Thanks, Gaurav Aradhye
Re: hackathon CCCEU14
kocka, go ahead and edit (though you can't work on all of those subjects during the hackathon, hope you realize that) On Thu, Jun 12, 2014 at 7:46 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Hi, Could you give me write permission to the wiki? Or you can just add me to the wikipage, I will want to work a little bit on all of those :) Thank you, Laszlo On Tue, Jun 10, 2014 at 2:35 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Hello everybody, Do we still want to have a Hackathon next CCC? we need to plan for the resources (noticably the room) pretty soon. On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland dhoogl...@schubergphilis.com wrote: People, I added two more hackathon subjects at https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU In doing so I saw no moderators on the hackathons that were already announced. We need moderators to have successful hackathons. If you feel a hackathon subject is important enough to go through, please add your name in the wiki. Only hackathons with enough attendance will have resources assigned at the conference. \DaanH -- Daan -- EOF -- Daan
moving issues to 4.5
On Thu, Jun 12, 2014 at 11:12 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: [Animesh] Every release has a filter for new features and improvements. Here is one for 4.4 that I had setup a while back https://issues.apache.org/jira/issues/?filter=12326986 [Animesh] 9 of these issues are still open and I sent BULK EDIT reminder to move them out. Along the lines of what Animesh sugested but slightly more radical, I will move features that were scheduled for 4.4 out to 'future' in a couple.. Feel free to move them back in if they are ready and in the 4.4 source base already. This is just a jira action. regards -- Daan
[ACS44] moving issues to 4.5
tagging the subject On Fri, Jun 13, 2014 at 10:18 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: On Thu, Jun 12, 2014 at 11:12 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: [Animesh] Every release has a filter for new features and improvements. Here is one for 4.4 that I had setup a while back https://issues.apache.org/jira/issues/?filter=12326986 [Animesh] 9 of these issues are still open and I sent BULK EDIT reminder to move them out. Along the lines of what Animesh sugested but slightly more radical, I will move features that were scheduled for 4.4 out to 'future' in a couple.. Feel free to move them back in if they are ready and in the 4.4 source base already. This is just a jira action. regards -- Daan -- Daan
Re: FindBugs report disabled ?
I disabled it as it did no longer give output on where new issues were found. I started building a new job called master-slowbuild. It is not fully functional and it slipped my mind. there is non for 4.4 On Fri, Jun 13, 2014 at 12:06 AM, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi, I am looking for FindBugs report in jenkis http://jenkins.buildacloud.org/job/build-master-slowbuild/ ; looks like its disabled from May 21 , any idea about this ? Is there FindBugs reported scheduled for 4.4 branch? Regards, Rayees -- Daan
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45589 --- Commit 66d1eb92f03c39734dcaf83e20639cd9a338e388 in cloudstack's branch refs/heads/master from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66d1eb9 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45590 --- Commit 66d1eb92f03c39734dcaf83e20639cd9a338e388 in cloudstack's branch refs/heads/master from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66d1eb9 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/#review45592 --- Commit b43036d10e718eea869574780e8ad70b18862b16 in cloudstack's branch refs/heads/master from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b43036d ] CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, DisconnectRemote methods which in turn fixes this bug. connectToRemote was used to connect to share, but once the share is domain joined we don't need this method as we already have required permissions - ASF Subversion and Git Services On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/ --- (Updated June 11, 2014, 7:31 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6872 https://issues.apache.org/jira/browse/CLOUDSTACK-6872 Repository: cloudstack-git Description --- Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need this method as share is domain joined so it has all the required permissions. Removal of this method fixes this bug also. Diffs - plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs 0ad95b8 plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs c8e951e plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 372f848 Diff: https://reviews.apache.org/r/22452/diff/ Testing --- tested that volume operations are working fine after removal of this method Thanks, Anshul Gangwar
Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/#review45591 --- Commit 7ea3930ae9770c2c52749de9a523f007b80d8b24 in cloudstack's branch refs/heads/master from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ea3930 ] CLOUDSTACK-6867: Added option to upload the volume in VHDX format - ASF Subversion and Git Services On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/ --- (Updated June 11, 2014, 5:20 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6867 https://issues.apache.org/jira/browse/CLOUDSTACK-6867 Repository: cloudstack-git Description --- added the option for vhdx image format in upload volume Diffs - ui/scripts/storage.js 604f09d Diff: https://reviews.apache.org/r/22415/diff/ Testing --- verified by opening the upload volume dialog in UI Thanks, Anshul Gangwar
Re: [DISCUSS] 4.3.1
Sebastian, Please disregard the revert request, Thanks, ilya On 6/12/14, 5:55 PM, ilya musayev wrote: Sebastian, Please cherry-pick following commits: CLOUDSTACK-5891.[VMware] If a template has been registered and cpu.corespersocket... https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=008b029a29460d883ac7d645877e6f4f2945b1e1 CLOUDSTACK-6317 [VMware] Tagged VLAN support broken for Management/Control/Storage traffic https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=5bc72ea25000456b4a479baac8f9e0690794c0d2 CLOUDSTACK-6478: Failed to download Template when having 3 SSVM's in one zone on Vmware. https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=8e286996c8cdb58255a631b3bd977ad4b4baebd2 I would ask if we can revert not so useful functionality that actually makes cloudstack very inflexible: https://issues.apache.org/jira/browse/CLOUDSTACK-3911 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3b1a49c303a929c754561ca07fd8a9ed84e0382 Thanks ilya PS: In the next week or two, i should have a lighter work load and willing to help with testing or whatever else you may need to help with. On 6/12/14, 7:17 AM, sebgoa wrote: While we are talking about 4.4 I am game to RM a 4.3.1 , there has been several bug fixes since 4.3.0. Anybody interested, any suggestions of what would still need to be cherry picked ? https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 -Sebastien
Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/ --- (Updated June 13, 2014, 9:08 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Changes --- updated patch for master Bugs: CLOUDSTACK-6897 https://issues.apache.org/jira/browse/CLOUDSTACK-6897 Repository: cloudstack-git Description --- when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later Diffs (updated) - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 3cf8c6c Diff: https://reviews.apache.org/r/22500/diff/ Testing --- tested by uploading a volume and attaching it to vm on zwps in multi cluster setup Thanks, Anshul Gangwar
Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/#review45596 --- Ship it! Ship It! - Devdeep Singh On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/ --- (Updated June 11, 2014, 5:20 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6867 https://issues.apache.org/jira/browse/CLOUDSTACK-6867 Repository: cloudstack-git Description --- added the option for vhdx image format in upload volume Diffs - ui/scripts/storage.js 604f09d Diff: https://reviews.apache.org/r/22415/diff/ Testing --- verified by opening the upload volume dialog in UI Thanks, Anshul Gangwar
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45595 --- Ship it! Ship It! - Devdeep Singh On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/#review45597 --- Ship it! Ship It! - Devdeep Singh On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/ --- (Updated June 11, 2014, 7:31 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6872 https://issues.apache.org/jira/browse/CLOUDSTACK-6872 Repository: cloudstack-git Description --- Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need this method as share is domain joined so it has all the required permissions. Removal of this method fixes this bug also. Diffs - plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs 0ad95b8 plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs c8e951e plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 372f848 Diff: https://reviews.apache.org/r/22452/diff/ Testing --- tested that volume operations are working fine after removal of this method Thanks, Anshul Gangwar
Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22554/
---
Review request for cloudstack.
Bugs: CLOUDSTACK-6909
https://issues.apache.org/jira/browse/CLOUDSTACK-6909
Repository: cloudstack-git
Description
---
Fix marvin's handling of details field for primary and secondary storage to
cope with SMB credentials. This allows Hyper-V to work.
Diffs
-
tools/marvin/marvin/deployDataCenter.py 22b78ab
Diff: https://reviews.apache.org/r/22554/diff/
Testing
---
Tested deploydataCenter with this JSON:
{
dbSvr:{
dbSvr:10.220.137.39,
passwd:cloud,
db:cloud,
port:3306,
user:cloud
},
zones:[
{
name:XenRT-Zone-0,
guestcidraddress:192.168.200.0/24,
dns1:10.220.160.11,
physical_networks:[
{
XRT_VLANRangeSize:10,
name:AdvPhyNetwork,
providers:[
{
broadcastdomainrange:ZONE,
name:VirtualRouter
},
{
broadcastdomainrange:ZONE,
name:VpcVirtualRouter
},
{
broadcastdomainrange:ZONE,
name:InternalLbVm
}
],
broadcastdomainrange:Zone,
vlan:3000-3009,
traffictypes:[
{
typ:Guest
},
{
typ:Management
},
{
typ:Public
}
],
isolationmethods:[
VLAN
]
}
],
ipranges:[
{
startip:10.220.164.0,
endip:10.220.164.9,
netmask:255.255.240.0,
XRT_GuestIPRangeSize:10,
gateway:10.220.160.1
}
],
networktype:Advanced,
pods:[
{
XRT_PodIPRangeSize:10,
name:XenRT-Zone-0-Pod-0,
endip:10.220.164.39,
startip:10.220.164.30,
netmask:255.255.240.0,
clusters:[
{
XRT_HyperVHostIds:0,
clustername:XenRT-Zone-0-Pod-0-Cluster-0,
hypervisor:hyperv,
primaryStorages:[
{
url:cifs://10.220.163.45/storage/primary,
name:XenRT-Zone-0-Pod-0-Primary-Store,
details:[
{
user:Administrator
},
{
password:xenroot01T
},
{
domain:XSQA
}
]
}
],
clustertype:CloudManaged,
hosts:[
{
url:http://10.220.163.45;,
username:root,
password:xenroot
}
],
XRT_Hosts:1
}
],
gateway:10.220.160.1
}
],
internaldns1:10.220.160.11,
secondaryStorages:[
{
url:cifs://10.220.163.45/storage/secondary,
details:{
domain:XSQA,
password:xenroot01T,
user:Administrator
},
provider:SMB
}
]
}
],
mgtSvr:[
{
mgtSvrIp:10.220.137.39,
passwd:xenroot,
port:8096,
user:root
}
]
}
Thanks,
John Dilley
Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/#review45599 --- Commit aa21cdcd494aff1df119d2e17a3a51da861e3f51 in cloudstack's branch refs/heads/master from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa21cdc ] CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later - ASF Subversion and Git Services On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/ --- (Updated June 13, 2014, 9:08 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6897 https://issues.apache.org/jira/browse/CLOUDSTACK-6897 Repository: cloudstack-git Description --- when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 3cf8c6c Diff: https://reviews.apache.org/r/22500/diff/ Testing --- tested by uploading a volume and attaching it to vm on zwps in multi cluster setup Thanks, Anshul Gangwar
Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/#review45600 --- Ship it! Ship It! - Devdeep Singh On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/ --- (Updated June 13, 2014, 9:08 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6897 https://issues.apache.org/jira/browse/CLOUDSTACK-6897 Repository: cloudstack-git Description --- when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 3cf8c6c Diff: https://reviews.apache.org/r/22500/diff/ Testing --- tested by uploading a volume and attaching it to vm on zwps in multi cluster setup Thanks, Anshul Gangwar
Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22554/#review45598
---
tools/marvin/marvin/deployDataCenter.py
https://reviews.apache.org/r/22554/#comment80484
Just use in instead
- Santhosh Edukulla
On June 13, 2014, 9:17 a.m., John Dilley wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22554/
---
(Updated June 13, 2014, 9:17 a.m.)
Review request for cloudstack.
Bugs: CLOUDSTACK-6909
https://issues.apache.org/jira/browse/CLOUDSTACK-6909
Repository: cloudstack-git
Description
---
Fix marvin's handling of details field for primary and secondary storage to
cope with SMB credentials. This allows Hyper-V to work.
Diffs
-
tools/marvin/marvin/deployDataCenter.py 22b78ab
Diff: https://reviews.apache.org/r/22554/diff/
Testing
---
Tested deploydataCenter with this JSON:
{
dbSvr:{
dbSvr:10.220.137.39,
passwd:cloud,
db:cloud,
port:3306,
user:cloud
},
zones:[
{
name:XenRT-Zone-0,
guestcidraddress:192.168.200.0/24,
dns1:10.220.160.11,
physical_networks:[
{
XRT_VLANRangeSize:10,
name:AdvPhyNetwork,
providers:[
{
broadcastdomainrange:ZONE,
name:VirtualRouter
},
{
broadcastdomainrange:ZONE,
name:VpcVirtualRouter
},
{
broadcastdomainrange:ZONE,
name:InternalLbVm
}
],
broadcastdomainrange:Zone,
vlan:3000-3009,
traffictypes:[
{
typ:Guest
},
{
typ:Management
},
{
typ:Public
}
],
isolationmethods:[
VLAN
]
}
],
ipranges:[
{
startip:10.220.164.0,
endip:10.220.164.9,
netmask:255.255.240.0,
XRT_GuestIPRangeSize:10,
gateway:10.220.160.1
}
],
networktype:Advanced,
pods:[
{
XRT_PodIPRangeSize:10,
name:XenRT-Zone-0-Pod-0,
endip:10.220.164.39,
startip:10.220.164.30,
netmask:255.255.240.0,
clusters:[
{
XRT_HyperVHostIds:0,
clustername:XenRT-Zone-0-Pod-0-Cluster-0,
hypervisor:hyperv,
primaryStorages:[
{
url:cifs://10.220.163.45/storage/primary,
name:XenRT-Zone-0-Pod-0-Primary-Store,
details:[
{
user:Administrator
},
{
password:xenroot01T
},
{
domain:XSQA
}
]
}
],
clustertype:CloudManaged,
hosts:[
{
url:http://10.220.163.45;,
username:root,
password:xenroot
}
],
XRT_Hosts:1
}
],
gateway:10.220.160.1
}
],
internaldns1:10.220.160.11,
secondaryStorages:[
{
url:cifs://10.220.163.45/storage/secondary,
details:{
domain:XSQA,
password:xenroot01T,
user:Administrator
},
provider:SMB
}
]
}
],
mgtSvr:[
{
mgtSvrIp:10.220.137.39,
passwd:xenroot,
port:8096,
user:root
}
]
}
Thanks,
John Dilley
[ACS44] Cherry pick for CLOUDSTACK-6897, CLOUDSTACK-6868, CLOUDSTACK-6872, CLOUDSTACK-6867, CLOUDSTACK-6865
Hi Daan/Hugo, Can you please cherry-pick following commits from 4.4-forward to 4.4: commit 2dc9e2c530b36efc4c4684e13ae0412103925d05 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Thu Jun 12 13:54:56 2014 +0530 CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope s commit cef29948a708fbbae1261dbd8b6a13e4da19c703 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Wed Jun 11 11:04:35 2014 +0530 CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, DisconnectRemote methods which in turn fixes this bug. connectToRemote was used to connect to share, but once the share is domain joined we don commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Tue Jun 10 16:43:40 2014 +0530 CLOUDSTACK-6867: Added option to upload the volume in VHDX format commit ebff469b46551f8613013e80aa0386203a9c7912 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Tue Jun 10 16:28:32 2014 +0530 CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Thanks, Anshul
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45608 --- Commit a951b51523069e72e5cd1e503df11b9370b6d6d8 in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a951b51 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set (cherry picked from commit ebff469b46551f8613013e80aa0386203a9c7912) - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/#review45604 --- Commit 117c8fe5b0e1b9f1045cbf65e3285fbf205770bf in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=117c8fe ] CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later (cherry picked from commit 2dc9e2c530b36efc4c4684e13ae0412103925d05) - ASF Subversion and Git Services On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22500/ --- (Updated June 13, 2014, 9:08 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6897 https://issues.apache.org/jira/browse/CLOUDSTACK-6897 Repository: cloudstack-git Description --- when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope storage allocator, allocating a storage pool for VM on zwps beacuse of pod id not null. This was resulting in scope conflict later Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 3cf8c6c Diff: https://reviews.apache.org/r/22500/diff/ Testing --- tested by uploading a volume and attaching it to vm on zwps in multi cluster setup Thanks, Anshul Gangwar
Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/#review45605 --- Commit ef0cec938165fdf3531f92dc8f4c2930ff95fa5e in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ef0cec9 ] CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, DisconnectRemote methods which in turn fixes this bug. connectToRemote was used to connect to share, but once the share is domain joined we don't need this method as we already have required permissions (cherry picked from commit cef29948a708fbbae1261dbd8b6a13e4da19c703) - ASF Subversion and Git Services On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22452/ --- (Updated June 11, 2014, 7:31 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6872 https://issues.apache.org/jira/browse/CLOUDSTACK-6872 Repository: cloudstack-git Description --- Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need this method as share is domain joined so it has all the required permissions. Removal of this method fixes this bug also. Diffs - plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs 0ad95b8 plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs c8e951e plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 372f848 Diff: https://reviews.apache.org/r/22452/diff/ Testing --- tested that volume operations are working fine after removal of this method Thanks, Anshul Gangwar
Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/#review45606 --- Commit 2c5f352e94e071113ae1bbf74435662568902043 in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c5f352 ] CLOUDSTACK-6867: Added option to upload the volume in VHDX format (cherry picked from commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150) - ASF Subversion and Git Services On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22415/ --- (Updated June 11, 2014, 5:20 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6867 https://issues.apache.org/jira/browse/CLOUDSTACK-6867 Repository: cloudstack-git Description --- added the option for vhdx image format in upload volume Diffs - ui/scripts/storage.js 604f09d Diff: https://reviews.apache.org/r/22415/diff/ Testing --- verified by opening the upload volume dialog in UI Thanks, Anshul Gangwar
Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/#review45607 --- Commit a951b51523069e72e5cd1e503df11b9370b6d6d8 in cloudstack's branch refs/heads/4.4 from Anshul Gangwar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a951b51 ] CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format. Now changed the behavior to set Image Format for volume only when it is not set (cherry picked from commit ebff469b46551f8613013e80aa0386203a9c7912) - ASF Subversion and Git Services On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22414/ --- (Updated June 10, 2014, 11:23 a.m.) Review request for cloudstack, Devdeep Singh and Rajesh Battala. Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868 https://issues.apache.org/jira/browse/CLOUDSTACK-6865 https://issues.apache.org/jira/browse/CLOUDSTACK-6868 Repository: cloudstack-git Description --- while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Now changed the behavior to set Image Format for volume only when it is not set Diffs - engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java 064ffca Diff: https://reviews.apache.org/r/22414/diff/ Testing --- verified by uploading the vhd volume and attaching it to VM Thanks, Anshul Gangwar
Re: [ACS44] Cherry pick for CLOUDSTACK-6897, CLOUDSTACK-6868, CLOUDSTACK-6872, CLOUDSTACK-6867, CLOUDSTACK-6865
4 picked On Fri, Jun 13, 2014 at 12:25 PM, Anshul Gangwar anshul.gang...@citrix.com wrote: Hi Daan/Hugo, Can you please cherry-pick following commits from 4.4-forward to 4.4: commit 2dc9e2c530b36efc4c4684e13ae0412103925d05 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Thu Jun 12 13:54:56 2014 +0530 CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on zwps, then we were passing the podId of VM instead of storage pool to storage allocator. This resulting in use of Clusterscope s commit cef29948a708fbbae1261dbd8b6a13e4da19c703 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Wed Jun 11 11:04:35 2014 +0530 CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, DisconnectRemote methods which in turn fixes this bug. connectToRemote was used to connect to share, but once the share is domain joined we don commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Tue Jun 10 16:43:40 2014 +0530 CLOUDSTACK-6867: Added option to upload the volume in VHDX format commit ebff469b46551f8613013e80aa0386203a9c7912 Author: Anshul Gangwar anshul.gang...@citrix.com Date: Tue Jun 10 16:28:32 2014 +0530 CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were changing the volume's Image format to hypervisor's default Image format, hence it was failing to find the volume with vhdx format Thanks, Anshul -- Daan
Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)
Hi Silvano, On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback silv...@corp.globo.com wrote: Hi there, I work at Globo.com, a media company in Brazil. Here we use a cloudstack private network with an advanced zone setup (isolated vlans). For some couple of reasons, the name of virtual machine needs to be available not only on virtual router network context, but on our internal DNS servers. Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server) thru an open source API written by globo.com called DNSAPI. More info at https://github.com/globocom/Dns-Api. Thanks for the proposal. I recommend that you document your design goals in 4.5 or above design docs wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents I saw the video you shared, it looked seamless but I could not figure out how the ACS plugin interacts with the DNS provider. The API library you mentioned is written in Ruby, so how does it integrate or work with the dns plugin in ACS, is it over HTTP or RPC/Thrift? Regards. To make this implementation of DNS provider, we based our plugin on dns-notifier, but we had to add more classes for our implementation. * DnsAPINetworkDAO to manage the networkDomain for each network. * DnsAPIVirtualMachineDAO to manage DNS records for vms. * DnsAPIElement, this class implements the provider itself. * DnsAPIResource, implements all communications with DNSAPI (ServerResource). Besides this classes, another one was necessary to the call to DnsAPIResource and return the answer, and one API command was created to configure the provider in Zone. Above a video that show you how everything was integrated. https://www.youtube.com/watch?v=fAB53T_NZMI We really appreciate all your comments about our implementation, thanks in advance PS: Sorry about duplicated e-mail in mailing list, but I forget to use DISCUSS and send using company e-mail)
Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/#review45609 --- Ship it! Ship It! - Girish Shilamkar On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/ --- (Updated June 13, 2014, 7:42 a.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-6887 https://issues.apache.org/jira/browse/CLOUDSTACK-6887 Repository: cloudstack-git Description --- Fixing account cleanup issues across multiple test cases. This patch contains test cases fixes in 8 test suites. Will put up new patch for remaining test suites as and when I fix them. Diffs - test/integration/component/test_add_remove_network.py 20aefe4 test/integration/component/test_persistent_networks.py ab1e2c2 test/integration/component/test_projects.py c593fb6 test/integration/component/test_snapshot_gc.py 42c361c test/integration/component/test_snapshot_limits.py 95c6432 test/integration/component/test_usage.py 03823be test/integration/component/test_volumes.py b5b08e2 test/integration/smoke/test_affinity_groups.py 4f3f9ec Diff: https://reviews.apache.org/r/22549/diff/ Testing --- Tested on VMware. Thanks, Gaurav Aradhye
[ACS44] cherry-pick request
Daan, Please cherry-pick below commits in 4.4-forward into 4.4 commit be937a08213f06a801cf07d19867d48dad35d19f CLOUDSTACK-6832: [OVS]vnet is not released even the network is deleted fix ensures allocated VNET is released during network shutdown commit 9dfbdb5ffd2f0981651bc98f1c5d71718a24a29f CLOUDSTACK-6749: [OVS] xe network-param-get with param-key=is-ovs-vpc-distributed-vr-network alway returns error fixing unnecessary errors in the logs Thanks.
Re: [ACS44] cherry-pick request
both pulled On Fri, Jun 13, 2014 at 1:53 PM, Murali Reddy murali.re...@citrix.com wrote: Daan, Please cherry-pick below commits in 4.4-forward into 4.4 commit be937a08213f06a801cf07d19867d48dad35d19f CLOUDSTACK-6832: [OVS]vnet is not released even the network is deleted fix ensures allocated VNET is released during network shutdown commit 9dfbdb5ffd2f0981651bc98f1c5d71718a24a29f CLOUDSTACK-6749: [OVS] xe network-param-get with param-key=is-ovs-vpc-distributed-vr-network alway returns error fixing unnecessary errors in the logs Thanks. -- Daan
RE: [ACS44] CLOUDSTACK-6464
Daan, Thanks for following up. Both Marcus and Edison have been involved looking at this bug, and it appears to be related to what CS expects in the cloud.vlan table between releases. This issue affects both untagged networks and tagged networks in the same manner, and simply changing the vlan_id column data format seems to fix the problem. A couple of us (myself included) have tested a database fix and commented success in the issue notes. Since our testing, I haven't seen any comment on how this should be fixed permanently (either a database data change during upgrade, or code to support the older data format for original installs prior to 4.3). My preference would be a data change, as that's easier to maintain moving forward. I still think a note should be posted on 4.3, suggesting people to avoid it for KVM upgrades, or at the very least pointing them to this issue so they can updated the data format manually post upgrade, and prior to restarting their VRs. - Si From: Daan Hoogland daan.hoogl...@gmail.com Sent: Thursday, June 12, 2014 8:47 AM To: dev Subject: Re: [ACS44] CLOUDSTACK-6464 Simon, I found you in my spam box looking for my colleague, Hugo. Didn't find him there;) I guess you're request is no longer actual, The bug is, no doubt. Can you give an update on it? On Wed, May 14, 2014 at 1:00 AM, Simon Weller swel...@ena.com wrote: All, Could someone with knowledge of the KVM traffic label code take a look at https://issues.apache.org/jira/browse/CLOUDSTACK-6464? It appears egress traffic is broken currently when basic or advanced networking is in use with traffic labels on KVM. Daan, Could you change the tag for this to 4.4 from 4.3.1, and in my opinion this should be a blocker, as it completely breaks KVM VR networking. Thanks, - Si -- Daan
Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/#review45614 --- Commit b849b7ee3d9b4a141c2eb3fd689d197ed20c4581 in cloudstack's branch refs/heads/4.4-forward from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b849b7e ] CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases - ASF Subversion and Git Services On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/ --- (Updated June 13, 2014, 7:42 a.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-6887 https://issues.apache.org/jira/browse/CLOUDSTACK-6887 Repository: cloudstack-git Description --- Fixing account cleanup issues across multiple test cases. This patch contains test cases fixes in 8 test suites. Will put up new patch for remaining test suites as and when I fix them. Diffs - test/integration/component/test_add_remove_network.py 20aefe4 test/integration/component/test_persistent_networks.py ab1e2c2 test/integration/component/test_projects.py c593fb6 test/integration/component/test_snapshot_gc.py 42c361c test/integration/component/test_snapshot_limits.py 95c6432 test/integration/component/test_usage.py 03823be test/integration/component/test_volumes.py b5b08e2 test/integration/smoke/test_affinity_groups.py 4f3f9ec Diff: https://reviews.apache.org/r/22549/diff/ Testing --- Tested on VMware. Thanks, Gaurav Aradhye
Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/#review45615 --- Commit 59a98839ce895cef6e4864f37fd831805d1da8f1 in cloudstack's branch refs/heads/master from Gaurav Aradhye [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59a9883 ] CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases - ASF Subversion and Git Services On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22549/ --- (Updated June 13, 2014, 7:42 a.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-6887 https://issues.apache.org/jira/browse/CLOUDSTACK-6887 Repository: cloudstack-git Description --- Fixing account cleanup issues across multiple test cases. This patch contains test cases fixes in 8 test suites. Will put up new patch for remaining test suites as and when I fix them. Diffs - test/integration/component/test_add_remove_network.py 20aefe4 test/integration/component/test_persistent_networks.py ab1e2c2 test/integration/component/test_projects.py c593fb6 test/integration/component/test_snapshot_gc.py 42c361c test/integration/component/test_snapshot_limits.py 95c6432 test/integration/component/test_usage.py 03823be test/integration/component/test_volumes.py b5b08e2 test/integration/smoke/test_affinity_groups.py 4f3f9ec Diff: https://reviews.apache.org/r/22549/diff/ Testing --- Tested on VMware. Thanks, Gaurav Aradhye
Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins
Mike, I completely agree with the need to attach driver-specified key-value pairs to a storage driver (we have been batting this around for nearly a year). However, I think this facility should be generalized to support all drivers (e.g. network, compute, etc) where storage maybe the first layer to implement it. For example, we have a raft of places where vendor specific data/concepts leak into the object model and schema. For example, in networking, we have vendor specific API calls. One of the main value propositions of a cloud platform is to provide a unified abstraction for underlying infrastructure components. Furthermore, requiring vendor implements to add API calls further increases the complexity and effort required to support CloudStack — discouraging their participation. In terms of the design of itself, I don’t feel that the MapString, String getPropertiesAndTypes is a rich enough semantic for such an extension facility. First, it does not provide a mechanism to validate that the form and content of the values being set. Second, it is incredible lose contract that does not exploit the Java compiler to ensure drivers are providing well-formed metadata to the CloudStack orchestration components. Finally, it does not support notions such as hinting which fields are required (very useful for creating useful UIs) and constrained values (rendered as drop downs). My thoughts are as follows: Define an ExtenstionPropertyType enumeration with the following types permitted: STRING DATE NUMBER BOOLEAN The following methods as well: Class getType(): The underlying Java type used to represent the type Object convertFromString(String aValue): Converts a value from a string to the underlying Java type String convertToString(Object aValue): Converts a value to a string from the underlying Java type Define a ExtensionPropertyDefinition interface that describes the following attributes about a extension property: String getName(): The name of the property conforming to JavaBean standards (while we don’t support reflection, it’s a well known standard by Java developers …) ExtensionPropertyType getType(): The type of the property boolean isRequired(): Whether or not a value for the property is required boolean isCollected(): Whether or not the property’s value is a single value or collected (default to a list) SetString getConstraints: A list of the values that constrain the values of this extension property. ListString validate(Object aValue): A callback to validate a value for this property definition — returning a list of strings describing the validation errors. An empty list implies a valid value. An additional nicety for this interface would be to define a type which the definition would expect of the underlying value to be at runtime. Introduce an Extendable interface that indicates that a type can have its data extended with a set of key-value pairs. I would define the following methods: SetExtenstionPropertyDefinition getExtenstionPropertyDefinitions(): The set of extension property descriptions Object getExtensionPropertyValue(String aPropertyName): Get a value for an extension property ListString validateExtensionProperties(): Validates the values of the extension properties There are likely pieces I missed and refinements to improve this design — I jotted it down off the top of my head. However, we have to ensue that the semantic is rich enough to render friendly UIs, as well as, protect against GIGO (garbage in, garbage out). Finally, I would like to see the design expanded to explain when and where this information will pass into drivers for use. As the design stands now, it does not explain how the data would actually be used during operation. The scope of these changes is important to understand for both impact analysis and driver developers and implementors. Also, I don’t understand how the addition of generic key-values to drivers would eliminate tags. As I understand them, tags are used to establish valid combinations of drivers (e.g. mutual exclusion) to avoid defining an unimplementable infrastructure configuration. While I agree with the desire to eliminate them, I don’t understand how such a facility would contribute to that goal. Great work putting together an initial design, and getting this important conversation started. Thanks, -John On Jun 10, 2014, at 6:26 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Please feel free to review the following proposal for 4.5: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111 Here is the summary: Today the way you associate a Compute Offering (CO) or a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging. This has some benefits and drawbacks. One benefit is being able to have some level of vendor independence from the point of view of the CO or DO. For example, if the storage tag of a DO is Fast, then this
Re: Code Documentation
On Wed, Jun 11, 2014 at 9:58 PM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Hi All, Many of code areas under CS, currently don't have enough documentation i believe, we have few one liner comments at places. But, largely, was missing at various code areas. We in one of our earlier project, used to enforce strictly a template for comments\documentation for every new function added. These comments were later retrieved automatically to build code documentation easily. This gets enforced during review itself, or otherwise review wont be accepted. It will make the flow lot easier to understand some times i believe. Please add atleast basic description for every major interface\class\function, description for input\output arguments for individual entities. IMO we should prefer writing code so it documents itself and we save ourselves from maintaining both code and comments. Regards. EX: Currently, for below we dont have any comments in general. public boolean shutdownNetwork(final long networkId, ReservationContext context, boolean cleanupElements) Regards, Santhosh
RE: Unable to create a Template from ROOT Volume Snapshot
I'm using Apache CloudStack 4.2.0 and XenServer 6.0.2. Thank you, Suneel Mallela From: Venkata Suneel Babu Mallela Sent: Friday, June 13, 2014 11:31 AM To: us...@cloudstack.apache.org; dev@cloudstack.apache.org Subject: Unable to create a Template from ROOT Volume Snapshot Hi All, I tried to create a template from a ROOT volume snapshot and I got the following error Failed to create templatejava.io.FileNotFoundException: /mnt/SecStorage/*/template/tmpl/*/*/template.properties (No such file or directory) Please help me to resolve this problem. Thank you, Suneel Mallela
Re: [ACS44] CLOUDSTACK-6464
ok, please note discussions on 4.3.1 and my comment in it. The db upgrade solution will go in the alleged 4.3.1! I changed the bug to fix-version 4.4.0 but will put it back to 4.3.1. It is solved this way in the coming 4.4.0 as well. On Fri, Jun 13, 2014 at 2:54 PM, Simon Weller swel...@ena.com wrote: Daan, Thanks for following up. Both Marcus and Edison have been involved looking at this bug, and it appears to be related to what CS expects in the cloud.vlan table between releases. This issue affects both untagged networks and tagged networks in the same manner, and simply changing the vlan_id column data format seems to fix the problem. A couple of us (myself included) have tested a database fix and commented success in the issue notes. Since our testing, I haven't seen any comment on how this should be fixed permanently (either a database data change during upgrade, or code to support the older data format for original installs prior to 4.3). My preference would be a data change, as that's easier to maintain moving forward. I still think a note should be posted on 4.3, suggesting people to avoid it for KVM upgrades, or at the very least pointing them to this issue so they can updated the data format manually post upgrade, and prior to restarting their VRs. - Si From: Daan Hoogland daan.hoogl...@gmail.com Sent: Thursday, June 12, 2014 8:47 AM To: dev Subject: Re: [ACS44] CLOUDSTACK-6464 Simon, I found you in my spam box looking for my colleague, Hugo. Didn't find him there;) I guess you're request is no longer actual, The bug is, no doubt. Can you give an update on it? On Wed, May 14, 2014 at 1:00 AM, Simon Weller swel...@ena.com wrote: All, Could someone with knowledge of the KVM traffic label code take a look at https://issues.apache.org/jira/browse/CLOUDSTACK-6464? It appears egress traffic is broken currently when basic or advanced networking is in use with traffic labels on KVM. Daan, Could you change the tag for this to 4.4 from 4.3.1, and in my opinion this should be a blocker, as it completely breaks KVM VR networking. Thanks, - Si -- Daan -- Daan
DevCloud replacement
Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes … It works out of the box. Enjoy the week-end, -Sebastien
Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins
+1 to Johns first comment; I think we need it in a more generic way then for storage plugins. I am sure network providers/loadbalancers/firewalls need such properties as well. John, should we make your ExtensionPropertyType a generic and let the convert-methods deal with the parameter types instead of with Objects? greatings On Fri, Jun 13, 2014 at 4:38 PM, John Burwell jburw...@basho.com wrote: Mike, I completely agree with the need to attach driver-specified key-value pairs to a storage driver (we have been batting this around for nearly a year). However, I think this facility should be generalized to support all drivers (e.g. network, compute, etc) where storage maybe the first layer to implement it. For example, we have a raft of places where vendor specific data/concepts leak into the object model and schema. For example, in networking, we have vendor specific API calls. One of the main value propositions of a cloud platform is to provide a unified abstraction for underlying infrastructure components. Furthermore, requiring vendor implements to add API calls further increases the complexity and effort required to support CloudStack — discouraging their participation. In terms of the design of itself, I don’t feel that the MapString, String getPropertiesAndTypes is a rich enough semantic for such an extension facility. First, it does not provide a mechanism to validate that the form and content of the values being set. Second, it is incredible lose contract that does not exploit the Java compiler to ensure drivers are providing well-formed metadata to the CloudStack orchestration components. Finally, it does not support notions such as hinting which fields are required (very useful for creating useful UIs) and constrained values (rendered as drop downs). My thoughts are as follows: Define an ExtenstionPropertyType enumeration with the following types permitted: STRING DATE NUMBER BOOLEAN The following methods as well: Class getType(): The underlying Java type used to represent the type Object convertFromString(String aValue): Converts a value from a string to the underlying Java type String convertToString(Object aValue): Converts a value to a string from the underlying Java type Define a ExtensionPropertyDefinition interface that describes the following attributes about a extension property: String getName(): The name of the property conforming to JavaBean standards (while we don’t support reflection, it’s a well known standard by Java developers …) ExtensionPropertyType getType(): The type of the property boolean isRequired(): Whether or not a value for the property is required boolean isCollected(): Whether or not the property’s value is a single value or collected (default to a list) SetString getConstraints: A list of the values that constrain the values of this extension property. ListString validate(Object aValue): A callback to validate a value for this property definition — returning a list of strings describing the validation errors. An empty list implies a valid value. An additional nicety for this interface would be to define a type which the definition would expect of the underlying value to be at runtime. Introduce an Extendable interface that indicates that a type can have its data extended with a set of key-value pairs. I would define the following methods: SetExtenstionPropertyDefinition getExtenstionPropertyDefinitions(): The set of extension property descriptions Object getExtensionPropertyValue(String aPropertyName): Get a value for an extension property ListString validateExtensionProperties(): Validates the values of the extension properties There are likely pieces I missed and refinements to improve this design — I jotted it down off the top of my head. However, we have to ensue that the semantic is rich enough to render friendly UIs, as well as, protect against GIGO (garbage in, garbage out). Finally, I would like to see the design expanded to explain when and where this information will pass into drivers for use. As the design stands now, it does not explain how the data would actually be used during operation. The scope of these changes is important to understand for both impact analysis and driver developers and implementors. Also, I don’t understand how the addition of generic key-values to drivers would eliminate tags. As I understand them, tags are used to establish valid combinations of drivers (e.g. mutual exclusion) to avoid defining an unimplementable infrastructure configuration. While I agree with the desire to eliminate them, I don’t understand how such a facility would contribute to that goal. Great work putting together an initial design, and getting this important conversation started. Thanks, -John On Jun 10, 2014, at 6:26 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Please feel free to
Re: DevCloud replacement
Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes … It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins
Thanks for the detailed response, John! When Chris Suich (formerly from NetApp) and I talked about this several months ago, we were thinking that this would replace the need for storage tagging. However, as you point out, I now think it does not. We were originally figuring that by specifically selecting a vendor (by picking the applicable storage plug-in) that this removed the need for storage tagging, but I see now that you might still want to further refine within a given storage provider which primary storage CloudStack selects. That being the case, if the user selects a specific storage plug-in, that will be the first step in filtering and storage tagging will be the next. Once I update the design, maybe you can take a look at it again. I can include the new data types you listed. Thanks! On Fri, Jun 13, 2014 at 8:38 AM, John Burwell jburw...@basho.com wrote: Mike, I completely agree with the need to attach driver-specified key-value pairs to a storage driver (we have been batting this around for nearly a year). However, I think this facility should be generalized to support all drivers (e.g. network, compute, etc) where storage maybe the first layer to implement it. For example, we have a raft of places where vendor specific data/concepts leak into the object model and schema. For example, in networking, we have vendor specific API calls. One of the main value propositions of a cloud platform is to provide a unified abstraction for underlying infrastructure components. Furthermore, requiring vendor implements to add API calls further increases the complexity and effort required to support CloudStack — discouraging their participation. In terms of the design of itself, I don’t feel that the MapString, String getPropertiesAndTypes is a rich enough semantic for such an extension facility. First, it does not provide a mechanism to validate that the form and content of the values being set. Second, it is incredible lose contract that does not exploit the Java compiler to ensure drivers are providing well-formed metadata to the CloudStack orchestration components. Finally, it does not support notions such as hinting which fields are required (very useful for creating useful UIs) and constrained values (rendered as drop downs). My thoughts are as follows: - Define an ExtenstionPropertyType enumeration with the following types permitted: - STRING - DATE - NUMBER - BOOLEAN - The following methods as well: - Class getType(): The underlying Java type used to represent the type - Object convertFromString(String aValue): Converts a value from a string to the underlying Java type - String convertToString(Object aValue): Converts a value to a string from the underlying Java type - Define a ExtensionPropertyDefinition interface that describes the following attributes about a extension property: - String getName(): The name of the property conforming to JavaBean standards (while we don’t support reflection, it’s a well known standard by Java developers …) - ExtensionPropertyType getType(): The type of the property - boolean isRequired(): Whether or not a value for the property is required - boolean isCollected(): Whether or not the property’s value is a single value or collected (default to a list) - SetString getConstraints: A list of the values that constrain the values of this extension property. - ListString validate(Object aValue): A callback to validate a value for this property definition — returning a list of strings describing the validation errors. An empty list implies a valid value. An additional nicety for this interface would be to define a type which the definition would expect of the underlying value to be at runtime. - Introduce an Extendable interface that indicates that a type can have its data extended with a set of key-value pairs. I would define the following methods: - SetExtenstionPropertyDefinition getExtenstionPropertyDefinitions(): The set of extension property descriptions - Object getExtensionPropertyValue(String aPropertyName): Get a value for an extension property - ListString validateExtensionProperties(): Validates the values of the extension properties There are likely pieces I missed and refinements to improve this design — I jotted it down off the top of my head. However, we have to ensue that the semantic is rich enough to render friendly UIs, as well as, protect against GIGO (garbage in, garbage out). Finally, I would like to see the design expanded to explain when and where this information will pass into drivers for use. As the design stands now, it does not explain how the data would actually be used during operation. The scope of these
Creating BareMetal templates from vmid via API
Hello, Please forgive me for crossposting - I originally sent this to users, but then realized dev was probably a more appropriate mailing list. I am trying to create a BareMetal template based on vm id using the CloudStack API. The API documentations suggests that this should be possible by providing the virtual machine ID and a URL for template storage. However, this doesn't work; I followed the API documentation, provided the ostypeid, name, displaytext, virtualmachineid, and url, but I got this error message: “Failed to create private template record, neither volume ID nor snapshot ID were specified. ” So I took a look at the code, and while I did find the code which should support BareMetal template creation from vmid in the BareMetalPxeManager, it is not called from anywhere. The TemplateManager handles CreateTemplateCommands which specify either a volume or a snapshot, but doesn't deal with the BareMetal template creation in any way. Is this omission made intentionally? Is the API capable of handling creation of these templates in some other way, or should support for BareMetal templates be added to the TemplateManager? Regards, -- *Nera Nešić* Backend Developer Mobile: (+354) 782 1337 n...@greenqloud.com a...@greenqloud.com www.greenqloud.com
Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22554/
---
(Updated June 13, 2014, 4:53 p.m.)
Review request for cloudstack.
Changes
---
Updated diff with Santhosh's comments
Bugs: CLOUDSTACK-6909
https://issues.apache.org/jira/browse/CLOUDSTACK-6909
Repository: cloudstack-git
Description
---
Fix marvin's handling of details field for primary and secondary storage to
cope with SMB credentials. This allows Hyper-V to work.
Diffs (updated)
-
tools/marvin/marvin/deployDataCenter.py 22b78ab
Diff: https://reviews.apache.org/r/22554/diff/
Testing
---
Tested deploydataCenter with this JSON:
{
dbSvr:{
dbSvr:10.220.137.39,
passwd:cloud,
db:cloud,
port:3306,
user:cloud
},
zones:[
{
name:XenRT-Zone-0,
guestcidraddress:192.168.200.0/24,
dns1:10.220.160.11,
physical_networks:[
{
XRT_VLANRangeSize:10,
name:AdvPhyNetwork,
providers:[
{
broadcastdomainrange:ZONE,
name:VirtualRouter
},
{
broadcastdomainrange:ZONE,
name:VpcVirtualRouter
},
{
broadcastdomainrange:ZONE,
name:InternalLbVm
}
],
broadcastdomainrange:Zone,
vlan:3000-3009,
traffictypes:[
{
typ:Guest
},
{
typ:Management
},
{
typ:Public
}
],
isolationmethods:[
VLAN
]
}
],
ipranges:[
{
startip:10.220.164.0,
endip:10.220.164.9,
netmask:255.255.240.0,
XRT_GuestIPRangeSize:10,
gateway:10.220.160.1
}
],
networktype:Advanced,
pods:[
{
XRT_PodIPRangeSize:10,
name:XenRT-Zone-0-Pod-0,
endip:10.220.164.39,
startip:10.220.164.30,
netmask:255.255.240.0,
clusters:[
{
XRT_HyperVHostIds:0,
clustername:XenRT-Zone-0-Pod-0-Cluster-0,
hypervisor:hyperv,
primaryStorages:[
{
url:cifs://10.220.163.45/storage/primary,
name:XenRT-Zone-0-Pod-0-Primary-Store,
details:[
{
user:Administrator
},
{
password:xenroot01T
},
{
domain:XSQA
}
]
}
],
clustertype:CloudManaged,
hosts:[
{
url:http://10.220.163.45;,
username:root,
password:xenroot
}
],
XRT_Hosts:1
}
],
gateway:10.220.160.1
}
],
internaldns1:10.220.160.11,
secondaryStorages:[
{
url:cifs://10.220.163.45/storage/secondary,
details:{
domain:XSQA,
password:xenroot01T,
user:Administrator
},
provider:SMB
}
]
}
],
mgtSvr:[
{
mgtSvrIp:10.220.137.39,
passwd:xenroot,
port:8096,
user:root
}
]
}
Thanks,
John Dilley
Re: hackathon CCCEU14
Whatever I find company for, because sitting and working alone is what I can do anytime :-) On Fri, Jun 13, 2014 at 10:04 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: kocka, go ahead and edit (though you can't work on all of those subjects during the hackathon, hope you realize that) On Thu, Jun 12, 2014 at 7:46 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Hi, Could you give me write permission to the wiki? Or you can just add me to the wikipage, I will want to work a little bit on all of those :) Thank you, Laszlo On Tue, Jun 10, 2014 at 2:35 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Hello everybody, Do we still want to have a Hackathon next CCC? we need to plan for the resources (noticably the room) pretty soon. On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland dhoogl...@schubergphilis.com wrote: People, I added two more hackathon subjects at https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU In doing so I saw no moderators on the hackathons that were already announced. We need moderators to have successful hackathons. If you feel a hackathon subject is important enough to go through, please add your name in the wiki. Only hackathons with enough attendance will have resources assigned at the conference. \DaanH -- Daan -- EOF -- Daan -- EOF
Re: 2014-6-09 Japanese CloudStack Community Weekly Update
You guys are doing great work, simply amazing, please keep it up! On 6/8/14, 10:14 PM, Mayumi K wrote: Hi everyone Activities of Japanese CloudStack Community. ## Event [6/12] JCSUG will hold a Meet-up in Hokkaido [6/13] Interop Tokyo 2014 : JCSUG will have a session. http://www.interop.jp/2014/index2.html [6/14] OSC Hokkaido: JCSUG will have a session and booth. [6/22] July Tech Festa : JCSUG will have a session. http://2014.techfesta.jp/ [7/04] JCSUG will hold a Meet-up in Nagoya [7/05] OSC Nagoya: JCSUG will have a session and booth. [8/02] OSC Kansai@kyoto: JCSUG will have a session and booth. If you have any comment, please let ad...@cloudstack.jp know. Thanks, JCSUG (Japan CloudStack User Group) Mayumi Koshimizu (samem...@gmail.com) -- Web: http://cloudstack.jp Ustream http://www.ustream.tv/channel/cloudstackja Twitter: @cloudstackja Facebook: https://www.facebook.com/cloudstackjapan Admin ML: ad...@cloudstack.jp User ML: us...@cloudstack.jp
Re: DevCloud replacement
Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes … It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
Just out of interest. Is there any reason we don't use devcloud.sql to modify the service offerings and disk offerings to use local storage? On 13 June 2014 19:21, Ian Duffy i...@ianduffy.ie wrote: Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes … It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
On Fri, Jun 13, 2014 at 11:54 PM, Ian Duffy i...@ianduffy.ie wrote: Just out of interest. Is there any reason we don't use devcloud.sql to modify the service offerings and disk offerings to use local storage? I think we should do it, I used to do it myself (manually though). I was also thinking to change couple of default CloudStack global settings. For example, the local storage for systemvms to true -- these days any host would consist of 100+GBs primary storage. In previous decades/years, I could understand why people had dedicated secondary storages but now a typical host is capable of having terabytes of storage therefore we should allow systemvms to run on local storage by default among other things. Also, I think most of us have been setting them up (which is a pain) everytime we boot up ACS on a freshly deployed database. Regards. On 13 June 2014 19:21, Ian Duffy i...@ianduffy.ie wrote: Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Unable to start primary and secondary storage instances
Hello, I am trying to run the cloudstack (4.4), where the following are warnings shown, Unable to acquire lock on storage vm WARN [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) Exception while trying to start secondary storage vm java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is unreachable: Host 1: Unable to start instance due to Unable to acquire lock on VMTemplateStoragePool: 66 at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) INFO [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) Unable to start secondary storage vm for standby capacity, secStorageVm vm Id : 57, will recycle it and start a new one INFO [o.a.c.s.PremiumSecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) Primary secondary storage is not even started, wait until next turn INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-25:ctx-8555714b job-276/job-301) Remove job-301 Could some one help me on this.
Re: DevCloud replacement
Thanks for your work Ian, it's up and running, and I finally have a Xen vm/box to play with. Cheers. On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy i...@ianduffy.ie wrote: Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
Awesome! I'm still tweaking things here and there. For whatever reason my internet connection to S3 is very poor so I'm insuring that caching of templates on the host via vagrant-cachier works 100%. Will do out more in-depth documentation over the next 2 weeks. Will explain what makes up the boxes and how all the projects tie into each other. Still need to deliver on the two other designs 2 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/imduffy15/5662278724616192 On 13 June 2014 20:02, Rohit Yadav bhais...@apache.org wrote: Thanks for your work Ian, it's up and running, and I finally have a Xen vm/box to play with. Cheers. On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy i...@ianduffy.ie wrote: Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes … It works out of the box. Enjoy the week-end, -Sebastien -- Daan
Re: DevCloud replacement
Caching of templates would be great, looking forward to your work on rest of the designs. Cheers. On Sat, Jun 14, 2014 at 12:35 AM, Ian Duffy i...@ianduffy.ie wrote: Awesome! I'm still tweaking things here and there. For whatever reason my internet connection to S3 is very poor so I'm insuring that caching of templates on the host via vagrant-cachier works 100%. Will do out more in-depth documentation over the next 2 weeks. Will explain what makes up the boxes and how all the projects tie into each other. Still need to deliver on the two other designs 2 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/imduffy15/5662278724616192 On 13 June 2014 20:02, Rohit Yadav bhais...@apache.org wrote: Thanks for your work Ian, it's up and running, and I finally have a Xen vm/box to play with. Cheers. On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy i...@ianduffy.ie wrote: Hi Rohit, Thank you for the PR :) was meaning to add a section on the vagrant setup. I've recently extended some of it to use vagrant-cachier for caching the systemvm templates. On 13 June 2014 19:05, Rohit Yadav bhais...@apache.org wrote: I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1 I installed two vagrant plugins and now it has started to work :) Still under progress. Cheers. On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav bhais...@apache.org wrote: Hi Ian, I tried to launch using vagrant up and getting following errors related to librarian_chef and omnibus. I just followed the README file - cloned your repo, updated submodules (so they are cloned too) and did vagrant up. Before opening issue on JIRA, I thought I share it here. Here's the full log; $ vagrant up [21:48:22] Bringing machine 'management' up with 'virtualbox' provider... Bringing machine 'xenserver' up with 'virtualbox' provider... == management: Box 'chef/centos-6.5' could not be found. Attempting to find and install... management: Box Provider: virtualbox management: Box Version: = 0 == management: Loading metadata for box 'chef/centos-6.5' management: URL: https://vagrantcloud.com/chef/centos-6.5 == management: Adding box 'chef/centos-6.5' (v1.0.0) for provider: virtualbox management: Downloading: https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box == management: Successfully added box 'chef/centos-6.5' (v1.0.0) for 'virtualbox'! There are errors in the configuration of this machine. Please fix the following errors and try again: Vagrant: * Unknown configuration section 'librarian_chef'. * Unknown configuration section 'omnibus'. On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav bhais...@apache.org wrote: On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Sebastien and of course Ian, I will try. BUT i think the reason is that xcp is not well supported and devcloud is not based on xenserver but on xcp or even a vanilla (debian/ubuntu?) xen. So will we continue on Ians path or go back and fix devcloud? I think there is no point in supporting XCP, so we should continue with Ian's path and start using/testing ACS with xenserver ( or xenproject). Thanks Ian and Sebastien, trying it out now. The ttylinux image is also accessible here: http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd Cheers. On Fri, Jun 13, 2014 at 5:36 PM, sebgoa run...@gmail.com wrote: Hi folks, As you know I love Devcloud, but it has its pains and lately it got broken in 4.3, and I don't think it works with 4.4. So I encourage you to check out: https://github.com/imduffy15/GSoC-2014 This works out of the box. It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the hypervisor. You then build locally, 3306 is forwarded localhost, so it looks like your db is local. NAT routing is setup nicely. Devcloud cfg file used . You start bhaissab ttylinux image. It uses Chef recipes ... It works out of the box. Enjoy the week-end, -Sebastien -- Daan
CloudStack-3831
I have created a patch for CloudStack-3831, but unfortunately I am having an issue getting it submitted to the review board. Upon submission I get the following error: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /r/new/. Is there another way I can submit this to the review board?
[ACS44] CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary
Hi Daan, Please cherry-pick following commit from 4.4-forward. Thanks! commit 60e46293234cccea5d2bd31588123e65af3e9bad Author: Sheng Yang sheng.y...@citrix.com Date: Fri Jun 13 11:05:35 2014 -0700 CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary This new way would only enable IPv6 when VR is created in IPv6 shared network. Otherwise IPv6 sysctl options remain disable. --Sheng
Re: [ACS44] CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary
On Sat, Jun 14, 2014 at 1:08 AM, Sheng Yang sh...@yasker.org wrote: 60e46293234cccea5d2bd31588123e65af3e9bad is in -- Daan
Re: [DISCUSS] 4.3.1
David, this is very depending on the amount/nature of the upgrade code from 4.3.0 to 4.3.1 In the best case no extra upgrade code has to be written and the 4.3.0 to 4.4.0 code can be used. In the worst case a full set of conditional schema changes has to be created. I am not pessimistic, totally against my nature. regards, Daan On Thu, Jun 12, 2014 at 4:57 PM, David Nalley da...@gnsa.us wrote: And just as important - figuring out an upgrade strategy from 4.3.1 to 4.4.0 --David On Thu, Jun 12, 2014 at 10:24 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: not a cherry-pick but a upgrade data thingy: private void updateVlanUris(Connection conn) from Upgrade430to440.java should be implemented in Upgrade430to431.java (to be created) as well. On Thu, Jun 12, 2014 at 4:17 PM, sebgoa run...@gmail.com wrote: While we are talking about 4.4 I am game to RM a 4.3.1 , there has been several bug fixes since 4.3.0. Anybody interested, any suggestions of what would still need to be cherry picked ? https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 -Sebastien -- Daan -- Daan
