Re: Review Request: Fixes marvin integration test for the copy template/iso between zones
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8082/ --- (Updated Nov. 29, 2012, 9 a.m.) Review request for cloudstack. Changes --- Updated the diff Description --- This is a fix 1. to populate 'destzoneid' as part of the test data by issuing listZones API. Earlier, this is provided manually in the test data. 2. to wait till the ISO/template is downloaded & installed successfully before being deleted as part of the cleanup. Diffs (updated) - test/integration/component/test_templates.py e6b2dd6 test/integration/smoke/test_iso.py 0215d89 test/integration/smoke/test_templates.py 9a7f6b1 Diff: https://reviews.apache.org/r/8082/diff/ Testing --- Testing done on Advanced zone setup and tests passed. Thanks, SrikanteswaraRao Talluri
[jira] [Created] (CLOUDSTACK-557) For createFirewallRule API startport and endport are optional arguments but in UI ports are not optional
Pranav Saxena created CLOUDSTACK-557: Summary: For createFirewallRule API startport and endport are optional arguments but in UI ports are not optional Key: CLOUDSTACK-557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-557 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.0.1 Reporter: Pranav Saxena Assignee: Pranav Saxena Priority: Minor Fix For: 4.0.1 For createFirewallRule API startport and endport are optional arguments but in UI ports are not optional. Both API and UI arguments should be same. -- 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
[jira] [Commented] (CLOUDSTACK-557) For createFirewallRule API startport and endport are optional arguments but in UI ports are not optional
[ https://issues.apache.org/jira/browse/CLOUDSTACK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506445#comment-13506445 ] Pranav Saxena commented on CLOUDSTACK-557: -- Commit: http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/46b16e59 > For createFirewallRule API startport and endport are optional arguments but > in UI ports are not optional > > > Key: CLOUDSTACK-557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.1 >Reporter: Pranav Saxena >Assignee: Pranav Saxena >Priority: Minor > Fix For: 4.0.1 > > > For createFirewallRule API startport and endport are optional arguments but > in UI ports are not optional. > Both API and UI arguments should be same. -- 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
[jira] [Resolved] (CLOUDSTACK-557) For createFirewallRule API startport and endport are optional arguments but in UI ports are not optional
[ https://issues.apache.org/jira/browse/CLOUDSTACK-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranav Saxena resolved CLOUDSTACK-557. -- Resolution: Fixed > For createFirewallRule API startport and endport are optional arguments but > in UI ports are not optional > > > Key: CLOUDSTACK-557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.1 >Reporter: Pranav Saxena >Assignee: Pranav Saxena >Priority: Minor > Fix For: 4.0.1 > > > For createFirewallRule API startport and endport are optional arguments but > in UI ports are not optional. > Both API and UI arguments should be same. -- 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: New DevCloud Appliance
On Nov 28, 2012, at 7:49 PM, Rohit Yadav wrote: > Already did that, just git pull: > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=af12a25a608cdef45547a4da83515f57fd6129bf > > Let me know if there are any other issues. I am using it as a host and nfs server, running the mgt server on my laptop. Everything works fine, except that the tiny linux VM never gets available. I tried to register it, but it never gets to the "ready" stage. thoughts ? -sebastien > > Regards. > > On 28-Nov-2012, at 8:28 AM, Sebastien Goasguen wrote: > >> Rohit, small tweak maybe: >> >> Since you set 192.168.56.10, the tools/devcloud/devcloud.cfg needs to be >> updated (was 192.168.56.2) >> >> -sebastien >> >> On Nov 28, 2012, at 3:08 AM, Rohit Yadav wrote: >> >>> I finally got the new DevCloud appliance working and tested in different >>> appliances, thanks to Prasanna. The new appliance can be used both as a all >>> in a box solution like the original DevCloud or you can run mgmt server and >>> mysql on your host os and use it as a Xen server host and NFS >>> infrastructure. It's about 862MB, and the whole setup can run within 1G RAM >>> if you disable console proxy vm from global settings, also you may run >>> multiple DevClouds. >>> >>> It's available for download from: >>> http://people.apache.org/~bhaisaab/cloudstack/devcloud >>> >>> More details on the blog: >>> http://rohityadav.in/logs/devcloud/ >>> >>> Please try the new appliance and report any issues. >>> Also help write a page on cwiki.a.o. Thanks. >>> >>> Regards. >> >
[jira] [Created] (CLOUDSTACK-558) Duplicate routerVM entry on network create!
Tamas Monos created CLOUDSTACK-558: -- Summary: Duplicate routerVM entry on network create! Key: CLOUDSTACK-558 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-558 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Environment: 3.0.2->4.0 upgrade, CentOS, VMware Reporter: Tamas Monos Priority: Blocker Hi, In 4.0 when trying to create a new network the "cloud.vm.VirtualMachineManagerImpl" calls the "Allocating entries for VM: VM[DomainRouter|r-x-VM" twice and this causes mysql exception due to the duplicate entry! 2012-11-29 13:29:27,511 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-18:job-49) Creating the router 40 in datacenter com.cloud.dc.DataCenterVO$$EnhancerByCGLIB$$88af38d9@1 2012-11-29 13:29:27,517 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-18:job-49) Allocating the domR with the hypervisor type VMware 2012-11-29 13:29:27,519 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-18:job-49) Allocating entries for VM: VM[DomainRouter|r-40-VM] 2012-11-29 13:29:27,523 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-18:job-49) Allocating nics for VM[DomainRouter|r-40-VM] 2012-11-29 13:29:27,524 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Allocating nic for vm VM[DomainRouter|r-40-VM] in network Ntwk[211|Guest|7] with requested profile NicProfile[0-0-null-10.1.1.1-vlan://937 2012-11-29 13:29:27,537 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Service SecurityGroup is not supported in the network id=211 2012-11-29 13:29:27,539 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Allocating nic for vm VM[DomainRouter|r-40-VM] in network Ntwk[202|Control|3] with requested profile null 2012-11-29 13:29:27,547 WARN [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Can't get the physical network 2012-11-29 13:29:27,548 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Allocating nic for vm VM[DomainRouter|r-40-VM] in network Ntwk[200|Public|1] with requested profile NicProfile[0-0-null-217.27.254.119-vlan://100 2012-11-29 13:29:27,556 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-18:job-49) Allocaing disks for VM[DomainRouter|r-40-VM] 2012-11-29 13:29:27,560 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-18:job-49) Allocation completed for VM: VM[DomainRouter|r-40-VM] 2012-11-29 13:29:27,560 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-18:job-49) Allocating the domR with the hypervisor type VMware 2012-11-29 13:29:27,562 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-18:job-49) Allocating entries for VM: VM[DomainRouter|r-40-VM] 2012-11-29 13:29:27,565 DEBUG [db.Transaction.Transaction] (Job-Executor-18:job-49) Rolling back the transaction: Time = 3 Name = -AsyncJobManagerImpl$1.run:398-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by -Transaction.rollback:887-Transaction.removeUpTo:830-Transaction.close:649-DatabaseCallback.interceptComplete:71-DatabaseCallback.intercept:36-VirtualNetworkApplianceManagerImpl.persist:2476-VirtualNetworkApplianceManagerImpl.persist:235-VirtualMachineManagerImpl.allocate:284-DatabaseCallback.intercept:34-VirtualMachineManagerImpl.allocate:337-VirtualNetworkApplianceManagerImpl.deployRouter:1409-VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork:1350 2012-11-29 13:29:27,567 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-18:job-49) Lock is released for network id 211 as a part of router startup in Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(47|ROOT-->Pool(201))] 2012-11-29 13:29:27,567 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-18:job-49) Cleaning up because we're unable to implement the network Ntwk[211|Guest|7] -- 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: New DevCloud Appliance
Import DevCloud and a make a snapshot (so you can rollback in case you mess up). Git pull latest, when you start make sure; host is 192.168.56.1, mgmt cidr is 192.168.56.0/24 and internal cidr (secondary storage) is 192.168.56.0/24. This is fixed in the latest, you will need to kill old ssvms, it may never show up if ssvm is unable to reach host, unable to mount storage or the cidr is incorrect. This fix actually forces host ip and cidrs before mgmt server starts: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=51a5919be13daa3c2d46f782a8ff71052ca87d80 Also, using XenCenter or if console proxy works, or via ssh on link-local, you may debug these values by checking params in the /proc/cmdline file, it should not have any incorrect values (host ip, cidr etc.). Other issue is the systemvm.iso does not get created by default and is necessary to patch the systemvm template which is common for all ssvms, cpvms, routervms. To create it you've to use the 'systemvm' profile like this: mvn clean install -P developer,systemvm It's before of this commit, may be we an enable it by default?: commit 79e5a3a3ab825f0a44c1699479cbd3481b225b05 Author: Hugo Trippaers Date: Mon Nov 19 17:16:45 2012 +0100 Summary: Don't expect that mkisofs is installed by default, use the systemvm flag to enable the iso build Regards. From: sebgoa [run...@gmail.com] Sent: Thursday, November 29, 2012 6:49 PM To: cloudstack-dev@incubator.apache.org Subject: Re: New DevCloud Appliance On Nov 28, 2012, at 7:49 PM, Rohit Yadav wrote: > Already did that, just git pull: > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=af12a25a608cdef45547a4da83515f57fd6129bf > > Let me know if there are any other issues. I am using it as a host and nfs server, running the mgt server on my laptop. Everything works fine, except that the tiny linux VM never gets available. I tried to register it, but it never gets to the "ready" stage. thoughts ? -sebastien > > Regards. > > On 28-Nov-2012, at 8:28 AM, Sebastien Goasguen wrote: > >> Rohit, small tweak maybe: >> >> Since you set 192.168.56.10, the tools/devcloud/devcloud.cfg needs to be >> updated (was 192.168.56.2) >> >> -sebastien >> >> On Nov 28, 2012, at 3:08 AM, Rohit Yadav wrote: >> >>> I finally got the new DevCloud appliance working and tested in different >>> appliances, thanks to Prasanna. The new appliance can be used both as a all >>> in a box solution like the original DevCloud or you can run mgmt server and >>> mysql on your host os and use it as a Xen server host and NFS >>> infrastructure. It's about 862MB, and the whole setup can run within 1G RAM >>> if you disable console proxy vm from global settings, also you may run >>> multiple DevClouds. >>> >>> It's available for download from: >>> http://people.apache.org/~bhaisaab/cloudstack/devcloud >>> >>> More details on the blog: >>> http://rohityadav.in/logs/devcloud/ >>> >>> Please try the new appliance and report any issues. >>> Also help write a page on cwiki.a.o. Thanks. >>> >>> Regards. >> >
askForHelp
hello,recently i do some development on cloudstack.and i success to set up the development enviroment and log in the client through http://localhost:8080/client. but when i import the project into eclipse, i come across a problem from the pom.xml in the folder deps:.the problem is : Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 (org.apache.maven.plugins:maven-dependency-plugin:2.5.1:copy-dependencies:copy-dependencies:install) and i can not fix it.can you help me. thanks, Charles.
RE: New DevCloud Appliance
One more thing, if you are developing inside DevCloud, you'll have to make sure host ip is 192.168.56.10 (or if you change the ip from /etc/network/interfaces) and make sure you've mkisofs preinstalled. I've fixed this issue in the image which I'll upload later sometime, but the change is simply to compile and install mkisofs (there was no default pkg in debian). Regards. From: sebgoa [run...@gmail.com] Sent: Thursday, November 29, 2012 6:49 PM To: cloudstack-dev@incubator.apache.org Subject: Re: New DevCloud Appliance On Nov 28, 2012, at 7:49 PM, Rohit Yadav wrote: > Already did that, just git pull: > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=af12a25a608cdef45547a4da83515f57fd6129bf > > Let me know if there are any other issues. I am using it as a host and nfs server, running the mgt server on my laptop. Everything works fine, except that the tiny linux VM never gets available. I tried to register it, but it never gets to the "ready" stage. thoughts ? -sebastien > > Regards. > > On 28-Nov-2012, at 8:28 AM, Sebastien Goasguen wrote: > >> Rohit, small tweak maybe: >> >> Since you set 192.168.56.10, the tools/devcloud/devcloud.cfg needs to be >> updated (was 192.168.56.2) >> >> -sebastien >> >> On Nov 28, 2012, at 3:08 AM, Rohit Yadav wrote: >> >>> I finally got the new DevCloud appliance working and tested in different >>> appliances, thanks to Prasanna. The new appliance can be used both as a all >>> in a box solution like the original DevCloud or you can run mgmt server and >>> mysql on your host os and use it as a Xen server host and NFS >>> infrastructure. It's about 862MB, and the whole setup can run within 1G RAM >>> if you disable console proxy vm from global settings, also you may run >>> multiple DevClouds. >>> >>> It's available for download from: >>> http://people.apache.org/~bhaisaab/cloudstack/devcloud >>> >>> More details on the blog: >>> http://rohityadav.in/logs/devcloud/ >>> >>> Please try the new appliance and report any issues. >>> Also help write a page on cwiki.a.o. Thanks. >>> >>> Regards. >> >
Re: Review Request: cs-bugtool implementation, new troubleshooting tool dedicated for collecting CS logs and basic system information
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8248/ --- (Updated Nov. 29, 2012, 2:25 p.m.) Review request for cloudstack. Changes --- Rohit, thanks for looking on this. > 1. Make python code PEP8 compliant Done. > 2. Chmod +x cs-bugtool, so it's an executable by default I am looking on the patch and see: create mode 100644 tools/support/README create mode 100755 tools/support/cs-bugtool so I assume it should be right. > 3. For the shebang interpretor use this path: /usr/bin/python Done. > Logs can have sensitive information (api, mgmt server logs for example with > auth, keys information, > access logs with full urls and sensitive values such as passwords and keys as > arguments). > Maybe we can identify such string patterns and search and replace them, add > code for doing that? I understand your concern but I am not sure how we can avoid this and how useful those information may be? We would have session keys in api-server.log which are expired and even having those session keys it would be extremely difficult to use them. Please correct me is I ma wrong? Maybe we can add some warring which will say, please be aware there may be some small piece of sensitive information in output file. And after all, user who uses this utility is going to send this info to some trusted person, support representative to process it. > 4. This is using zip (which assumes zip tool is preinstalled and which is the > case for most installations) We use Python zip library. >5. Add help docs in README. Done. Cheers, Radek. Description --- The main purpose behind cs-bugtool is to make easier collecting logs required for CloudStack/CloudPlatform troubleshooting and it mainly comes from Support. cs-bugtool collects logs, system information and cloud database dump, compress everything and creates .zip archive file ready to share with others. For those familiar with Xen/XenServer cs-bugtool name may sound similar to xen-bugtool, this similarity is intentional. Current version of cs-bugtool collects: - basic system and environment information - CP/CS management service logs - basic system logs - cloud database Current version does not accept any arguments but this may changed in next iterations of cs-bugtool. We DO NOT collect and do not want to collect any sensitive information. If there is still any sensitive pice of information please let us know and we will try to remove it or replace by meaningless data. Diffs (updated) - tools/support/README PRE-CREATION tools/support/cs-bugtool PRE-CREATION Diff: https://reviews.apache.org/r/8248/diff/ Testing --- I tested this on CS 3.0.4 and 3.0.5. Thanks, Radoslaw Smigielski
Re: New DevCloud Appliance
Great news, thank you Rohit ! I think you can tweak in devcloud project by adding more options in maven to set up advance zone instead of basic zone in devcloud VM (devcloud.cfg is just basic). On Thu, Nov 29, 2012 at 8:46 PM, Rohit Yadav wrote: > One more thing, if you are developing inside DevCloud, you'll have to make > sure host ip is 192.168.56.10 (or if you change the ip from > /etc/network/interfaces) and make sure you've mkisofs preinstalled. I've > fixed this issue in the image which I'll upload later sometime, but the > change is simply to compile and install mkisofs (there was no default pkg > in debian). > > Regards. > > From: sebgoa [run...@gmail.com] > Sent: Thursday, November 29, 2012 6:49 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: New DevCloud Appliance > > On Nov 28, 2012, at 7:49 PM, Rohit Yadav wrote: > > > Already did that, just git pull: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=af12a25a608cdef45547a4da83515f57fd6129bf > > > > Let me know if there are any other issues. > > I am using it as a host and nfs server, running the mgt server on my > laptop. Everything works fine, except that the tiny linux VM never gets > available. I tried to register it, but it never gets to the "ready" stage. > > thoughts ? > > -sebastien > > > > > Regards. > > > > On 28-Nov-2012, at 8:28 AM, Sebastien Goasguen wrote: > > > >> Rohit, small tweak maybe: > >> > >> Since you set 192.168.56.10, the tools/devcloud/devcloud.cfg needs to > be updated (was 192.168.56.2) > >> > >> -sebastien > >> > >> On Nov 28, 2012, at 3:08 AM, Rohit Yadav > wrote: > >> > >>> I finally got the new DevCloud appliance working and tested in > different appliances, thanks to Prasanna. The new appliance can be used > both as a all in a box solution like the original DevCloud or you can run > mgmt server and mysql on your host os and use it as a Xen server host and > NFS infrastructure. It's about 862MB, and the whole setup can run within 1G > RAM if you disable console proxy vm from global settings, also you may run > multiple DevClouds. > >>> > >>> It's available for download from: > >>> http://people.apache.org/~bhaisaab/cloudstack/devcloud > >>> > >>> More details on the blog: > >>> http://rohityadav.in/logs/devcloud/ > >>> > >>> Please try the new appliance and report any issues. > >>> Also help write a page on cwiki.a.o. Thanks. > >>> > >>> Regards. > >> > > > > -- Le Quang Hieu Specialist – Core Cloud Computing Dept Cloud Computing Research Center Viettel Research and Development Institute No. 380 Lac Long Quan Str, Tay Ho Dist, Hanoi, Vietnam Mobile: (84) 974616850
[jira] [Created] (CLOUDSTACK-559) source code import problem
charles_sysu created CLOUDSTACK-559: --- Summary: source code import problem Key: CLOUDSTACK-559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-559 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.0.0 Environment: ubuntu12.04_64bit eclipse+m2e Reporter: charles_sysu Fix For: 4.0.0 i can set up the development environment successfully.But when i import the source code into Eclipse,it come across some problem with the pom.xml in the deps/.The question is: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 (org.apache.maven.plugins:maven-dependency-plugin:2.5.1:copy-dependencies:copy-dependencies:install) i have tried "mvn -P deps" before i import the project. thanks. -- 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
Router VM and previous dhcp info
I had an issue with my router vm in a cluster and had to drop it and create another one. This happened for all of my zones. I had to drop and recreate all router vms. While my issue was addressed by redeploying a new router vm (typical DHCP, DNS and UserData offering) I'm not certain if the dhcp info for previous existing instances is preserved and carried over to a new router vm. I see that the IP information is stored in DB, however I dont know if the router vm pulls iP info from DB and recreates dhcpd leases fIle. As always - any feedback is appreciated. Thanks Ilya
Re: Router VM and previous dhcp info
Was there a specific issue you had? If you recreate the router and guest VMS can still get their addresses then that answers this question. I've never had a problem with recreating the router, in fact there's a global option to recreate the router root disk on every router reboot, presumably because it should be rare and it avoid having to deal with corruption. On Nov 29, 2012 8:50 AM, "Musayev, Ilya" wrote: > I had an issue with my router vm in a cluster and had to drop it and > create another one. This happened for all of my zones. I had to drop and > recreate all router vms. > > > While my issue was addressed by redeploying a new router vm (typical DHCP, > DNS and UserData offering) I'm not certain if the dhcp info for previous > existing instances is preserved and carried over to a new router vm. I see > that the IP information is stored in DB, however I dont know if the router > vm pulls iP info from DB and recreates dhcpd leases fIle. > > As always - any feedback is appreciated. > > Thanks > Ilya >
[ACS401] Blocker Bugs for 4.0.1
Hey all, We have two blocker bugs for 4.0.1 that I wanted to bring up since we're closing in on the date I'd set for the freeze (tomorrow): CLOUDSTACK-515 NVP Installation: https://issues.apache.org/jira/browse/CLOUDSTACK-515 CLOUDSTACK-505 cloudstack logs the private key in plaintext: https://issues.apache.org/jira/browse/CLOUDSTACK-505 Best, Joe -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RE: [ACS401] Blocker Bugs for 4.0.1
Hi Joe, in transit will try to fix 515 on my way. Regards. From: Joe Brockmeier [j...@zonker.net] Sent: Thursday, November 29, 2012 9:25 PM To: CloudStack Developers Subject: [ACS401] Blocker Bugs for 4.0.1 Hey all, We have two blocker bugs for 4.0.1 that I wanted to bring up since we're closing in on the date I'd set for the freeze (tomorrow): CLOUDSTACK-515 NVP Installation: https://issues.apache.org/jira/browse/CLOUDSTACK-515 CLOUDSTACK-505 cloudstack logs the private key in plaintext: https://issues.apache.org/jira/browse/CLOUDSTACK-505 Best, Joe -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: Review Request: Fixes marvin integration test for the copy template/iso between zones
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8082/#review13852 --- Where is the bug that describes the problem that needs to be fixed? - David Nalley On Nov. 29, 2012, 9 a.m., SrikanteswaraRao Talluri wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8082/ > --- > > (Updated Nov. 29, 2012, 9 a.m.) > > > Review request for cloudstack. > > > Description > --- > > This is a fix > 1. to populate 'destzoneid' as part of the test data by issuing listZones > API. Earlier, this is provided manually in the test data. > 2. to wait till the ISO/template is downloaded & installed successfully > before being deleted as part of the cleanup. > > > Diffs > - > > test/integration/component/test_templates.py e6b2dd6 > test/integration/smoke/test_iso.py 0215d89 > test/integration/smoke/test_templates.py 9a7f6b1 > > Diff: https://reviews.apache.org/r/8082/diff/ > > > Testing > --- > > Testing done on Advanced zone setup and tests passed. > > > Thanks, > > SrikanteswaraRao Talluri > >
[jira] [Created] (CLOUDSTACK-560) Usage server doesn't work in 4.0.0 due to missing db changes
David Nalley created CLOUDSTACK-560: --- Summary: Usage server doesn't work in 4.0.0 due to missing db changes Key: CLOUDSTACK-560 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-560 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.0.0 Reporter: David Nalley Assignee: Kishan Kavala Priority: Blocker Fix For: 4.0.1, 4.1.0 [Alerts] Usage job failed. Job id: 1 25 Nov 2012 03:13:00 [usage.log] 2012-11-25 03:13:00,154 ERROR [cloud.usage.UsageManagerImpl] (Usage-Job-1:null) Exception in usage manager com.cloud.utils.exception.CloudRuntimeException: DB Exception on: org.apache.commons.dbcp.DelegatingPreparedStatement@5b5a5cf Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'account.default_zone_id' in 'field list' The usage server tried to get "account.default_zone_id" from "cloud_usage" database, but the "account" table doesn't have "default_zone_id" column. Kishan: This is the same bug as http://bugs.cloudstack.org/browse/CS-15170 - which apparently didn't make it into master or 4.0 branch. -- 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
[jira] [Created] (CLOUDSTACK-561) createNetwork can block for long periods causing clients to time out when called at certain times
Marcus Sorensen created CLOUDSTACK-561: -- Summary: createNetwork can block for long periods causing clients to time out when called at certain times Key: CLOUDSTACK-561 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-561 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Environment: KVM or Xen (maybe all environments) Reporter: Marcus Sorensen Priority: Minor createNetwork can block for minutes if called when VPC router is being created (maybe non-vpc router too?), whether it's the first time or if VPC router is deleted. If I call createNetwork any time after the new VPC router is running it's fine, wether the router is stopped, starting, or running state. If I destroy the router then createNetwork also still works instantly, but when router is recreating and in 'starting' state, createNetwork blocks until this is done. Since it's a sync call this causes trouble for us, and we've worked around it in our client by never calling createNetwork if the VPC router is not 'running', but since createNetwork is sync we should really either fix the block or return 'try again later' if this state is found. -- 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: [ACS401] Blocker Bugs for 4.0.1
I'll look at 505. On Thu, Nov 29, 2012 at 10:55 AM, Joe Brockmeier wrote: > Hey all, > > We have two blocker bugs for 4.0.1 that I wanted to bring up since we're > closing in on the date I'd set for the freeze (tomorrow): > > CLOUDSTACK-515 NVP Installation: > https://issues.apache.org/jira/browse/CLOUDSTACK-515 > CLOUDSTACK-505 cloudstack logs the private key in plaintext: > https://issues.apache.org/jira/browse/CLOUDSTACK-505 > > Best, > > Joe > > -- > Joe Brockmeier > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/ >
RE: Router VM and previous dhcp info
When router vm is started through CS UI/API, CS will send all dhcp info to router VM again. Anthony > -Original Message- > From: Musayev, Ilya [mailto:imusa...@webmd.net] > Sent: Thursday, November 29, 2012 7:50 AM > To: cloudstack-dev@incubator.apache.org > Subject: Router VM and previous dhcp info > > I had an issue with my router vm in a cluster and had to drop it and > create another one. This happened for all of my zones. I had to drop > and recreate all router vms. > > > While my issue was addressed by redeploying a new router vm (typical > DHCP, DNS and UserData offering) I'm not certain if the dhcp info for > previous existing instances is preserved and carried over to a new > router vm. I see that the IP information is stored in DB, however I > dont know if the router vm pulls iP info from DB and recreates dhcpd > leases fIle. > > As always - any feedback is appreciated. > > Thanks > Ilya
Re: [ACS401] Blocker Bugs for 4.0.1
On Thu, Nov 29, 2012 at 09:46:17PM +0530, Rohit Yadav wrote: > Hi Joe, in transit will try to fix 515 on my way. Thanks! Joe -- Joe Brockmeier http://dissociatedpress.net/ Twitter: @jzb
Re: [ACS401] Blocker Bugs for 4.0.1
On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote: > I'll look at 505. Great, thanks! -- Joe Brockmeier http://dissociatedpress.net/ Twitter: @jzb
Re: [ACS401] Blocker Bugs for 4.0.1
On Thu, Nov 29, 2012 at 09:55:30AM -0600, Joe Brockmeier wrote: > We have two blocker bugs for 4.0.1 that I wanted to bring up since we're > closing in on the date I'd set for the freeze (tomorrow): > > CLOUDSTACK-515 NVP Installation: > https://issues.apache.org/jira/browse/CLOUDSTACK-515 > CLOUDSTACK-505 cloudstack logs the private key in plaintext: > https://issues.apache.org/jira/browse/CLOUDSTACK-505 Let's make that three: CLOUDSTACK-560 Usage server doesn't work in 4.0.0 due to missing db changes https://issues.apache.org/jira/browse/CLOUDSTACK-560 Best, Joe -- Joe Brockmeier http://dissociatedpress.net/ Twitter: @jzb
Re: [ACS401] Blocker Bugs for 4.0.1
On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier wrote: > On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote: >> I'll look at 505. > > Great, thanks! Fix committed to master and 4.0 branches (from the air no-less) ;-) -chip
[jira] [Resolved] (CLOUDSTACK-505) cloudstack logs the private key in plaintext
[
https://issues.apache.org/jira/browse/CLOUDSTACK-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chip Childers resolved CLOUDSTACK-505.
--
Resolution: Fixed
Assignee: Chip Childers (was: edison su)
Committed in master at:
commit e4a51731990c7599f92e00cd286d6ae760a98ed4
Author: Chip Childers
Date: Thu Nov 29 12:24:42 2012 -0500
CLOUDSTACK-505: Do not log the command response object for the
createSSHKeyPair command.
Signed-off-by: Chip Childers
Cherry Picked over to 4.0 branch as:
commit 8de21b2b745ac6eacd209fc801285fe6b82aad28
Author: Chip Childers
Date: Thu Nov 29 12:24:42 2012 -0500
CLOUDSTACK-505: Do not log the command response object for the
createSSHKeyPair command.
Signed-off-by: Chip Childers
> cloudstack logs the private key in plaintext
>
>
> Key: CLOUDSTACK-505
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-505
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0
>Reporter: Ahmad Emneina
>Assignee: Chip Childers
>Priority: Blocker
> Fix For: 4.0.1
>
>
> When creating my sshkeypair, theyre logged in the api-server.log.
> 2012-11-16 04:16:44,387 INFO [cloud.api.ApiServer] (ApiServer-8:null)
> (userId=1 accountId=1 sessionId=null) /0:0:0:0:0:0:0:1 -- GET
> /client/api?command=createSSHKeyPair&name=testkeys2&response=json&domainid=1&zone=2&account=admin
> HTTP/1.0 200
> {
> "createsshkeypairresponse": {
> "keypair": {
> "name": "testkeys2",
> "fingerprint": "f2:0c:b1:d9:be:73:4f:a9:0a:c0:c8:59:17:e0:67:07",
> "privatekey": "-BEGIN RSA PRIVATE
> KEY-\nMIICXgIBAAKBgQDD8CUiTQL26bhcDDW1kg8QqY2Pzm9EkeNwcTtglZEYkfSV7IHI\nDO7kRvB8ca4uKOpQD+jIpz0+leTQAc2JwLPzIFfTpN/mn+vwMwBviTZjYUDePkw+\nuwe97KB4Xg+RM7m0f4sPUHe9IZPshebl8nFhFpp8bL1g/FcDalJs3GhyPwIDAQAB\nAoGBAL0czVp75f6Wul/tUPF8lZnJbF5+KpqODGz8fQjNkwuZ4+3IJcMF6JTfe0FB\nH5Jh3zWDBXSVJeGAHyY8dzsbiRHRoXb4HRXUfSdMVLAlXDmH+REcE/4OY+Sd+GU2\ncrIsq9E3R2Nhr7lujP6BOO4IEzSrKFQ531lLBolCNZ/YpHThAkEA4/N1BeuB7ihI\nlzfdikjEmg3BfDn+s7FlQz42x4iAOBRBcMeO0e7ma+UWD7LUER3tuADAY3D4C/xs\nAluSbEyHdwJBANwMRK4jsmsGFf5GjH/iyVApZx/U71OR8OJx48NSdWmCzEkMdCE+\nH5Lska7j8mfAfqbOYfYqR4gwOXXHGr8XrXkCQAF9GYqMWzDe+npiVwQMLZyD8nuJ\nNWye//ZMdbcf4RZ8q2C9LOWaFc8mk9pOZKwn8eF9v8PmfPg3Ec2CI5apeUkCQQDK\nEj4TyFY07/7MZc7qNcH26j54PduVW+TgngOxv4xw2xtsTZJrYJgwHSzfdRaK7nug\nBNBy9XqA9wAdRz0plL3JAkEAiyCuxFhz6F2NhMxDX9IczJPPiJ+v6qHGwSThiBv0\n9XgwpQqrFmBdqAZ3SDjsgXkG2gAqZRuddbq55ffGSFtkpg==\n-END
> RSA PRIVATE KEY-\n"
> }
> }
> }
--
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: Router VM and previous dhcp info
Thank you Anthony. -Original Message- From: Anthony Xu [mailto:xuefei...@citrix.com] Sent: Thursday, November 29, 2012 12:07 PM To: cloudstack-dev@incubator.apache.org; Musayev, Ilya Subject: RE: Router VM and previous dhcp info When router vm is started through CS UI/API, CS will send all dhcp info to router VM again. Anthony > -Original Message- > From: Musayev, Ilya [mailto:imusa...@webmd.net] > Sent: Thursday, November 29, 2012 7:50 AM > To: cloudstack-dev@incubator.apache.org > Subject: Router VM and previous dhcp info > > I had an issue with my router vm in a cluster and had to drop it and > create another one. This happened for all of my zones. I had to drop > and recreate all router vms. > > > While my issue was addressed by redeploying a new router vm (typical > DHCP, DNS and UserData offering) I'm not certain if the dhcp info for > previous existing instances is preserved and carried over to a new > router vm. I see that the IP information is stored in DB, however I > dont know if the router vm pulls iP info from DB and recreates dhcpd > leases fIle. > > As always - any feedback is appreciated. > > Thanks > Ilya
[jira] [Created] (CLOUDSTACK-562) Unable to download DATA volume on CS4 and vSphere 5
ilya musayev created CLOUDSTACK-562: --- Summary: Unable to download DATA volume on CS4 and vSphere 5 Key: CLOUDSTACK-562 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-562 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.0.0 Environment: CS4 on CentOS 6.3 that also NFS for primary and Secondary vSphere 5 cluster with basic network Reporter: ilya musayev When i attempt to download the template via GUI, i see that cloudstack performs many calls on Virtual Center and succeeds on creating and OVF template of DATA disk i would like to export - however on the last step it fails with message "There is no secondary storage VM for secondary storage host nfs:/cloudstack-data.mydomain.com/storage/secondary" My secondary storage is present and fully functional. The logs contains the following ERROR: 2012-11-29 13:20:03,358 ERROR [cloud.api.ApiDispatcher] (Job-Executor-34:job-359) Exception while executing ExtractVolumeCmd: com.cloud.utils.exception.CloudRuntimeException: There is no secondary storage VM for secondary storage host nfs://cloudstack-data.mydomain.com/storage/secondary at com.cloud.storage.upload.UploadMonitorImpl.createVolumeDownloadURL(UploadMonitorImpl.java:281) at com.cloud.server.ManagementServerImpl.extractVolume(ManagementServerImpl.java:3041) at com.cloud.event.ActionEventCallback.intercept(ActionEventCallback.java:36) at com.cloud.api.commands.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:130) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2012-11-29 13:20:03,359 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-34:job-359) Complete async job-359, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: There is no secondary storage VM for secondary storage host nfs://cloustack-data.domain.com/storage/secondary -- 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
[jira] [Created] (CLOUDSTACK-563) Unable to create guest network in UI for Advanced Zone
ilya musayev created CLOUDSTACK-563: --- Summary: Unable to create guest network in UI for Advanced Zone Key: CLOUDSTACK-563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-563 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.0.0 Environment: CS 4.0 on CentOS 6.3 vSphere 5.0 clusters with Advanced networks Reporter: ilya musayev The UI would not allow for creation of guest Network. - Please look at the attached image. Screenshot - http://i50.tinypic.com/33zfmvs.jpg The drop down for NetworkOfferings is blank There is a dropdown for VPC - which is also blank (not needed for shared networks) We also need the ability to pick the proper Physical Network Name - which is not available/ This feature is also broken in the Add A Zone wizard, i will open a separate bug request for that. -- 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
[jira] [Created] (CLOUDSTACK-564) cloudstack UI - EIP/ELB Basic Zone - Network menu - Guest Network section - network detailView - Add Load Balancer tab - use jobid from assignToLoadBalancerRule inste
Jessica Wang created CLOUDSTACK-564: --- Summary: cloudstack UI - EIP/ELB Basic Zone - Network menu - Guest Network section - network detailView - Add Load Balancer tab - use jobid from assignToLoadBalancerRule instead of createLoadBalancerRule. Key: CLOUDSTACK-564 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-564 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- 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
[jira] [Resolved] (CLOUDSTACK-564) cloudstack UI - EIP/ELB Basic Zone - Network menu - Guest Network section - network detailView - Add Load Balancer tab - use jobid from assignToLoadBalancerRule inst
[ https://issues.apache.org/jira/browse/CLOUDSTACK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-564. - Resolution: Fixed Author: Jessica Wang #mailto:jessica.w...@citrix.com Date: 36 seconds ago (Thu Nov 29 10:55:51 2012) Commit hash:6d8cd9f5c07f22cce33f823fd4a932a8bb098edf CLOUDSTACK-564: cloudstack UI - EIP/ELB Basic Zone - Network menu - Guest Network section - network detailView - Add Load Balancer tab - use jobid from assignToLoadBalancerRule instead of createLoadBalancerRule. Contained in branches: master Contained in no tag > cloudstack UI - EIP/ELB Basic Zone - Network menu - Guest Network section - > network detailView - Add Load Balancer tab - use jobid from > assignToLoadBalancerRule instead of createLoadBalancerRule. > --- > > Key: CLOUDSTACK-564 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-564 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- 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: List API performance optimization part I.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8172/ --- (Updated Nov. 29, 2012, 6:57 p.m.) Review request for cloudstack and Prachi Damle. Changes --- Added unit testcases for those two modified list apis. Based on response to my question on dev list, this change should come with unit testcase with no dependent on db, and functional testcases that will rely on a real MS and DB running. Functional testcases for these two APIs are already existing, so no new functional tests are needed for this patch. Description --- This is part 1 of list API refactoring. Commands covered: listVmsCmd, listRoutersCmd Response covered: UserVmResponse, DomainRouterResponse. DB views created: user_vm_view, domain_router_view. This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-527. Diffs (updated) - api/src/com/cloud/api/ResponseGenerator.java 4e8fbd8 api/src/com/cloud/api/ResponseObject.java 2d08fb9 api/src/com/cloud/api/commands/ListRoutersCmd.java 8bf9ba8 api/src/com/cloud/api/commands/ListVMsCmd.java 2f6f988 api/src/com/cloud/api/response/BaseResponse.java e343a10 api/src/com/cloud/api/response/ControlledViewEntityResponse.java PRE-CREATION api/src/com/cloud/api/response/DomainRouterResponse.java d710aad api/src/com/cloud/api/response/NicResponse.java 69d5c31 api/src/com/cloud/api/response/UserVmResponse.java f74c072 api/src/com/cloud/api/view/vo/ControlledViewEntity.java PRE-CREATION api/src/com/cloud/api/view/vo/DomainRouterJoinVO.java PRE-CREATION api/src/com/cloud/api/view/vo/UserVmJoinVO.java PRE-CREATION api/src/com/cloud/server/ManagementService.java 7532cae api/src/com/cloud/vm/UserVmService.java 98d02db api/test/src/com/cloud/api/commands/test/ListRoutersCmdTest.java PRE-CREATION api/test/src/com/cloud/api/commands/test/ListVmsCmdTest.java PRE-CREATION server/src/com/cloud/api/ApiDBUtils.java 3b5f634 server/src/com/cloud/api/ApiResponseHelper.java ebe8415 server/src/com/cloud/api/ApiServer.java a5c9ea5 server/src/com/cloud/api/response/ApiResponseSerializer.java 4be5dfa server/src/com/cloud/configuration/DefaultComponentLibrary.java ef61044 server/src/com/cloud/server/ManagementServerImpl.java 117be57 server/src/com/cloud/user/AccountManager.java 90a34ad server/src/com/cloud/user/AccountManagerImpl.java f595478 server/src/com/cloud/vm/UserVmManager.java 4ce9bfe server/src/com/cloud/vm/UserVmManagerImpl.java 687f521 server/src/com/cloud/vm/dao/DomainRouterJoinDao.java PRE-CREATION server/src/com/cloud/vm/dao/DomainRouterJoinDaoImpl.java PRE-CREATION server/src/com/cloud/vm/dao/UserVmJoinDao.java PRE-CREATION server/src/com/cloud/vm/dao/UserVmJoinDaoImpl.java PRE-CREATION server/test/com/cloud/keystore/KeystoreTest.java e0e2126 server/test/com/cloud/user/MockAccountManagerImpl.java 08234fd server/test/com/cloud/vm/MockUserVmManagerImpl.java 35ee139 setup/db/create-schema.sql fff084e utils/src/com/cloud/utils/db/GenericDaoBase.java 8d5cb96 Diff: https://reviews.apache.org/r/8172/diff/ Testing --- Create a performance unit test class to test the performance time. Thanks, Min Chen
[jira] [Created] (CLOUDSTACK-565) cloudstack UI - EIP/ELB Basic Zone - Network menu > Guest Network Section > Network detailView > Add Load Balancer tab > Add VMs button: pass current login's domainId
Jessica Wang created CLOUDSTACK-565: --- Summary: cloudstack UI - EIP/ELB Basic Zone - Network menu > Guest Network Section > Network detailView > Add Load Balancer tab > Add VMs button: pass current login's domainId and account to listVirtualMachines API. Key: CLOUDSTACK-565 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-565 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- 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
[jira] [Resolved] (CLOUDSTACK-565) cloudstack UI - EIP/ELB Basic Zone - Network menu > Guest Network Section > Network detailView > Add Load Balancer tab > Add VMs button: pass current login's domainI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-565. - Resolution: Fixed Author: Jessica Wang #mailto:jessica.w...@citrix.com Date: 32 seconds ago (Thu Nov 29 11:02:34 2012) Commit hash:fefec372a2da48f15151bf927f78894654775d51 CLOUDSTACK-565: cloudstack UI - EIP/ELB Basic Zone - Network menu > Guest Network Section > Network detailView > Add Load Balancer tab > Add VMs button: pass current login's domainId and account to listVirtualMachines API. Contained in branches: master Contained in no tag > cloudstack UI - EIP/ELB Basic Zone - Network menu > Guest Network Section > > Network detailView > Add Load Balancer tab > Add VMs button: pass current > login's domainId and account to listVirtualMachines API. > -- > > Key: CLOUDSTACK-565 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-565 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- 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: Need help in updating patch for Review Request
Thanks Rohit. By following your recommended workflow, I was able to create a patch for my current review. But here comes another scenario that I need some guidance: now I need to work on another list api refactoring in parallel while current review https://reviews.apache.org/r/8172 is still pending, but the new work needs to depend on the new code that is pending review and thus is not yet in remote api_refactoring branch yet. Based on your workflow, I should do this: 1) git checkout api_refactoring (my local branch tracking remote api_refactoring branch) 2) git pull origin api_refactoring 3) git checkout -b mybranch2 But I cannot work on mybranch2 for my new feature changes since "mybranch2" does not have the required code currently in review. What should I do now? Apply the pending patch to mybranch2? If so, what is the right procedure for me to create the second patch after the first patch is approved and checked into remote api_refactoring branch? Thanks -min On 11/28/12 10:14 PM, "Rohit Yadav" wrote: >You don't sync your personal branch, "mybranch" with remote branch unless >required, you can cherry pick commits too. When you create a patch by >merge --squash this would create a single patch that is difference >between the branch on which you're squashing/merging and your personal >branch, so this would get all the new commits as one. Other way to >squash is to use git rebase -i HEAD~5 (this will let you interactively >rebase last five commits), say you've four commits/changes, you squash >them into one commit by changing the "pick" to "squash" and rebasing. > >If your new changes rely on code from remote branch, git pull them on to >your local branch tracking the remote branch and cherry pick commits to >your personal "mybranch", after you're done, you can squash them. Other >ways are you do this; git pull --rebase origin x (x is the remote branch, >and you're in your personal "mybranch"). Goto 2. > >For your last question, you actually created a branch called api-refactor >that tracks a remote branch "api_refactoring" (so you actually created a >local branch with a different name, I usually keep same names for local >branches that track remote ones) which is fine. Now do: >1. git checkout -b # this >is your personal branch off api-refactor >1a. git am >2. git add/commit new changes, no code in staging area (nothing that >requires to be committed) >3. Once you're done, git checkout api-refactor and git pull origin >api_refactoring (switch to the local branch tracking remote one and gets >latest code), next git checkout -b tempsquash >4. Create a single patch for review: git merge --squash "mybranch" # this >can have merge conflicts which is fine, this saves the reviewer handling >merge conflicts if you handle it yourself here >5. Create patch and send for review; git format-patch -o patches HEAD~1 > >Hope this helps. > > >From: Min Chen [min.chen@citrix >Sent: Thursday, November 29, 2012 11:04 AM >To: cloudstack-dev@incubator.apache.org >Cc: cloudstack-dev@incubator.apache.org >Subject: Re: Need help in updating patch for Review Request > >Thanks Rohit. > >Two more questions: >1. In your step 6, when I go back to "my ranch" to make more changes, do >i need to make "mybranch" sync with remote branch? what if my new changes >rely on new code from remote branch? In my case, my new changes are >adding new unit tests which relies on a change of pom.xml . >2. Currently I have implemented all my changes on a local branch created >using > >Git checkout -b api-refactor origin/api_refactoring > >What should I do now? > >-min > >Sent from my iPhone > >On Nov 28, 2012, at 6:59 PM, "Rohit Yadav" wrote: > >> Min, here how my workflow is now irrespective of the fact that one can >>commit or not this works for me: >> >> 0. Rule 0, you never ever work on the branch that tracks a remote >>branch, i.e. on master or on api_refactoring for example. >> 1. Say I want to work on a branch x (can be master, can be >>api_refactoring), I create my own personal branch; git checkout x; git >>checkout -b mybranch >> 2. I work on my branch "mybranch", add commit, there may be 100 >>commits, does not matter. >> 3. Time to send it for review? git checkout master or git checkout x >>(remember x was your local branch that tracks a remote branch); git pull >>origin x; >> create a merge branch, a merge branch is basically a temporary branch >>where you would squash all your 100 commits from your "mybranch" to one >>commit: >> git checkout -b mysquashbranch >> 4. Time to squash all 100 commits to one commit: >> git merge --squash "mybranch" (you're on the mysquashbranch) >> 5. git format patch -o HEAD~1, email or post on review board >> 6. Goto 2. make changes as suggested by reviewer. If patch accepted, >>stop. >> >> Hope this helps. >> >> On 28-Nov-2012, at 5:55 PM, Min Chen wrote: >> >>> Hi there, >>> >>> I have been following instructions in >>>http://incubator.apache.org/cloudstack/d
Re: Review Request: HttpClient needs releaseConnection method call
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8186/#review13865 --- Ship it! Ship It! - Hugo Trippaers On Nov. 27, 2012, 2:03 a.m., Hiroaki Kawai wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8186/ > --- > > (Updated Nov. 27, 2012, 2:03 a.m.) > > > Review request for cloudstack. > > > Description > --- > > Thanks to Hugo about pointing out the page > http://hc.apache.org/httpclient-3.x/threading.html , I found that we MUST > call releaseConnection when we're using HttpClient in conjunction with > MultiThreadedHttpConnectionManager. > > > Diffs > - > > agent/src/com/cloud/agent/AgentShell.java 774f222 > awsapi/src/com/cloud/bridge/io/S3CAStorBucketAdapter.java 2101afe > > plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java > 26e7e0d > server/src/com/cloud/cluster/ClusterServiceServletImpl.java 0c3a175 > server/src/com/cloud/maint/UpgradeManagerImpl.java c1ce3f0 > > Diff: https://reviews.apache.org/r/8186/diff/ > > > Testing > --- > > > Thanks, > > Hiroaki Kawai > >
Re: Review Request: HttpClient needs releaseConnection method call
> On Nov. 29, 2012, 7:25 p.m., Hugo Trippaers wrote: > > Ship It! Commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=a28f4cac3c6e98439d92d72ed6a29f89ecc2c7b5 - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8186/#review13865 --- On Nov. 27, 2012, 2:03 a.m., Hiroaki Kawai wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8186/ > --- > > (Updated Nov. 27, 2012, 2:03 a.m.) > > > Review request for cloudstack. > > > Description > --- > > Thanks to Hugo about pointing out the page > http://hc.apache.org/httpclient-3.x/threading.html , I found that we MUST > call releaseConnection when we're using HttpClient in conjunction with > MultiThreadedHttpConnectionManager. > > > Diffs > - > > agent/src/com/cloud/agent/AgentShell.java 774f222 > awsapi/src/com/cloud/bridge/io/S3CAStorBucketAdapter.java 2101afe > > plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java > 26e7e0d > server/src/com/cloud/cluster/ClusterServiceServletImpl.java 0c3a175 > server/src/com/cloud/maint/UpgradeManagerImpl.java c1ce3f0 > > Diff: https://reviews.apache.org/r/8186/diff/ > > > Testing > --- > > > Thanks, > > Hiroaki Kawai > >
[jira] [Resolved] (CLOUDSTACK-515) NVP Installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-515. Resolution: Fixed Fixed on 4.0 commit e9692831b5e1e90fca6fa6afbf898d9edeace878 Author: Rohit Yadav Date: Thu Nov 29 09:54:55 2012 -0800 CLOUDSTACK-515: Package nvp_commands.properties for debian This fixes the missing nvp_commands.properties in debian builds for the client package. > NVP Installation > - > > Key: CLOUDSTACK-515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 package installation >Reporter: Dimitri Desmidt >Assignee: Rohit Yadav >Priority: Blocker > Fix For: 4.0.1 > > > When installation CloudStack on Ubuntu 12.04 (package installation), the > etc/cloud/management/nicira-nvp_commands.properties file was missing. > Note: To get the installation working, I had to manually copy it from git + > restart management. -- 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
[jira] [Commented] (CLOUDSTACK-515) NVP Installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506745#comment-13506745 ] Rohit Yadav commented on CLOUDSTACK-515: Fixed on 4.0, not sure about master as pkging is still wip. > NVP Installation > - > > Key: CLOUDSTACK-515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 package installation >Reporter: Dimitri Desmidt >Assignee: Rohit Yadav >Priority: Blocker > Fix For: 4.0.1 > > > When installation CloudStack on Ubuntu 12.04 (package installation), the > etc/cloud/management/nicira-nvp_commands.properties file was missing. > Note: To get the installation working, I had to manually copy it from git + > restart management. -- 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: [ACS401] Blocker Bugs for 4.0.1
Committed on 4.0, 515. For 505, I'm not sure fix by Chip will work as logging
into api.log happens by the servlet (APIServlet) some fix like this should work:
diff --git a/server/src/com/cloud/api/ApiServlet.java
b/server/src/com/cloud/api/ApiServlet.java
index 8a1d4de..3ab6497 100755
--- a/server/src/com/cloud/api/ApiServlet.java
+++ b/server/src/com/cloud/api/ApiServlet.java
@@ -103,6 +103,13 @@ public class ApiServlet extends HttpServlet {
}
}
+/*
+ * Strips off sensitive content based on
+ */
+private String stripSensitiveContent(String str) {
+
+}
+
@SuppressWarnings("unchecked")
private void processRequest(HttpServletRequest req, HttpServletResponse
resp) {
StringBuffer auditTrailSb = new StringBuffer();
@@ -334,7 +341,7 @@ public class ApiServlet extends HttpServlet {
auditTrailSb.append(" unknown exception writing api response");
}
} finally {
-s_accessLogger.info(auditTrailSb.toString());
+
s_accessLogger.info(stripSensitiveContent(auditTrailSb.toString()));
// cleanup user context to prevent from being peeked in other
request context
UserContext.unregisterContext();
}
Some work on refactoring the api layer is going on api_refactoring, the goal is
to separate policy from mechanism and separate tightly coupled security checks
using annotations, and also fix and automate docs. Because this the
APIServlet.java will have a function, one point to strip out sensitive data
like passwords and ssh-keys from logs instead of not logging them completely.
I'll start another thread on api_refactoring and this issue.
Regards.
On 29-Nov-2012, at 9:34 AM, Chip Childers wrote:
> On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier wrote:
>> On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote:
>>> I'll look at 505.
>>
>> Great, thanks!
>
> Fix committed to master and 4.0 branches (from the air no-less) ;-)
>
> -chip
Re: [ACS401] Blocker Bugs for 4.0.1
Rohit,
Thanks... I'll do some debugging to make sure I get it covered off
correctly. However, the change I did should have eliminated the
response object from being appended to the auditTrailSb for the
command in question. Unless I'm reading the code incorrectly (which I
might be), the fact that the actual logger call happens in the
ApiServlet class shouldn't matter.
Good to know about the api_refactoring part... and I do agree that
pulling sensitive data out in a clean way would be better than the
simple if/else logic I added.
On Thu, Nov 29, 2012 at 3:13 PM, Rohit Yadav wrote:
> Committed on 4.0, 515. For 505, I'm not sure fix by Chip will work as logging
> into api.log happens by the servlet (APIServlet) some fix like this should
> work:
>
> diff --git a/server/src/com/cloud/api/ApiServlet.java
> b/server/src/com/cloud/api/ApiServlet.java
> index 8a1d4de..3ab6497 100755
> --- a/server/src/com/cloud/api/ApiServlet.java
> +++ b/server/src/com/cloud/api/ApiServlet.java
> @@ -103,6 +103,13 @@ public class ApiServlet extends HttpServlet {
> }
> }
>
> +/*
> + * Strips off sensitive content based on
> + */
> +private String stripSensitiveContent(String str) {
> +
> +}
> +
> @SuppressWarnings("unchecked")
> private void processRequest(HttpServletRequest req, HttpServletResponse
> resp) {
> StringBuffer auditTrailSb = new StringBuffer();
> @@ -334,7 +341,7 @@ public class ApiServlet extends HttpServlet {
> auditTrailSb.append(" unknown exception writing api
> response");
> }
> } finally {
> -s_accessLogger.info(auditTrailSb.toString());
> +
> s_accessLogger.info(stripSensitiveContent(auditTrailSb.toString()));
> // cleanup user context to prevent from being peeked in other
> request context
> UserContext.unregisterContext();
> }
>
> Some work on refactoring the api layer is going on api_refactoring, the goal
> is to separate policy from mechanism and separate tightly coupled security
> checks using annotations, and also fix and automate docs. Because this the
> APIServlet.java will have a function, one point to strip out sensitive data
> like passwords and ssh-keys from logs instead of not logging them completely.
> I'll start another thread on api_refactoring and this issue.
>
> Regards.
>
> On 29-Nov-2012, at 9:34 AM, Chip Childers wrote:
>
>> On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier wrote:
>>> On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote:
I'll look at 505.
>>>
>>> Great, thanks!
>>
>> Fix committed to master and 4.0 branches (from the air no-less) ;-)
>>
>> -chip
>
>
[jira] [Created] (CLOUDSTACK-566) KVM systemvm patchdisks are orphaned when system vms are deleted
Marcus Sorensen created CLOUDSTACK-566: -- Summary: KVM systemvm patchdisks are orphaned when system vms are deleted Key: CLOUDSTACK-566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-566 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.0.0 Environment: KVM/Cloudstack 4.0 with NFS/CLVM/Local storage (and more?) Reporter: Marcus Sorensen Fix For: 4.0.1 patch disks are a LibvirtComputingResource construct, and not tracked anywhere in cloudstack. Their purpose is to pass on configs to the system vms, but these disks are left behind and eventually litter your primary storage. -- 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: [ACS401] Blocker Bugs for 4.0.1
On 29-Nov-2012, at 12:23 PM, Chip Childers wrote:
> Rohit,
>
> Thanks... I'll do some debugging to make sure I get it covered off
> correctly. However, the change I did should have eliminated the
> response object from being appended to the auditTrailSb for the
> command in question. Unless I'm reading the code incorrectly (which I
> might be), the fact that the actual logger call happens in the
> ApiServlet class shouldn't matter.
Yes, I checked it gets logged by the ApiServlet class. Thanks for covering that.
Btw folks, I'm at the Venetian now, any idea how may I meet as many of you? A
little bird told me that the registration would be open for Collab12 from 4-7PM
today at the Venetian near Casanova Ballroom. Looking forward to meeting you
all.
Regards.
>
> Good to know about the api_refactoring part... and I do agree that
> pulling sensitive data out in a clean way would be better than the
> simple if/else logic I added.
>
> On Thu, Nov 29, 2012 at 3:13 PM, Rohit Yadav wrote:
>> Committed on 4.0, 515. For 505, I'm not sure fix by Chip will work as
>> logging into api.log happens by the servlet (APIServlet) some fix like this
>> should work:
>>
>> diff --git a/server/src/com/cloud/api/ApiServlet.java
>> b/server/src/com/cloud/api/ApiServlet.java
>> index 8a1d4de..3ab6497 100755
>> --- a/server/src/com/cloud/api/ApiServlet.java
>> +++ b/server/src/com/cloud/api/ApiServlet.java
>> @@ -103,6 +103,13 @@ public class ApiServlet extends HttpServlet {
>> }
>> }
>>
>> +/*
>> + * Strips off sensitive content based on
>> + */
>> +private String stripSensitiveContent(String str) {
>> +
>> +}
>> +
>> @SuppressWarnings("unchecked")
>> private void processRequest(HttpServletRequest req, HttpServletResponse
>> resp) {
>> StringBuffer auditTrailSb = new StringBuffer();
>> @@ -334,7 +341,7 @@ public class ApiServlet extends HttpServlet {
>> auditTrailSb.append(" unknown exception writing api
>> response");
>> }
>> } finally {
>> -s_accessLogger.info(auditTrailSb.toString());
>> +
>> s_accessLogger.info(stripSensitiveContent(auditTrailSb.toString()));
>> // cleanup user context to prevent from being peeked in other
>> request context
>> UserContext.unregisterContext();
>> }
>>
>> Some work on refactoring the api layer is going on api_refactoring, the goal
>> is to separate policy from mechanism and separate tightly coupled security
>> checks using annotations, and also fix and automate docs. Because this the
>> APIServlet.java will have a function, one point to strip out sensitive data
>> like passwords and ssh-keys from logs instead of not logging them
>> completely. I'll start another thread on api_refactoring and this issue.
>>
>> Regards.
>>
>> On 29-Nov-2012, at 9:34 AM, Chip Childers wrote:
>>
>>> On Wed, Nov 28, 2012 at 7:41 PM, Joe Brockmeier wrote:
On Thu, Nov 29, 2012 at 11:56:39AM -0500, Chip Childers wrote:
> I'll look at 505.
Great, thanks!
>>>
>>> Fix committed to master and 4.0 branches (from the air no-less) ;-)
>>>
>>> -chip
>>
>>
[jira] [Commented] (CLOUDSTACK-566) KVM systemvm patchdisks are orphaned when system vms are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506777#comment-13506777 ] Marcus Sorensen commented on CLOUDSTACK-566: fixed via commit 05d3f86b16e78de2f16ebcd368f662c8c8cfeb8a on master > KVM systemvm patchdisks are orphaned when system vms are deleted > - > > Key: CLOUDSTACK-566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: KVM/Cloudstack 4.0 with NFS/CLVM/Local storage (and > more?) >Reporter: Marcus Sorensen > Fix For: 4.0.1 > > > patch disks are a LibvirtComputingResource construct, and not tracked > anywhere in cloudstack. Their purpose is to pass on configs to the system > vms, but these disks are left behind and eventually litter your primary > storage. -- 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
[jira] [Resolved] (CLOUDSTACK-566) KVM systemvm patchdisks are orphaned when system vms are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen resolved CLOUDSTACK-566. Resolution: Fixed fixed via commit 05d3f86b16e78de2f16ebcd368f662c8c8cfeb8a on master > KVM systemvm patchdisks are orphaned when system vms are deleted > - > > Key: CLOUDSTACK-566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: KVM/Cloudstack 4.0 with NFS/CLVM/Local storage (and > more?) >Reporter: Marcus Sorensen > Fix For: 4.0.1 > > > patch disks are a LibvirtComputingResource construct, and not tracked > anywhere in cloudstack. Their purpose is to pass on configs to the system > vms, but these disks are left behind and eventually litter your primary > storage. -- 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
[jira] [Closed] (CLOUDSTACK-566) KVM systemvm patchdisks are orphaned when system vms are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen closed CLOUDSTACK-566. -- > KVM systemvm patchdisks are orphaned when system vms are deleted > - > > Key: CLOUDSTACK-566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: KVM/Cloudstack 4.0 with NFS/CLVM/Local storage (and > more?) >Reporter: Marcus Sorensen > Fix For: 4.0.1 > > > patch disks are a LibvirtComputingResource construct, and not tracked > anywhere in cloudstack. Their purpose is to pass on configs to the system > vms, but these disks are left behind and eventually litter your primary > storage. -- 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
[jira] [Commented] (CLOUDSTACK-459) [Optional Public IP assignment for EIP with Basic Zone] Associate IP Checkbox in Create Network Offering Dialog is Displayed When Elastic LB is Selected
[ https://issues.apache.org/jira/browse/CLOUDSTACK-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506798#comment-13506798 ] Jessica Wang commented on CLOUDSTACK-459: - Author: Jessica Wang #mailto:jessica.w...@citrix.com Date: 52 seconds ago (Thu Nov 29 13:11:37 2012) Commit hash:ec40aff931f3bbe3678751964ac75ea00328a765 CLOUDSTACK-459: cloudstack UI - create network offering - When capability ElasticIp=true is passed to API, if capability associatePublicIP=true/false is not passed to API, cloudStack API will assume associatePublicIP=true. So, UI has to explicitly pass associatePublicIP=false to API if its checkbox is unchecked. Contained in branches: master Contained in no tag > [Optional Public IP assignment for EIP with Basic Zone] Associate IP Checkbox > in Create Network Offering Dialog is Displayed When Elastic LB is Selected > > > Key: CLOUDSTACK-459 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-459 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0 >Reporter: Radhika Nair >Assignee: Pranav Saxena >Priority: Minor > Fix For: 4.1.0 > > Attachments: elastic-lb.png > > > As per the PRD, Create Network Offering dialog box should display the > Associate IP checkbox when EIP service capability is chosen. Checkbox for the > capability shall only show up when 'EIP service' capability is chosen. > But, the Associate IP checkbox is displayed when you select Elastic LB > instead of Elastic IP option. -- 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: Need help in updating patch for Review Request
On 29-Nov-2012, at 11:21 AM, Min Chen wrote: > Thanks Rohit. By following your recommended workflow, I was able to create > a patch for my current review. But here comes another scenario that I need > some guidance: now I need to work on another list api refactoring in > parallel while current review https://reviews.apache.org/r/8172 is still > pending, but the new work needs to depend on the new code that is pending > review and thus is not yet in remote api_refactoring branch yet. Based on > your workflow, I should do this: > 1) git checkout api_refactoring (my local branch tracking remote > api_refactoring branch) > 2) git pull origin api_refactoring > 3) git checkout -b mybranch2 It may help if you can draw your changes, git commits and branches are basically link lists. Checkout mybranch2 from mybranch1 (the one on which your upstream feature is). Next assume that the patch you created from mybranch1 will work, continue working on mybranch2. If reviewer suggest something, change in mybranch1 and commit it. Next, cherry pick the same commit on mybranch2, this way your downstream is in sync with mybranch1. Work on mybranch2, when done, squash on a temp. branch out of current b2, you'll get a new patch. I prefer squashing because, it saves reviewers from handling merge conflicts. Checkout git NVIE model, which is recommended for all, once you understand why we've branching and most important merging in git, it will make your workflow very easy: http://nvie.com/posts/a-successful-git-branching-model/ If this shows up correctly in your mail client: api_refactoring | b1->commit-new-feature1->new-change-after-review | | | squash-or-temp-branch-for-b2->squash-here-b2-when-done->handle merge conflicts, create new patch for feature in b2 | b2->work-on-feature2->cherry-pick from b1, handle merge conflicts if any->continue your work Hope this helps. > But I cannot work on mybranch2 for my new feature changes since > "mybranch2" does not have the required code currently in review. What > should I do now? Apply the pending patch to mybranch2? If so, what is the > right procedure for me to create the second patch after the first patch is > approved and checked into remote api_refactoring branch? > > Thanks > -min > > On 11/28/12 10:14 PM, "Rohit Yadav" wrote: > >> You don't sync your personal branch, "mybranch" with remote branch unless >> required, you can cherry pick commits too. When you create a patch by >> merge --squash this would create a single patch that is difference >> between the branch on which you're squashing/merging and your personal >> branch, so this would get all the new commits as one. Other way to >> squash is to use git rebase -i HEAD~5 (this will let you interactively >> rebase last five commits), say you've four commits/changes, you squash >> them into one commit by changing the "pick" to "squash" and rebasing. >> >> If your new changes rely on code from remote branch, git pull them on to >> your local branch tracking the remote branch and cherry pick commits to >> your personal "mybranch", after you're done, you can squash them. Other >> ways are you do this; git pull --rebase origin x (x is the remote branch, >> and you're in your personal "mybranch"). Goto 2. >> >> For your last question, you actually created a branch called api-refactor >> that tracks a remote branch "api_refactoring" (so you actually created a >> local branch with a different name, I usually keep same names for local >> branches that track remote ones) which is fine. Now do: >> 1. git checkout -b # this >> is your personal branch off api-refactor >> 1a. git am >> 2. git add/commit new changes, no code in staging area (nothing that >> requires to be committed) >> 3. Once you're done, git checkout api-refactor and git pull origin >> api_refactoring (switch to the local branch tracking remote one and gets >> latest code), next git checkout -b tempsquash >> 4. Create a single patch for review: git merge --squash "mybranch" # this >> can have merge conflicts which is fine, this saves the reviewer handling >> merge conflicts if you handle it yourself here >> 5. Create patch and send for review; git format-patch -o patches HEAD~1 >> >> Hope this helps. >> >> >> From: Min Chen [min.chen@citrix >> Sent: Thursday, November 29, 2012 11:04 AM >> To: cloudstack-dev@incubator.apache.org >> Cc: cloudstack-dev@incubator.apache.org >> Subject: Re: Need help in updating patch for Review Request >> >> Thanks Rohit. >> >> Two more questions: >> 1. In your step 6, when I go back to "my ranch" to make more changes, do >> i need to make "mybranch" sync with remote branch? what if my new changes >> rely on new code from remote branch? In my case, my new changes are >> adding new unit tests which relies on a change of
[jira] [Created] (CLOUDSTACK-567) Integration Test: Test for Copy Zone has hardcoded destination id
Prasanna Santhanam created CLOUDSTACK-567: - Summary: Integration Test: Test for Copy Zone has hardcoded destination id Key: CLOUDSTACK-567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-567 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.0.0 Reporter: Prasanna Santhanam The smoke and integration tests for copying image (template/iso) between zones assumes the destination id is always 2 which is incorrect since all entities are now based on uuid. Furthermore the listTemplates response needs to resolve the template to be in READY state to ensure that the image was copied over successfully. Here's the review request that corrects this: https://reviews.apache.org/r/8082/ -- 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
[jira] [Assigned] (CLOUDSTACK-567) Integration Test: Test for Copy Zone has hardcoded destination id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-567: - Assignee: Prasanna Santhanam > Integration Test: Test for Copy Zone has hardcoded destination id > - > > Key: CLOUDSTACK-567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-567 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.0.0 >Reporter: Prasanna Santhanam >Assignee: Prasanna Santhanam > > The smoke and integration tests for copying image (template/iso) between > zones assumes the destination id is always 2 which is incorrect since all > entities are now based on uuid. Furthermore the listTemplates response needs > to resolve the template to be in READY state to ensure that the image was > copied over successfully. > Here's the review request that corrects this: > https://reviews.apache.org/r/8082/ -- 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: Fixes marvin integration test for the copy template/iso between zones
> On Nov. 29, 2012, 4:19 p.m., David Nalley wrote: > > Where is the bug that describes the problem that needs to be fixed? created one here: https://issues.apache.org/jira/browse/CLOUDSTACK-567 - Prasanna --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8082/#review13852 --- On Nov. 29, 2012, 9 a.m., SrikanteswaraRao Talluri wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8082/ > --- > > (Updated Nov. 29, 2012, 9 a.m.) > > > Review request for cloudstack. > > > Description > --- > > This is a fix > 1. to populate 'destzoneid' as part of the test data by issuing listZones > API. Earlier, this is provided manually in the test data. > 2. to wait till the ISO/template is downloaded & installed successfully > before being deleted as part of the cleanup. > > > Diffs > - > > test/integration/component/test_templates.py e6b2dd6 > test/integration/smoke/test_iso.py 0215d89 > test/integration/smoke/test_templates.py 9a7f6b1 > > Diff: https://reviews.apache.org/r/8082/diff/ > > > Testing > --- > > Testing done on Advanced zone setup and tests passed. > > > Thanks, > > SrikanteswaraRao Talluri > >
back in the game, deploying to devcloud
Sorry folks, had to take a long hiatus from my cloudstack work, but I'm back in the game and determined to get my devcloud work ready for a patch and submitted. Right now the problem I'm running into is deploying the build: mvn clean install -P developer -D skipTests ; ant build-all rdeploy rdeploydb -Dport=7222 [sshexec] [sshexec] [sshexec] deploydb: [sshexec] [sshexec] [sshexec] deploycddb: [sshexec] [sshexec] [exec] failed to init cloudev dbdeploy-db-clouddev.sh: line 20: clouddev.sql: No such file or directory This is running from master. - James
Re: back in the game, deploying to devcloud
On Thu, Nov 29, 2012 at 06:43:29PM -0500, James Martin wrote: > Sorry folks, had to take a long hiatus from my cloudstack work, but > I'm back in the game and determined to get my devcloud work ready for > a patch and submitted. Right now the problem I'm running into is > deploying the build: > > mvn clean install -P developer -D skipTests ; ant build-all rdeploy > rdeploydb -Dport=7222 > > > [sshexec] > [sshexec] > [sshexec] deploydb: > [sshexec] > [sshexec] > [sshexec] deploycddb: > [sshexec] > [sshexec] [exec] failed to init cloudev > dbdeploy-db-clouddev.sh: line 20: clouddev.sql: No such file or > directory > Just wondering which image of devloud you were using. Rohit released a new Debian Wheezy based image recently which works against master. Are you running this for 4.0? -- Prasanna.,
Re: back in the game, deploying to devcloud
Irrespective of whatever cloudstack version you're on, you don't have different workflows for 4.0 and asf master, just build, deploydb and run the mgmt server as you have on your laptop, using the new devcloud image: http://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova And make sure to set these global settings and restart mgmt server, before you deploy a basic zone: host = 192.168.56.1 system.vm.use.local.storage = true management.network.cidr = 192.168.56.0/24 secstorage.allowed.internal.sites = 192.168.56.0/8 If you're want to build inside use host ip equal to 192.168.56.10. Checkout instructions on working with ASF master and the new devcloud in the DevCloud 2.0 section: http://rohityadav.in/logs/devcloud/ Hope this helps, Rohit On 29-Nov-2012, at 3:54 PM, Prasanna Santhanam wrote: > On Thu, Nov 29, 2012 at 06:43:29PM -0500, James Martin wrote: >> Sorry folks, had to take a long hiatus from my cloudstack work, but >> I'm back in the game and determined to get my devcloud work ready for >> a patch and submitted. Right now the problem I'm running into is >> deploying the build: >> >> mvn clean install -P developer -D skipTests ; ant build-all rdeploy >> rdeploydb -Dport=7222 >> >> >> [sshexec] >> [sshexec] >> [sshexec] deploydb: >> [sshexec] >> [sshexec] >> [sshexec] deploycddb: >> [sshexec] >> [sshexec] [exec] failed to init cloudev >> dbdeploy-db-clouddev.sh: line 20: clouddev.sql: No such file or >> directory >> > > Just wondering which image of devloud you were using. Rohit released > a new Debian Wheezy based image recently which works against master. > > Are you running this for 4.0? > > > -- > Prasanna.,
Re: back in the game, deploying to devcloud
Irrespective of whatever cloudstack version you're on, you don't have different workflows for 4.0 and asf master, just build, deploydb and run the mgmt server as you have on your laptop, using the new devcloud image: http://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova And make sure to set these global settings and restart mgmt server, before you deploy a basic zone: host = 192.168.56.1 system.vm.use.local.storage = true management.network.cidr = 192.168.56.0/24 secstorage.allowed.internal.sites = 192.168.56.0/8 If you're want to build inside use host ip equal to 192.168.56.10. Checkout instructions on working with ASF master and the new devcloud in the DevCloud 2.0 section: http://rohityadav.in/logs/devcloud/ Hope this helps, Rohit On 29-Nov-2012, at 3:54 PM, Prasanna Santhanam wrote: > On Thu, Nov 29, 2012 at 06:43:29PM -0500, James Martin wrote: >> Sorry folks, had to take a long hiatus from my cloudstack work, but >> I'm back in the game and determined to get my devcloud work ready for >> a patch and submitted. Right now the problem I'm running into is >> deploying the build: >> >> mvn clean install -P developer -D skipTests ; ant build-all rdeploy >> rdeploydb -Dport=7222 >> >> >> [sshexec] >> [sshexec] >> [sshexec] deploydb: >> [sshexec] >> [sshexec] >> [sshexec] deploycddb: >> [sshexec] >> [sshexec] [exec] failed to init cloudev >> dbdeploy-db-clouddev.sh: line 20: clouddev.sql: No such file or >> directory >> > > Just wondering which image of devloud you were using. Rohit released > a new Debian Wheezy based image recently which works against master. > > Are you running this for 4.0? > > > -- > Prasanna.,
Re: Need help in updating patch for Review Request
Thanks a lot, Rohit. -min On 11/29/12 1:55 PM, "Rohit Yadav" wrote: > >On 29-Nov-2012, at 11:21 AM, Min Chen wrote: > >> Thanks Rohit. By following your recommended workflow, I was able to >>create >> a patch for my current review. But here comes another scenario that I >>need >> some guidance: now I need to work on another list api refactoring in >> parallel while current review https://reviews.apache.org/r/8172 is still >> pending, but the new work needs to depend on the new code that is >>pending >> review and thus is not yet in remote api_refactoring branch yet. Based >>on >> your workflow, I should do this: >> 1) git checkout api_refactoring (my local branch tracking remote >> api_refactoring branch) >> 2) git pull origin api_refactoring >> 3) git checkout -b mybranch2 > >It may help if you can draw your changes, git commits and branches are >basically link lists. > >Checkout mybranch2 from mybranch1 (the one on which your upstream feature >is). >Next assume that the patch you created from mybranch1 will work, continue >working on mybranch2. If reviewer suggest something, change in mybranch1 >and commit it. Next, cherry pick the same commit on mybranch2, this way >your downstream is in sync with mybranch1. Work on mybranch2, when done, >squash on a temp. branch out of current b2, you'll get a new patch. I >prefer squashing because, it saves reviewers from handling merge >conflicts. Checkout git NVIE model, which is recommended for all, once >you understand why we've branching and most important merging in git, it >will make your workflow very easy: >http://nvie.com/posts/a-successful-git-branching-model/ > >If this shows up correctly in your mail client: > >api_refactoring >| >b1->commit-new-feature1->new-change-after-review > | | > | >squash-or-temp-branch-for-b2->squash-here-b2-when-done->handle merge >conflicts, create new patch for feature in b2 > | > b2->work-on-feature2->cherry-pick from >b1, handle merge conflicts if any->continue your work > > >Hope this helps. > >> But I cannot work on mybranch2 for my new feature changes since >> "mybranch2" does not have the required code currently in review. What >> should I do now? Apply the pending patch to mybranch2? If so, what is >>the >> right procedure for me to create the second patch after the first patch >>is >> approved and checked into remote api_refactoring branch? >> >> Thanks >> -min >> >> On 11/28/12 10:14 PM, "Rohit Yadav" wrote: >> >>> You don't sync your personal branch, "mybranch" with remote branch >>>unless >>> required, you can cherry pick commits too. When you create a patch by >>> merge --squash this would create a single patch that is difference >>> between the branch on which you're squashing/merging and your personal >>> branch, so this would get all the new commits as one. Other way to >>> squash is to use git rebase -i HEAD~5 (this will let you interactively >>> rebase last five commits), say you've four commits/changes, you squash >>> them into one commit by changing the "pick" to "squash" and rebasing. >>> >>> If your new changes rely on code from remote branch, git pull them on >>>to >>> your local branch tracking the remote branch and cherry pick commits to >>> your personal "mybranch", after you're done, you can squash them. Other >>> ways are you do this; git pull --rebase origin x (x is the remote >>>branch, >>> and you're in your personal "mybranch"). Goto 2. >>> >>> For your last question, you actually created a branch called >>>api-refactor >>> that tracks a remote branch "api_refactoring" (so you actually created >>>a >>> local branch with a different name, I usually keep same names for local >>> branches that track remote ones) which is fine. Now do: >>> 1. git checkout -b # >>>this >>> is your personal branch off api-refactor >>> 1a. git am >>> 2. git add/commit new changes, no code in staging area (nothing that >>> requires to be committed) >>> 3. Once you're done, git checkout api-refactor and git pull origin >>> api_refactoring (switch to the local branch tracking remote one and >>>gets >>> latest code), next git checkout -b tempsquash >>> 4. Create a single patch for review: git merge --squash "mybranch" # >>>this >>> can have merge conflicts which is fine, this saves the reviewer >>>handling >>> merge conflicts if you handle it yourself here >>> 5. Create patch and send for review; git format-patch -o patches HEAD~1 >>> >>> Hope this helps. >>> >>> >>> From: Min Chen [min.chen@citrix >>> Sent: Thursday, November 29, 2012 11:04 AM >>> To: cloudstack-dev@incubator.apache.org >>> Cc: cloudstack-dev@incubator.apache.org >>> Subject: Re: Need help in updating patch for Review Request >>> >>> Thanks Rohit. >>> >>> Two more questions: >>> 1. In your step 6, when I go back to "my ranch" to make more changes, >>>do >>> i need to make "mybranch" sync with remote branch? what
Re: About cloud-scripts-signature in System VM .
This is checked and updated in /etc/init.d/cloud-early-config On 11/27/12 11:35 PM, "田春峰" wrote: >hi all, > > >Currently , I have to do some customise jobs on system vm . After over all >listing files about scripts of cloudstack , I find a file named : > > *cloud-scripts-signature* in /var/cache/cloud directory. > >The content in the file is just one line >signature: 54a6f65f3ac6b7d66cf595706e9c0933. > > After digging , I know this file comes from System VM Template , but , >with a different signature value . > > > My question need clearly is : > >1. When and by which script change the value in the file ? >2. This signature value was used by which script after initialized? > ( where dynamically check the value ) > > > >Thanks in advance. > >ChunFeng Tian
[jira] [Created] (CLOUDSTACK-568) Source template id is recorded incorrectly.
Bharat Kumar created CLOUDSTACK-568: --- Summary: Source template id is recorded incorrectly. Key: CLOUDSTACK-568 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-568 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: ISO, Template, Volumes Affects Versions: pre-4.0.0 Environment: Operating System: All Platform: PC Reporter: Bharat Kumar Fix For: 4.0.1 In the database, there appears to be three templates that have their parents (source_template_id) set to the VMWare tools or XenServer tools ISOs instead of the ISO actually used to install the VM the template was generated from: mysql> select id, name, format, source_template_id from vm_template where source_template_id in (200,201); +-+--+++ | id | name | format | source_template_id | +-+--+++ | 271 | Windows 2008 Ent. R2 64bit (XEN) | VHD | 200 | | 272 | W2k8 R2 Ent 64 bit vSphere | OVA | 201 | | 273 | W2K8 R2 Ent. 64bit | OVA | 201 | +-+--+++ 3 rows in set (0.00 sec) According to Kelven, this could happen if you launch a VM from an ISO, then later attach the tools ISOs before taking a snapshot and creating the template. The source_template_id is often used to determine billing information by upstream systems (such as CloudPortal), so this can cause incorrect billing. -- 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
[jira] [Updated] (CLOUDSTACK-568) Source template id is recorded incorrectly.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-568: Affects Version/s: (was: pre-4.0.0) 4.0.0 > Source template id is recorded incorrectly. > --- > > Key: CLOUDSTACK-568 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-568 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Template, Volumes >Affects Versions: 4.0.0 > Environment: Operating System: All > Platform: PC >Reporter: Bharat Kumar > Fix For: 4.0.1 > > > In the database, there appears to be three templates that have their parents > (source_template_id) set to the VMWare tools or XenServer tools ISOs instead > of the ISO actually used to install the VM the template was generated from: > mysql> select id, name, format, source_template_id from vm_template where > source_template_id in (200,201); > +-+--+++ > | id | name | format | source_template_id | > +-+--+++ > | 271 | Windows 2008 Ent. R2 64bit (XEN) | VHD | 200 | > | 272 | W2k8 R2 Ent 64 bit vSphere | OVA | 201 | > | 273 | W2K8 R2 Ent. 64bit | OVA | 201 | > +-+--+++ > 3 rows in set (0.00 sec) > According to Kelven, this could happen if you launch a VM from an ISO, then > later attach the tools ISOs before taking a snapshot and creating the > template. > The source_template_id is often used to determine billing information by > upstream systems (such as CloudPortal), so this can cause incorrect billing. -- 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
Review Request: The already deleted same hostname is not deleted from /etc/hosts of vRouter.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8289/ --- Review request for cloudstack. Description --- The already deleted same hostname is not deleted from /etc/hosts of vRouter. vRouter's /etc/hosts format: $ip $host This deletion logic does not match. sed -i /"$host "/d $HOSTS Diffs - patches/systemvm/debian/config/root/edithosts.sh 3c6102d Diff: https://reviews.apache.org/r/8289/diff/ Testing --- Thanks, Atsushi Midorikawa
[jira] [Commented] (CLOUDSTACK-559) source code import problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507131#comment-13507131 ] charles_sysu commented on CLOUDSTACK-559: - can someone help me? > source code import problem > -- > > Key: CLOUDSTACK-559 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-559 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.0 > Environment: ubuntu12.04_64bit eclipse+m2e >Reporter: charles_sysu > Fix For: 4.0.0 > > > i can set up the development environment successfully.But when i import the > source code into Eclipse,it come across some problem with the pom.xml in the > deps/.The question is: > Artifact has not been packaged yet. When used on reactor artifact, copy > should be executed after packaging: see MDEP-187 > (org.apache.maven.plugins:maven-dependency-plugin:2.5.1:copy-dependencies:copy-dependencies:install) > i have tried "mvn -P deps" before i import the project. > thanks. -- 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
[jira] [Comment Edited] (CLOUDSTACK-563) Unable to create guest network in UI for Advanced Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507156#comment-13507156 ] Dave Cahill edited comment on CLOUDSTACK-563 at 11/30/12 7:19 AM: -- Are relevant providers Enabled on the underlying Physical Network? If you navigate to Infrastructure > Zones > YOURZONENAME > Physical Network > YOURPHYSICALNETWORKNAME > Network Service Providers, are any of the providers marked as Enabled? I experienced the same behaviour you mention, but it turned out to be because I set up my env using CloudMonkey CLI and hadn't enabled any of the providers (e.g. VirtualRouter). was (Author: davecahill): Are relevant providers Enabled on the underlying Physical Network? If you navigate to Infrastructure > Zones > YOURZONENAME > Physical Network > YOURPHYSICALNETWORKNAME > Network Service Providers, are any of the providers marked as Enabled? I exeprienced the saem behaviour you mention, but it turned out to be because I set up my env using CloudMonkey CLI and hadn't enabled any of the providers (e.g. VirtualRouter). > Unable to create guest network in UI for Advanced Zone > -- > > Key: CLOUDSTACK-563 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-563 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: CS 4.0 on CentOS 6.3 > vSphere 5.0 clusters with Advanced networks >Reporter: ilya musayev > Labels: Bug, UI > > The UI would not allow for creation of guest Network. - Please look at the > attached image. > Screenshot - http://i50.tinypic.com/33zfmvs.jpg > The drop down for NetworkOfferings is blank > There is a dropdown for VPC - which is also blank (not needed for shared > networks) > We also need the ability to pick the proper Physical Network Name - which is > not available/ > This feature is also broken in the Add A Zone wizard, i will open a separate > bug request for that. -- 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
[jira] [Commented] (CLOUDSTACK-563) Unable to create guest network in UI for Advanced Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507156#comment-13507156 ] Dave Cahill commented on CLOUDSTACK-563: Are relevant providers Enabled on the underlying Physical Network? If you navigate to Infrastructure > Zones > YOURZONENAME > Physical Network > YOURPHYSICALNETWORKNAME > Network Service Providers, are any of the providers marked as Enabled? I exeprienced the saem behaviour you mention, but it turned out to be because I set up my env using CloudMonkey CLI and hadn't enabled any of the providers (e.g. VirtualRouter). > Unable to create guest network in UI for Advanced Zone > -- > > Key: CLOUDSTACK-563 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-563 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: CS 4.0 on CentOS 6.3 > vSphere 5.0 clusters with Advanced networks >Reporter: ilya musayev > Labels: Bug, UI > > The UI would not allow for creation of guest Network. - Please look at the > attached image. > Screenshot - http://i50.tinypic.com/33zfmvs.jpg > The drop down for NetworkOfferings is blank > There is a dropdown for VPC - which is also blank (not needed for shared > networks) > We also need the ability to pick the proper Physical Network Name - which is > not available/ > This feature is also broken in the Add A Zone wizard, i will open a separate > bug request for that. -- 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: back in the game, deploying to devcloud
Just to clear things up -- I'm not using an image at all. I'm working on the stuff that builds devcloud. I'd like devcloud to be part of the source tree, not something external that you download. I feel this makes for a cleaner development experience and forces the creation of the devcloud image to remain in the core codebase. The goal is to be able, from the cloudstack project root: cd tools/devcloud vagrant up vagrant ssh In order for this to work it requires a vagrant basebox, and a vagrant xenbox. Currently in my fork these are built cleanly with veewee, vagrant, and puppet via a shell script by simply: cd tools/devcloud/deps ./boxer.sh -b all And you end up with: vagrant box list devcloudbase (virtualbox) devcloudbase-xen (virtualbox) Once those vagrant boxes are completed you'd run, cd ../ vagrant up vagrant ssh vagrant ssh Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686) * Documentation: https://help.ubuntu.com/ Last login: Fri Nov 30 05:29:32 2012 from 10.0.2.2 devcloud@devcloud:~$ ls /opt/cloudstack/ apache-tomcat-6.0.32 apache-tomcat-6.0.32.zip incubator-cloudstack startdevcloud.sh and now you have an clean devcloud vagrant install. If you ever screw up the system, you simply: vagrant destroy vagrant up to start fresh I have all of that completed. I just want to be able to install a build to this blank vm. It seems like I should follow these steps: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+devcloud+environment+setup but I receive an error here: mvn -P developer -pl developer,tools/devcloud -Ddeploydb [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] Apache CloudStack Developer Tools [INFO] Apache CloudStack Developer Tools [INFO] [INFO] [INFO] Building Apache CloudStack Developer Tools 4.1.0-SNAPSHOT [INFO] [INFO] [INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties (default) @ cloud-developer --- [WARNING] Ignoring missing properties file: /Users/jmartin/work/code/basho-cloudstack/utils/conf/db.properties.override [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-developer --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer --- [INFO] Executing tasks main: [copy] Copying 60 files to /Users/jmartin/work/code/basho-cloudstack/developer/target/db [copy] Copying 9 files to /Users/jmartin/work/code/basho-cloudstack/developer/target/db [INFO] Executed tasks [INFO] [INFO] --- sql-maven-plugin:1.5:execute (drop-database) @ cloud-developer --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools . FAILURE [2.025s] [INFO] Apache CloudStack Developer Tools . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.947s [INFO] Finished at: Fri Nov 30 02:15:39 EST 2012 [INFO] Final Memory: 12M/81M [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute (drop-database) on project cloud-developer: Communications link failure [ERROR] [ERROR] The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException I don't believe that it's connecting to the vagrant vm I have running and doing the proper deploys. How can we fix this? Thanks! James On Thu, Nov 29, 2012 at 7:12 PM, Rohit Yadav wrote: > Irrespective of whatever cloudstack version you're on, you don't have > different workflows for 4.0 and asf master, just build, deploydb and run the > mgmt server as you have on your laptop, using the new devcloud image: > http://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova > > And make sure to set these global settings and restart mgmt server, before > you deploy a basic zone: > > host = 192.168.56.1 > system.vm.use.local.storage = true > management.network.cidr = 192.168.56.0/24 > secstorage.allowed.internal.sites = 192.168.56.0/8 > > If you're want to build ins
RE: back in the game, deploying to devcloud
James, I see your point, this will probably be fixed later on. We need to fix the veewee and vagrant configs in tools/devcloud. Right now I created only the image as most people would not want to create their own. If you're looking to create your own, checkout diy section of http://rohityadav.in/logs/devcloud The problem is I've used Debian Wheezy, configuring the vagrant box was tricky also some packages like mkisofs and maven3 will have to fetched as they are not on distro's repos. Any help in fixing these scripts would be great. Regards. From: James Martin [jmar...@basho.com] Sent: Friday, November 30, 2012 1:10 PM To: cloudstack-dev@incubator.apache.org Subject: Re: back in the game, deploying to devcloud Just to clear things up -- I'm not using an image at all. I'm working on the stuff that builds devcloud. I'd like devcloud to be part of the source tree, not something external that you download. I feel this makes for a cleaner development experience and forces the creation of the devcloud image to remain in the core codebase. The goal is to be able, from the cloudstack project root: cd tools/devcloud vagrant up vagrant ssh In order for this to work it requires a vagrant basebox, and a vagrant xenbox. Currently in my fork these are built cleanly with veewee, vagrant, and puppet via a shell script by simply: cd tools/devcloud/deps ./boxer.sh -b all And you end up with: vagrant box list devcloudbase (virtualbox) devcloudbase-xen (virtualbox) Once those vagrant boxes are completed you'd run, cd ../ vagrant up vagrant ssh vagrant ssh Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686) * Documentation: https://help.ubuntu.com/ Last login: Fri Nov 30 05:29:32 2012 from 10.0.2.2 devcloud@devcloud:~$ ls /opt/cloudstack/ apache-tomcat-6.0.32 apache-tomcat-6.0.32.zip incubator-cloudstack startdevcloud.sh and now you have an clean devcloud vagrant install. If you ever screw up the system, you simply: vagrant destroy vagrant up to start fresh I have all of that completed. I just want to be able to install a build to this blank vm. It seems like I should follow these steps: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+devcloud+environment+setup but I receive an error here: mvn -P developer -pl developer,tools/devcloud -Ddeploydb [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] Apache CloudStack Developer Tools [INFO] Apache CloudStack Developer Tools [INFO] [INFO] [INFO] Building Apache CloudStack Developer Tools 4.1.0-SNAPSHOT [INFO] [INFO] [INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties (default) @ cloud-developer --- [WARNING] Ignoring missing properties file: /Users/jmartin/work/code/basho-cloudstack/utils/conf/db.properties.override [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-developer --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer --- [INFO] Executing tasks main: [copy] Copying 60 files to /Users/jmartin/work/code/basho-cloudstack/developer/target/db [copy] Copying 9 files to /Users/jmartin/work/code/basho-cloudstack/developer/target/db [INFO] Executed tasks [INFO] [INFO] --- sql-maven-plugin:1.5:execute (drop-database) @ cloud-developer --- [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache CloudStack Developer Tools . FAILURE [2.025s] [INFO] Apache CloudStack Developer Tools . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.947s [INFO] Finished at: Fri Nov 30 02:15:39 EST 2012 [INFO] Final Memory: 12M/81M [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:sql-maven-plugin:1.5:execute (drop-database) on project cloud-developer: Communications link failure [ERROR] [ERROR] The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException I don't believe tha
