Re: [jira] [Commented] (CLOUDSTACK-2683) creation of system VMs fail when using devcloud
It's because the tomcat memory limits were raised in 4.1 to deal with the initial memory footprint increase back in Feb. It hasn't run in stock devcloud since. I increased the dom0 memory on mine to make it work. I think there was subsequent work in April or so to get the memory back down, so we may be able to decrease the xmx=2G or whatever it is back down. XCP may not have ever increased their run limit. On Sun, May 26, 2013 at 12:43 AM, Prasanna Santhanam (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667216#comment-13667216 ] Prasanna Santhanam commented on CLOUDSTACK-2683: This doesn't seem to be a problem on a XCP 1.6 host. The devcloud xcp-xapi.log lists the following lines: [20130526T06:36:32.088Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|audit] VM.set_memory_limits: self = 9b937ca6-9548-d334-0d01-54657aea2c3f (s-5-VM); static_min = 134217728; static_max = 104857600; dynamic_ min = 104857600; dynamic_max = 104857600 [20130526T06:36:32.090Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|xapi] Raised at xapi_vm_memory_constraints.ml:56.13-184 - xapi_vm.ml:157.1-90 - pervasiveext.ml:22.2-9 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at pervasiveext.ml:26.22-25 - rbac.ml:229.16-23 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at rbac.ml:238.10-15 - server_helpers.ml:79.11-41 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|dispatcher] Server_helpers.exec exception_handler: Got exception MEMORY_CONSTRAINT_VIOLATION: [ Memory limits must satisfy: static_min ≤ dy namic_min ≤ dynamic_max ≤ static_max ] The memory limits are in the required range with static_min = dynamic_min = dynamic_max = static_max Further investigating the failure. creation of system VMs fail when using devcloud --- Key: CLOUDSTACK-2683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Xen Affects Versions: 4.2.0 Environment: Host OS is Mac OS X, devcloud 2.0 appliance Reporter: Shane Witbeck Following the devcloud guide [1] in the wiki, I get the following exception when the management server attempts to create system VMs: WARN [xen.resource.CitrixResourceBase] (DirectAgent-21:) Catch Exception: class com.xensource.xenapi.Types$XenAPIException due to MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max at com.xensource.xenapi.Types.checkResponse(Types.java:1936) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VM.setMemoryLimits(VM.java:3735) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixResourceBase.java:3530) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1240) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1582) at com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResource.java:143) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:546) at com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:137) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) [1]
Re: [jira] [Commented] (CLOUDSTACK-2683) creation of system VMs fail when using devcloud
I should say that it randomly fails with the larger memory limits (as the process grows it eventually causes problems), if dom0 has a small amount of memory like devcloud does. Shane said in a previous message that 4.1 works. So I'm not entirely sure, but one thing to check at least would be that the java process isn't asking for as much or more memory than dom0 has. On Sun, May 26, 2013 at 1:01 AM, Marcus Sorensen shadow...@gmail.com wrote: It's because the tomcat memory limits were raised in 4.1 to deal with the initial memory footprint increase back in Feb. It hasn't run in stock devcloud since. I increased the dom0 memory on mine to make it work. I think there was subsequent work in April or so to get the memory back down, so we may be able to decrease the xmx=2G or whatever it is back down. XCP may not have ever increased their run limit. On Sun, May 26, 2013 at 12:43 AM, Prasanna Santhanam (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667216#comment-13667216 ] Prasanna Santhanam commented on CLOUDSTACK-2683: This doesn't seem to be a problem on a XCP 1.6 host. The devcloud xcp-xapi.log lists the following lines: [20130526T06:36:32.088Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|audit] VM.set_memory_limits: self = 9b937ca6-9548-d334-0d01-54657aea2c3f (s-5-VM); static_min = 134217728; static_max = 104857600; dynamic_ min = 104857600; dynamic_max = 104857600 [20130526T06:36:32.090Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|xapi] Raised at xapi_vm_memory_constraints.ml:56.13-184 - xapi_vm.ml:157.1-90 - pervasiveext.ml:22.2-9 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at pervasiveext.ml:26.22-25 - rbac.ml:229.16-23 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at rbac.ml:238.10-15 - server_helpers.ml:79.11-41 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|dispatcher] Server_helpers.exec exception_handler: Got exception MEMORY_CONSTRAINT_VIOLATION: [ Memory limits must satisfy: static_min ≤ dy namic_min ≤ dynamic_max ≤ static_max ] The memory limits are in the required range with static_min = dynamic_min = dynamic_max = static_max Further investigating the failure. creation of system VMs fail when using devcloud --- Key: CLOUDSTACK-2683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Xen Affects Versions: 4.2.0 Environment: Host OS is Mac OS X, devcloud 2.0 appliance Reporter: Shane Witbeck Following the devcloud guide [1] in the wiki, I get the following exception when the management server attempts to create system VMs: WARN [xen.resource.CitrixResourceBase] (DirectAgent-21:) Catch Exception: class com.xensource.xenapi.Types$XenAPIException due to MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max at com.xensource.xenapi.Types.checkResponse(Types.java:1936) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VM.setMemoryLimits(VM.java:3735) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixResourceBase.java:3530) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1240) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1582) at com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResource.java:143) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:546) at com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:137) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at
patchviasocket: Why in Perl and not native Java?
Hi Marcus, This is somewhat a rhetorical question, but I wanted to confirm anyway. The 4.2 SystemVMs use a VirtIO socket on KVM to get their boot arguments. That is great, since there is no longer a need for patch disks which enables them to run on RBD. One of the things I dislike about the KVM agent is all the scripts it runs, I'd rather see them all disappear since executing scripts and getting the correct exit statuses is always a difficult thing. Anyway, the patchviasocket.pl script opens the VirtIO Unix Socket on the hypervisor and writes some data to it. I've been searching and with some third party libraries it is also possible to do this natively from Java, for example: * http://www.matthew.ath.cx/projects/java/ * http://code.google.com/p/junixsocket/ They require libraries on the system with JNI though, so it will make our packaging efforts harder. Was this the reasoning behind doing this in Perl? If so, why Perl? Since most of the stuff in CloudStack is done in Java, Python or Bash, why Perl? Couldn't we rewrite this in Python if we don't want to do this in Java? Wido
Re: [jira] [Commented] (CLOUDSTACK-2683) creation of system VMs fail when using devcloud
We were setting the static_min in XcpOssResource (resource used by DevCloud's xcp kronos xen) to 128m and the static_max the offering had sent through was set to 100m. This caused the violation in the memory values. Introduced the appropriate override for the XcpOssResource of DevCloud. SystemVMs came up in DevCloud successfully. I had forgotten to make the fix (7ea2c95) I made last week for XCP into the DevCloud resource. Fixed now with (5b902c7) -- Prasanna., On Sun, May 26, 2013 at 01:06:23AM -0600, Marcus Sorensen wrote: I should say that it randomly fails with the larger memory limits (as the process grows it eventually causes problems), if dom0 has a small amount of memory like devcloud does. Shane said in a previous message that 4.1 works. So I'm not entirely sure, but one thing to check at least would be that the java process isn't asking for as much or more memory than dom0 has. On Sun, May 26, 2013 at 1:01 AM, Marcus Sorensen shadow...@gmail.com wrote: It's because the tomcat memory limits were raised in 4.1 to deal with the initial memory footprint increase back in Feb. It hasn't run in stock devcloud since. I increased the dom0 memory on mine to make it work. I think there was subsequent work in April or so to get the memory back down, so we may be able to decrease the xmx=2G or whatever it is back down. XCP may not have ever increased their run limit. On Sun, May 26, 2013 at 12:43 AM, Prasanna Santhanam (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667216#comment-13667216 ] Prasanna Santhanam commented on CLOUDSTACK-2683: This doesn't seem to be a problem on a XCP 1.6 host. The devcloud xcp-xapi.log lists the following lines: [20130526T06:36:32.088Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|audit] VM.set_memory_limits: self = 9b937ca6-9548-d334-0d01-54657aea2c3f (s-5-VM); static_min = 134217728; static_max = 104857600; dynamic_ min = 104857600; dynamic_max = 104857600 [20130526T06:36:32.090Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|xapi] Raised at xapi_vm_memory_constraints.ml:56.13-184 - xapi_vm.ml:157.1-90 - pervasiveext.ml:22.2-9 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at pervasiveext.ml:26.22-25 - rbac.ml:229.16-23 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|backtrace] Raised at rbac.ml:238.10-15 - server_helpers.ml:79.11-41 [20130526T06:36:32.092Z|debug|devcloud|510 INET 127.0.0.1:80|VM.set_memory_limits R:18b4b6b53f80|dispatcher] Server_helpers.exec exception_handler: Got exception MEMORY_CONSTRAINT_VIOLATION: [ Memory limits must satisfy: static_min ??? dy namic_min ??? dynamic_max ??? static_max ] The memory limits are in the required range with static_min = dynamic_min = dynamic_max = static_max Further investigating the failure. creation of system VMs fail when using devcloud --- Key: CLOUDSTACK-2683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Xen Affects Versions: 4.2.0 Environment: Host OS is Mac OS X, devcloud 2.0 appliance Reporter: Shane Witbeck Following the devcloud guide [1] in the wiki, I get the following exception when the management server attempts to create system VMs: WARN [xen.resource.CitrixResourceBase] (DirectAgent-21:) Catch Exception: class com.xensource.xenapi.Types$XenAPIException due to MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ? dynamic_min ? dynamic_max ? static_max at com.xensource.xenapi.Types.checkResponse(Types.java:1936) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VM.setMemoryLimits(VM.java:3735) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixResourceBase.java:3530) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1240) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1582) at
Re: [VOTE] Apache CloudStack 4.1.0 (third round)
Hi Chip, I'm sorry, but I'm going to have to vote -1 on this one. It's my bad, but it seems that I made a mistake on the Debian packaging side. See this commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=dc822a83d77830281402175b4a57b25b7e3b180a I just verified, cloudstack-setup-agent has variables in it like @AGENTSYSCONFDIR@ which would render the tool useless. I see this commit is already in the 4.1 branch, but it isn't in the commit you are voting on (873c19). I also found a problem with the AWSAPI package, which is in master in commit 28f7a216d8bf4da29a45cb76e5c28ee568ae1984 I already cherry-picked that one to 4.1 since it's only touching packaging and not code. Other then the packaging I'm happy with this code. I obviously wasn't able to do a full QA on my own, but the tests I've done all work, which include: * Deploying instances * Adding RBD storage * Attaching RBD volumes With the packaging resolved I'd vote +1, but for now it's -1 (binding). Wido On 05/24/2013 07:41 PM, Chip Childers wrote: Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: 873c1972c7bbe337cee2000a09451d14ebbcb728 List of changes: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
Re: [VOTE] Apache CloudStack 4.1.0 (third round)
Ok. Vote cancelled. Wido, is the 4.1 branch corrected now? I'll be back near my laptop tonight. Just want to know if there is work to do, or can I just re-spin a forth round? On May 26, 2013, at 6:01 AM, Wido den Hollander w...@widodh.nl wrote: Hi Chip, I'm sorry, but I'm going to have to vote -1 on this one. It's my bad, but it seems that I made a mistake on the Debian packaging side. See this commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=dc822a83d77830281402175b4a57b25b7e3b180a I just verified, cloudstack-setup-agent has variables in it like @AGENTSYSCONFDIR@ which would render the tool useless. I see this commit is already in the 4.1 branch, but it isn't in the commit you are voting on (873c19). I also found a problem with the AWSAPI package, which is in master in commit 28f7a216d8bf4da29a45cb76e5c28ee568ae1984 I already cherry-picked that one to 4.1 since it's only touching packaging and not code. Other then the packaging I'm happy with this code. I obviously wasn't able to do a full QA on my own, but the tests I've done all work, which include: * Deploying instances * Adding RBD storage * Attaching RBD volumes With the packaging resolved I'd vote +1, but for now it's -1 (binding). Wido On 05/24/2013 07:41 PM, Chip Childers wrote: Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: 873c1972c7bbe337cee2000a09451d14ebbcb728 List of changes: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
Re: [MERGE]object_store branch into master
On Fri, May 24, 2013 at 10:10:25PM +, Animesh Chaturvedi wrote: [Animesh] Plan means targeted for 4.2. Community review and technical quality are of course important and being attended to. The effort to find and fix issues with this change speaks for the attention to technical quality. I am simply asking how much time is needed to review. This discussion is going in circles Animesh. The answer to your question above: as much time as is needed. If the details of a set of changes were created / debated on this list (which these were not really), the review would be much shorter and easier! However, in this case, we are looking at 25 pages of review content on reviewboard, impacting many different features. Let me restate my primary concern (the one that I wish we would focus on): Why would we bring in a significant architectural change late in a release merge cycle? It hurt us to do it with Javelin, and I just don't see *any* valid argument to do it again here. I've said it before in this thread, but I'll say it again: I'm not judging the work. I'm judging the wisdom of the timing of the merge. Why can't we just wait until 4.2 is branched, and then bring this into master? It would go out with 4.3. Is there some sort of unspoken pressure that is causing you to argue against our previous consensus here? I'm really struggling to see what would make us want to do this level of change right before we cut a release branch *again*. I'm especially confused about the need to merge into master when the only delay I'm suggesting is 1 week. It's not like I'm saying wait for next year. -chip
Re: 4.1 release manager
On Sat, May 25, 2013 at 10:52:34AM -0400, Outback Dingo wrote: On Sat, May 25, 2013 at 10:33 AM, Chip Childers chip.child...@sungard.comwrote: On May 25, 2013, at 10:16 AM, Sebastien Goasguen run...@gmail.com wrote: On May 25, 2013, at 10:08 AM, Outback Dingo outbackdi...@gmail.com wrote: On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen run...@gmail.com wrote: Hi folks, Some time back I offered to be RM for 4.1.x , since then I took on the GSoC effort and won't have time to be the RM. Therefore the position is up for grabs. Any takers ? can we get a brief description of the responsibilities? I just might be interested You would be responsible to get the 4.1.x releases out the door. Keep track of the JIRA bugs that need to be applied to the 4.1 branch, cherry-pick them, do some minimal testing and conflict resolution. Then prepare the source artifacts, signature, release notes. And finally start the [VOTE] threads. Basically what Joe has been doing for 4.0.x, am I sure he can elaborate and my one sentence description. I am sure, Chip, Joe, myself and others would help you out to get in the groove. -Sebastien The only requirement is that the RM needs to be a committer for the technical aspects of the work. However, we might be able to work something out if a non committer wanted to do this. From my opinion on being an RM, I dont believe the need to be a commiter should exist. It does for the technical bits - actually doing commits to the repo, access to the release distro area, the right to call a release VOTE, etc... However I have no issues being a commiter, Im not inclined to do major works, until I shore up the work Ive done, which is very XCP specific. Sorry - just to be clear here. I'm not suggesting that someone offering to help with the release management would immediately be given commit rights. In my opinion, an RM should have some autonomy in management. An RM within this community is a facilitator for the rest of the community, as we work toward a shared goal: to do a release. Ive run RD shops for a decade, We always designated a non-dev type to manage the release, to remove the politics from the development and build process. And all senior development leaders would have to sign off on a release as being ready from their code perspective. For us it helped our developers take ownership of issues as they arose. Aside from that Id like to contribute, in light of responsibilities I do have the experience. and well some of the CS people know me and what Ive been up. :) Ill throw my hat in the ring. Id be more then happy to help. Glad you are willing to help! I do think this would be easier with a volunteer to be the official RM that's already a committer. That being said, perhaps you want to help with identifying bugs that are fixed in master, and can easily be brought into 4.1 for an eventual 4.1.1 release? That's actually the harder part of the maintenance release work. -chip
Re: [VOTE] Apache CloudStack 4.1.0 (third round)
On Sun, May 26, 2013 at 12:00:19PM +0200, Wido den Hollander wrote: Hi Chip, I'm sorry, but I'm going to have to vote -1 on this one. It's my bad, but it seems that I made a mistake on the Debian packaging side. See this commit: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=dc822a83d77830281402175b4a57b25b7e3b180a I just verified, cloudstack-setup-agent has variables in it like @AGENTSYSCONFDIR@ which would render the tool useless. I see this commit is already in the 4.1 branch, but it isn't in the commit you are voting on (873c19). I also found a problem with the AWSAPI package, which is in master in commit 28f7a216d8bf4da29a45cb76e5c28ee568ae1984 I already cherry-picked that one to 4.1 since it's only touching packaging and not code. Other then the packaging I'm happy with this code. I obviously wasn't able to do a full QA on my own, but the tests I've done all work, which include: * Deploying instances * Adding RBD storage * Attaching RBD volumes With the packaging resolved I'd vote +1, but for now it's -1 (binding). Wido I got myself to my laptop. I see that these corrections are in 4.1 now. I'll respin a release candidate right now.
[VOTE][CANCELLED] Apache CloudStack 4.1.0 (third round)
This vote is cancelled. I'll re-spin a round 4 shortly. On Fri, May 24, 2013 at 01:41:44PM -0400, Chip Childers wrote: Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: 873c1972c7bbe337cee2000a09451d14ebbcb728 List of changes: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
[VOTE] Release Apache CloudStack 4.1.0 (fourth round)
Hi All, I've created a 4.1.0 release, with the following artifacts up for a vote. The changes from round 3 are two commits related to DEB packaging. Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1 Commit: db007da15290970c842c3229a11051c20b512a65 List of changes: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1 Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/ PGP release keys (signed using A99A5D58): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Testing instructions are here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
[QA][PROPOSAL][ACS4.2] Test plan review: Portable Public IP feature
Hi, Here is the link to TestPlan : https://cwiki.apache.org/confluence/display/CLOUDSTACK/TestPlan+for+PortableIP+feature Please review and let me know your review comments. FS Link : https://cwiki.apache.org/CLOUDSTACK/portable-public-ip.html Earlier, I used to see a category for each release that contains list of plans based on release but, now I just see a generic page called TestPlans hence, uploaded it there. Thanks, SWAMY
RE: [QA][PROPOSAL][ACS4.2] Test plan review: Portable Public IP feature
Should be fine Swamy, Test plans are not categorized based on release but test execution results are so that is how I have setup the structure. You will find test execution results under each ACS release specific to that release. Thanks /sudha -Original Message- From: Venkata SwamyBabu Budumuru [mailto:venkataswamybabu.budum...@citrix.com] Sent: Sunday, May 26, 2013 8:23 AM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: [QA][PROPOSAL][ACS4.2] Test plan review: Portable Public IP feature Hi, Here is the link to TestPlan : https://cwiki.apache.org/confluence/display/CLOUDSTACK/TestPlan+for+PortableIP+feature Please review and let me know your review comments. FS Link : https://cwiki.apache.org/CLOUDSTACK/portable-public-ip.html Earlier, I used to see a category for each release that contains list of plans based on release but, now I just see a generic page called TestPlans hence, uploaded it there. Thanks, SWAMY
RE: [ANNOUNCE] New committer: Venkata Swamy
Congratulations Swamy :) -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Friday, May 24, 2013 3:00 AM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Venkata Swamy The Project Management Committee (PMC) for Apache CloudStack has asked Venkata Swamy to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Venkata! -chip on behalf of the CloudStack PMC
Re: patchviasocket: Why in Perl and not native Java?
Yes, you're welcome to rewrite it in Python. You're spot on with why it's not in Java. As for why it's in Perl, it was simple for me to do and we already have a dependency on it. As far as I've seen, the majority of what's written for the agent to call is in Bash, and this task was fairly difficult for Bash. The exceptions being security groups and the installation helpers, which are in Python, presumably because they're also difficult in Bash. The script this replaced was a Bash script. It's probably because some people are really good at Bash, but don't know Perl or Python, some are good at Python, but don't know Perl, and vice versa. Or maybe someone knows them all but has a preference on a specific tool for a specific job, for compatibility or whatever reason. I personally tend to shy away from Python if I want to write something that I know will work everywhere, due to the 2.6/2.7 compatibility and spread between distros, but that shouldn't matter for a simple script like patchviasocket.pl. Do we want to standardize and say that if it can't be in Java, and it can't be in Bash, it has to be in Python? The other dependencies on Perl are few, so we could probably wipe them out as well. If we have to limit, I'd much rather it be Java, Perl, Python than Java, Bash, Python, but it's too late for that I think. As a side note, Bash seems to be highly preferred in the agent code, even though some of the system vm scripts are fairly complex. It would be nice to see these simplified by using a more powerful language as well. On Sun, May 26, 2013 at 3:20 AM, Wido den Hollander w...@widodh.nl wrote: Hi Marcus, This is somewhat a rhetorical question, but I wanted to confirm anyway. The 4.2 SystemVMs use a VirtIO socket on KVM to get their boot arguments. That is great, since there is no longer a need for patch disks which enables them to run on RBD. One of the things I dislike about the KVM agent is all the scripts it runs, I'd rather see them all disappear since executing scripts and getting the correct exit statuses is always a difficult thing. Anyway, the patchviasocket.pl script opens the VirtIO Unix Socket on the hypervisor and writes some data to it. I've been searching and with some third party libraries it is also possible to do this natively from Java, for example: * http://www.matthew.ath.cx/projects/java/ * http://code.google.com/p/junixsocket/ They require libraries on the system with JNI though, so it will make our packaging efforts harder. Was this the reasoning behind doing this in Perl? If so, why Perl? Since most of the stuff in CloudStack is done in Java, Python or Bash, why Perl? Couldn't we rewrite this in Python if we don't want to do this in Java? Wido
Re: 4.1 release manager
On Sun, May 26, 2013 at 10:24 AM, Chip Childers chip.child...@sungard.comwrote: On Sat, May 25, 2013 at 10:52:34AM -0400, Outback Dingo wrote: On Sat, May 25, 2013 at 10:33 AM, Chip Childers chip.child...@sungard.comwrote: On May 25, 2013, at 10:16 AM, Sebastien Goasguen run...@gmail.com wrote: On May 25, 2013, at 10:08 AM, Outback Dingo outbackdi...@gmail.com wrote: On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen run...@gmail.com wrote: Hi folks, Some time back I offered to be RM for 4.1.x , since then I took on the GSoC effort and won't have time to be the RM. Therefore the position is up for grabs. Any takers ? can we get a brief description of the responsibilities? I just might be interested You would be responsible to get the 4.1.x releases out the door. Keep track of the JIRA bugs that need to be applied to the 4.1 branch, cherry-pick them, do some minimal testing and conflict resolution. Then prepare the source artifacts, signature, release notes. And finally start the [VOTE] threads. Basically what Joe has been doing for 4.0.x, am I sure he can elaborate and my one sentence description. I am sure, Chip, Joe, myself and others would help you out to get in the groove. -Sebastien The only requirement is that the RM needs to be a committer for the technical aspects of the work. However, we might be able to work something out if a non committer wanted to do this. From my opinion on being an RM, I dont believe the need to be a commiter should exist. It does for the technical bits - actually doing commits to the repo, access to the release distro area, the right to call a release VOTE, etc... well, yes if the responsibilities include modification of code, you would require access However I have no issues being a commiter, Im not inclined to do major works, until I shore up the work Ive done, which is very XCP specific. Sorry - just to be clear here. I'm not suggesting that someone offering to help with the release management would immediately be given commit rights. Which is understandable, committers need time to be vetted and work reviewed, of which I have been working for months and object storage design specific to CS, as a project of my own which hopefully, one day will see light of day in CS and a plugin In my opinion, an RM should have some autonomy in management. An RM within this community is a facilitator for the rest of the community, as we work toward a shared goal: to do a release. Ive run RD shops for a decade, We always designated a non-dev type to manage the release, to remove the politics from the development and build process. And all senior development leaders would have to sign off on a release as being ready from their code perspective. For us it helped our developers take ownership of issues as they arose. Aside from that Id like to contribute, in light of responsibilities I do have the experience. and well some of the CS people know me and what Ive been up. :) Ill throw my hat in the ring. Id be more then happy to help. Glad you are willing to help! I do think this would be easier with a volunteer to be the official RM that's already a committer. That being said, perhaps you want to help with identifying bugs that are fixed in master, and can easily be brought into 4.1 for an eventual 4.1.1 release? That's actually the harder part of the maintenance release work. -chip
Re: patchviasocket: Why in Perl and not native Java?
One thing I should add, while it makes perfect sense to me to draw a line on which technologies should be allowed in our code base, I will say that I'm fine with Java calling external scripts to do system admin work. I don't really like to see things split, like we have with libvirt where we use java bindings in some places and scripts in others (due to missing bindings), in those cases it makes sense to work toward pulling them back into java, but in general Java is a fairly poor system administration language. In addition, I'd wager that the overlap of people who are good at linux system administration and capable of scripting these tasks with those who can script these tasks in Java is very small. So I'm not really for trying to pull everything we possibly can back into Java. I'm ok with someone implementing a feature by writing a stub in the agent code that calls their system script. This is one advantage OpenStack has; being in Python it's easier for system admins to get in and work with, extend, etc. On Sun, May 26, 2013 at 10:41 AM, Marcus Sorensen shadow...@gmail.com wrote: Yes, you're welcome to rewrite it in Python. You're spot on with why it's not in Java. As for why it's in Perl, it was simple for me to do and we already have a dependency on it. As far as I've seen, the majority of what's written for the agent to call is in Bash, and this task was fairly difficult for Bash. The exceptions being security groups and the installation helpers, which are in Python, presumably because they're also difficult in Bash. The script this replaced was a Bash script. It's probably because some people are really good at Bash, but don't know Perl or Python, some are good at Python, but don't know Perl, and vice versa. Or maybe someone knows them all but has a preference on a specific tool for a specific job, for compatibility or whatever reason. I personally tend to shy away from Python if I want to write something that I know will work everywhere, due to the 2.6/2.7 compatibility and spread between distros, but that shouldn't matter for a simple script like patchviasocket.pl. Do we want to standardize and say that if it can't be in Java, and it can't be in Bash, it has to be in Python? The other dependencies on Perl are few, so we could probably wipe them out as well. If we have to limit, I'd much rather it be Java, Perl, Python than Java, Bash, Python, but it's too late for that I think. As a side note, Bash seems to be highly preferred in the agent code, even though some of the system vm scripts are fairly complex. It would be nice to see these simplified by using a more powerful language as well. On Sun, May 26, 2013 at 3:20 AM, Wido den Hollander w...@widodh.nl wrote: Hi Marcus, This is somewhat a rhetorical question, but I wanted to confirm anyway. The 4.2 SystemVMs use a VirtIO socket on KVM to get their boot arguments. That is great, since there is no longer a need for patch disks which enables them to run on RBD. One of the things I dislike about the KVM agent is all the scripts it runs, I'd rather see them all disappear since executing scripts and getting the correct exit statuses is always a difficult thing. Anyway, the patchviasocket.pl script opens the VirtIO Unix Socket on the hypervisor and writes some data to it. I've been searching and with some third party libraries it is also possible to do this natively from Java, for example: * http://www.matthew.ath.cx/projects/java/ * http://code.google.com/p/junixsocket/ They require libraries on the system with JNI though, so it will make our packaging efforts harder. Was this the reasoning behind doing this in Perl? If so, why Perl? Since most of the stuff in CloudStack is done in Java, Python or Bash, why Perl? Couldn't we rewrite this in Python if we don't want to do this in Java? Wido
Re: [jira] [Commented] (CLOUDSTACK-2406) language display error
On Sun, May 26, 2013 at 9:12 PM, Hiroaki Kawai (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667432#comment-13667432 ] Hiroaki Kawai commented on CLOUDSTACK-2406: --- I confirmed. I'll fix Japanese soon. For Japanese translations, the strings are already broken in trasifex. language display error --- Is the problem one with Transifex, or is it on our side? --David
RE: [ANNOUNCE] New committer: Sailaja Mada
Congrats Sailaja :) -Sanjeev -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: Friday, May 24, 2013 10:20 PM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] New committer: Sailaja Mada Congratulations Sailaja -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Thursday, May 23, 2013 2:21 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Sailaja Mada The Project Management Committee (PMC) for Apache CloudStack has asked Sailaja Mada to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Sailaja! -chip on behalf of the CloudStack PMC
Question about Review Request
Hi everyone, I'm trying to submit code for the first time. I'm following the instructions here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines When it says to upload my diff, I assume it means my .patch file. Is that correct? I generate such a file this way: git format-patch upstream/master --stdout solidfire_plugin.patch It works just fine, but when I try to upload it by clicking on the Create Review Request button, I get the following error: The file 'plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java' (r5f45a62) could not be found in the repository * * I'm not sure why it says this because this file is a part of the current repository. Would someone be able to explain what I might be doing wrong here? I did update from the ACS repo and merge its master (my upstream/master) into my solidfire_plugin branch recently. After doing this, I committed the changes and made my .patch file. 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 *™*
