[DISCUSS] Cloudstack agent - standardized directory for plugin jars
Moving discussion from Jira ticket to dev list as suggested by Hugo. Request from Kawai-san: There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. Suggestion by Marcus: I'd actually defer to the guys who have been working on the packaging. It seems like it would be distribution specific, and handled by the startup scripts. The obvious solution to me would be to create a directory, say /usr/share/cloudstack-agent/plugins, and append that to the classpath in the init scripts so that the agent can see the plugins copied there. Maybe go a step further and make a symlink /etc/cloudstack/agent/plugins; easier for admins to find. Noa, Hugo and I are happy with that solution, but if anyone has any thoughts, please let us know. Thanks, Dave. On Wed, Mar 6, 2013 at 4:58 PM, Hugo Trippaers (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13594478#comment-13594478] Hugo Trippaers commented on CLOUDSTACK-1489: Good idea, but discuss these things on list so everybody is involved. cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2 Environment: Linux kvm Reporter: Hiroaki Kawai Assignee: Noa Resare There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request: Fix the integration scripts for nose import and ostypeid corrections
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9769/#review17466 --- Ship it! 9342f56 (master) Thanks - Prasanna Santhanam On March 6, 2013, 6:56 a.m., SrikanteswaraRao Talluri wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9769/ --- (Updated March 6, 2013, 6:56 a.m.) Review request for cloudstack and Prasanna Santhanam. Description --- Fix the integration scripts for nose import and ostypeid corrections from nose.plugins.attrib import attr ostype: 'CentOS 5.3 (64-bit)', template = get_template( cls.api_client, cls.zone.id, cls.services[ostype] ) This addresses bug CLOUDSTACK-1530. Diffs - test/integration/component/test_accounts.py d0b4434 test/integration/component/test_allocation_states.py 006f879 test/integration/component/test_blocker_bugs.py cc5da0a test/integration/component/test_egress_rules.py 73a91f4 test/integration/component/test_eip_elb.py 4c8dcbe test/integration/component/test_network_offering.py c1a518b test/integration/component/test_project_configs.py d5ce9d6 test/integration/component/test_project_limits.py 8f7c128 test/integration/component/test_project_resources.py 27452be test/integration/component/test_project_usage.py 4561576 test/integration/component/test_projects.py 811d092 test/integration/component/test_resource_limits.py cd007f1 test/integration/component/test_routers.py a65c5c3 test/integration/component/test_security_groups.py 13a87b6 test/integration/component/test_templates.py e9be63d test/integration/component/test_usage.py 34dbc37 test/integration/component/test_volumes.py 5819001 Diff: https://reviews.apache.org/r/9769/diff/ Testing --- done Thanks, SrikanteswaraRao Talluri
Re: unit tests guidelines...
On 03/06/2013 02:42 AM, Alex Huang wrote: With the discussion in the BVT thread and other evidence from the check-ins, I think there are some confusion on when to and what to write in a unit test. Unit tests are a philosophy thing and I usually stay away from things like that. If you are interested in writing the right type unit tests, here's my $.02. Thanks for your input! Writing good tests is indeed a challenge, but definitely worth it, although I'm not a guru-status yet. Wido Unit tests are for - Guaranteeing the component is upholding its contract. - Illustrating how the component is to be used. - Mocking up failure scenarios - Explaining something that people might not understand if they look inside your code. When to write a unit test: - Write it at the component level because that's where the value is. You can test everything under the sun but basically code changes all of the time. What you really want - Write it for an interface. For example, if you have AgentManager and AgentManagerImpl, the methods you should test is in AgentManager. And a lot of this goes back to your design. I have seen quite a bit of code that just adds all the methods from the class to the interface. It's just something you do rather than something you think before doing. That's just wrong and it increases the number of unit tests you have to write. These are usually what you need to test for when writing unit tests. - Errors in the incoming parameters...no duh! - Different positive paths for your code...to state the obvious. - The one that people don't seem to do is to inject results into the components that the component being tested is dependent on. This forces component being tested to travel a different path. Most people recognize incoming parameters causing a different path but does not recognize that results from the components being used can cause a different path. How to recognize a good unit test? - The mock objects do not always return true or positive result. - The unit test sets something for the mock object, test the method; sets something else for the mock objects and then test the method again. This means the tester is testing the component handling different returns from the components it is using. - The unit test makes a call to the component, and checks the mock object to see if certain things are called. White box testing there. - The unit test has asserts for catching exceptions or negative returns (negative paths are tested) - The unit test has comments that tell you what and why you're testing - The unit test asserts tells you why the assert should not fail - You won the blame game by saying look I have a test case for exactly that. Misconceptions about unit tests. - You only write it when you write the component. Actually, a good unit test is one that's progressively built up. You found a bug, you write a test to make sure the bug is fixed. If you've gotten to that stage, then you've pretty much reach guru status. --Alex
RE: Review Request: Two test cases from snapshots imporevement feature
Thanks for the comments David. I will add the ASF license header and test_concurrent_snapshot.py is not the intended one. I will remove it. Thanks, Sanjeev From: David Nalley [mailto:nore...@reviews.apache.org] On Behalf Of David Nalley Sent: Tuesday, March 05, 2013 10:49 PM To: Prasanna Santhanam Cc: cloudstack; Sanjeev Neelarapu; David Nalley Subject: Re: Review Request: Two test cases from snapshots imporevement feature This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9752/ First - thanks for working on tests!! It's something we need lots of. Both of these files are missing the ASF license header, please add that in. test/integration/component/test_concurrent_snapshot.pyhttps://reviews.apache.org/r/9752/diff/1/?file=266195#file266195line1 (Diff revision 1) None 1 test This doesn't look like valid python to me. Are you sure this is the intended content? - David On March 5th, 2013, 5:15 p.m., sanjeev n wrote: Review request for cloudstack and Prasanna Santhanam. By sanjeev n. Updated March 5, 2013, 5:15 p.m. Description Added two test cases for snapshots improvement feature. Testing Executed the tests in advanced zone setup. Diffs * test/integration/component/test_concurrent_snapshot.py (PRE-CREATION) * test/integration/component/test_snapshots_improvements.py (PRE-CREATION) View Diffhttps://reviews.apache.org/r/9752/diff/
Re: Using newer DIY SystemVMs
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
- template creation works
- snapshot to template works
I won't be able to test VPC/advance zone of DevCloud, ipv6 etc.
someone from QA would have to help.
Thanks Marcus for your suggestion, will compress qcow2 and test on KVM
today.
I need help on testing/fixing VMWare systemvm template appliance.
Ahmad :) all natural:
http://highlatencylife.files.wordpress.com/2010/12/awesomesauce.png
Regards.
PS. Was AFK yesterday, down with flu, much better now.
On Fri, Mar 1, 2013 at 11:29 PM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
On 3/1/13 4:03 AM, Rohit Yadav bhais...@apache.org wrote:
- Saw systemvms started from the template, saw patching happening,
logged in with creds (root/password) to verify that it was indeed the
new one (Linux 3.2 :)
- The agents were running fine, there was a latency issue (agents were
lagging behind)
- (Applied a fix describe on CLOUDSTACK-1370 to make the deployVM
work) VR came up, did it's SDN magic and tinyLinux was deployed
- Console proxy worked for me as well
I would also test
- password server
- user data management (is apache web server running?)
In addition
- zone-to-zone template copy
- template creation
- convert snapshot to template
- vpc
- ipv6
Chiradeep, is there a way to convert VHD (HyperV) to VHD (Xen), I hear
that they both differ in some magic bits?
Actually since we intend to support Windows 2012, we should be using
VHDX.
There's a way to do it with Powershell (from vhd(hyper-v) - vhdx)
http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/10/03/using-powershel
l-
to-convert-a-vhd-to-a-vhdx.aspx
Re: Review Request: CLOUDSTACK-1013 : running cloudstack overwrites default public/private ssh keys
On March 4, 2013, 7:38 a.m., Dave Cahill wrote: This looks good to me - and great to see someone is fixing it! One slightly strange edge case springs to mind - I think the behavior in this edge case is fine, but wanted to bring it up explicitly just in case: In KVM, if running management server as root, this will set /root/.ssh/id_rsa.pub.cloud and /root/.ssh/id_rsa.cloud on management server startup. If running on a single-node setup, the same machine (acting as host) will receive the keys and set /root/.ssh/id_rsa.pub.cloud and /root/.ssh/id_rsa.cloud again, to the same values. Again, I guess this is fine, but wanted to point out the filename clash. It can go wrong and overwrite the keys within the KVM agent. May be a different name will serve the purpose - something like id_rsa.devel instead of cloud since it affects only the developer environment? - Prasanna --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9727/#review17325 --- On March 4, 2013, 7:22 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9727/ --- (Updated March 4, 2013, 7:22 a.m.) Review request for cloudstack and Abhinandan Prateek. Description --- SSH keys overwritten for user running management server. Fix: Using non-default file names (id_rsa.cloud and id_rsa.pub.cloud) in developer mode. This addresses bug CLOUDSTACK-1013. Diffs - server/src/com/cloud/server/ConfigurationServerImpl.java c5ae1e2 Diff: https://reviews.apache.org/r/9727/diff/ Testing --- Tested locally Thanks, Harikrishna Patnala
Review Request: [CLOUDSTACK-1535] kvm agent will silently ignore many exceptions
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9774/ --- Review request for cloudstack. Description --- Current kvm agent will silently ignore many exception, and there's no way to see what really happened. This patch will log in trace level log that was silently ignored. And also, it will fix huge bare Exception catch, which is very harmful because it also catches RuntimeException. This addresses bug CLOUDSTACK-1535. Diffs - core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java fc7f08f plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHABase.java af89d9b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 3c848de plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtXMLParser.java 3a61403 Diff: https://reviews.apache.org/r/9774/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: (CLOUDSTACK-1475) update keystore in SSVM and change download iso/template url after Update SSL Certificate
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9696/ --- (Updated March 6, 2013, 10:06 a.m.) Review request for cloudstack, Nitin Mehta and Jayapal Reddy. Changes --- Can you guys help review this? The patch is for 4.0.1 but should be applicable for master too Description --- This patch is for issue CLOUD-1475 (RegisterISO error after Update SSL Certificate) on CloudStack 4.0.1. Changes include: (1) update realhostip.keystore in SSVM (see the change in config_ssl.sh) (2) change suffix of download iso/template url rom realhostip.com to domain_suffix in SSL Certificate. (3) validate download URL because ssvm publicip or domain suffix may change. This addresses bug CLOUD-1475. Diffs - agent/src/com/cloud/agent/resource/consoleproxy/ConsoleProxyResource.java 48f5079 console-proxy/scripts/config_ssl.sh 8d80c47 core/src/com/cloud/storage/resource/CifsSecondaryStorageResource.java c606fca core/src/com/cloud/storage/resource/NfsSecondaryStorageResource.java 155210d server/src/com/cloud/configuration/Config.java dbcc97a server/src/com/cloud/consoleproxy/AgentBasedConsoleProxyManager.java 01b4720 server/src/com/cloud/consoleproxy/AgentBasedStandaloneConsoleProxyManager.java 6172780 server/src/com/cloud/consoleproxy/StaticConsoleProxyManager.java d2df83c server/src/com/cloud/server/ConfigurationServerImpl.java 3368c9b server/src/com/cloud/storage/download/DownloadMonitorImpl.java 2736777 server/src/com/cloud/storage/upload/UploadMonitorImpl.java 4231be8 Diff: https://reviews.apache.org/r/9696/diff/ Testing --- Testing manually ok. We need to restart management-server after Update SSL Certificate Thanks, Wei Zhou
Re: [QA][DISCUSS] Should we document formal release criteria?
On Mar 5, 2013, at 2:18 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, Mar 5, 2013, at 01:14 PM, Chip Childers wrote: On Tue, Mar 05, 2013 at 11:11:51AM -0800, Alex Huang wrote: So in this definition, MAJOR and above must be fixed before a release is cut? Personally, I've used the no blockers and 5 critical with work arounds as the criteria, using the definitions I offered. How many Major bugs are acceptable? Currently we have 187. Even if they're not going to completely disrupt use of the platform, it seems to me that releasing with 100 major bugs is a bit much. Bit off-thread, but could we have a bug sprint ? Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: [DOCS] cloud monkey and friends docs
On Mar 6, 2013, at 12:08 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hi Sebastien, I am still updating the Developer guide. The latest patch https://reviews.apache.org/r/9726/ has updated the Dev Guide. Marcus marked it Ship it, and I am going to merge it right away. Would you be considering these changes for translation ? I will do an update of translation strings next week. If you can get all your writing done this week, that'd be awesome. -sebastien Regards -Radhika -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Wednesday, March 06, 2013 3:14 AM To: cloudstack-dev@incubator.apache.org Developers Subject: [DOCS] cloud monkey and friends docs Hi, I just closed CLOUDSTACK-825, cloud monkey docs. Committed to master and picked to 4.1 (as agreed). Please check staging area for the pdf I just built: http://people.apache.org/~sebgoa/Apache_CloudStack-4.0.0-incubating-Developers_Guide-en-US.pdf Don't worry about the version number on the file. Chapter 8 is brand new (chapter 7 as well) contains devcloud, marvin and cloud monkey preliminary docs. Please review, comment, file bugs. thanks, -sebastien
Re: Review Request: CLOUDSTACK-1013 : running cloudstack overwrites default public/private ssh keys
On March 4, 2013, 7:38 a.m., Dave Cahill wrote: This looks good to me - and great to see someone is fixing it! One slightly strange edge case springs to mind - I think the behavior in this edge case is fine, but wanted to bring it up explicitly just in case: In KVM, if running management server as root, this will set /root/.ssh/id_rsa.pub.cloud and /root/.ssh/id_rsa.cloud on management server startup. If running on a single-node setup, the same machine (acting as host) will receive the keys and set /root/.ssh/id_rsa.pub.cloud and /root/.ssh/id_rsa.cloud again, to the same values. Again, I guess this is fine, but wanted to point out the filename clash. Prasanna Santhanam wrote: It can go wrong and overwrite the keys within the KVM agent. May be a different name will serve the purpose - something like id_rsa.devel instead of cloud since it affects only the developer environment? It won't go wrong as it copies the same value on the same file. I think this name (.cloud) serves our purpose. - Harikrishna --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9727/#review17325 --- On March 4, 2013, 7:22 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9727/ --- (Updated March 4, 2013, 7:22 a.m.) Review request for cloudstack and Abhinandan Prateek. Description --- SSH keys overwritten for user running management server. Fix: Using non-default file names (id_rsa.cloud and id_rsa.pub.cloud) in developer mode. This addresses bug CLOUDSTACK-1013. Diffs - server/src/com/cloud/server/ConfigurationServerImpl.java c5ae1e2 Diff: https://reviews.apache.org/r/9727/diff/ Testing --- Tested locally Thanks, Harikrishna Patnala
Re: Review Request: take into account potential NFS timeouts when determining if xenheartbeat timeout value has been met.
On March 5, 2013, 8:47 a.m., Hugo Trippaers wrote: Ship It! Commit on master: e8b6f6658280f858e6c15a8b4e5ac4b74eff4490 - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9647/#review17390 --- On Feb. 27, 2013, 9:06 a.m., Brenn Oosterbaan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9647/ --- (Updated Feb. 27, 2013, 9:06 a.m.) Review request for cloudstack and Hugo Trippaers. Description --- In some storage failure scenario’s the NFS timeout can cause writing the heartbeat to take longer than expected. By comparing the last successful heartbeat epoch with the current epoch we check if the timeout value has been met. Diffs - scripts/vm/hypervisor/xenserver/xenheartbeat.sh 5edacf7 Diff: https://reviews.apache.org/r/9647/diff/ Testing --- Tested on hostxxx with an empty heartbeat file: Feb 26 21:54:13 hostxxx heartbeat: Problem with heartbeat, no iSCSI or NFS mount defined in /opt/xensource/bin/heartbeat! Tested on hostxxx with a 120 seconds timeout value by causing a storage failover (hits NFS timeout): Feb 26 08:04:15 hostxxx heartbeat: Potential problem with /var/run/sr-mount/d392d770-330b-bdbf-9c07-e1c38af81c6e/hb-faecefb3-9ac0-47a2-b0fb-ae383762ba13: not reachable since 18 seconds Feb 26 08:04:48 hostxxx heartbeat: Potential problem with /var/run/sr-mount/d392d770-330b-bdbf-9c07-e1c38af81c6e/hb-faecefb3-9ac0-47a2-b0fb-ae383762ba13: not reachable since 51 seconds Feb 26 08:05:20 hostxxx heartbeat: Potential problem with /var/run/sr-mount/d392d770-330b-bdbf-9c07-e1c38af81c6e/hb-faecefb3-9ac0-47a2-b0fb-ae383762ba13: not reachable since 83 seconds The storage failover stayed within the 120 seconds timeout value so no reboot Tested on hostxxx with a 120 second timeout by removing the storage altogether (hits NFS timeout): Feb 26 10:08:52 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 32 seconds Feb 26 10:09:24 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 64 seconds Feb 26 10:09:57 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 97 seconds Feb 26 10:10:29 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 129 seconds Feb 26 10:10:29 hostxxx heartbeat: Problem with /var/run/sr-mount/test/hb-test: not reachable since 129 seconds, rebooting system! Tested on hostxxx with a 120 second timeout by removing write rights on the storage (does not hit NFS timeout): Feb 26 10:22:13 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 5 seconds Feb 26 10:22:18 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 10 seconds Feb 26 10:22:23 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 15 seconds Feb 26 10:22:28 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 20 seconds Feb 26 10:22:33 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 25 seconds Feb 26 10:22:38 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 30 seconds Feb 26 10:22:43 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 35 seconds Feb 26 10:22:48 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 40 seconds Feb 26 10:22:53 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 45 seconds Feb 26 10:22:58 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 50 seconds Feb 26 10:23:03 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 55 seconds Feb 26 10:23:08 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 60 seconds Feb 26 10:23:13 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 65 seconds Feb 26 10:23:18 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 70 seconds Feb 26 10:23:23 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 75 seconds Feb 26 10:23:28 hostxxx heartbeat: Potential problem with /var/run/sr-mount/test/hb-test: not reachable since 80 seconds Feb 26 10:23:33 hostxxx heartbeat: Potential problem with
Re: Review Request: Feature SNMP Alerts support in CloudStack
On March 6, 2013, 5:57 a.m., Rajesh Battala wrote: plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/SnmpConstants2.java, line 2 https://reviews.apache.org/r/9587/diff/1/?file=261699#file261699line2 As SnmpConstants class is already available from Library, you can rename this to CS Specific Snmp Constants instead of using number will rename it to CloudStack specific - Anshul --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9587/#review17458 --- On March 6, 2013, 11:01 a.m., Anshul Gangwar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9587/ --- (Updated March 6, 2013, 11:01 a.m.) Review request for cloudstack and Rajesh Battala. Description --- This patch implements the SNMP Alerts support in CloudStack. With this feature one can configure log4j-cloud.xml to get the SNMP alerts. This feature uses the snmp4j library with Apache License. This feature is implemented by extending log4j Appeneder. Multiple SNMP Managers can be specified. To configure multiple SNMP Managers one needs to modify following portion in log4j-cloud.xml appender name=SNMP class=org.apache.cloudstack.alert.snmp.SnmpTrapAppender param name=Threshold value=WARN/ param name=SnmpManagerIpAddresses value=/ param name=SnmpManagerPorts value=/ param name=SnmpManagerCommunities value=/ layout class=org.apache.cloudstack.alert.snmp.SnmpEnhancedPatternLayout param name=PairDelimeter value=/// param name=KeyValueDelimeter value=::/ /layout /appender To specify multiple SnmpManagerIpAddresses one has to give as follows with each SNMP Manager separated by , appender name=SNMP class=org.apache.cloudstack.alert.snmp.SnmpTrapAppender param name=Threshold value=WARN/ param name=SnmpManagerIpAddresses value=10.1.1.1,10.1.1.2/ param name=SnmpManagerPorts value=162,162/ param name=SnmpManagerCommunities value=public,public/ layout class=org.apache.cloudstack.alert.snmp.SnmpEnhancedPatternLayout param name=PairDelimeter value=/// param name=KeyValueDelimeter value=::/ /layout /appender This patch also resolves the bug https://issues.apache.org/jira/browse/CLOUDSTACK-960 This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-680. Diffs - client/pom.xml cda6ab8 client/tomcatconf/log4j-cloud.xml.in 0866693 core/src/com/cloud/alert/AlertManager.java a24e18c plugins/alert-handlers/snmp-alerts/pom.xml PRE-CREATION plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/CsSnmpConstants.java PRE-CREATION plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/SnmpEnhancedPatternLayout.java PRE-CREATION plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/SnmpHelper.java PRE-CREATION plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/SnmpTrapAppender.java PRE-CREATION plugins/alert-handlers/snmp-alerts/src/org/apache/cloudstack/alert/snmp/SnmpTrapInfo.java PRE-CREATION plugins/alert-handlers/snmp-alerts/test/org/apache/cloudstack/alert/snmp/SnmpEnhancedPatternLayoutTest.java PRE-CREATION plugins/alert-handlers/snmp-alerts/test/org/apache/cloudstack/alert/snmp/SnmpTrapAppenderTest.java PRE-CREATION plugins/pom.xml 88f617b server/src/com/cloud/alert/AlertManagerImpl.java f8a8fd8 usage/src/com/cloud/usage/UsageAlertManagerImpl.java a0765b2 Diff: https://reviews.apache.org/r/9587/diff/ Testing --- 9 unit tests have been written to test the functionality. Manually tested alert generation for few alerts. Thanks, Anshul Gangwar
Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/ --- Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den Hollander, and Noa Resare. Description --- Initial issue was cloudstack-awsapi is not installing along with MS and then webapps7080 folder is missing on the management server. Solution: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. Moved the post awsapi section to the post management since it was trying to provide symb link before installing management server. Diffs - packaging/centos63/cloud.spec 1ef35414dfd87c5ac04ce83b09aa1e409f1702e7 Diff: https://reviews.apache.org/r/9776/diff/ Testing --- Tested with the new build + packaging Thanks, Pradeep Soundararajan
Review Request: Minor cloudmonkey cosmetics patch for 4.1 branch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9778/ --- Review request for cloudstack and Chip Childers. Description --- A minor cosmetics patch for cloudmonkey for 4.1 Diffs - tools/cli/cloudmonkey/cloudmonkey.py b5b185f tools/cli/cloudmonkey/config.py 5dfe09b Diff: https://reviews.apache.org/r/9778/diff/ Testing --- Thanks, Rohit Yadav
Re: Building on Cloudstack
On Mar 6, 2013, at 12:50 AM, Seif Eddine Jemli seifeddineje...@gmail.com wrote: You asked me about the scheduler i would like to implement. In fact, i have a school project: i have to divide matrix calculus on several VM's, the VM's have to calculate then return the results to the scheduler for aggregation. The scheduler have then to send the aggregated results to the user who typed the matrices. so the scheduler: * * *-have to contact cloudstack and ask for X number of VM's* *-then the vm's get work assigned to them crunch the work and return the results to the scheduler for aggregation* * * * * what do you think of this project? Is it feasible? Seif, yes this is definitely feasible but the parallelizing of tasks is not provided by CloudStack. What you should do: 1-Deploy CloudStack so you have a cloud 2-Prepare a template that has the batch scheduler that you want and the parallel libraries needed (e.g MPI) 3-Launch several VMs via CloudStack using the prepared template. 4-Access the head node of your virtual cluster (that you just started) and submit your parallel job Again CloudStack won't help with the actual parallelizing, that's not what it's made for. If you wanted an optimized VM instance, for true HPC, you would need to set it up on hypervisors with PCI passthrough, some type of low latency network like infiniband. In addition you could have GPU instances (like on Amazon), if you had GPUs on your hardware. Hope that helps, -sebastien Thanks in advance for your help.
[ACS41][ACS42][QA] Current Blockers - 3/6
CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
Re: Building on Cloudstack
On Mar 5, 2013, at 4:31 PM, Serge A. Salamanka salsa-...@tut.by wrote: Hi, Alex I've joined the list couple days ago. Interested in this same feature. At the supercomputing center where I work we have lots of computing power that could be used as a virtual supercomputer through virtualization with CloudStack. I'm just thinking how it can be realized with the help of CloudStack. I guess Seif is doing something similar? I found an article [1] that explains pretty much all that I wish to do with CloudStack for that purpose. Regards, Serge [1] http://sebgoa.blogspot.com/2012/11/i-was-asked-other-day-what-was.html Hi Serge, I wrote that blog. Yes it can be done, I am not aware of a large scale deployment for HPC purposes yet, however I don't foresee any huge obstacles. The biggest issue is to make CloudStack play nicely with your current infrastructure, especially if you want to keep traditional jobs running at the same time than having VMs running on the hosts. Im my previous job what we had done, is write a simple batch job that would get nodes from the scheduler, then once we would get the nodes we would run the cloud agent to basically build a cloud-infrastructure on top of the existing supercomputer. The cloud would just appear has a regular HPC job and be destroyed once the wall time expires. The issue tends to be with the networking, you may want to setup a specific VLAN for you transient cloud. If you don't need to multiplex regular hpc jobs and VMs then things gets easier. Just build a CloudStack cloud, and setup your HPC cluster via templates. One template for a head node and one template for the compute nodes. Put MPI or whatever libraries you need and your are up. -sebastien On 06.03.2013 00:20, Alex Huang wrote: Seif, What is the function of your scheduler? Can you go into it a little more? Thanks. --Alex -Original Message- From: Seif Eddine Jemli [mailto:seifeddineje...@gmail.com] Sent: Tuesday, March 5, 2013 12:36 PM To: cloudstack-dev@incubator.apache.org Subject: Building on Cloudstack Hi, I am working on a project using Cloudstack. I'll need to implement a scheduler to control the virtual machines generated by Cloudstack. (in fact, the project is about parallel calculus on different virtual machines). So, it seems that i have to use the Cloudstack API. i wanted to ask for some tips for my project. any volunteers? :) thanks in advance.
Re: [PROPOSAL] BVT for CloudStack checkins
Great to see you kick this off Alex! I have a few ideas for this and had been looking for help as well .. I had a draft lying around of an email you sent me long ago about tiered testing and I think your proposal fits very well on this: The tl;dr of that conversation was as below - improve simulator for runtime testability - customize to model and inject failures - make a habit of writing tests around bug reports (I started tagging tests since api_refactoring on JIRA already. look for the integration-test label) - make integration testing easier using factories and DSLs (from Chiradeep) (part 1 of this work was started on this in the marvin-refactor branch) More comments inline On Wed, Mar 06, 2013 at 12:12:11AM +0530, Alex Huang wrote: Hi All, As most of you are aware, the master branch keeps getting broken by checkins for various reasons. Committers need to be more responsible about their checkins but I don't think we can depend on that happening. There are various reasons. The most obvious to me is that granting committership is not based on code competency. (And I don't think it should.) Given that we need to build a BVT system for ensure that checkins do not break the branch. Here's my proposal: Existing components that we'll use. - Citrix has contributed its testing to Apache. - Apache CloudStack has already a simulator that's been used for scale testing. - Marvin - DevCloud-kvm Work Proposal: - Convert the Citrix testing into three phases: o Setup o Test o Verify I do the build, package, setup, test, verify in my integration test pipeline and a similar pipeline for a developer combined into easily runnable maven profiles/lifecycles/goals would be great to have. - Add a Setup and Verify phase for the simulator - Add all of the agent commands necessary for the simulator to pass the testing. - Add a Setup and Verify phase for devCloud-kvm The setups exists as configs in the marvin sandbox already. Just need to hook it up with mvn. For verify there is a simple python script testSetupSuccess.py already that checks two things - system VMs are up - built-in templates are downloaded This should be a good start IMO. Currently devcloud-kvm is a bit hard to run from a developer environment. But it's great to have in a continuous environment backed by a KVM host with a Linux 3.0 kernel. Marcus has written up some pretty good documentation for this. If someone can help bring up that setup I can assist in bringing up the tests using my devcloud-ci scripts. I'm bringing up devcloud after Kelven 'alerted' us of the memory fix. - Add two more profiles to pom o Checkin-test-with-simulator: Runs the testing against the simulator o Checkin-test-with-devCloud: Runs the testing against devcloud - All of the profiles will attempt to also check the merge list that Chip has proposed.' - We will also change marvin to easily add zones with actual hardware. It will be based on a data driven document to do the setup. This is currently partly doable using a properties file in the sandbox $ python advanced_env.py -i xen.properties -o xen.cfg gives out a advanced zone config for the properties specified. Is data driven similar or you are talking about a DSL that Edison mentioned at CCC12? For a developer to checkin: - S/he must writes marvin tests for their feature and add it to the BVT. I made some progress on this in my marvin-refactor branch and will collect my thoughts in an FS that I am drafting. The marvin tests are difficult to write in their current form. I'm following Chiradeep's recommendation for providing factories and once those are baked a DSL language devs can quickly mock down tests against a simulator using the above mentioned mvn profiles. - S/he must run the checkin tests to verify everything works. - If the feature contains a hardware/vpx component, simulation must be added. At this point, everything is about the developer writing in their feature branch and merging in. On infrastructure side: - We'll setup continuous BVT based on the simulator. I brought this up on the IRC and the list y'day, so +1 - happy to help - I again push that we must use Gerrit to test the code before it gets merge into the branch but I'll leave that for someone else to do that. Let me know what you guys think. I'll probably break out a bvt branch to work on this. Anyone want to join me? Count me in! -- Prasanna.,
Review Request: CLOUDSTACK-1453: support restore for VM created from ISO
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9779/ --- Review request for cloudstack, Nitin Mehta and Koushik Das. Description --- CLOUDSTACK-1453: support restore for VM created from ISO Previously this was not there. Fixed with small changes This addresses bug CLOUDSTACK-1453. Diffs - api/src/org/apache/cloudstack/api/command/user/vm/RestoreVMCmd.java 9c33f97 server/src/com/cloud/vm/UserVmManagerImpl.java ca9c13f Diff: https://reviews.apache.org/r/9779/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/#review17472 --- But awsapi should be an optional component to install, right? - Prasanna Santhanam On March 6, 2013, 11:58 a.m., Pradeep Soundararajan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/ --- (Updated March 6, 2013, 11:58 a.m.) Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den Hollander, and Noa Resare. Description --- Initial issue was cloudstack-awsapi is not installing along with MS and then webapps7080 folder is missing on the management server. Solution: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. Moved the post awsapi section to the post management since it was trying to provide symb link before installing management server. Diffs - packaging/centos63/cloud.spec 1ef35414dfd87c5ac04ce83b09aa1e409f1702e7 Diff: https://reviews.apache.org/r/9776/diff/ Testing --- Tested with the new build + packaging Thanks, Pradeep Soundararajan
Review Request: CLOUDSTACK-1417 bugfix for 4.1 branch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9780/ --- Review request for cloudstack and Chip Childers. Description --- Cosmetic fix for CLOUDSTACK-1417 to log param name alongwith value for the param causing error while translation uuid to internal id. Tested and patch applies smoothly on current 4.1 This addresses bug CLOUDSTACK-1417. Diffs - server/src/com/cloud/api/ApiDispatcher.java 552dea5 Diff: https://reviews.apache.org/r/9780/diff/ Testing --- Thanks, Rohit Yadav
Re: Review Request: CLOUDSTACK-465 - French language file quotes are dropping javascript syntax errors (after login)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9762/#review17473 --- Ship it! Tested on 4.1. Committed to master: 38aec6fc4d490f9aecaf9dd56116f45cd1eb60ed committed to 4.1: 5807635533261adbb8fad98201caf5c2b7ba5df7 Can you close the review as submitted. Thanks for the patch, if you feel like helping with the japanese/russian/chinese UI as well, please do :) - Sebastien Goasguen On March 5, 2013, 11:03 p.m., Milamber ASF wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9762/ --- (Updated March 5, 2013, 11:03 p.m.) Review request for cloudstack and Sebastien Goasguen. Description --- Currently the 4.1 branch (and 4.0.1 too) doesn't works with the French version of UI. See: https://issues.apache.org/jira/browse/CLOUDSTACK-465 With this patch, I download the current transifex resource file for French, and put in 4.1 branch, and accomplish this tasks: * Replace all quote ' by \\' * Fix some incompatibles chars in UTF-8 iconv: illegal input sequence at position 15910 iconv: illegal input sequence at position 17789 iconv: illegal input sequence at position 46774 iconv: illegal input sequence at position 72127 * changes charset from UTF-8 to ISO-8859-1 via iconv iconv -f UTF-8 -t ISO-8859-1 messages_fr_FR.properties_UTF8 messages_fr_FR.properties * Transform ISO-8859-1 charset to ASCII with I18NEdit and re-order keys/values with alphabetical order * Re-add Apache License v2 Please note, this patch leaves an issue with pre-completed field like in the login page, the value Username in field login shows Nom d\'utilisateur After apply this patch, French version works on 4.1 branch This addresses bug 465. Diffs - client/WEB-INF/classes/resources/messages_fr_FR.properties e29d61b Diff: https://reviews.apache.org/r/9762/diff/ Testing --- Thanks, Milamber ASF
Re: Review Request: AWS Style HealthCheck feature BugID : 664
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9165/#review17454
---
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37046
Check for the the HealthCheck Policy TO object's revoke flag instead of
passing null for health check policy. Because it might mean 2 things, either
policy is not present or have to be removed.
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37045
This will cause failure for lb vservers which does not have monitors.
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37047
You could use getMonitorIfExisits() != null
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37048
No need to check for this exception!
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37049
No need to check for this exception
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37050
Checking state for each service, is expensive. Please use
lbvserver_service_binding resource for querying all the service bindings of a
lbvserver and then check for curState property on each binding. Please NOTE:
the NetScaler doc wrongly claims it as LB state
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37051
This exception not required to be checked
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37052
You might not be required to do the delete twice. Just check by setting
resp_code to null and it should work
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37053
exception check not required
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
https://reviews.apache.org/r/9165/#comment37029
Looks like the monitor name conflicts with AutoScale Monitor! Check
generateAutoScaleVmGroupIdentifier()
server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java
https://reviews.apache.org/r/9165/#comment37026
I guess it has to be !isAutoScaleConfig(). Or it has to be ignored inside
NetScaler Resource!
server/src/com/cloud/network/dao/LBHealthCheckPolicyDaoImpl.java
https://reviews.apache.org/r/9165/#comment37062
You might want to remove this if not used!
server/src/com/cloud/network/dao/LBHealthCheckPolicyDaoImpl.java
https://reviews.apache.org/r/9165/#comment37054
Looks like an unused public function
server/src/com/cloud/network/lb/LBHealthCheckManagerImpl.java
https://reviews.apache.org/r/9165/#comment37056
Might not be required to set it to 600.
server/src/com/cloud/network/lb/LBHealthCheckManagerImpl.java
https://reviews.apache.org/r/9165/#comment37057
why DB?
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37058
Is there a genuine requirement to suppress rawtypes?
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37037
lbRule object created here does not seemed to be used?
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37039
no DB annotation?
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37040
Typo: Only health check is removed!
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37059
Please give a code comment that this function is primary function which
collects the status of all service VMs for all LBs
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
https://reviews.apache.org/r/9165/#comment37061
Please avoid checking NetScaler provider here. I understand you want to do
some optimization but you could better structure it. You can use the Capability
infrastructure already available.
Basically, you need to introduce a new Lb Capability. It will be in
Network.java = Capability.HealthCheck.
Here it will be
nwElmnt = _networkMgr.getElementForServiceInNetwork(network, Service.Lb)
if(nwElmnt.getCapabalities().get(Service.Lb).get(Capability.Health).equals(true))
{
// Here is the code for
Re: Review Request: multiple ip address per nic changes for basic zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9730/ --- (Updated March 6, 2013, 12:45 p.m.) Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and anthony xu. Changes --- updated patch minor chagnes Description --- In this patch changes are made for the basic zone and security groups This addresses bug cloudstack-24. Diffs (updated) - api/src/com/cloud/agent/api/SecurityGroupRulesCmd.java affad1f api/src/com/cloud/agent/api/to/NicTO.java aa2aa19 api/src/com/cloud/network/security/SecurityGroupService.java c648032 api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 0f99274 api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java cb5e085 core/src/com/cloud/agent/api/NetworkRulesVmSecondaryIpCommand.java PRE-CREATION plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java 4a89806 scripts/vm/hypervisor/xenserver/vmops db6f6d6 server/src/com/cloud/hypervisor/HypervisorGuruBase.java efe9396 server/src/com/cloud/network/NetworkManager.java 8b6bf9a server/src/com/cloud/network/NetworkManagerImpl.java ba5ab5d server/src/com/cloud/network/NetworkModelImpl.java e83c0d2 server/src/com/cloud/network/NetworkServiceImpl.java 821aa6d server/src/com/cloud/network/dao/IPAddressDao.java 1052639 server/src/com/cloud/network/dao/IPAddressDaoImpl.java b0eef4f server/src/com/cloud/network/guru/DirectNetworkGuru.java 46a525e server/src/com/cloud/network/security/SecurityGroupManagerImpl.java eafe88e server/src/com/cloud/network/security/SecurityGroupManagerImpl2.java a3a0fc3 server/src/com/cloud/vm/UserVmManagerImpl.java ca9c13f server/src/com/cloud/vm/dao/NicDao.java 794bacc server/src/com/cloud/vm/dao/NicDaoImpl.java 4491174 server/test/com/cloud/network/MockNetworkManagerImpl.java 8004310 server/test/com/cloud/vpc/MockNetworkManagerImpl.java 63ef874 Diff: https://reviews.apache.org/r/9730/diff/ Testing --- Unit Tests done: 1. adding a secondary ip to nic 2. remove ip from nic 3. reaching public network from the VM. 4. security groups changes for the secondary ip are done. Thanks, Jayapal Reddy
Database diversions for minor releases?
Sudha, CLOUDSTACK-1515 is related to packaging, pl. see the comments on the issue. My only concern is that people who have installed 4.0.1 and I don't know how the packaging was done for 4.1: Was the @VERSION@ in create-schema == 4.1? We need to have an empty upgrade path from 4.0 to 4.0.1 to 4.1 rightnow for 4.1 release. The question I want to ask everyone: - Do we change db version for minor releases, or stick with its parent? - How we do upgrades for minor releases? Regards. On Wed, Mar 6, 2013 at 5:39 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
RE: [QA][DISCUSS] Should we document formal release criteria?
We are already in defect fix mode right?? ( even though blockers took longer time to get resolved which prevented QA to make good progress) Now we are getting features blockers but not QA blockers i.e only few feature validation is blocked but QA is making progress on rest of features. -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Wednesday, March 06, 2013 2:15 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [QA][DISCUSS] Should we document formal release criteria? On Mar 5, 2013, at 2:18 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, Mar 5, 2013, at 01:14 PM, Chip Childers wrote: On Tue, Mar 05, 2013 at 11:11:51AM -0800, Alex Huang wrote: So in this definition, MAJOR and above must be fixed before a release is cut? Personally, I've used the no blockers and 5 critical with work arounds as the criteria, using the definitions I offered. How many Major bugs are acceptable? Currently we have 187. Even if they're not going to completely disrupt use of the platform, it seems to me that releasing with 100 major bugs is a bit much. Bit off-thread, but could we have a bug sprint ? Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain
Thanks Alex for the comments. Sure I will get in touch with Prachi regarding this. -Original Message- From: Alex Huang Sent: Tuesday, March 05, 2013 5:50 AM To: cloudstack-dev@incubator.apache.org Cc: Deepti Dohare; Prachi Damle Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain Deepti, I have read through the update. I have the following comments. You can talk with Prachi further because she's restricting the planning process. You can talk to Brian about pluggable UIs. For the Service Offering: - The SO flag should just be a set of name/value pairs. Of which implicit dedicate is one such key. Planner Plugins should just set their own name/value pairs. - On creation of the SO, the admin should be able to specify the Planner to use for a SO. At that time, the planner is called with its pluggable UI to set the above name/value pair. Then, this planner along with the name/value pair is passed to deploy vm. - With that then there should be no is_dedicated column added to the service-offering table. - There's also no isdedicated flag on the createserviceoffering call. This means the service offering can be compose by other calls rather than always by the create service offering call. The problem with having it in the create service offering call is that now you've binded the create service offering call to the dedication and no one can remove it as a plugin. For the Implicit Dedication: - I don't see any mention of monitoring for the administrator. So if the implicit pool is close to capacity, how would an administrator know? Is there any type of alert? For the feature to work with different hypervisors: - I don't see any talks about what if the hypervisor native HA and DRS is on. This is a problem especially for vmware. Do we work with this? If we don't, how do we disable? If we do, how can we work with it? - Also, what if someone migrates the VM outside of cloudstack, then what happens? - I talked about being able to find a VM through VM sync that the VM has moved to a host that doesn't match the condition and alert the admin user. Has this been discussed and decided against? If it is against, how to we deal with the above cases? Thanks. --Alex -Original Message- From: Deepti Dohare [mailto:deepti.doh...@citrix.com] Sent: Thursday, February 28, 2013 3:25 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain Hi all, The feature Dedicated Resources Private pod, cluster and host is updated with some changes. Here is the updated FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dedicated+Reso urces+-+Private+pod%2C+cluster%2C+host+Functional+Spec Overview of updates to the feature requirement: 1. Implicit Dedication: Admin can implicitly dedicate resources. Implicit dedication can be for a zone/pod/cluster/host, but not associated with any domain or account. 2. A new flag in Service Offering, will indicate whether implicit dedication is required or not. 3. Explicit Dedication: Admin will explicitly dedicate resources to domain/account. 4. A new parameter in deployVirtulMachine API will indicate whether to use explicitly dedicated resources or not. So I am planning to add a new planner that will process dedication and modify existing planners/allocators to make sure dedicated-resources will not be used if any of the above flag is not specified. Any thoughts/comments? Thanks, Deepti -Original Message- From: Hari Kannan [mailto:hari.kan...@citrix.com] Sent: Thursday, January 24, 2013 12:23 PM To: cloudstack-dev@incubator.apache.org; Kiran Koneti Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain Deepti, Regarding, no.5, I concur with your statement. However, we also assume that this scenario would not arise i.e. theoretically, in a cloud, a service provider always has capacity i.e. request for a VM should not fail, unless there are any specific conditions attached (such as request with a tag and there is no host that has that tag available etc.) Hari -Original Message- From: Deepti Dohare [mailto:deepti.doh...@citrix.com] Sent: Wednesday, January 23, 2013 9:44 PM To: Kiran Koneti Cc: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain Hi Kiran, See my comments inline. Thanks Deepti -Original Message- From: Kiran Koneti Sent: Wednesday, January 23, 2013 3:16 PM To: Deepti Dohare Cc: cloudstack-dev@incubator.apache.org Subject: Regarding the Dedicated Resources - Private pod, cluster, host Functional Spec . Hi Deepti , I have gone through the FS located in the below location and have
Re: [DOCS][TRANSLATION] Update
On Mar 5, 2013, at 8:27 AM, Sebastien Goasguen run...@gmail.com wrote: On Mar 5, 2013, at 8:27 AM, Milamber milam...@apache.org wrote: Hello, Please note: currently the 4.1 branch (and 4.0.1 too) doesn't works with the French version of UI. See: https://issues.apache.org/jira/browse/CLOUDSTACK-465 If I download the current transifex resource file for French, and put in 4.1 branch, I must : * Replace all quote ' by \\' * Fix some incompatibles chars in UTF-8 iconv: illegal input sequence at position 15910 iconv: illegal input sequence at position 17789 iconv: illegal input sequence at position 46774 iconv: illegal input sequence at position 72127 * changes charset from UTF-8 to ISO-88-59-1 via iconv iconv -f UTF-8 -t ISO-8859-1 messages_fr_FR.properties_UTF8 messages_fr_FR.properties * (An optional point:) Transform ISO-8859-1 charset to ASCII with I18NEdit (and order keys/values) I've put the modified file that works with 4.1 branch : https://issues.apache.org/jira/secure/attachment/12572089/messages_fr_FR.properties Milamber Hi, thanks. I am actually looking at this and I noticed the problem, we have issues with other languages as well. will get it fixed, thanks a lot. -sebastien Milamber, thanks for the review/patch. This was applied, I shipped the review and closed the ticket CLOUDSTACK-465 (which I assigned to you retroactively). -sebastien Le 02/03/2013 13:17, Milamber a ecrit : Hello, I've translate last sentences/words for French translation on Transifex for Cloudstack UI. I've made a full review of all elements (fixed some typo, translate some words in sentences, etc.) You can make a update of resources files. Milamber Le 23/02/2013 20:32, Sebastien Goasguen a ecrit : Hi, Quick update on translation. We had a complete translation of the runbook in Italian. Awesome ! Things are progressing, but I would like everyone to forward this tutorial: http://www.slideshare.net/sebastiengoasguen/how-to-translate-apache-cloudstack-docs To your friends and colleagues who speak something else than english. Our friends in China and Japan especially have a chance to finish the complete translation before 4.1, this would be huge. Since the complete translation is a lot of work, some of you may want to focus on the runbook and the UI. It's shorter. Keep a it !!! Cheers, -Sebastien
RE: Database diversions for minor releases?
So far we did not see any difference in minor version Vs Major version upgrades. Both work the same way. -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Wednesday, March 06, 2013 4:46 AM To: cloudstack-dev@incubator.apache.org Subject: Database diversions for minor releases? Sudha, CLOUDSTACK-1515 is related to packaging, pl. see the comments on the issue. My only concern is that people who have installed 4.0.1 and I don't know how the packaging was done for 4.1: Was the @VERSION@ in create-schema == 4.1? We need to have an empty upgrade path from 4.0 to 4.0.1 to 4.1 rightnow for 4.1 release. The question I want to ask everyone: - Do we change db version for minor releases, or stick with its parent? - How we do upgrades for minor releases? Regards. On Wed, Mar 6, 2013 at 5:39 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
Re: Database diversions for minor releases?
Can you help test upgrade scenario from 4.0.1 to 4.1? Regards. On Wed, Mar 6, 2013 at 6:24 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: So far we did not see any difference in minor version Vs Major version upgrades. Both work the same way. -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Wednesday, March 06, 2013 4:46 AM To: cloudstack-dev@incubator.apache.org Subject: Database diversions for minor releases? Sudha, CLOUDSTACK-1515 is related to packaging, pl. see the comments on the issue. My only concern is that people who have installed 4.0.1 and I don't know how the packaging was done for 4.1: Was the @VERSION@ in create-schema == 4.1? We need to have an empty upgrade path from 4.0 to 4.0.1 to 4.1 rightnow for 4.1 release. The question I want to ask everyone: - Do we change db version for minor releases, or stick with its parent? - How we do upgrades for minor releases? Regards. On Wed, Mar 6, 2013 at 5:39 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
RE: Database diversions for minor releases?
Yeah - let me get the packaging change done -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Wednesday, March 06, 2013 5:15 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Database diversions for minor releases? Can you help test upgrade scenario from 4.0.1 to 4.1? Regards. On Wed, Mar 6, 2013 at 6:24 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: So far we did not see any difference in minor version Vs Major version upgrades. Both work the same way. -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: Wednesday, March 06, 2013 4:46 AM To: cloudstack-dev@incubator.apache.org Subject: Database diversions for minor releases? Sudha, CLOUDSTACK-1515 is related to packaging, pl. see the comments on the issue. My only concern is that people who have installed 4.0.1 and I don't know how the packaging was done for 4.1: Was the @VERSION@ in create-schema == 4.1? We need to have an empty upgrade path from 4.0 to 4.0.1 to 4.1 rightnow for 4.1 release. The question I want to ask everyone: - Do we change db version for minor releases, or stick with its parent? - How we do upgrades for minor releases? Regards. On Wed, Mar 6, 2013 at 5:39 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
Re: [ALERT] Memory issue fix in master has been pushed in
Thanks Kelven, the much awaited fix! On Wed, Mar 6, 2013 at 6:49 AM, Kelven Yang kelven.y...@citrix.com wrote: I've pushed in the memory issue fix to master to work with storage subsystem. This will help get rid of huge memory footprint issue on master builds. A small stripped version of MAVEN_OPTS can be used if your development environment is in short of memory, you may try following settings to MAVEN_OPTS -XX:MaxPermSize=128m -Xmx512m Kelven
RE: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
I have also noticed cloudstack-awsapi*.rpm is getting generated as part of packaging which is irrespective of awsapi build. That is the reason I have included the same as part of MS install. “mvn -P awsapi package -Dsystemvm” Thanks, Pradeep S From: Prasanna Santhanam [mailto:nore...@reviews.apache.org] On Behalf Of Prasanna Santhanam Sent: Wednesday, March 06, 2013 5:53 PM To: Chip Childers; Wido den Hollander; Noa Resare; Hugo Trippaers Cc: cloudstack; Prasanna Santhanam; Pradeep Soundararajan Subject: Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/ But awsapi should be an optional component to install, right? - Prasanna On March 6th, 2013, 11:58 a.m., Pradeep Soundararajan wrote: Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den Hollander, and Noa Resare. By Pradeep Soundararajan. Updated March 6, 2013, 11:58 a.m. Description Initial issue was cloudstack-awsapi is not installing along with MS and then webapps7080 folder is missing on the management server. Solution: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. Moved the post awsapi section to the post management since it was trying to provide symb link before installing management server. Testing Tested with the new build + packaging Diffs * packaging/centos63/cloud.spec (1ef35414dfd87c5ac04ce83b09aa1e409f1702e7) View Diffhttps://reviews.apache.org/r/9776/diff/
RE: [ACS41][ACS42][QA] Current Blockers - 3/6
Should CLOUDSTACK-1426 be included in the list. The same problem surfaces with any api which takes storage pool id as a parameter. For example: migrateVolume. Regards, Devdeep -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: Wednesday, March 06, 2013 5:40 PM To: cloudstack-dev@incubator.apache.org Subject: [ACS41][ACS42][QA] Current Blockers - 3/6 CLOUDSTACK-1526 Template registration fails in the VMware Setup. Jayapal Reddy 3/5/2013 20:45 CLOUDSTACK-1402 listRouters API response doesn't return linklocal IP and public IP details Min Chen2/26/2013 3:49 CLOUDSTACK-1368 Shared network - Not able to delete network because of java.lang.NullPointerException.Murali Reddy 2/21/2013 17:29 CLOUDSTACK-1252 Failed to download default template in VMware Pradeep Soundararajan2/12/2013 20:00 CLOUDSTACK-1515 None of the cloudstack packges are marked for upgrade when tried to upgrade from.4.0/4.0.1 to 4.1 Rohit Yadav 3/5/2013 7:43 CLOUDSTACK-1536 System VM's not creating in Master with VMware setup. Sateesh Chodapuneedi 3/6/2013 1:59
Re: [Discuss] CloudStack Collab Summit 2013
On Tue, Mar 05, 2013 at 06:13:36PM -0500, Mark Hinkle wrote: The best laid plans. I heard back from our EMEA contingent for the Collab Summit and their conference planners think that the the spring might be too aggressive to but on the European event. The conference folks that organized ApacheCon (The Open Bastion) tell me that they are available to organize the North American event this spring and have a venue available on June 23 through 25 in Silicon Valley for 500 people. I think that we can make that happen. Then we can give the European folks enough time to plan an event in the fall in Amersterdam. Please let me know if you have any objections time is ticking and I think as agreed it would be good to have two events so not everyone has to travel so far. Regards, Mark I think we should go for it as you propose. NA summit in the June, and an EU one for the fall. On 2/27/13 2:40 PM, kdam...@apache.org kdam...@apache.org wrote: Sounds good to me, and I am certainly willing to help organize the fall NA event. -Kelcey Damage -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, February 26, 2013 1:19 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [Discuss] CloudStack Collab Summit 2013 On Tue, Feb 26, 2013 at 01:27:47PM -0500, Mark Hinkle wrote: So to summarize the threadŠ I think the collective opinion is that we should do a CloudStack Collab Summit in EMEA this spring and since Hugo's got the resources to help plan in Amersterdam I think we should let him take the lead for that and Sebastien, Mohammed, Wido and the others that stepped up can help him. I'll volunteer to find the funding once he has a proposed venue and some costs and the PPMC and ConCom sign-off on the event. Also unless we get objections we'll plan for a second summit in North America in the fall and want to try to get that venue reserved it is very hard to find a place on short timeframes. I'll work to get the funding in place for that one too. To Chip's question on is two summits too many, I see a huge appetite for people to come talk about CloudStack.I think since all decisions are made on list it's not like you miss out by not going to both or either it's just nice to put faces to IRC nicks/email addies. Thanks for addressing my question (and for everyone's feedback). Sounds like we have a plan to make some plans! Anything else? Mark
Re: [Discuss] CloudStack Collab Summit 2013
On Mar 6, 2013, at 9:06 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, Mar 05, 2013 at 06:13:36PM -0500, Mark Hinkle wrote: The best laid plans. I heard back from our EMEA contingent for the Collab Summit and their conference planners think that the the spring might be too aggressive to but on the European event. The conference folks that organized ApacheCon (The Open Bastion) tell me that they are available to organize the North American event this spring and have a venue available on June 23 through 25 in Silicon Valley for 500 people. I think that we can make that happen. Then we can give the European folks enough time to plan an event in the fall in Amersterdam. Please let me know if you have any objections time is ticking and I think as agreed it would be good to have two events so not everyone has to travel so far. Regards, Mark I think we should go for it as you propose. NA summit in the June, and an EU one for the fall. +1 On 2/27/13 2:40 PM, kdam...@apache.org kdam...@apache.org wrote: Sounds good to me, and I am certainly willing to help organize the fall NA event. -Kelcey Damage -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, February 26, 2013 1:19 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [Discuss] CloudStack Collab Summit 2013 On Tue, Feb 26, 2013 at 01:27:47PM -0500, Mark Hinkle wrote: So to summarize the threadŠ I think the collective opinion is that we should do a CloudStack Collab Summit in EMEA this spring and since Hugo's got the resources to help plan in Amersterdam I think we should let him take the lead for that and Sebastien, Mohammed, Wido and the others that stepped up can help him. I'll volunteer to find the funding once he has a proposed venue and some costs and the PPMC and ConCom sign-off on the event. Also unless we get objections we'll plan for a second summit in North America in the fall and want to try to get that venue reserved it is very hard to find a place on short timeframes. I'll work to get the funding in place for that one too. To Chip's question on is two summits too many, I see a huge appetite for people to come talk about CloudStack.I think since all decisions are made on list it's not like you miss out by not going to both or either it's just nice to put faces to IRC nicks/email addies. Thanks for addressing my question (and for everyone's feedback). Sounds like we have a plan to make some plans! Anything else? Mark
Re: Master branch build is broken again
On Wed, Mar 06, 2013 at 11:19:50AM +0530, Nitin Mehta wrote: Chip - This is relatively small feature and more or less isolated with other functionalities. IMHO I don¹t think it needs a different feature branch. I will definitely add unit tests for this though. I disagree. As Alex noted, you changed 18 files and the build obviously broke because of it. I'd assess this change as being one that doing the right thing would be to have had a branch from which to propose a merge. It's a gray area, but leaning towards more a conservative approach to master branch stability will serve us well as a community. Thanks, -Nitin On 05/03/13 12:02 AM, Chip Childers chip.child...@sungard.com wrote: On Mon, Mar 04, 2013 at 10:00:24AM -0800, Alex Huang wrote: -1 on this checkin And this is not a small change. 18 files. Some large completely new methods checked in. Changes to the virtual machine state machine. No unit testing. I would reject this fix on these problems alone. Nitin, Shouldn't a change this big be in a feature branch, with a MERGE request to bring it into master? --Alex -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Monday, March 4, 2013 9:56 AM To: cloudstack-dev@incubator.apache.org Cc: Nitin Mehta; Abhinandan Prateek Subject: RE: Master branch build is broken again Min, You should just revert the commit. --Alex -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Monday, March 4, 2013 9:51 AM To: cloudstack-dev@incubator.apache.org Cc: Nitin Mehta Subject: Master branch build is broken again Importance: High Hi there, I could not compile master after pulling latest code today, build failed with the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler- plugin:2.5.1:compile (default-compile) on project cloud-engine- orchestration: Compilation failure [ERROR] /Users/minc/dev/cloud- asf/engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity /a pi/db/VMEntityVO.java:[52,7] org.apache.cloudstack.engine.cloud.entity.api.db.VMEntityVO is not abstract and does not override abstract method getNewSvcOfferingId() in com.cloud.vm.VirtualMachine [ERROR] - [Help 1] I checked the commit history, it seems related to commit e0019eccd997d9b2b3ff9395bcd99f821f5121db, so CC Nitin here. Can somebody quickly fix this? This is blocking me from verifying CLOUDSTACK- 1491 and merge my feature branch vim51_win8. Thanks -min
[DISCUSS] Method/Algorithm to gather Health Check states
Hi, As part of HealthCheck feature review, I have suggested to introduce a new Capability for HealthCheck. So that any Network Element who has this capability can advertise it. Any alternative thoughts? The most important part of health check functionality is to update the status of a destination VM in CS DB (as seen by the LB Appliance) on a scheduled thread launched every time interval. So on every iteration, the need is to go to every LB rule and find the status of its destinations. I can think of 2 ways to get this done Method 1: A. List all the Health Monitors; For each monitor= B. Work backwards find the LbRule C. Find the network for LbRule D. Find the LB provider in the network E. Call LoadBalancingServiceProvider.updateStatus by passing LB and its destinations. F. Which will reach the Resource and ultimately the Appliance Method 2: A. List all the Networks; For each network = B. Find the LB provider in the network C. Find the NetworkElement for the LB provider D. Proceed to (E.) If NetworkElement has the HealthCheck Capability E. Call LoadBalancingServiceProvider.updateStatus by passing LB and its destinations. F. Which will reach the Resource and ultimately the Appliance I like the top down approach of Method 2. Any thoughts? Thanks, Vijay V. From: Vijay Venkatachalam [mailto:nore...@reviews.apache.org] On Behalf Of Vijay Venkatachalam Sent: Wednesday, March 06, 2013 6:10 PM To: Vijay Venkatachalam Cc: Rajesh Battala; cloudstack Subject: Re: Review Request: AWS Style HealthCheck feature BugID : 664
[ACS41][QA] VMware vNetwork Distributed Virtual Switch support in CloudStack
Ilya, Looks like Sateesh has checked in the code for [1]. Would you accept this for testing now or are there any outstanding issues before testing starts. Is possible can a test scope document or test plan can be submitted?? [1] https://issues.apache.org/jira/browse/CLOUDSTACK-657 Thanks /sudha
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
On 03/06/2013 09:03 AM, Dave Cahill wrote: Moving discussion from Jira ticket to dev list as suggested by Hugo. Request from Kawai-san: There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. Suggestion by Marcus: I'd actually defer to the guys who have been working on the packaging. It seems like it would be distribution specific, and handled by the startup scripts. The obvious solution to me would be to create a directory, say /usr/share/cloudstack-agent/plugins, and append that to the classpath in the init scripts so that the agent can see the plugins copied there. Sounds very good to me! The init scripts can do that, no problem. I would indeed use a plugins directory which is by default empty since what we distribute goes into lib. While you could place your plugin in the lib directory I wouldn't recommend it. Maybe go a step further and make a symlink /etc/cloudstack/agent/plugins; easier for admins to find. Nack, that symlink will start haunting us at some point I think. /etc is also for configuration, not for plugins. Better point the admin into the right directorion. We can always add a comment in the example agent.properties. Wido Noa, Hugo and I are happy with that solution, but if anyone has any thoughts, please let us know. Thanks, Dave. On Wed, Mar 6, 2013 at 4:58 PM, Hugo Trippaers (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13594478#comment-13594478] Hugo Trippaers commented on CLOUDSTACK-1489: Good idea, but discuss these things on list so everybody is involved. cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2 Environment: Linux kvm Reporter: Hiroaki Kawai Assignee: Noa Resare There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
On Mar 6, 2013 8:04 AM, Wido den Hollander w...@widodh.nl wrote: On 03/06/2013 09:03 AM, Dave Cahill wrote: Moving discussion from Jira ticket to dev list as suggested by Hugo. Request from Kawai-san: There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. Suggestion by Marcus: I'd actually defer to the guys who have been working on the packaging. It seems like it would be distribution specific, and handled by the startup scripts. The obvious solution to me would be to create a directory, say /usr/share/cloudstack-agent/plugins, and append that to the classpath in the init scripts so that the agent can see the plugins copied there. Sounds very good to me! The init scripts can do that, no problem. I would indeed use a plugins directory which is by default empty since what we distribute goes into lib. While you could place your plugin in the lib directory I wouldn't recommend it. Maybe go a step further and make a symlink /etc/cloudstack/agent/plugins; easier for admins to find. Nack, that symlink will start haunting us at some point I think. /etc is also for configuration, not for plugins. Better point the admin into the right directorion. We can always add a comment in the example agent.properties. Wido That's fine with me as well, I've just seen a trend of apps doing that (apache modules for example) on certain distros, so I thought it might be worth discussing. If we were putting the agent stuff in a different location for each distro I might care about having that more, to present a more standard/predictable interface to admins. Noa, Hugo and I are happy with that solution, but if anyone has any thoughts, please let us know. Thanks, Dave. On Wed, Mar 6, 2013 at 4:58 PM, Hugo Trippaers (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13594478#comment-13594478 ] Hugo Trippaers commented on CLOUDSTACK-1489: Good idea, but discuss these things on list so everybody is involved. cloudstack agent plugin classpath is missing Key: CLOUDSTACK-1489 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1489 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2 Environment: Linux kvm Reporter: Hiroaki Kawai Assignee: Noa Resare There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
On Wed, Mar 06, 2013 at 12:23:09PM +, Prasanna Santhanam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/#review17472 --- But awsapi should be an optional component to install, right? Why? Isn't it part of the core product now, with only a global setting as it's flag to enable / disable the feature? IMO, it should be part of the default installation.
RE: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
I automatically assumed it's an optional component, but I don't think we actually discussed this. It's also optional in the maven compile/build I've noticed. I'm certainly not against it being part of the main management server, but the dependencies are not really aligned yet. So it's going to be a huge rpm if we make a single package out of it. We should make a point of redoing the axis stuff to generate new classes and try to get the dependencies in line with the management server. But that's something for later. We could technically use the maven axis task to generate that part of the code automagically. Cheers, Hugo -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 06, 2013 4:22 PM To: cloudstack-dev@incubator.apache.org; Prasanna Santhanam Cc: Wido den Hollander; Noa Resare; Hugo Trippaers; Pradeep Soundararajan Subject: Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. On Wed, Mar 06, 2013 at 12:23:09PM +, Prasanna Santhanam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/#review17472 --- But awsapi should be an optional component to install, right? Why? Isn't it part of the core product now, with only a global setting as it's flag to enable / disable the feature? IMO, it should be part of the default installation.
Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
On Wed, Mar 06, 2013 at 03:35:17PM +, Hugo Trippaers wrote: I automatically assumed it's an optional component, but I don't think we actually discussed this. It's also optional in the maven compile/build I've noticed. I'm certainly not against it being part of the main management server, but the dependencies are not really aligned yet. So it's going to be a huge rpm if we make a single package out of it. The switch to make it optional in maven was done (per comments on the list) to speed up build time. I'd also be OK with calling this optional, but then we need to document the installation as a specific optional step. My preference is to have it be installed by default though. Having an AWS compatible API that's easily enabled (easily being a qualitative and debatable term) is a Good Thing (tm). We should make a point of redoing the axis stuff to generate new classes and try to get the dependencies in line with the management server. But that's something for later. We could technically use the maven axis task to generate that part of the code automagically. Cheers, Hugo -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Wednesday, March 06, 2013 4:22 PM To: cloudstack-dev@incubator.apache.org; Prasanna Santhanam Cc: Wido den Hollander; Noa Resare; Hugo Trippaers; Pradeep Soundararajan Subject: Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature. On Wed, Mar 06, 2013 at 12:23:09PM +, Prasanna Santhanam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9776/#review17472 --- But awsapi should be an optional component to install, right? Why? Isn't it part of the core product now, with only a global setting as it's flag to enable / disable the feature? IMO, it should be part of the default installation.
Re: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts to a domain
On Wed, Mar 06, 2013 at 06:19:56PM +0530, Deepti Dohare wrote: Thanks Alex for the comments. Sure I will get in touch with Prachi regarding this. Please have this discussion on-list (and perhaps in this thread).
Re: Review Request: 4.1 deb packaging tomcat fixes
Wido / Noa: Is this ready to pull into 4.1? On Sat, Mar 02, 2013 at 11:34:14PM +, Noa Resare wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 11:34 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules ba9056e packaging/debian/replace.properties fee1def Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
On Wed, Mar 6, 2013 at 10:20 AM, Marcus Sorensen shadow...@gmail.com wrote: On Mar 6, 2013 8:04 AM, Wido den Hollander w...@widodh.nl wrote: On 03/06/2013 09:03 AM, Dave Cahill wrote: Moving discussion from Jira ticket to dev list as suggested by Hugo. Request from Kawai-san: There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. Suggestion by Marcus: I'd actually defer to the guys who have been working on the packaging. It seems like it would be distribution specific, and handled by the startup scripts. The obvious solution to me would be to create a directory, say /usr/share/cloudstack-agent/plugins, and append that to the classpath in the init scripts so that the agent can see the plugins copied there. Sounds very good to me! The init scripts can do that, no problem. I would indeed use a plugins directory which is by default empty since what we distribute goes into lib. While you could place your plugin in the lib directory I wouldn't recommend it. Maybe go a step further and make a symlink /etc/cloudstack/agent/plugins; easier for admins to find. Nack, that symlink will start haunting us at some point I think. /etc is also for configuration, not for plugins. Better point the admin into the right directorion. We can always add a comment in the example agent.properties. Wido That's fine with me as well, I've just seen a trend of apps doing that (apache modules for example) on certain distros, so I thought it might be worth discussing. If we were putting the agent stuff in a different location for each distro I might care about having that more, to present a more standard/predictable interface to admins. Typically in most cases I've seen distros that are doing that are using those directories as a way to show all modules and a way to enable modules that (e.g. mods_available and mods_enabled). I personally am not a fan of that, and hope that we wouldn't use such trickery to accomplish things when a simple text file will do. --David
Re: Document for deleteUser command
On Wed, Mar 6, 2013 at 10:26 AM, Isaac Chiang isaacchi...@gmail.com wrote: Hi all: When I looked up for deleteUser command on the website, I found that both description and response format are wrong. http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/root_admin/deleteUser.html The deleteUSer response is a SuccessResponse Object in both 4.0.1 and current master branch. I've checked the JIRA system and there is no related ticket to the issue. Is there any fix plan for this or apply new API document for CS 4.2 on the website? Thanks Regards Isaac Please file a bug for this. --David
Re: Review Request: 4.1 deb packaging tomcat fixes
On 03/06/2013 04:46 PM, Chip Childers wrote: Wido / Noa: Is this ready to pull into 4.1? I've been debugging the agent and common package the last couple of days. The packages themself seem to work, but it's all the small tweaks which take time. The agent package should be pretty stable now. It is spread out over multiple commits though, so they have to be cherry-picked. Wido On Sat, Mar 02, 2013 at 11:34:14PM +, Noa Resare wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/ --- (Updated March 2, 2013, 11:34 p.m.) Review request for cloudstack and Wido den Hollander. Description --- Changes isolated to the deb package build files, to fix failure to start management server from deb built packages * Adds the tomcat6 bootstrap jar to outer classpath * Removes install of cloud-server-4.1.0-SNAPSHOT.jar in /usr/share/cloudstack-management/lib. This causes /usr/share/cloudstack-management structure to be in the way tomcat expects it to * Update paths to logfiles, which restores log4j functionality CLOUDSTACK-1490: 4.1 deb management fails to start This addresses bug CLOUDSTACK-1490. Diffs - debian/rules ba9056e packaging/debian/replace.properties fee1def Diff: https://reviews.apache.org/r/9714/diff/ Testing --- Thanks, Noa Resare
Re: Review Request: CLOUDSTACK-1417 bugfix for 4.1 branch
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9780/#review17477 --- Ship it! Applied to 4.1: commit 525d391d65070097c31ba195da95d137e8b6e46c Author: Rohit Yadav bhais...@apache.org Date: Wed Mar 6 17:47:37 2013 +0530 CLOUDSTACK-1417: cosmetics, print param name, value for uuid-id translate error Signed-off-by: Rohit Yadav bhais...@apache.org - Chip Childers On March 6, 2013, 12:29 p.m., Rohit Yadav wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9780/ --- (Updated March 6, 2013, 12:29 p.m.) Review request for cloudstack and Chip Childers. Description --- Cosmetic fix for CLOUDSTACK-1417 to log param name alongwith value for the param causing error while translation uuid to internal id. Tested and patch applies smoothly on current 4.1 This addresses bug CLOUDSTACK-1417. Diffs - server/src/com/cloud/api/ApiDispatcher.java 552dea5 Diff: https://reviews.apache.org/r/9780/diff/ Testing --- Thanks, Rohit Yadav
RE: Security Groups in Advanced Zone - Plugin Support
We at ShapeBlue are also very keen to understand the direction that 'Security Groups in Advanced Zones' is going. We have a large client who would like to use advanced zone VLAN isolation of accounts, with security groups based isolation of VM tiers within each account. Regards, Paul Angus S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com -Original Message- From: Mills, Joseph [mailto:j...@midokura.jp] Sent: 05 March 2013 08:34 To: cloudstack-dev@incubator.apache.org Cc: Anthony Xu Subject: Re: Security Groups in Advanced Zone - Plugin Support Hi Anthony, Any thoughts? We are looking forward to hearing back from you about this. Just to recap: (1) Your current changes add Security Group capabilities for the Virtual Router in advance-shared only, is this correct? (2) Your future plan is to add Security Groups to Virtual Router in advanced-isolated, but will NOT be supportable by other network service providers, is this correct? (3) Any reason you have decided to implement Security Groups differently than the other network services? Particularly with respect to pluggability? Thanks, Joe On Fri, Mar 1, 2013 at 12:16 PM, Dave Cahill dcah...@midokura.com wrote: Hi Anthony, Adding you in CC in case you missed this message. We're trying to understand in more detail your plan for Security Groups support. Thanks, Dave. On Fri, Feb 15, 2013 at 3:19 PM, Mills, Joseph j...@midokura.jp wrote: *Hi Anthony, Thanks for the quick response. Just to check my understanding: CloudStack has 4 networking models: Basic (Only in Basic Zone) Isolated (Only in Advanced Zone) Shared (Only in Advanced Zone) VPC (Only in Advanced Zone) Zones can be Security Group enabled, or Security Group disabled - this is a tickbox in the UI when creating a Zone. Network Offerings can have the Security Groups Capability enabled or not - this is a tickbox in the UI when creating a NetworkOffering. You have code that is almost ready to commit (CLOUDSTACK-737, currently adding unit tests), and you also plan to make further changes for 4.2 - let’s call these “current” and “future”. changes. (1) Your “current” changes add support for the Security Groups Capability in Advanced Shared networks, however this will be only be supported by the Virtual Router Provider, with no option to be supported by other network plugins. (2) For 4.2 (“future”), you plan to add support for the Security Groups Capability in Advanced Isolated networks. This will also not have the option of being supported by other network plugins. Is this correct? Any reason why you have chosen to implement this service differently than the other Services with respect to pluggability? Thanks, Joe* On Fri, Feb 15, 2013 at 1:11 PM, Anthony Xu xuefei...@citrix.com wrote: I have plan to add isolated and shared networks to SG enabled zone in 4.2, the service providers on these network will be supported in SG enabled zone, but as for SG enabled shared network, current plan is only support Virtual Router as service provider. If you want to add other service provider in SG enabled shared network, please file a feature request for it, and welcome work on that feature. Anthony -Original Message- From: Mills, Joseph [mailto:j...@midokura.jp] Sent: Thursday, February 14, 2013 7:02 PM To: cloudstack-dev@incubator.apache.org Subject: Security Groups in Advanced Zone - Plugin Support I was looking at the FS for Security Group Isolation in Advanced Zone, (CLOUDSTACK-737) and I noticed that: Only one network service provider is supported in advanced SG enabled zone - Virtual Router Are there currently any plans to add pluggability support for Security Groups in 4.2, and if so, is any timeline estimate available? As far as we know, all other Services are pluggable, and we would like to support Security Group Isolation as well. Thanks, Joe ShapeBlue provides a range of strategic and technical consulting and implementation services to help IT Service Providers and Enterprises to build a true IaaS compute cloud. ShapeBlue’s expertise, combined with CloudStack technology, allows IT Service Providers and Enterprises to deliver true, utility based, IaaS to the customer or end-user. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company
Re: Review Request: Adding awsapi in the require section of cloud.spec as it resolves issue with EC2 QUERY API Feature.
On 6 March 2013 21:13, Chip Childers chip.child...@sungard.com wrote: On Wed, Mar 06, 2013 at 03:35:17PM +, Hugo Trippaers wrote: I automatically assumed it's an optional component, but I don't think we actually discussed this. It's also optional in the maven compile/build I've noticed. I'm certainly not against it being part of the main management server, but the dependencies are not really aligned yet. So it's going to be a huge rpm if we make a single package out of it. The switch to make it optional in maven was done (per comments on the list) to speed up build time. I'd also be OK with calling this optional, but then we need to document the installation as a specific optional step. My preference is to have it be installed by default though. Having an AWS compatible API that's easily enabled (easily being a qualitative and debatable term) is a Good Thing (tm). What I meant was it should be like the cloudstack-agent. I install it if I run KVM hypervisors. Something like cloudstack-awsapi may be. Having it install by default when you install cloudstack-management shouldn't be necessary.
Re: Document for deleteUser command
The link for filing bugs is: https://issues.apache.org/jira/browse/CLOUDSTACK On 6 March 2013 15:26, Isaac Chiang isaacchi...@gmail.com wrote: Hi all: When I looked up for deleteUser command on the website, I found that both description and response format are wrong. http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/root_admin/deleteUser.html The deleteUSer response is a SuccessResponse Object in both 4.0.1 and current master branch. I've checked the JIRA system and there is no related ticket to the issue. Is there any fix plan for this or apply new API document for CS 4.2 on the website? Thanks Regards Isaac -- NS
Re: [DISCUSS] Cloudstack agent - standardized directory for plugin jars
Yes, Ubuntu is doing that, but for example on CentOS, apache is packaged such that you have : [marcus@www2 modules]$ ls -l /etc/httpd/modules lrwxrwxrwx 1 root root 29 Apr 17 2012 /etc/httpd/modules - ../../usr/lib64/httpd/modules On Wed, Mar 6, 2013 at 8:47 AM, David Nalley da...@gnsa.us wrote: On Wed, Mar 6, 2013 at 10:20 AM, Marcus Sorensen shadow...@gmail.com wrote: On Mar 6, 2013 8:04 AM, Wido den Hollander w...@widodh.nl wrote: On 03/06/2013 09:03 AM, Dave Cahill wrote: Moving discussion from Jira ticket to dev list as suggested by Hugo. Request from Kawai-san: There is no place to put plugin jar files for cloudstack agent program now, while management server program has default @PLUGINJAVADIR@ where plugin classes will be loaded into server at startup. We will need to load a class, for example when we try to use a custom libvirt.vif.driver which can be configured at agent.properties. Suggestion by Marcus: I'd actually defer to the guys who have been working on the packaging. It seems like it would be distribution specific, and handled by the startup scripts. The obvious solution to me would be to create a directory, say /usr/share/cloudstack-agent/plugins, and append that to the classpath in the init scripts so that the agent can see the plugins copied there. Sounds very good to me! The init scripts can do that, no problem. I would indeed use a plugins directory which is by default empty since what we distribute goes into lib. While you could place your plugin in the lib directory I wouldn't recommend it. Maybe go a step further and make a symlink /etc/cloudstack/agent/plugins; easier for admins to find. Nack, that symlink will start haunting us at some point I think. /etc is also for configuration, not for plugins. Better point the admin into the right directorion. We can always add a comment in the example agent.properties. Wido That's fine with me as well, I've just seen a trend of apps doing that (apache modules for example) on certain distros, so I thought it might be worth discussing. If we were putting the agent stuff in a different location for each distro I might care about having that more, to present a more standard/predictable interface to admins. Typically in most cases I've seen distros that are doing that are using those directories as a way to show all modules and a way to enable modules that (e.g. mods_available and mods_enabled). I personally am not a fan of that, and hope that we wouldn't use such trickery to accomplish things when a simple text file will do. --David
[DOCS] Sprint on Friday
Hi all, Having another Doc Sprint this Friday - please join us! We currently have 47 bugs open for 4.1.0, several are unassigned at the moment. Note that almost all of these are for documenting new features - it'd be *very* helpful if we can get someone to pick them up and if the developer of the features can be in IRC to answer questions. CLOUDSTACK-1478: Document baremetal kickstart CLOUDSTACK-1442: Document BigSwitch plugin CLOUDSTACK-1441: Document ApiDiscoverService CLOUDSTACK-997: Improve documentation of assignVirtualMachine API CLOUDSTACK-895: Document autoscale request handling capacity by provisioning LB appliances feature CLOUDSTACK-883: Document 3rd party plugin feature CLOUDSTACK-856: Document CPU and memory overcommit functionality CLOUDSTACK-827: Document new advanced searching capabilities CLOUDSTACK-823: Document any changes to the baremetal provisioning feature I will try to have the new install docs done by Friday so we can test those as well. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RE: [DISCUSS] Dedicated Resources: Public IP Addresses and VLANs per Tenant
First draft of the FS can be found here - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS-+Dedicate+Public+IP+Addresses+per+tenant . Comments/Suggestions? Thank you, Likitha -Original Message- From: Manan Shah Sent: Friday, February 22, 2013 12:08 PM To: Likitha Shetty; cloudstack-us...@incubator.apache.org; cloudstack- d...@incubator.apache.org Cc: Manan Shah Subject: Re: [DISCUSS] Dedicated Resources: Public IP Addresses and VLANs per Tenant Thanks Likitha for your prompt response. I will wait for the FS. Regards, Manan Shah On 2/21/13 10:30 PM, Likitha Shetty likitha.she...@citrix.com wrote: Yes Manan, with the 1st solution the dedication should be applicable for both Isolated and VPC networks. I will capture all that is being discussed here in the FS (yet to publish). Thank you, Likitha -Original Message- From: Manan Shah Sent: Friday, February 22, 2013 11:55 AM To: Manan Shah; Likitha Shetty; cloudstack-us...@incubator.apache.org; cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] Dedicated Resources: Public IP Addresses and VLANs per Tenant Hi Likitha, One additional question. When an admin assigns a Public IP Address range to an account and if that account creates a VPC, I am assuming they will still get the Public IP Address from this reserved IP range. Can you please confirm that this reserved Public IP Address would work for both Isolated Networks as well as VPC? Regards, Manan Shah On 2/21/13 9:57 PM, Manan Shah manan.s...@citrix.com wrote: Hi Likitha, I agree with you that the 1st solution seems like a better approach. Regards, Manan Shah On 2/21/13 9:39 PM, Likitha Shetty likitha.she...@citrix.com wrote: Hi Manan, Thanks for the feedback. Please find my answers inline. Thank you, Likitha -Original Message- From: Manan Shah Sent: Friday, February 22, 2013 10:28 AM To: Likitha Shetty; cloudstack-us...@incubator.apache.org; cloudstack- d...@incubator.apache.org Cc: Manan Shah Subject: Re: [DISCUSS] Dedicated Resources: Public IP Addresses and VLANs per Tenant Hi Likitha, Comments in-line belowŠ. Also, please let us know once the FS is updated. Regards, Manan Shah On 2/19/13 8:59 PM, Likitha Shetty likitha.she...@citrix.com wrote: CCing Manan to comment on the requirements. -Original Message- From: Likitha Shetty [mailto:likitha.she...@citrix.com] Sent: Friday, February 15, 2013 7:09 PM To: cloudstack-us...@incubator.apache.org; cloudstack- d...@incubator.apache.org Subject: RE: [DISCUSS] Dedicated Resources: Public IP Addresses and VLANs per Tenant Hi All, This is with respect to Part 1 of the feature 'Dedicate Public IP range' which is already implemented in CS. Following is the observation wrt what is the current CS implementation and the proposed changes to the same, 1. A public VLAN-IP range can only be associated to an account during the creation of the range Proposed change - Admin should be allowed to dedicate a range even after it has been created and also allowed to change the owner [Manan] Agreed with the functionality. 2. If an admin associates an IP range to an account, all the IP's of that range get acquired by a single isolated network in that account [Manan] Why do you think this is the right functionality. What if the admin wants to allocate a public IP range to a account and wants to allow the tenant to create as many networks as they want and use this public IP range. [Likitha] Manan, I agree. I don't think this is the right behavior. So the following is what currently happens in CS, If an admin associates an IP range to an account, all the IP's of that range get acquired by a single isolated network in that account 1. If there are no isolated guest networks, a new network is created and all the IP's from the range are dedicated to the new network 2. If there is 1 isolated guest network, all the IP's from the range are dedicated to the existing network 3. If there are more than 1 isolated guest network CS throws an error There are 2 possible changes we can introduce to resolve this, 1. During dedication we just mark this range of IP's as dedicated. And when the user acquires an IP for a particular network we allow the network to choose from the dedicated range. 2. During dedication when an account is chosen, the user also has the option to choose one of the network in the account which can acquire the IP's I prefer the 1st solution because with the 2nd solution, one of the networks of the tenant will acquire all the IP's. Thoughts? a. If there are no isolated guest networks, a new network is created and all the IP's from the range are dedicated to the new network b. If there is 1 isolated guest network, all the IP's from the range are dedicated to the existing network c. If there are more than 1 isolated guest network CS throws an error Proposed change - When an account is chosen, the user also has the option to choose the network in
Re: Setting up a better eclipse environment....
This is the exception I see in my Eclipse console (but not my regular
console):
Caused by: java.lang.OutOfMemoryError: Java heap space
... 329 more
2013-03-06 10:50:09.764:WARN::Failed startup of context
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@557ce3bb
{/client,/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/client/target/cloud-client-ui-4.2.0-SNAPSHOT}
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'virtualMachineEntityImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: private
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManager
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.manager;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'VMEntityManagerImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: protected com.cloud.vm.VirtualMachineManager
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl._itMgr;
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'clusteredVirtualMachineManagerImpl':
Injection of autowired dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: protected com.cloud.storage.StorageManager
com.cloud.vm.VirtualMachineManagerImpl._storageMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'storageManagerImpl': Injection of autowired dependencies
failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: protected com.cloud.vm.UserVmManager
com.cloud.storage.StorageManagerImpl._userVmMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'userVmManagerImpl': Injection of autowired dependencies
failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: protected com.cloud.network.NetworkModel
com.cloud.vm.UserVmManagerImpl._networkModel; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'networkModelImpl': Injection of autowired dependencies
failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: com.cloud.configuration.ConfigurationManager
com.cloud.network.NetworkModelImpl._configMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'configurationManagerImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: com.cloud.user.AccountManager
com.cloud.configuration.ConfigurationManagerImpl._accountMgr; nested
exception is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'accountManagerImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: private com.cloud.network.security.SecurityGroupManager
com.cloud.user.AccountManagerImpl._networkGroupMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'securityGroupManagerImpl2': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: com.cloud.agent.AgentManager
com.cloud.network.security.SecurityGroupManagerImpl._agentMgr; nested
exception is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'clusteredAgentManagerImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: protected com.cloud.ha.HighAvailabilityManager
com.cloud.agent.manager.AgentManagerImpl._haMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'highAvailabilityManagerExtImpl': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: java.util.List
com.cloud.ha.HighAvailabilityManagerImpl._investigators; nested exception
is org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'XenServerInvestigator': Injection of autowired dependencies
failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
field: com.cloud.resource.ResourceManager
com.cloud.ha.XenServerInvestigator._resourceMgr; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
Review Request: CLOUDSTACK-1402: listRouters API response doesn't return linklocal IP and public IP details
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9784/ --- Review request for cloudstack and Chip Childers. Description --- This patch fixed the blocker defect CLOUDSTACK-1402. This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1402. Diffs - server/src/com/cloud/api/query/dao/DomainRouterJoinDaoImpl.java cdb859e Diff: https://reviews.apache.org/r/9784/diff/ Testing --- Run listRouters api with the patch, it returns the linkLocal and public IP details along with guest Ip, see below. listroutersresponse cloud-stack-version=4.1.0-SNAPSHOTcount1/countrouterid160e5c1b-f2f6-4d18-90fc-838b9dca516f/idzoneid1547abf3-6805-4a5a-b552-64c56c627e5f/zoneidzonenameTest Zone/zonenamedns172.52.126.11/dns1dns272.52.126.12/dns2networkdomaincs2cloud.internal/networkdomaingateway10.223.138.65/gatewaynamer-9-VM/namepodide4d59b71-54fa-4da1-8a47-4c268cfe4412/podidhostid0ab78594-1326-4093-89ef-3b876afbb9e2/hostidhostnameRack3Host12.lab.vmops.com/hostnamelinklocalip169.254.2.164/linklocaliplinklocalmacaddress0e:00:a9:fe:02:a4/linklocalmacaddresslinklocalnetmask255.255.0.0/linklocalnetmasklinklocalnetworkidd98f68de-62c6-4f5b-b135-e2540b475804/linklocalnetworkidpublicip10.223.138.67/publicippublicmacaddress06:18:dc:00:00:0a/publicmacaddresspublicnetmask255.255.255.192/publicnetmaskpublicnetworkid370174c4-ce3a-4b29-91e0-f0d08b71ef18/publicnetworkidguestipaddress10.1.1.1/guestipaddressguestmacaddress02:00:1e:d5:00:02/guestmacaddressguestnetmask255.255.255.0/guestnetmaskguestnetworkid54535bed-f40c-4522-b60f-b745c84948f6/guestnetworkidtemplateidc64d8cf4-81dc-11e2-b8cf-066a9a000451/templateidcreated2013-02-28T15:20:29-0800/createdstateRunning/stateaccountadmin/accountdomainidc6276150-81dc-11e2-b8cf-066a9a000451/domainiddomainROOT/domainserviceofferingid09b00fbc-cfab-460f-8066-0778e48efb8d/serviceofferingidserviceofferingnameSystem Offering For Software Router/serviceofferingnameisredundantrouterfalse/isredundantrouterredundantstateUNKNOWN/redundantstatenicid2e0a0771-6be9-47a4-a37b-afa11a5e0c5f/idnetworkid54535bed-f40c-4522-b60f-b745c84948f6/networkidnetworknameTest Network/networknamenetmask255.255.255.0/netmaskipaddress10.1.1.1/ipaddressisolationurivlan://2303/isolationuribroadcasturivlan://2303/broadcasturitraffictypeGuest/traffictypetypeIsolated/typeisdefaultfalse/isdefaultmacaddress02:00:1e:d5:00:02/macaddress/nicnicid962d70e4-454c-4e89-9f9f-170e027026a0/idnetworkid370174c4-ce3a-4b29-91e0-f0d08b71ef18/networkidnetmask255.255.255.192/netmaskgateway10.223.138.65/gatewayipaddress10.223.138.67/ipaddressisolationurivlan://1381/isolationuribroadcasturivlan://1381/broadcasturitraffictypePublic/traffictypeisdefaulttrue/isdefaultmacaddress06:18:dc:00:00:0a/macaddress/nicnicidddec1f87-3af5-4a63-a689-7e004f50ba1b/idnetworkidd98f68de-62c6-4f5b-b135-e2540b475804/networkidnetmask255.255.0.0/netmaskgateway169.254.0.1/gatewayipaddress169.254.2.164/ipaddresstraffictypeControl/traffictypeisdefaultfalse/isdefaultmacaddress0e:00:a9:fe:02:a4/macaddress/nicjobstatus0/jobstatus/router/listroutersresponse Thanks, Min Chen
Re: Setting up a better eclipse environment....
Thanks I dropped that value down. For some reason I get this exception in Eclipse, but not my normal console: Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.cloud.vm.dao.DomainRouterDaoImpl]: Constructor threw exception; nested exception is java.lang.OutOfMemoryError: Java heap space at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:162) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate( SimpleInstantiationStrategy.java:76) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean( AbstractAutowireCapableBeanFactory.java:990) ... 327 more Caused by: java.lang.OutOfMemoryError: Java heap space On Wed, Mar 6, 2013 at 11:10 AM, Kelven Yang kelven.y...@citrix.com wrote: Mike, you are giving too much to MaxPermSize, with latest master/ASF 4.1 branch, -XX:MaxPermSize=128m would be enough Kelven On 3/5/13 11:04 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: -XX:MaxPermSize=1024m -Xmx2048m -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: [DOCS] Sprint on Friday
Hi Joe, I moved 1442 to 4.2 since the updated patch wasn't in time for 4.1. I also assigned the issue to myself. Kanzhe On Wed, Mar 6, 2013 at 8:23 AM, Joe Brockmeier j...@zonker.net wrote: Hi all, Having another Doc Sprint this Friday - please join us! We currently have 47 bugs open for 4.1.0, several are unassigned at the moment. Note that almost all of these are for documenting new features - it'd be *very* helpful if we can get someone to pick them up and if the developer of the features can be in IRC to answer questions. CLOUDSTACK-1478: Document baremetal kickstart CLOUDSTACK-1442: Document BigSwitch plugin CLOUDSTACK-1441: Document ApiDiscoverService CLOUDSTACK-997: Improve documentation of assignVirtualMachine API CLOUDSTACK-895: Document autoscale request handling capacity by provisioning LB appliances feature CLOUDSTACK-883: Document 3rd party plugin feature CLOUDSTACK-856: Document CPU and memory overcommit functionality CLOUDSTACK-827: Document new advanced searching capabilities CLOUDSTACK-823: Document any changes to the baremetal provisioning feature I will try to have the new install docs done by Friday so we can test those as well. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- Kanzhe Jiang MTS at BigSwitch
Re: [PROPOSAL] BVT for CloudStack checkins
First +1 on BVT. Second, should we consider the idea of having a staging area for people to check-in? Which is that making master always the stable(reasonable) branch for main development, but whenever people make check-ins, it goes into staging first, and we have maintainers(could be automatic) to run whatever test framework we have and only perform automatic merge to master from staging area after a successful test-run? Kelven On 3/6/13 4:21 AM, Prasanna Santhanam t...@apache.org wrote: Great to see you kick this off Alex! I have a few ideas for this and had been looking for help as well .. I had a draft lying around of an email you sent me long ago about tiered testing and I think your proposal fits very well on this: The tl;dr of that conversation was as below - improve simulator for runtime testability - customize to model and inject failures - make a habit of writing tests around bug reports (I started tagging tests since api_refactoring on JIRA already. look for the integration-test label) - make integration testing easier using factories and DSLs (from Chiradeep) (part 1 of this work was started on this in the marvin-refactor branch) More comments inline On Wed, Mar 06, 2013 at 12:12:11AM +0530, Alex Huang wrote: Hi All, As most of you are aware, the master branch keeps getting broken by checkins for various reasons. Committers need to be more responsible about their checkins but I don't think we can depend on that happening. There are various reasons. The most obvious to me is that granting committership is not based on code competency. (And I don't think it should.) Given that we need to build a BVT system for ensure that checkins do not break the branch. Here's my proposal: Existing components that we'll use. - Citrix has contributed its testing to Apache. - Apache CloudStack has already a simulator that's been used for scale testing. - Marvin - DevCloud-kvm Work Proposal: - Convert the Citrix testing into three phases: o Setup o Test o Verify I do the build, package, setup, test, verify in my integration test pipeline and a similar pipeline for a developer combined into easily runnable maven profiles/lifecycles/goals would be great to have. - Add a Setup and Verify phase for the simulator - Add all of the agent commands necessary for the simulator to pass the testing. - Add a Setup and Verify phase for devCloud-kvm The setups exists as configs in the marvin sandbox already. Just need to hook it up with mvn. For verify there is a simple python script testSetupSuccess.py already that checks two things - system VMs are up - built-in templates are downloaded This should be a good start IMO. Currently devcloud-kvm is a bit hard to run from a developer environment. But it's great to have in a continuous environment backed by a KVM host with a Linux 3.0 kernel. Marcus has written up some pretty good documentation for this. If someone can help bring up that setup I can assist in bringing up the tests using my devcloud-ci scripts. I'm bringing up devcloud after Kelven 'alerted' us of the memory fix. - Add two more profiles to pom o Checkin-test-with-simulator: Runs the testing against the simulator o Checkin-test-with-devCloud: Runs the testing against devcloud - All of the profiles will attempt to also check the merge list that Chip has proposed.' - We will also change marvin to easily add zones with actual hardware. It will be based on a data driven document to do the setup. This is currently partly doable using a properties file in the sandbox $ python advanced_env.py -i xen.properties -o xen.cfg gives out a advanced zone config for the properties specified. Is data driven similar or you are talking about a DSL that Edison mentioned at CCC12? For a developer to checkin: - S/he must writes marvin tests for their feature and add it to the BVT. I made some progress on this in my marvin-refactor branch and will collect my thoughts in an FS that I am drafting. The marvin tests are difficult to write in their current form. I'm following Chiradeep's recommendation for providing factories and once those are baked a DSL language devs can quickly mock down tests against a simulator using the above mentioned mvn profiles. - S/he must run the checkin tests to verify everything works. - If the feature contains a hardware/vpx component, simulation must be added. At this point, everything is about the developer writing in their feature branch and merging in. On infrastructure side: - We'll setup continuous BVT based on the simulator. I brought this up on the IRC and the list y'day, so +1 - happy to help - I again push that we must use Gerrit to test the code before it gets merge into the branch but I'll leave that for someone else to do that. Let me
Re: Review Request: [CLOUDSTACK-1535] kvm agent will silently ignore many exceptions
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9774/#review17479 --- Ship it! Ship It! - edison su On March 6, 2013, 9:54 a.m., Hiroaki Kawai wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9774/ --- (Updated March 6, 2013, 9:54 a.m.) Review request for cloudstack. Description --- Current kvm agent will silently ignore many exception, and there's no way to see what really happened. This patch will log in trace level log that was silently ignored. And also, it will fix huge bare Exception catch, which is very harmful because it also catches RuntimeException. This addresses bug CLOUDSTACK-1535. Diffs - core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java fc7f08f plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHABase.java af89d9b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 3c848de plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtXMLParser.java 3a61403 Diff: https://reviews.apache.org/r/9774/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Building on Cloudstack
On Wed, Mar 6, 2013 at 1:17 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Serge A. Salamanka [mailto:salsa-...@tut.by] Sent: Wednesday, March 06, 2013 2:16 AM To: cloudstack-dev@incubator.apache.org Subject: Re: Building on Cloudstack On 06.03.2013 08:50, Seif Eddine Jemli wrote: You asked me about the scheduler i would like to implement. In fact, i have a school project: i have to divide matrix calculus on several VM's, the VM's have to calculate then return the results to the scheduler for aggregation. The scheduler have then to send the aggregated results to the user who typed the matrices. so the scheduler: * * *-have to contact cloudstack and ask for X number of VM's* *-then the vm's get work assigned to them crunch the work and return the results to the scheduler for aggregation* * * * * what do you think of this project? Is it feasible? Thanks in advance for your help. The VM's by themselves are just simple OS boxes. To run some tasks on them you will need a job execution environment. There are plenty of solutions that could be used for that purpose. I'm personally looking at using IPython [1] and UNICORE [2] for accessing the computing resources provided in cloud. There is also an idea to use QosCosGrid [3] software stack but all this requires experiments with setups. We need some way to provision required resources in cloud with specially prepared VMs. This could be achieved through CloudStack API or with a help of BOSH [4]. Interesting topic. Yesterday, I read an article about google's borg and twitter's mesos: http://www.wired.com/wiredenterprise/2013/03/google-borg-twitter-mesos/ At the end of the article, it says: Yes, there are other ways of efficiently spreading workloads across a cluster of servers. You could use virtualization, where you run virtual servers atop your physical machines and then load them with whatever software you like. But with Borg and Mesos, you don't have to worry about juggling all those virtual machines. Are you trying to do the same thing like Borg and Mesos does, but using CloudStack + Virtual Machine? What CloudStack can provide is to allocate resources(virtual machines), e.g. I want 2GHz cpu, 2G memory, then you can call cloudstack api to create a VM with the same service offering. After VM is booted up, need a way to distribute workloads(e.g. Hadoop/Spark jobs) into VM. Seems, it's possible to port Mesos's hadoop code (https://svn.apache.org/repos/asf/incubator/mesos/trunk/hadoop/mesos/) to use CloudStack. Mesos is now part of the incubator: http://incubator.apache.org/mesos/ --David
Re: Building on Cloudstack
that's exactly what i am trying to do, distribute calculus on the VM's created by cloudstack. what about HADOOP??how should i use it?
Summary of IRC meeting in #cloudstack-meeting, Wed Mar 6 17:05:26 2013
Members present: Animesh, vogxn, _ps_, chipc, Humbedooh, jzb, widodh, sudhap, serverchief, ke4qqq Meeting summary: 1. Preface 2. Active Feature Release: Overall Status a. chipc start thread on the quality of 4.1.0 (jzb, 2) b. http://is.gd/api41bugs (jzb, 2) c. widodh to merge DEB packaging changes into 4.1 (cherry-pick) on Friday (chipc, 2) d. https://issues.apache.org/jira/browse/CLOUDSTACK-1515 (chipc, 2) 3. Active Feature Release: QA Status 4. Active Feature Release: Doc Status a. jzb send doc status to the ML (jzb, 4) 5. Active Feature Release: Additional Issues a. jzb start 4.1.0 marketing discussion on -marketing ML (jzb, 5) 6. Active Bug-Fix Release 7. Active Bug-Fix Release: Additional Issues 8. Master branch 9. Infra 10. Additional Items? Actions: - chipc start thread on the quality of 4.1.0 (jzb, 17:11:29) - widodh to merge DEB packaging changes into 4.1 (cherry-pick) on Friday (chipc, 17:15:37) - jzb send doc status to the ML (jzb, 17:34:03) - jzb start 4.1.0 marketing discussion on -marketing ML (jzb, 17:38:13) IRC log follows: # 1. Preface # 17:05:41 [jzb]: Good morning, afternoon, or evening as the case may be. Thanks for showing up, folks. 17:06:02 [jzb]: Let's get started with the standing agenda # 2. Active Feature Release: Overall Status # 17:06:20 [jzb]: chipc: you want to take it away? 17:06:31 [chipc]: sure 17:06:38 [chipc]: 2013-03-22 is supposed to be our first RC 17:06:46 [chipc]: as of right now, we have 7 outstanding blockers and 22 critical bugs for 4.1... that's a big number IMO 17:06:49 [chipc]: We need to bring the release criteria thread to a close 17:07:01 [chipc]: specifically, because I think it's going to matter when we evaluate readiness for 4.1 17:07:10 [chipc]: also sebgoa suggested a bug sprint... my thought is that this is a good thing, but I'm concerned about code churn, so it will have to 17:07:11 [chipc]: be carefully orchestrated 17:07:25 [chipc]: packaging remains outstanding, and is concerning 17:07:25 [chipc]: not sure what to do about that 17:07:25 [serverchief]: chipc, where would i find list of bugs 17:07:40 [serverchief]: is that something send by Sudha on dev list? 17:07:47 [chipc]: serverchief: issues.a.o/browse/CLOUDSTACK 17:07:47 [ke4qqq]: serverchief: query it on jira 17:07:55 [chipc]: then search for affects version of 4.1 17:07:57 [serverchief]: got it 17:08:32 [chipc]: so basically, that's all I have for 4.1... concerned about bug counts, and concerned about how to do a bug sprint in a way that does more good than harm 17:08:41 [chipc]: topics that need to be worked out on the ML though 17:08:47 [chipc]: so for overview EOF 17:09:05 [jzb]: ke4qqq: any experience with bug sprints from Fedora? 17:09:18 [jzb]: without excess churn ? 17:09:27 [ke4qqq]: jzb: sure, but nothing that quells the concerns of chipc 17:09:43 [jzb]: I'm really concerned about the number of major bugs outstanding. 17:10:10 [ke4qqq]: I'm terribly concerned about the number of API bugs 17:10:10 [chipc]: ok, so perhaps we just need to do the sprint anyway... and figure out how to do regression testing after it 17:10:10 [jzb]: I don't think we necessarily have to close *all* bugs that are tagged major, but releasing with more than 100 seems bad. 17:10:25 [chipc]: ke4qqq: +1 to the API concerns 17:10:52 [chipc]: ok, how about this... we don't have a specific ML thread talking about the quality state of 4.1 started 17:10:53 [ke4qqq]: ACTION is going to triage a number of those bugs - many of them are really 4.2 bugs (add new UI functionality for instance) 17:11:00 [chipc]: I'll take that action, and we can work this on list 17:11:00 [sudhap]: chipc:QA just got unblocked on features and you will see more incoming 17:11:07 [sudhap]: so count that for bug sprints 17:11:09 [chipc]: sudhap: I was sure we would 17:11:29 [jzb]: #action chipc start thread on the quality of 4.1.0 17:11:44 [chipc]: jzb: thx - you beat me to it 17:12:06 [chipc]: actually, packaging may need to happen first 17:12:14 [chipc]: we are still outstanding on DEB packaging 17:12:27 [jzb]: #link http://is.gd/api41bugs 17:12:42 [ke4qqq]: chipc: I am tempted to merge what they have - so we find more problems sooner 17:12:50 [chipc]: I know widodh was working on it a bit, and noa helped a bit as well... but we need to bring it to closure 17:12:50 [jzb]: Looks like 17 API bugs outstanding, 17:12:58 [ke4qqq]: s/merge/have merged 17:13:13 [widodh]: chipc: here 17:13:27 [widodh]: I'm actually working on the packaging every day, the agent is at 98% 17:13:35 [chipc]: widodh: any thoughs on how we can help get that completed / tested? 17:13:42 [widodh]: haven't touched the management server, aka, haven't verified if it works yet 17:14:08 [widodh]: for now it's mainly just install the packages and see what goes wrong. We can create issues for everything, but most of the time the fixes are very small 17:14:22
Re: Review Request: CLOUDSTACK-874 Ability to delete Events and Alerts
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9753/ --- (Updated March 6, 2013, 6:16 p.m.) Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min Chen. Changes --- Added unit tests and resolved conflicts with the latest code. Description --- This feature will provide the functionality to delete or archive the Alerts/Events. Delete or archive alerts APIs are available only for root-admin, delete or archive events are available for regular users. Functional Spec:https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+delete+or+archive+Events+and+Alerts This addresses bugs Ability, Alerts, CLOUDSTACK-874, Events, and, delete, and to. Diffs (updated) - api/src/com/cloud/alert/Alert.java 050f97f api/src/com/cloud/event/Event.java 1a61636 api/src/com/cloud/server/ManagementService.java 1736da3 api/src/org/apache/cloudstack/api/ApiConstants.java 1b544fd api/src/org/apache/cloudstack/api/command/admin/resource/ArchiveAlertsCmd.java PRE-CREATION api/src/org/apache/cloudstack/api/command/admin/resource/DeleteAlertsCmd.java PRE-CREATION api/src/org/apache/cloudstack/api/command/user/event/ArchiveEventsCmd.java PRE-CREATION api/src/org/apache/cloudstack/api/command/user/event/DeleteEventsCmd.java PRE-CREATION client/tomcatconf/commands.properties.in dd0c3f8 core/src/com/cloud/alert/AlertVO.java f6089d6 core/src/com/cloud/event/EventVO.java ac46f24 core/src/com/cloud/event/dao/EventDao.java bfcb818 core/src/com/cloud/event/dao/EventDaoImpl.java 44fbb03 server/src/com/cloud/alert/dao/AlertDao.java eb1faa5 server/src/com/cloud/alert/dao/AlertDaoImpl.java 2f3be88 server/src/com/cloud/api/ApiDispatcher.java 764b3ae server/src/com/cloud/api/query/QueryManagerImpl.java 8d8663a server/src/com/cloud/api/query/vo/EventJoinVO.java f29a942 server/src/com/cloud/configuration/Config.java 418f97d server/src/com/cloud/server/ManagementServerImpl.java 3c615e1 server/test/com/cloud/alert/AlertControlsUnitTest.java PRE-CREATION server/test/com/cloud/event/EventControlsUnitTest.java PRE-CREATION setup/db/db/schema-410to420.sql f3112a1 Diff: https://reviews.apache.org/r/9753/diff/ Testing --- Tested the new API archiveAlerts, deleteAlerts, archiveEvents, deleteEvents with all the possible combinations of parameters as input on my local CloudStack setup. Thanks, Sanjay Tripathi
CloudStack in the News
All, Robert van der Meulen was kind enough to share this with us on the marketing mailing list, and personally I believe that it is important enough to see across the lists so that you can share with others across your organizations, friends, colleagues, blogs, twitters, etc… This is great exposure for Apache CloudStack and when we get questions about Is CloudStack ready for Production? here's one reference that clearly shows that it is! Thanks, Matt Hi all, We just released this: http://www.prnewswire.com/news-releases/leaseweb-usa-adds-authentic-private-virtual-networking-to-its-cloud-195551701.html This is CloudStack advanced networking (for 'cloud') and CloudStack Basic networking (for 'virtual server') as a product. Thought it might be on-topic (as I mention CloudStack in the release, and we contribute to the project) - if this kind of stuff is too commercial for this list, let me know. We're now running 6 Cloudstack setups (in datacenters in NL, Germany and USA) serving thousands of instances to customers - and are obviously happy with it :) As part of the product there's some firewall functionality in our control panel (built on the firewalling stuff in 4.x/apache setup, and security groups in the 2.x/citrix setup we run for the classical virtual server product) - built on top of the CS api. Met vriendelijke groet / kind regards, Robert van der Meulen Manager Cloud www.leaseweb.comhttp://www.leaseweb.com/ T: +31 (0)20 316 2880 E: r.vandermeu...@leaseweb.commailto:r.vandermeu...@leaseweb.commailto:r.vandermeu...@leaseweb.com
Re: Review Request: CLOUDSTACK-1402: listRouters API response doesn't return linklocal IP and public IP details
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9784/#review17483 --- Ship it! Pushed to 4.1: commit cbbc488d3c878e95b8155280a220a7fa4262dc8d Author: Min Chen min.c...@citrix.com Date: Wed Mar 6 10:11:28 2013 -0800 CLOUDSTACK-1402: listRouters API response doesn't return linklocal IP and public IP details. - Chip Childers On March 6, 2013, 6:16 p.m., Min Chen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9784/ --- (Updated March 6, 2013, 6:16 p.m.) Review request for cloudstack and Chip Childers. Description --- This patch fixed the blocker defect CLOUDSTACK-1402. This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-1402. Diffs - server/src/com/cloud/api/query/dao/DomainRouterJoinDaoImpl.java cdb859e Diff: https://reviews.apache.org/r/9784/diff/ Testing --- Run listRouters api with the patch, it returns the linkLocal and public IP details along with guest Ip, see below. listroutersresponse cloud-stack-version=4.1.0-SNAPSHOTcount1/countrouterid160e5c1b-f2f6-4d18-90fc-838b9dca516f/idzoneid1547abf3-6805-4a5a-b552-64c56c627e5f/zoneidzonenameTest Zone/zonenamedns172.52.126.11/dns1dns272.52.126.12/dns2networkdomaincs2cloud.internal/networkdomaingateway10.223.138.65/gatewaynamer-9-VM/namepodide4d59b71-54fa-4da1-8a47-4c268cfe4412/podidhostid0ab78594-1326-4093-89ef-3b876afbb9e2/hostidhostnameRack3Host12.lab.vmops.com/hostnamelinklocalip169.254.2.164/linklocaliplinklocalmacaddress0e:00:a9:fe:02:a4/linklocalmacaddresslinklocalnetmask255.255.0.0/linklocalnetmasklinklocalnetworkidd98f68de-62c6-4f5b-b135-e2540b475804/linklocalnetworkidpublicip10.223.138.67/publicippublicmacaddress06:18:dc:00:00:0a/publicmacaddresspublicnetmask255.255.255.192/publicnetmaskpublicnetworkid370174c4-ce3a-4b29-91e0-f0d08b71ef18/publicnetworkidguestipaddress10.1.1.1/guestipaddressguestmacaddress02:00:1e:d5:00:02/guestmacaddressguestnetmask255.255.255.0/guestnetmaskguestnetworkid54535bed-f40c-4522-b60f-b745c84948f6/guestnetworkidtemplateidc64d8cf4-81dc-11e2-b8cf-066a9a000451/templateidcreated2013-02-28T15:20:29-0800/createdstateRunning/stateaccountadmin/accountdomainidc6276150-81dc-11e2-b8cf-066a9a000451/domainiddomainROOT/domainserviceofferingid09b00fbc-cfab-460f-8066-0778e48efb8d/serviceofferingidserviceofferingnameSystem Offering For Software Router/serviceofferingnameisredundantrouterfalse/isredundantrouterredundantstateUNKNOWN/redundantstatenicid2e0a0771-6be9-47a4-a37b-afa11a5e0c5f/idnetworkid54535bed-f40c-4522-b60f-b745c84948f6/networkidnetworknameTest Network/networknamenetmask255.255.255.0/netmaskipaddress10.1.1.1/ipaddressisolationurivlan://2303/isolationuribroadcasturivlan://2303/broadcasturitraffictypeGuest/traffictypetypeIsolated/typeisdefaultfalse/isdefaultmacaddress02:00:1e:d5:00:02/macaddress/nicnicid962d70e4-454c-4e89-9f9f-170e027026a0/idnetworkid370174c4-ce3a-4b29-91e0-f0d08b71ef18/networkidnetmask255.255.255.192/netmaskgateway10.223.138.65/gatewayipaddress10.223.138.67/ipaddressisolationurivlan://1381/isolationuribroadcasturivlan://1381/broadcasturitraffictypePublic/traffictypeisdefaulttrue/isdefaultmacaddress06:18:dc:00:00:0a/macaddress/nicnicidddec1f87-3af5-4a63-a689-7e004f50ba1b/idnetworkidd98f68de-62c6-4f5b-b135-e2540b475804/networkidnetmask255.255.0.0/netmaskgateway169.254.0.1/gatewayipaddress169.254.2.164/ipaddresstraffictypeControl/traffictypeisdefaultfalse/isdefaultmacaddress0e:00:a9:fe:02:a4/macaddress/nicjobstatus0/jobstatus/router/listroutersresponse Thanks, Min Chen
RE: [PROPOSAL] BVT for CloudStack checkins
That's gerrit part of the proposal. I don't have enough karma with Infra to make that work. Dave or someone else need to take that up. --Alex -Original Message- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Wednesday, March 6, 2013 10:22 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [PROPOSAL] BVT for CloudStack checkins First +1 on BVT. Second, should we consider the idea of having a staging area for people to check-in? Which is that making master always the stable(reasonable) branch for main development, but whenever people make check-ins, it goes into staging first, and we have maintainers(could be automatic) to run whatever test framework we have and only perform automatic merge to master from staging area after a successful test-run? Kelven On 3/6/13 4:21 AM, Prasanna Santhanam t...@apache.org wrote: Great to see you kick this off Alex! I have a few ideas for this and had been looking for help as well .. I had a draft lying around of an email you sent me long ago about tiered testing and I think your proposal fits very well on this: The tl;dr of that conversation was as below - improve simulator for runtime testability - customize to model and inject failures - make a habit of writing tests around bug reports (I started tagging tests since api_refactoring on JIRA already. look for the integration-test label) - make integration testing easier using factories and DSLs (from Chiradeep) (part 1 of this work was started on this in the marvin-refactor branch) More comments inline On Wed, Mar 06, 2013 at 12:12:11AM +0530, Alex Huang wrote: Hi All, As most of you are aware, the master branch keeps getting broken by checkins for various reasons. Committers need to be more responsible about their checkins but I don't think we can depend on that happening. There are various reasons. The most obvious to me is that granting committership is not based on code competency. (And I don't think it should.) Given that we need to build a BVT system for ensure that checkins do not break the branch. Here's my proposal: Existing components that we'll use. - Citrix has contributed its testing to Apache. - Apache CloudStack has already a simulator that's been used for scale testing. - Marvin - DevCloud-kvm Work Proposal: - Convert the Citrix testing into three phases: o Setup o Test o Verify I do the build, package, setup, test, verify in my integration test pipeline and a similar pipeline for a developer combined into easily runnable maven profiles/lifecycles/goals would be great to have. - Add a Setup and Verify phase for the simulator - Add all of the agent commands necessary for the simulator to pass the testing. - Add a Setup and Verify phase for devCloud-kvm The setups exists as configs in the marvin sandbox already. Just need to hook it up with mvn. For verify there is a simple python script testSetupSuccess.py already that checks two things - system VMs are up - built-in templates are downloaded This should be a good start IMO. Currently devcloud-kvm is a bit hard to run from a developer environment. But it's great to have in a continuous environment backed by a KVM host with a Linux 3.0 kernel. Marcus has written up some pretty good documentation for this. If someone can help bring up that setup I can assist in bringing up the tests using my devcloud-ci scripts. I'm bringing up devcloud after Kelven 'alerted' us of the memory fix. - Add two more profiles to pom o Checkin-test-with-simulator: Runs the testing against the simulator o Checkin-test-with-devCloud: Runs the testing against devcloud - All of the profiles will attempt to also check the merge list that Chip has proposed.' - We will also change marvin to easily add zones with actual hardware. It will be based on a data driven document to do the setup. This is currently partly doable using a properties file in the sandbox $ python advanced_env.py -i xen.properties -o xen.cfg gives out a advanced zone config for the properties specified. Is data driven similar or you are talking about a DSL that Edison mentioned at CCC12? For a developer to checkin: - S/he must writes marvin tests for their feature and add it to the BVT. I made some progress on this in my marvin-refactor branch and will collect my thoughts in an FS that I am drafting. The marvin tests are difficult to write in their current form. I'm following Chiradeep's recommendation for providing factories and once those are baked a DSL language devs can quickly mock down tests against a simulator using the above mentioned mvn profiles. - S/he must run the checkin tests to verify everything works. - If the feature contains a
Re: Setting up a better eclipse environment....
If you run directly through Eclipse, you don't need -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n You may put your memory settings to the debug profile under JRE tab for JVM settings Kelven On 3/6/13 10:16 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Thanks I dropped that value down. For some reason I get this exception in Eclipse, but not my normal console: Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.cloud.vm.dao.DomainRouterDaoImpl]: Constructor threw exception; nested exception is java.lang.OutOfMemoryError: Java heap space at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:162) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.inst antiate( SimpleInstantiationStrategy.java:76) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.instantiateBean( AbstractAutowireCapableBeanFactory.java:990) ... 327 more Caused by: java.lang.OutOfMemoryError: Java heap space On Wed, Mar 6, 2013 at 11:10 AM, Kelven Yang kelven.y...@citrix.com wrote: Mike, you are giving too much to MaxPermSize, with latest master/ASF 4.1 branch, -XX:MaxPermSize=128m would be enough Kelven On 3/5/13 11:04 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: -XX:MaxPermSize=1024m -Xmx2048m -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play **
Re: [DOCS] Sprint on Friday
On Wed, Mar 6, 2013, at 12:20 PM, Radhika Puthiyetath wrote: I suppose CLOUDSTACK-856: Document CPU and memory overcommit functionality is signed up by Jessica. CC'ed so she can grab that one if she wants it. Or even if she doesn't want it, but is willing to do the work anyway. :-) As I am familiar with the NetScaler AutoScale feature, I would pick up CLOUDSTACK-895: Document autoscale request handling capacity by provisioning LB appliances feature. Thanks! Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: [ACS41][QA] BigSwitch network plugin
The updated patch was not in time for 4.1. The feature wasn't complete in 4.1 I will re-submit the patch to master later today. On Wed, Mar 6, 2013 at 8:45 AM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Would like to check if anyone is interested to do QA for this feature [1] Big Switch network plugin. Before that would like to check with Murali/Khanzi if dev work is complete for this?? Besides description I do not see any other documentation submitted for this like PRD/FS [1] https://issues.apache.org/jira/browse/CLOUDSTACK-733 -- Kanzhe Jiang MTS at BigSwitch
RE: [ACS41][QA] BigSwitch network plugin
Thanks Kanzhe, Moved it to 4.2. Thanks /sudha -Original Message- From: Kanzhe Jiang [mailto:kanzhe.ji...@bigswitch.com] Sent: Wednesday, March 06, 2013 10:09 AM To: cloudstack-dev@incubator.apache.org Cc: Murali Reddy; khanzi.zi...@bigswitch.com Subject: Re: [ACS41][QA] BigSwitch network plugin The updated patch was not in time for 4.1. The feature wasn't complete in 4.1 I will re-submit the patch to master later today. On Wed, Mar 6, 2013 at 8:45 AM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Would like to check if anyone is interested to do QA for this feature [1] Big Switch network plugin. Before that would like to check with Murali/Khanzi if dev work is complete for this?? Besides description I do not see any other documentation submitted for this like PRD/FS [1] https://issues.apache.org/jira/browse/CLOUDSTACK-733 -- Kanzhe Jiang MTS at BigSwitch
[4.0.x] waf doesn't seem to be honoring --build-number=$BUILD_NUMBER
I am running ./waf rpm --package-version=4.0.1 --build-number=2 from
within the 4.0.1 release tarball and --build-number doesn't seem to be
honored. I have a workaround, but anyone have insight into why waf
isn't passing this to %{_rel}??
--David
RE: [PROPOSAL] BVT for CloudStack checkins
- improve simulator for runtime testability
- customize to model and inject failures
- make a habit of writing tests around bug reports (I started tagging tests
since api_refactoring on JIRA already.
look for the integration-test label)
- make integration testing easier using factories and DSLs (from
Chiradeep)
Sorry for long thread again. All my opinion is don't distract from tools,
improving
Marvin should be good enough. Below are points that you can simply skip.
I used to create a DSL after studying Domain Specific Language (by Martin
Fowler), using Python.
From my experience, I feel it's not suitable for CloudStack integration test.
Here are points:
1. Syntax puzzle
The DSL I created is known as internal DSL which builds on syntax of host
language,
internal DSL saves your time to write parser but limited by host language's
ability. For example:
Target(
name='deploy',
actions = [
Action(id='zone', name='createZone',
args=IN(name='testZone')),
Action(id='pod', name='createPod', args=IN(name='testPod',
zoneUuid=O('zone').uuid)),
],
depends = ['deploydb'],
)
RunTarget('deploy')
This is an example my DSL applying to CloudStack test, you see a few syntaxes
which are not intuitive.
Actually with a well-defined library the case could be as simple as:
import actions
import nose
@nose.time(600)
def test_deploy():
zone = actions.createZone(name='testZone')
pod = actions.createPod(name='testPod', zoneUuid=zone.uuid)
test_deploy()
which is very pythonic every Python programmer can easily understand.
Maybe I am an inexperience DSL writer, but syntax puzzle is common problem for
DSL, I really think we gain little
by introducing such thing into our test framework
2. capability
DSL varying from common language usually lacks loop, condition statement, and
sometimes variable. But
these things are very important to our test. if you strip these abilities from
your DSL, I believe you will finally
add them back that ends up with writing a common language, then you have been
distracted much from writing
test case
3. it's not our business now
The urgent need for CloudStack now is a set of reliable test cases, which I
think could be done by improving current
Marvin. Building our DSL distracts us at this point.
4. you don't even need to search a test framework for this time being
When I studying DSL, I ever looked into some famous test framework. For
Behavior Driven Test I looked Cucumber(Ruby),
for Model Driven Test I looked fpmt(the name maybe wrong, written by a French).
They both use DSL. My conclusion is the
benefit of DSL is for stuff that has nothing to do with test logic itself. For
example, driving test cases, producing document/report,
scheduling random test case combination ...
they are nice to have, but not urgent. So for our purpose, I would suggest
using python nose which is a unit test case framework but
can still use for integration test. simple, quick, and easy.
(part 1 of this work was started on this in the marvin-refactor
branch)
More comments inline
On Wed, Mar 06, 2013 at 12:12:11AM +0530, Alex Huang wrote:
Hi All,
As most of you are aware, the master branch keeps getting broken by
checkins for various reasons. Committers need to be more responsible
about their checkins but I don't think we can depend on that
happening. There are various reasons. The most obvious to me is that
granting committership is not based on code competency.
(And I don't think it should.) Given that we need to build a BVT
system for ensure that checkins do not break the branch.
Here's my proposal:
Existing components that we'll use.
- Citrix has contributed its testing to Apache.
- Apache CloudStack has already a simulator that's been used for
scale
testing.
- Marvin
- DevCloud-kvm
Work Proposal:
- Convert the Citrix testing into three phases:
o Setup
o Test
o Verify
I do the build, package, setup, test, verify in my integration test pipeline
and
a similar pipeline for a developer combined into easily runnable maven
profiles/lifecycles/goals would be great to have.
- Add a Setup and Verify phase for the simulator
- Add all of the agent commands necessary for the simulator to pass
the testing.
- Add a Setup and Verify phase for devCloud-kvm
The setups exists as configs in the marvin sandbox already. Just need to hook
it up with mvn. For verify there is a simple python script testSetupSuccess.py
already that checks two things
- system VMs are up
- built-in templates are downloaded
This should be a good start IMO.
Currently devcloud-kvm is a bit hard to run from a developer environment.
But it's great to have in a continuous environment backed by a KVM host
with a Linux 3.0 kernel. Marcus
Re: IPv6 plan - questions
On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill dcah...@midokura.com wrote: Hi, Hi Dave, I've been catching up on IPv6 plans by reading the functional specs and Jira tickets - it's great to have so much material to refer to. I still have a few questions though, and I'm hoping someone involved with the feature can enlighten me. *[Support for Providers other than Virtual Router]* In [3], the spec says No external device support in plan. What does this mean exactly? Because CloudStack also supports using external devices as network controller e.g. Juniper SRX as firewall and NetScaler as load balancer. The words here said is just we don't support these devices when using IPv6. For example, if using Providers other than the Virtual Router, does the UI still allow setting IPv6 addresses? If so, do we attempt to pass IPv6 addresses to the Providers no matter what, or do we check whether the Provider has IPv6 support? Yes, we checked it when you try to create a IPv6 network(currently only support advance shared network). *[Networking Modes]* Advanced Shared mode and Basic mode are mentioned in the Jira ticket [1] - Isolated Network is mentioned briefly in [2], but I wanted to check if the Advanced Isolated and VPC modes are on the roadmap? There is no basic isolated network, so Isolated network is what we're talking about. We haven't got plan for VPC yet. And one correction: we didn't support basic mode for phase 1. We support only advance shared network in phase 1. The supported cases are described in FS. Jira ticket only provided a rough idea at the time. *[IP Address Management / IPAM]* From [1], re: handing out IPv6 addresses: One way could be that the network admin creates a static route for a /48 towards a Virtual Router and then the VR can hand out /64s to Instances. With IPv4, IPAM is handled by the CloudStack management server, and the VR is told which IP address to give to the VM over DHCP. Would this change with IPv6? The VR can hand out /64s to instances sounds like the VR is handling IPAM to some extent. Well, it's not how it works now. Please refer to the FS. The current implementation works like before. VR get a /64 then handle out IPv6 addresses to VM. From [3], Router advertisement should be sent by public gateway in the network. - to double-check, does this mean the router outside the CloudStack network should send RAs, but the VR won't send RAs? Yes. Because in phase 1, we support only advance shared network, in which case, VR is NOT the gateway. So we assume the gateway router outside CloudStack should send out RA to the VMs. But in the phase 2, VR would acting as gateway, then it would send out RAs. --Sheng Thanks, Dave. [1] IPv6 Support main Jira ticket https://issues.apache.org/jira/browse/CLOUDSTACK-452 [2] IPv6 Support in CloudStack FS https://cwiki.apache.org/CLOUDSTACK/ipv6-support-in-cloudstack.html [3] IPv6 Support FS https://cwiki.apache.org/CLOUDSTACK/ipv6-support.html
StoragePoolVO Issue with 4.1
A new column was added to storage_pool, called storage_provider_id. When trying to access a StoragePoolVO instance (when I go to attach a volume to a VM) I popped a null pointer. This may be related to CLOUDSTACK-1547, but I'm not sure yet. The bigger issue in my mind though, is the fact that the assert in GenericDaoBase wasn't tripped! (line 1683) assert (attr != null) : How come I can't find + meta.getCatalogName(index) + . + meta.getColumnName(index); My questions are. Why doesn't the default startup for cloudstack mvn -pl :cloud-client-ui jetty:run enable asserts? (the -ea flag)? Why in the world is SqlGenerator using STAR in it's queries? I've pasted the query it generated below. This new column isn't mapped as an attribute. SELECT storage_pool.* from storage_pool LEFT JOIN storage_pool_details ON storage_pool.id = storage_pool_details.pool_id WHERE storage_pool.removed is null and storage_pool.data_center_id = 1 and (storage_pool.pod_id = 1 or storage_pool.pod_id is null) and (storage_pool.cluster_id = 1 OR storage_pool.cluster_id IS NULL) AND (((storage_pool_details.name='bssan') AND (storage_pool_details.value='true'))) GROUP BY storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name) = 1 -Ryan Dietrich
[DOCS] [ACS41] Status Update for 4.1.0
Hey all, I touched on this a bit in the sprint email, but I wanted to give a status update for 4.1.0 docs and see if we can find takers for the unassigned docs. Status: We have 42 open doc bugs against 4.1.0. We're down to 5 unassigned bugs (perhaps less by the time you read this!): http://is.gd/und41 Please take a look and see if you can grab one of these! Also - please be sure to go through and triage any bugs assigned to you. I've found a number of bugs that are tagged 4.1.0 that either seem to have had a patch committed, or the feature was moved to 4.2 or later. If something is still in progress and it hasn't been updated recently, please provide a short update so we know that it's still on your plate. I'm going to be pretty aggressive about closing out, grabbing, or looking to re-assign some of the hanging bugs that haven't been touched in months. Questions, comments, suggestions, or flames? Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
[ACS41][QA] Clarification on add/remove network on VM
Marcus/Mice/Sateesh, Looks like you have already tested this feature[1] on all HV. Can any test case list be provided for this?? Any automation done for it?? Just checking if this is enough validation or do you need QA to pick up this feature for validation?? If QA is needed, looking for community members to see if they would be interested to contribute. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-645 Thanks /sudha
Re: VXLAN Support
Hi Paul, Others can probably give a more detailed answer, but I can tell you that folks are working on re-adding Cisco Nexus 1000V DVS support (see https://issues.apache.org/jira/browse/CLOUDSTACK-301) and there is a larger effort for Cisco VNMC integration (described here https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cisco+VNMC+integration) that specifically mentions adding VXLAN support. Hope that helps! - Chris On Wed, Mar 6, 2013 at 9:19 AM, Paul Sanders paul.sander...@gmail.comwrote: Afternoon All, Is vxlan support on the roadmap? Cisco are pushing the technology heavily. Thanks Paul --- Kind Regards Paul Sanders Mail: paul.sander...@googlemail.com
Re: Using newer DIY SystemVMs
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
- template creation works
- snapshot to template works
I won't be able to test VPC/advance zone of DevCloud, ipv6 etc.
someone from QA would have to help.
Thanks Marcus for your suggestion, will compress qcow2 and test on KVM
today.
I need help on testing/fixing VMWare systemvm
Re: Using newer DIY SystemVMs
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable
aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
(blogs.citrix.com/2012/10/04/convert-a-raw-image-to-xenserver-vhd/)
I'm able to ship appliances that work for Xen. Chiradeep, there is no
need to use the powershell hack now, if people still want vhdx, they
can use that hack. The current appliance for Xen (vbox-raw-vhd)
works.
At least appliance for HyperV and Xen works:
http://jenkins.cloudstack.org/job/build-systemvm-master/
I've tested and found that:
- patching happens
- password server works
- apache was running, user data works
-
Reverting UI for IPv6 in 4.1
Hi, Since we didn't plan to include ipv6 template as default for 4.1 release, is it necessary to revert the UI part of IPv6 to avoid confusion in 4.1? We can support API only for 4.1 --Sheng
Re: Reverting UI for IPv6 in 4.1
On Wed, Mar 6, 2013 at 1:54 PM, Chip Childers chip.child...@sungard.com wrote: On Wed, Mar 06, 2013 at 01:50:20PM -0800, Sheng Yang wrote: Hi, Since we didn't plan to include ipv6 template as default for 4.1 release, is it necessary to revert the UI part of IPv6 to avoid confusion in 4.1? We can support API only for 4.1 --Sheng So we talked about it being experimental. Do you think we should make experimental = API-based configuration only? I tend to lean that way myself. I am OK with it, just want to hear more people's idea on it. If it's only API-based, it would be more difficult for potential user to try it. But left UI there without default system vm template support would be misleading. --Sheng
Re: Reverting UI for IPv6 in 4.1
UI + docs on how to use the feature via api and its caveats (system template X). On Wed, Mar 6, 2013 at 2:08 PM, Sheng Yang sh...@yasker.org wrote: On Wed, Mar 6, 2013 at 1:54 PM, Chip Childers chip.child...@sungard.com wrote: On Wed, Mar 06, 2013 at 01:50:20PM -0800, Sheng Yang wrote: Hi, Since we didn't plan to include ipv6 template as default for 4.1 release, is it necessary to revert the UI part of IPv6 to avoid confusion in 4.1? We can support API only for 4.1 --Sheng So we talked about it being experimental. Do you think we should make experimental = API-based configuration only? I tend to lean that way myself. I am OK with it, just want to hear more people's idea on it. If it's only API-based, it would be more difficult for potential user to try it. But left UI there without default system vm template support would be misleading. --Sheng
GIT JIRA integration!
Devs, We have GIT JIRA integration. When making a checkin, simply mention any tickets by ticket number. The checking will generate a comment on the tickets you mention. Here's an example: https://issues.apache.org/jira/browse/COUCHDB-1418 I'm going to ask Infra if they can let us close tickets, etc, from commit messages. If you have any requests, let me know here, and I will gather them up. Thanks, -- NS
Re: Using newer DIY SystemVMs
After reading a little more about upstart, I don't think this script
does anything. I'm not entirely sure at the moment however how best to
ensure that networking starts after cloud-early-config, short of
converting cloud-early-config to an upstart script. It looks like this
debian build is using upstart just for networking, and everything else
uses the standard sysvinit ordering.
On Wed, Mar 6, 2013 at 2:49 PM, Marcus Sorensen shadow...@gmail.com wrote:
Just to be clear, that script may have no effect whatsoever, and I'm
not sure how to verify other than rebooting a bunch of times. I don't
have the time to do that at the moment.
On Wed, Mar 6, 2013 at 2:48 PM, Marcus Sorensen shadow...@gmail.com wrote:
There may be one other minor thing that needs to be addressed. In
getting rid of the patchdisk, my networking on the router is a bit
inconsistent. It looks like maybe networking is starting before
cloud-early-config completes, as /etc/network/interfaces looks right,
but I don't always get an ip on eth0.
I know next to nothing about upstart, and haven't had a chance to test
much, so if someone else can help that would be great. I've tried this
though and it worked the two times I rebooted, after 70% failures on
reboot. It goes it /etc/init/cloud-early-config-wait.conf
- script start here
#cloud-early-config-wait
start on (starting networking or starting network-interface)
instance $JOB
script
start cloud-early-config || true
# Waiting forever is ok.. upstart will kill this job when
# the service we tried to start above either starts or stops
while sleep 3600 ; do :; done
end script
script end here---
On Wed, Mar 6, 2013 at 9:10 AM, Marcus Sorensen shadow...@gmail.com wrote:
On Wed, Mar 6, 2013 at 2:09 AM, Rohit Yadav bhais...@apache.org wrote:
Thanks a lot Marcus, your findings have been useful. I've applied the
locale fix and a grub2 boot timeout fix (systemvms should boot 5
seconds faster now).
Alright so far we're good, tested and systemvm seems to work on KVM
(Marcus) and Xen, anyone to help us with VMWare?
Marcus, about the qemu-ga, we need to patch all our templates as per
systemvm type (ssvm, cpvm or rvm), for that we're using the
systemvm.iso to patch the template appliance and we reboot once
patching is done successfully in cloud-early-config. So, with using
qemu-ga or our own daemon (assumming through socket we already got
authorized key), do we want to make mgmt server or host copy the
scripts inside the systemvm or just continue using current patching
mechanism that uses the iso to mount and patch? Marcus can you share
how we can use the new systemvm on devcloud-kvm (osx/vmware-fusion).
Regards.
I think the systemvm.iso is a completely fine way of getting new code
onto the system vms. My main goal at this point was to just get rid of
the patch disk portion. Also, since it sounds like we're wanting to
move to a link-local API to control the system vms I think we'll
forego qemu-guest-agent or putting our own daemon on the virtio serial
device and simply use it to copy the cmdline/authorized keys.
If this updated system vm checks out, I'll update the devcloud-kvm
packages with it preinstalled, replacing the older one. Or in the
meantime what I've been doing is simply downloading yours and moving
it into place over the existing one, giving it the same name, before
deploying anything.
On Wed, Mar 6, 2013 at 6:43 AM, Marcus Sorensen shadow...@gmail.com
wrote:
Oh, and I have yet to test all of the vpc functions, but so far so
good. I was able to bring up the VPC, it got it's gateways all
configured, and my public ip with portforwarding rule/ acl to allow 22
in worked.
On Tue, Mar 5, 2013 at 6:04 PM, Marcus Sorensen shadow...@gmail.com
wrote:
Rohit, I think I tracked down why the router keeps rebooting. When it
comes up, the first thing we do is run get_template_version.sh, which
replies:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Cloudstack Release 4.2.0 Tue Mar 5 13:17:51 UTC
2013a8af8cdd546e575e64f69b6f80ef949c
Looks like we don't like that locale warning:
GetDomRVersionAnswer:{result:false,details:bash: warning:
setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I can fix it by running this in the system vm:
locale-gen en_US.UTF-8
On Tue, Mar 5, 2013 at 10:43 AM, Chiradeep Vittal
chiradeep.vit...@citrix.com wrote:
OK, one more niggle about the previous system vm. We tried to enable
aesni
[1] to boost encryption performance (ipsec vpn, anything ssl), but the
system vm would crash on Vmware if we did that (hence the module
blacklisted). Could someone try the new systemvm on VMWare with aesni
enabled? I believe it is as simple as
modprobe aesni_intel and
openssl 1.0.1
[1] http://en.wikipedia.org/wiki/AES_instruction_set
On 3/4/13 10:46 PM, Rohit Yadav bhais...@apache.org wrote:
Hi all,
Thanks to Mate
Re: GIT JIRA integration!
Did you mean this for couchdb? On Mar 6, 2013, at 5:32 PM, Noah Slater nsla...@apache.org wrote: Devs, We have GIT JIRA integration. When making a checkin, simply mention any tickets by ticket number. The checking will generate a comment on the tickets you mention. Here's an example: https://issues.apache.org/jira/browse/COUCHDB-1418 I'm going to ask Infra if they can let us close tickets, etc, from commit messages. If you have any requests, let me know here, and I will gather them up. Thanks, -- NS
Re: GIT JIRA integration!
Nope! I meant this for CloudStack. I just used a CouchDB ticket as a demo! I think this may be old news for you guys though... On 6 March 2013 22:59, Chip Childers chip.child...@sungard.com wrote: Did you mean this for couchdb? On Mar 6, 2013, at 5:32 PM, Noah Slater nsla...@apache.org wrote: Devs, We have GIT JIRA integration. When making a checkin, simply mention any tickets by ticket number. The checking will generate a comment on the tickets you mention. Here's an example: https://issues.apache.org/jira/browse/COUCHDB-1418 I'm going to ask Infra if they can let us close tickets, etc, from commit messages. If you have any requests, let me know here, and I will gather them up. Thanks, -- NS -- NS
[DISCUSS]Incremental build
Maven 3 doesn't support incremental build(https://cwiki.apache.org/MAVEN/incremental-builds.html), so it takes a long time(4-7mins) to make a build, even I just make a small changes in the source code. I know, you can specify which projects to build by using -pl instead of build whole projects. But usually, it's quite annoying, as I need to manually make sure incremental build works correctly. Are there other people asking for incremental build? Maybe switch to Gradle?:)
Re: [DISCUSS]Incremental build
On Wed, Mar 6, 2013 at 6:09 PM, Edison Su edison...@citrix.com wrote: Maven 3 doesn't support incremental build(https://cwiki.apache.org/MAVEN/incremental-builds.html), so it takes a long time(4-7mins) to make a build, even I just make a small changes in the source code. I know, you can specify which projects to build by using -pl instead of build whole projects. But usually, it's quite annoying, as I need to manually make sure incremental build works correctly. Are there other people asking for incremental build? Maybe switch to Gradle?:) After the pain from ant-maven. I am against switching build tools again :) I'm just learning to deal with maven as it is. --David
Review Request: (CLOUDSTACK-1558) vCenter service cookie parsing is wrong
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9786/ --- Review request for cloudstack and Min Chen. Description --- I'm sorry this is a bug I put before in the patch of CLOUDSTACK-1529 ( https://reviews.apache.org/r/9768/ ) . The bug is that cookie header value assigned was a single value from cookie key value pair. Correct value is a serialized format of key value pairs which can be get by CookieSpec#formatCookies. This addresses bug CLOUDSTACK-1558. Diffs - vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareClient.java cbae5a9 Diff: https://reviews.apache.org/r/9786/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: (CLOUDSTACK-1558) vCenter service cookie parsing is wrong
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9786/ --- (Updated March 6, 2013, 11:28 p.m.) Review request for cloudstack and Min Chen. Description --- I'm sorry this is a bug I put before in the patch of CLOUDSTACK-1529 ( https://reviews.apache.org/r/9768/ ) . The bug is that cookie header value assigned was a single value from cookie key value pair. Correct value is a serialized format of key value pairs which can be get by CookieSpec#formatCookies. This addresses bug CLOUDSTACK-1558. Diffs - vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareClient.java cbae5a9 Diff: https://reviews.apache.org/r/9786/diff/ Testing --- Thanks, Hiroaki Kawai
Review Request: Remove VNS isolation option from UI
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9787/ --- Review request for cloudstack and Chiradeep Vittal. Description --- The updated BigSwitch plugin patch didn't make into 4.1. Remove the VNS option from 4.1 UI. The plugin will be in 4.2. This addresses bug 1345. Diffs - ui/scripts/ui-custom/zoneWizard.js 718b454 Diff: https://reviews.apache.org/r/9787/diff/ Testing --- Launched the UI and confirmed the VNS is removed from isolation method in addZone wizard. Thanks, Kanzhe Jiang
What branch is 4.1 in?
Hi, I'd like to switch to 4.1 for a bit (been using master for a while now), but I want to make sure I have the correct branch. There is a branch called 4.1. Is that one the right one? Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: What branch is 4.1 in?
On Wed, Mar 6, 2013, at 05:44 PM, Mike Tutkowski wrote: I'd like to switch to 4.1 for a bit (been using master for a while now), but I want to make sure I have the correct branch. There is a branch called 4.1. Is that one the right one? Yep. 4.1 is 4.1. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: What branch is 4.1 in?
Thanks! I was hoping it would be that simple. :) On Wed, Mar 6, 2013 at 4:49 PM, Joe Brockmeier j...@zonker.net wrote: On Wed, Mar 6, 2013, at 05:44 PM, Mike Tutkowski wrote: I'd like to switch to 4.1 for a bit (been using master for a while now), but I want to make sure I have the correct branch. There is a branch called 4.1. Is that one the right one? Yep. 4.1 is 4.1. Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
[ACS402] Status of 4.0.2 - two blocker bugs remaining
Hey all, A quick update on the status of 4.0.2. We have two blocker bugs that need attention: CLOUDSTACK-1151: vmware systemVm template upgrade is missing in 4.0 upgrade CLOUDSTACK-528: Failed to create secondary storage Nitin - would you please provide an update on 1151? 528 is unassigned, we need someone to pick this one up. CLOUDSTACK-643: Also needs to be taken care of, and is a bug against 4.1.0 as well. Kishan, would you please look in on this in the next day or so? Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RSA key gets overridden on every management server startup
I've noticed that on every cloudStack management server startup, the public RSA key gets overridden (vi ~/.ssh/id_rsa.pub). I'm running cloudStack on OSX 10.8.2. Not sure if it's a known issue, so raised a new bug against 4.2 (donno if it exists in 4.1 branch). https://issues.apache.org/jira/browse/CLOUDSTACK-1560 -Alena.
