Re: Review Request 30821: CLOUDSTACK-8236: Automation test cases for storage migration test path
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30821/ --- (Updated Feb. 11, 2015, 9:30 a.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-8236 https://issues.apache.org/jira/browse/CLOUDSTACK-8236 Repository: cloudstack-git Description --- First few test scenarios for storage migration test path. Diffs (updated) - test/integration/component/test_storage_migration.py PRE-CREATION tools/marvin/marvin/codes.py a7e8ec8 tools/marvin/marvin/lib/base.py e38c394 Diff: https://reviews.apache.org/r/30821/diff/ Testing --- Test migrate Volume (root and data disk) ... === TestName: test_01_migrate_root_and_data_disk_nonlive | Status : SUCCESS === ok -- Ran 1 test in 663.665s OK Thanks, Ashutosh Kelkar
Re: Review Request 28030: CLOUDSTACK-7911: Automation test cases for Usage test path
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28030/ --- (Updated Feb. 11, 2015, 9:30 a.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7911 https://issues.apache.org/jira/browse/CLOUDSTACK-7911 Repository: cloudstack-git Description --- Automation test cases for Usage test path. More test cases to follow. This is first patch. Diffs (updated) - test/integration/testpaths/testpath_usage.py PRE-CREATION tools/marvin/marvin/config/test_data.py d5ed353 tools/marvin/marvin/dbConnection.py 66c6cb1 tools/marvin/marvin/lib/base.py e38c394 tools/marvin/marvin/lib/utils.py 8788b3b Diff: https://reviews.apache.org/r/28030/diff/ Testing --- Yes. Thanks, Ashutosh Kelkar
Review Request 30872: CLOUDSTACK-8149: Fixed test_Virtualrouter_alerts, py for Vmware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30872/ --- Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-8149 https://issues.apache.org/jira/browse/CLOUDSTACK-8149 Repository: cloudstack-git Description --- The test case failed for vmware because the service dnsmasq was not stopped. Further, the waiting time was hard coded. Fixed above issues. Diffs - test/integration/component/test_VirtualRouter_alerts.py 91a4fcf Diff: https://reviews.apache.org/r/30872/diff/ Testing --- test_01_VRServiceFailureAlerting (test_VirtualRouter_alerts.TestVRServiceFailureAlerting) ... === TestName: test_01_VRServiceFailureAlerting | Status : SUCCESS === ok -- Ran 1 test in 2588.687s OK Thanks, Gaurav Aradhye
Re: Review Request 30866: CLOUDSTACK-8241: Moved upload volume dict data to configurableData section of the test_data.py file so that data can be changed according to the setup, also made relevant cha
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30866/#review71953 --- Ship it! af09388eda491a529e88ed62fb2c3d62fe554a4d master - SrikanteswaraRao Talluri On Feb. 11, 2015, 5:53 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/30866/ > --- > > (Updated Feb. 11, 2015, 5:53 a.m.) > > > Review request for cloudstack and SrikanteswaraRao Talluri. > > > Bugs: CLOUDSTACK-8241 > https://issues.apache.org/jira/browse/CLOUDSTACK-8241 > > > Repository: cloudstack-git > > > Description > --- > > The volume upload URL is hard coded right now and should be moved to > configurableData section so that appropriate data can be filled before the > running the relevant test cases. > > > Diffs > - > > test/integration/component/test_escalations_volumes.py fe9d5e1 > test/integration/testpaths/testpath_volumelifecycle.py 6e56697 > tools/marvin/marvin/config/test_data.py d5ed353 > > Diff: https://reviews.apache.org/r/30866/diff/ > > > Testing > --- > > Did not run the test cases. Only the path changes in test cases. Should be > tested with correct volume path. > > > Thanks, > > Gaurav Aradhye > >
Re: Review Request 30865: CLOUDSTACK-8240: Skipping test case in test_vmware_drs.py because the scenario is not testable through automation
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30865/#review71955 --- Ship it! ec1c3894f0a2cfdd9b9b96e4e01b6e8bba77af0f master - SrikanteswaraRao Talluri On Feb. 11, 2015, 5:23 a.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/30865/ > --- > > (Updated Feb. 11, 2015, 5:23 a.m.) > > > Review request for cloudstack and SrikanteswaraRao Talluri. > > > Bugs: CLOUDSTACK-8240 > https://issues.apache.org/jira/browse/CLOUDSTACK-8240 > > > Repository: cloudstack-git > > > Description > --- > > The test case tries to deploy a VM with memory just below the host capacity > (which is normally in many GBs). This goes beyond the account capacity, and > also it is not feasible in automation to allocate such huge resources to > single account. > > Hence skipping the test case and marking it as invalid. > > > Diffs > - > > test/integration/component/test_vmware_drs.py 20d3839 > > Diff: https://reviews.apache.org/r/30865/diff/ > > > Testing > --- > > Tested with python command and pyflakes. > > > Thanks, > > Gaurav Aradhye > >
Re: Can System VMs be migrated?
Somesh Naidu and others, Now I understand the problem. But, that code does not make much sense to me. As I said before, the “system.vm.use.local.storage” parameter was already set to false. Therefore, the SQL command “select id,name,use_local_storage from disk_offering where system_use=1” returns: id nameuse_local_storage 7 System Offering For Software Router false 8 System Offering For Elastic LB VM false 9 System Offering For Secondary Storage VM false 10 System Offering For Console Proxyfalse 30 System Offering For Internal LB VM false All as expected. The problem happens because of the method “com.cloud.hypervisor.xen.resource.XcpOssResource.createPatchVbd(Connection, String, VM)” that was overwritten. Someone, for some odd reason changed the behavior of the default implementation that is found on “com.cloud.hypervisor.xen.resource.CitrixResourceBase”. I tested the commands that are in “com.cloud.hypervisor.xen.resource.CitrixResourceBase” and they work just fine for XAPI (XCP). Those are the commands used in XS environments. IMHO the “com.cloud.hypervisor.xen.resource.XcpOssResource.createPatchVbd(Connection, String, VM)” method should be removed and the behavior of the parent class should be kept, hence it works properly. Moreover, that overwritten method does not respect the “system.vm.use.local.storage” parameter. Thus, to the best of my knowledge ( http://pt.slideshare.net/xen_com_mgr/xpus13-pavlicek), at the end XAPI and XS are almost the same, hence the XAPI in bundled into xenserver. Should I open a bug report(is it really a bug or something intentional?)? On Tue, Feb 10, 2015 at 6:54 PM, Somesh Naidu wrote: > Ok. I don't know what the expected behavior for XCP is (though I believe > shared storage for system VMs should work on XCP as well). > > If you were using XenServer then the way it works is that depending on the > value (true/false) set for global config system.vm.use.local.storage, CS > will set the storage type in the system service offering during mgmt. > bootstrap. > > When I say system offering I refer to the records returned by the query - > select id,name,use_local_storage from disk_offering where system_use=1; > > Regards, > Somesh > > -Original Message- > From: Rafael Weingartner [mailto:rafaelweingart...@gmail.com] > Sent: Tuesday, February 10, 2015 1:55 PM > To: dev@cloudstack.apache.org > Subject: Re: Can System VMs be migrated? > > Somesh Naidu, > > I am using the 4.3.0 version. > > I am using Xen hypervisor with XAPI (old XCP) packages over Debian 7.4 > > I did not understand what you mean with “in the system offerings” . The > primary storage of the clusters are NFS servers. > > On Tue, Feb 10, 2015 at 1:25 PM, Somesh Naidu > wrote: > > > Rafael, > > > > What version of CS are you using? I have a 4.3 and a 4.5 environment with > > XS/VMware/KVM hypervisors and on all of them, the system VMs are being > > created on shared primary storage. > > > > Can you check what storage type is set in the system offerings? > > > > Regards, > > Somesh > > > > > > -Original Message- > > From: Rafael Weingartner [mailto:rafaelweingart...@gmail.com] > > Sent: Tuesday, February 10, 2015 7:20 AM > > To: dev@cloudstack.apache.org > > Subject: Re: Can System VMs be migrated? > > > > Marcus, the parameter “system.vm.use.local.storage” was already set to > > false. That parameter does not make any sense to me; it seems that it is > > not used, at least for Xen. > > > > Abhinandan Prateek, I did not configure it erroneously. I configured NFS > > storage to store users VMs (primary storage), I am not using local > storage > > for anything, but sadly I was forced to create a local SR into every > host. > > I had exchanged some emails about that in the users list a while ago: > > > > > > > http://mail-archives.apache.org/mod_mbox/cloudstack-users/201309.mbox/%3CCAG97radxdiUaim7-W5nw-BAcvTFV0MgD6RJzB64=uervm89...@mail.gmail.com%3E > > > > The problem seems to be here: > > > > > com.cloud.hypervisor.xen.resource.XcpOssResource.createPatchVbd(Connection, > > String, VM) > > > > That class do not use the parameter “system.vm.use.local.storage”, it > > forced us to add a local SR in the host. Then it deploys the systemvm-vdi > > into that “_host.localSRuuid”. > > > > > > > http://fossies.org/dox/apache-cloudstack-4.4.2-src/XcpOssResource_8java_source.html > > > > Is that behavior expected? I have lived with that since CS 4.1.1 (I am > > using 4.3.0) and it seems to be the same in 4.4. > > > > > > On Tue, Feb 10, 2015 at 3:09 AM, Marcus wrote: > > > > > edit the global setting "system.vm.use.local.storage", restart mgmt > > server. > > > > > > On Mon, Feb 9, 2015 at 8:20 PM, Abhinandan Prateek > > > wrote: > > > > While creating a zone you can configure the use of local storage. It > > > seems you configured it erroneously. > > > > In 4.3 as per my knowledge live vm mig
[GitHub] cloudstack pull request: Feature/systemvm persistent config 4
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/75#discussion_r24511453
--- Diff:
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java ---
@@ -1622,6 +1630,23 @@ protected StringBuilder
createRedundantRouterArgs(final NicProfile nic, DomainRo
// For a redundant VPC router, both shall have the same
router id. It will be used by the VRRP virtural_router_id attribute.
// So we use the VPC id to avoid group problems.
buf.append(" router_id=").append(vpcId);
+
+// Will build the routers password based on the VPC ID and
UUID.
+final Vpc vpc = _vpcDao.findById(vpcId);
+
+try {
+final MessageDigest digest =
MessageDigest.getInstance("SHA-512");
--- End diff --
let's make a ticket to make this configurable later on
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] cloudstack pull request: Feature/systemvm persistent config 4
Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/75 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: Feature/systemvm persistent config 4
Github user wilderrodrigues commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/75#discussion_r24514373
--- Diff:
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java ---
@@ -1622,6 +1630,23 @@ protected StringBuilder
createRedundantRouterArgs(final NicProfile nic, DomainRo
// For a redundant VPC router, both shall have the same
router id. It will be used by the VRRP virtural_router_id attribute.
// So we use the VPC id to avoid group problems.
buf.append(" router_id=").append(vpcId);
+
+// Will build the routers password based on the VPC ID and
UUID.
+final Vpc vpc = _vpcDao.findById(vpcId);
+
+try {
+final MessageDigest digest =
MessageDigest.getInstance("SHA-512");
--- End diff --
Which part should be configurable?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
query about 4.4 usage
H, Today we had a talk at work (Schuberg Philis) about our CloudStack strategy. We decided that we will keep at 4.4 until we have a good test environment of our own and then skip to 4.6 or up, depending on where we merge our redundant vpc work in. We don't have any time to put energy in 4.5 and need some features that won't make it there. The afore mentioned redundant vpcs, but also ipv6 for vpcs and ovm support. What I am wondering now is: Who else is on 4.4 in production systems? What versions do you run? How did you test it before going to production? What are your migration plans? thanks, -- Daan
Re: query about 4.4 usage
Hi, I'm with 4.4.1 in production on CentOS 6 HVs (should get it to 4.4.2 soon), Adv zone + SG. I keep a separate, somehow similar setup where I test stuff before going to production - I don't always catch all the bugs. Nothing fancy or automated like Jenkins etc, perhaps one day. My migration plan are to follow 4.5, mainly as to not get left behind too much and wake up with a non-upgradable setup (however unlikely). Looking forward to ipv6. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Daan Hoogland" > To: "dev" , us...@cloudstack.apache.org > Sent: Wednesday, 11 February, 2015 17:53:30 > Subject: query about 4.4 usage > H, > > Today we had a talk at work (Schuberg Philis) about our CloudStack > strategy. We decided that we will keep at 4.4 until we have a good > test environment of our own and then skip to 4.6 or up, depending on > where we merge our redundant vpc work in. We don't have any time to > put energy in 4.5 and need some features that won't make it there. The > afore mentioned redundant vpcs, but also ipv6 for vpcs and ovm > support. > > What I am wondering now is: > Who else is on 4.4 in production systems? > What versions do you run? > How did you test it before going to production? > What are your migration plans? > > thanks, > -- > Daan
Re: query about 4.4 usage
Just as a data point, at Citrix we actually decided to skip 4.4 and didn¹t put out a commercial distribution based on it. We put all our energy into fixing bugs that went into 4.5. We¹re now bringing up large customers on 4.5, but too early to publish results. Overall, though, I feel good about 4.5 quality. On 2/11/15, 9:53 AM, "Daan Hoogland" wrote: >H, > >Today we had a talk at work (Schuberg Philis) about our CloudStack >strategy. We decided that we will keep at 4.4 until we have a good >test environment of our own and then skip to 4.6 or up, depending on >where we merge our redundant vpc work in. We don't have any time to >put energy in 4.5 and need some features that won't make it there. The >afore mentioned redundant vpcs, but also ipv6 for vpcs and ovm >support. > >What I am wondering now is: >Who else is on 4.4 in production systems? >What versions do you run? >How did you test it before going to production? >What are your migration plans? > >thanks, >-- >Daan
CloudStack Days 2015
Hi all, In 2015, five CloudStack Days events will be held across the globe. Each one-day event will feature morning plenary sessions and afternoon breakout sessions in user and developer tracks. Here are the dates and websites for each event: CloudStack Days Austin 2015 (April 16th): http://events.linuxfoundation.org/events/cloudstack-austin CloudStack Days Tokyo 2015 (June 2nd): http://events.linuxfoundation.org/events/cloudstack-tokyo CloudStack Days Seattle 2015 (August 20th): http://events.linuxfoundation.org/events/cloudstack-seattle CloudStack Days Budapest 2015 (October 1st): http://events.linuxfoundation.org/events/cloudstack-budapest CloudStack Days Dublin 2015 (October 8th): http://events.linuxfoundation.org/events/cloudstack-dublin The Call for Participation (CFP) will be opened soon. CloudStack Days will replace the CloudStack Collaboration Conferences (which were normally held twice a year in North America and Europe). The format of the event has changed in order to hold more events reaching a larger number of users and developers. Help promote: Click to tweet: http://ctt.ec/p31L2 - Save the Date: April 16. @CloudStackDays is coming to Austin, TX! Co-located with #ApacheCon clds.co/1ChqRHL Click to tweet: http://ctt.ec/b52c0 - Five @CloudStackDays 2015 across the globe! Check out #CloudStack Days Tokyo on June 2 co-located with #CloudOpen clds.co/1vEPpxN Click to tweet: http://ctt.ec/y73As - Five @CloudStackDays 2015 across the globe! #CloudStack Days Seattle will be on Aug 20 co-located w/ #CloudOpen clds.co/1yhZwTt Click to tweet: http://ctt.ec/oNEi5 - Save the date: Oct 1. @CloudStackDays is coming to Budapest! Co-located w/ #ApacheCon clds.co/1zWHpqb Click to tweet: http://ctt.ec/cela5 - Save the Date: Oct 8. @CloudStackDays is coming to Dublin, Ireland! Co-located with #CloudOpen clds.co/1KJFV7y Sponsorship Prospectus: The sponsorship prospectus for CloudStack Days 2015 is available here: http://events.linuxfoundation.org/events/cloudstack-dublin/sponsor Thanks, Karen
details parameter of registerTemplate API
Hi, I used details parameter of registerTemplate API to set keyboard=jp. I use following format to pass argument as CLOUDSTACK-4719 says. details[0].keyboard=jp https://issues.apache.org/jira/browse/CLOUDSTACK-4719 Most of API parameters that accept map type seems to accept like following format, although details of registerTemplate can't accept it as expected detais[0].key=keyboard&details[0].value=jp Why details parameter of registerTemplate uses different format from most of the other parameters? It is hard to use API and make library correctly because we can't check which format is used in advance. If possible, I want to use same format in all case. Atsushi Sasaki
