cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <john.burw...@shapeblue.com>
Subject Re: [VOTE] Apache CloudStack 4.6.0
Date Sat, 07 Nov 2015 16:38:58 GMT
Remi,

Looking back over previous releases, we have not invalidated an RCs due to packaging issues.  While it seems a bit odd that we would ship any code that does not work, it appears to have been our policy for some time..  Therefore, we should carry forward our practice, and if the only issues in the RC are related to packaging, then the release can proceed.  I think it would be a mistake to changes to the release process at this point in the cycle because it introduces unacceptable quality risks.  All discussions about changes should be oriented towards future releases.

In terms of post-4.6.0, I completely disagree with this proposal and its premise.  The ASF does not specify what a project delivers.  A project's deliverables are left to its community to determine.  I believe, as a community, we should be delivering signed RHEL/Debian/Ubuntu packages [1] for the following reasons:

1. CloudStack is a system automation platform with specific system requirements in order to function properly.  In addition to simplifying the installation process, packages ensure that all necessary system dependencies are present.
2. It is clear from users@ that packages are the most popular way to install the project.  When users have a problems with 3rd party packages, they are bringing their issues to the community.  Given that we have to support packages of some kind, why not support packages we create and control instead?  Why not give our users what they want?
3. One thing that the most popular/successful open source projects (e.g. MongoDB, Docker, etc) share is a simple, reliable installation process.  Therefore, providing a set of high quality OS packages is very important to increase adoption.  If we had repos hosted from the project, the installation instructions on the site could directly reference package installs for platforms — further simplifying the process.  Compared with competing projects, such simple instructions would be a tremendous advantage.

In terms of packaging our own product, it makes tremendous sense that our packages derive from the Maven Central CloudStack artifacts.  This approach would validate the quality of these artifacts for 3rd party packagers to build packages that offer capabilities not present in the community’s packages (e.g. non-free components).  I agree we also need to have the ability to test packaging (e.g. every PR needs to have a package built and tested before a merge to master) as well as other infrastructure tasks (admittedly a big ole hand wave).  This effort would also likely have indirect benefit the overall quality of the project.

In summary, as a community, we decide our deliverables.  Given the needs of our users and nature of the project, we should add a set of OS packages to our list of official deliverables in the next release.  For 4.6.0, we should follow our established release process where packaging issues (for better or worse) have not been treated as release blockers.

Thanks,
-John

[1]: I believe we have hosting donated by the good folks at JFrog to provide packages and repos for various platforms.

---
John Burwell (@john_burwell)
VP of Software Engineering, ShapeBlue
(571) 403-2411 | +44 20 3603 0542
http://www.shapeblue.com | @ShapeBlue
53 Chandos Place, Covent Garden, London, WC2N 4HS



> On Nov 6, 2015, at 10:59 AM, Remi Bergsma <RBergsma@schubergphilis.com> wrote:
>
> Hi Paul,
>
> I just tried it, see the same message but also see it actually works. Management server starts and I can see the UI and work from that. I don’t see this as a blocking issue.
>
> On a more generic note, I think we need to move the packaging scripts to their own repository and iterate them separately from CloudStack itself. The ASF doesn’t deliver the packages anyway, so we better make it more flexible. The packaging scripts now compile the source. We should put our artifacts on Maven Central and use those in the packaging instead.
>
> Any change on the packaging needs to be automatically tested (including installs) so we prevent ending up in this situation.
>
> If we do this, we will have cloudstack-management-4.6.0-0 packages, make a fix to them and we’ll have cloudstack-management-4.6.0-1, etc. Package managers know very well how to handle this. The problems found now, can be addressed separately and make a new package, as the CloudStack code itself doesn’t change.
>
> TL;DR CloudStack is fine, hence it has never been in such a good shape. @all please continue the testing.
>
>
> Regards,
> Remi
>
>
> On 06/11/15 16:00, "Paul Angus" <paul.angus@shapeblue.com> wrote:
>
>> The messages plainly say that:
>>
>> Configure CloudStack Management Server ...[Failed]
>>
>> That is showing an error.
>>
>> It then says that it successfully rolled back.
>>
>> Restore Firewall ...          [OK]
>> Restore CloudStack Management Server ...[OK]
>>
>> You then restart it yourself manually after forcing https
>>
>> systemctl restart cloudstack-management
>>
>>
>> IMO that is not an acceptable user experience.
>>
>> If there are missing files and incorrect links due to CentOS 7 using tomcat7 then they need to be added to the packaging before the issue can be said to be fixed.
>> This is why it was taking me so long to untangle all of the changes required for centos7.
>>
>> serviceConfigServer.py  (deal with tomcat6&7 + sudoers)
>> syscfg.py (system for rhel7 for *server* not included)
>> and  /packaging/centos7/cloud.spec (tomcat7 conf files need adding)
>>
>>
>> Regards,
>>
>> Paul Angus
>> VP Technology/Cloud Architect
>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>> paul.angus@shapeblue.com
>>
>> -----Original Message-----
>> From: David Amorim da Cruz Faria [mailto:david@amorim-cruz.net]
>> Sent: 06 November 2015 14:36
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>
>> Hi Paul,
>>
>> the cloudstack-setup-management tool exits without error and the management server starts fine.
>> These files are currently missing from packaging/centos7/tomcat7 but are used by the tool.
>>
>> [root@mgmt01 ~]# cloudstack-setup-management Starting to configure CloudStack Management Server:
>> Configure Firewall ...        [OK]
>> Configure CloudStack Management Server ...[Failed] Cannot find /etc/cloudstack/management/server-nonssl.xml or /etc/cloudstack/management/tomcat6-nonssl.conf, https enables failed Try to restore your system:
>> Restore Firewall ...          [OK]
>> Restore CloudStack Management Server ...[OK]
>>
>> [root@mgmt01 ~]# echo $?
>> 0
>>
>> [root@mgmt01 ~]# cloudstack-setup-management --https Starting to configure CloudStack Management Server:
>> Configure Firewall ...        [OK]
>> Configure CloudStack Management Server ...[Failed] Cannot find /etc/cloudstack/management/server-ssl.xml or /etc/cloudstack/management/tomcat6-ssl.conf, https enables failed Try to restore your system:
>> Restore Firewall ...          [OK]
>> Restore CloudStack Management Server ...[OK]
>>
>> [root@mgmt01 ~]# echo $?
>> 0
>>
>> [root@mgmt01 ~]# systemctl restart cloudstack-management
>>
>> [root@mgmt01 ~]# systemctl status cloudstack-management -l cloudstack-management.service - CloudStack Management Server
>>  Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service;
>> enabled)
>>  Active: active (running) since vr 2015-11-06 14:31:15 UTC; 11s ago
>> Process: 4475 ExecStop=/usr/libexec/tomcat/server stop (code=exited,
>> status=0/SUCCESS)
>> Main PID: 4530 (java)
>>  CGroup: /system.slice/cloudstack-management.service
>>          └─4530 java -Djava.awt.headless=true -Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -classpath /etc/cloudstack/management:/usr/share/cloudstack-common:/usr/share/cloudstack-management/setup:/usr/share/java/mysql-connector-java.jar:/usr/share/cloudstack-management/bin/bootstrap.jar:/usr/share/cloudstack-management/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
>> -Dcatalina.base=/usr/share/cloudstack-management
>> -Dcatalina.home=/usr/share/cloudstack-management -Djava.endorsed.dirs= -Djava.io.tmpdir=/usr/share/cloudstack-management/temp
>> -Djava.util.logging.config.file=/usr/share/cloudstack-management/conf/logging.properties
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> org.apache.catalina.startup.Bootstrap start
>>
>> [lots of irrelevant stuff]
>>
>> From /var/log/cloudstack/management/management-server.log:
>> 2015-11-06 14:33:46,288 DEBUG [c.c.a.ClusterAlertAdapter]
>> (Cluster-Notification-1:ctx-dd28a932) Management server n ode 10.13.95.31 is up, send alert
>>
>>
>>
>> Regards,
>> David Amorim Faria
>>
>> On 6 November 2015 at 14:49, Paul Angus <paul.angus@shapeblue.com> wrote:
>>
>>> Sorry guys.  CentOS 7 install is NOT fixed in 4.6.0-RC20151104T1522.
>>>
>>>
>>> Sorry had to fly out to client in Kenya, so not been able to work on
>>> it recently.
>>>
>>> -1
>>>
>>> [root@CentOS7ACSTest ~]# cloudstack-setup-management Starting to
>>> configure CloudStack Management Server:
>>> Configure Firewall ...        [OK]
>>> Configure CloudStack Management Server ...[Failed] Cannot find
>>> /etc/cloudstack/management/server-nonssl.xml or
>>> /etc/cloudstack/management/tomcat6-nonssl.conf, https enables failed
>>> Try to restore your system:
>>> Restore Firewall ...          [OK]
>>> Restore CloudStack Management Server ...[OK]
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Paul Angus
>>> VP Technology/Cloud Architect
>>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>>> paul.angus@shapeblue.com
>>>
>>> -----Original Message-----
>>> From: Remi Bergsma [mailto:RBergsma@schubergphilis.com]
>>> Sent: 06 November 2015 13:33
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>
>>> Hi Raja,
>>>
>>> Thanks for the report. Most of these seem test-case related. For any
>>> issue you doubt this, can you please verify them manually?
>>>
>>> If it doesn’t work, please file a Jira issue (with details and stept)
>>> and set it to critical. It will then show up on the list of issues and
>>> we can discuss how to proceed.
>>>
>>> https://issues.apache.org/jira/issues/?filter=12332940 (requires
>>> login)
>>>
>>>
>>> Regards,
>>> Remi
>>>
>>>
>>>
>>>
>>> On 06/11/15 12:07, "Raja Pullela" <raja.pullela@citrix.com> wrote:
>>>
>>>> Here is the BVT report on the RC
>>>> KVM Basic – 98.6% , one test failed//test case issue KVM Adv – 96.3%,
>>>> four tests failed //couple due to VM deployment and couple due to
>>>> test case issue XS Basic – 97.2%, two tests failed//test case issues
>>>> XS Adv – 93.5%, seven tests failed //4 due to VM deployment and 3 due
>>>> to test case issues HyperV – 93.3%, seven tests failed Simulator –
>>>> need to run them… will report later today/tomorrow.
>>>>
>>>>
>>>> Failed test cases:
>>>> ·
>>>
>>> integration.smoke.test_vpc_vpn.TestVpcRemoteAccessVpn.test_vpc_remote_
>>> access_vpn
>>> //failed due to VM deployment
>>>> ·
>>>
>>> integration.smoke.test_vpc_vpn.TestVpcSite2SiteVpn.test_vpc_site2site_
>>> vpn
>>> //failed due to VM deployment
>>>> ·
>>>
>>> integration.smoke.test_internal_lb.TestInternalLb.test02_internallb_ha
>>> proxy_stats_on_all_interfaces
>>> //failed due to VM deployment
>>>> ·
>>>
>>> integration.smoke.test_internal_lb.TestInternalLb.test_01_internallb_r
>>> oundrobin_1VPC_3VM_HTTP_port80
>>> //failed due to VM deployment
>>>> ·
>>>
>>> integration.smoke.test_over_provisioning.TestUpdateOverProvision.test_
>>> UpdateStorageOverProvisioningFactor
>>> //test case issue
>>>> ·
>>>
>>> integration.smoke.test_vm_snapshots.TestSnapshots.test_01_test_vm_volu
>>> me_snapshot
>>> //test case issue
>>>> ·         integration.smoke.test_iso.TestISO.test_07_list_default_iso
>>> //test case issue
>>>> <nose.suite.ContextSuite context=TestNiciraContoller>:setup  //test
>>>> case issue
>>>>
>>>> From: Raja Pullela [mailto:raja.pullela@citrix.com]
>>>> Sent: Friday, November 6, 2015 4:30 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: RE: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>
>>>> Here is the BVT report on the RC -
>>>>
>>>> [cid:image001.png@01D118B0.21037340]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Wilder Rodrigues [mailto:WRodrigues@schubergphilis.com]
>>>> Sent: Friday, November 6, 2015 4:19 PM
>>>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>
>>>>
>>>> Thanks again, Lucian!
>>>>
>>>>
>>>>
>>>> I’m already working on 9015 and testing few things, hope to get it
>>>> fixed
>>> soon, but not for 4.6.0.
>>>>
>>>>
>>>>
>>>> If we kan keep the good work in terms of writing/executing tests -
>>>> which
>>> will help keeping Master stable - and also avoid merges that don’t
>>> follow the rule(*), we can have a 4.6.1/4.7.0 (new features) within
>>> two month from now.
>>>>
>>>>
>>>>
>>>> So, let us all keep the great work concerning tests/quality/stability.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Wilder
>>>>
>>>>
>>>>
>>>> * 2 LGTMs + tests (written/executed)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On 06 Nov 2015, at 10:49, Nux!
>>>>> <nux@li.nux.ro<mailto:nux@li.nux.ro>>
>>> wrote:
>>>>
>>>>>
>>>>
>>>>> Well, IMHO the 2 issues are not big problems:
>>>>
>>>>>
>>>>
>>>>> 9015 - it sounds somewhat serious, I'll try to test these days what
>>>>
>>>>> happens if one of the VRs crashes, that's when we'd need redundancy
>>>>> in
>>>>
>>>>> a more "real" scenario, if we could get this fixed before release
>>>>> it'd
>>>>
>>>>> be ideal, Remi should know more re correct procedure here
>>>>
>>>>>
>>>>
>>>>> 9035 - sounds like a non-issue to me, if I want to reset the
>>>>> password
>>> and the backup router does what it's told, then I don't care it
>>> doesn't have the old passwords from the other router cached. This
>>> could impact instance deployments or passwd resets right in the time
>>> BACKUP becomes MASTER. How long is this generally?
>>>>
>>>>>
>>>>
>>>>> Lucian
>>>>
>>>>>
>>>>
>>>>> --
>>>>
>>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>>>
>>>>
>>>>> Nux!
>>>>
>>>>> www.nux.ro<http://www.nux.ro>
>>>>
>>>>>
>>>>
>>>>> ----- Original Message -----
>>>>
>>>>>> From: "Wilder Rodrigues"
>>>>>> <WRodrigues@schubergphilis.com<mailto:WRodrigues@schubergphilis.co
>>>>>> m>
>>>>>>>
>>>>
>>>>>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>>>>
>>>>>> Sent: Friday, 6 November, 2015 09:29:56
>>>>
>>>>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>>
>>>>
>>>>>> Thanks for the clear message, Lucian. I really appreciated that.
>>>>>> :)
>>>>
>>>>>>
>>>>
>>>>>> It’s about the Redundant VPC, not the single one - which is
>>>>>> working
>>>>
>>>>>> pretty fine, btw!
>>>>
>>>>>>
>>>>
>>>>>> Open issues are:
>>>>
>>>>>>
>>>>
>>>>>> * https://issues.apache.org/jira/browse/CLOUDSTACK-9015
>>>>
>>>>>> * https://issues.apache.org/jira/browse/CLOUDSTACK-9035
>>>>
>>>>>>
>>>>
>>>>>> And I have to write tests to cover Private Gateway and S2S VPN for
>>>>
>>>>>> Redundant VPC.
>>>>
>>>>>>
>>>>
>>>>>> All the rest working fine, as you have seen in my report.
>>>>
>>>>>>
>>>>
>>>>>> Cheers,
>>>>
>>>>>> Wilder
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> On 06 Nov 2015, at 10:19, Nux! <nux@li.nux.ro<mailto:nux@li.nux.ro
>>> <mailto:nux@li.nux.ro%3cmailto:nux@li.nux.ro>>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> Well, in my non-coder opinion, we should not deliver broken
>>>>>> software,
>>>>
>>>>>> however we saw in the past fixing it all delayed release considerably.
>>>>
>>>>>> Now, how broken is that VPC? :)
>>>>
>>>>>>
>>>>
>>>>>> --
>>>>
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>>>>
>>>>
>>>>>> Nux!
>>>>
>>>>>> www.nux.ro<http://www.nux.ro<http://www.nux.ro%3chttp:/www.nux.ro>
>>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> ----- Original Message -----
>>>>
>>>>>> From: "Wilder Rodrigues"
>>>>>> <WRodrigues@schubergphilis.com<mailto:WRodrigues@schubergphilis.co
>>>>>> m>
>>>>>>>
>>>>
>>>>>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>>>>
>>>>>> Sent: Friday, 6 November, 2015 08:57:56
>>>>
>>>>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>>>
>>>>
>>>>>> I forgot to mention that for the failed rVPC test I followed the
>>>>>> same
>>>>
>>>>>> steps manually and it worked as expected.
>>>>
>>>>>>
>>>>
>>>>>> In addition, I would like to hear from the community what should
>>>>>> we
>>>>
>>>>>> do in terms of minor/major bugs in new features (like the rVPC).
>>>>>> Will
>>>>
>>>>>> those be fix and added to a 4.6.1 or should it still be part of 4.6.0?
>>>>
>>>>>>
>>>>
>>>>>> Cheers,
>>>>
>>>>>> Wilder
>>>>
>>>>>>
>>>>
>>>>>> On 06 Nov 2015, at 09:17, Wilder Rodrigues
>>>>
>>>>>> <WRodrigues@schubergphilis.com<mailto:WRodrigues@schubergphilis.co
>>>>>> m
>>> <mailto:WRodrigues@schubergphilis.com%
>>> 3cmailto:WRodrigues@schubergphilis.com>>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> Hi all,
>>>>
>>>>>>
>>>>
>>>>>> My considerations after the tests agains XenServer 6.2:
>>>>
>>>>>>
>>>>
>>>>>> We got 4 failures whilst testing against Xen62:
>>>>
>>>>>>
>>>>
>>>>>> * test_vpc_redundant.py on line 522
>>>>
>>>>>> - AssertionError: No Master or too many master routers found 0
>>>>
>>>>>> * test_internal_lb.py lines 712 and 576, when trying to deploy a
>>>>
>>>>>> virtual machine
>>>>
>>>>>> - Unable to create a deployment for VM[User|i-36-89-VM]
>>>>
>>>>>> - Unable to create a deployment for VM[User|i-36-91-VM]
>>>>
>>>>>> * test_vpc_vpn.py line 604 for the same reason as above
>>>>
>>>>>> - Unable to create a deployment for VM[User|i-37-95-VM]
>>>>
>>>>>>
>>>>
>>>>>> There are bugs in the test_vpc_vpn.py VPN test: in case of
>>>>>> failures,
>>>>
>>>>>> when we reach either line 604 or 624, it will try to assert the
>>>>>> state
>>>>
>>>>>> of the variable vm1/vm2, but is has not been assigned yet, which
>>>>
>>>>>> makes us face an Unbound
>>>>
>>>>>> Error:
>>>>
>>>>>> - UnboundLocalError: local variable 'vm1' referenced before
>>>>
>>>>>> assignment
>>>>
>>>>>>
>>>>
>>>>>> Looking at the code I noticed that the same will happen for vm2,
>>>>>> in
>>>>
>>>>>> case vm1 deployment passes but vm1 doesn’t.
>>>>
>>>>>>
>>>>
>>>>>> Concerning the LB and VPN tests, those failed due to a wrong
>>>>
>>>>>> template. Those tests should be executed against KVM only as they
>>>>
>>>>>> have a configuration which depends on KVM hypervisors
>>>>
>>>>>>
>>>>
>>>>>> ```
>>>>
>>>>>>        "default_hypervisor": "kvm",
>>>>
>>>>>>        "compute_offering": {
>>>>
>>>>>>            "name": "Tiny Instance",
>>>>
>>>>>>            "displaytext": "Tiny Instance",
>>>>
>>>>>>            "cpunumber": 1,
>>>>
>>>>>>            "cpuspeed": 100,
>>>>
>>>>>>            "memory": 128,
>>>>
>>>>>>        }
>>>>
>>>>>> ```
>>>>
>>>>>>
>>>>
>>>>>> But I will change that.
>>>>
>>>>>>
>>>>
>>>>>> Concerning the redundant VPC test that failed, it was due an
>>>>>> absence
>>>>
>>>>>> of a master router. For some reason, after the
>>>>
>>>>>> self.delete_nat_rules() was called, the router switched from
>>>>>> Master
>>>>
>>>>>> to Backup, which caused the error. I will investigate.
>>>>
>>>>>>
>>>>
>>>>>> There was also a problem reported by Boris concerning the DEB
>>>>
>>>>>> packages, which he already has a PR for ==>
>>>>
>>>>>> https://github.com/apache/cloudstack/pull/1040. This is package
>>>>
>>>>>> related, thus I don’t see it as a blocker for the release, hence
>>>>>> my
>>>>
>>>>>> +1.
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> ::: Full Report :::
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> :: Environment 1 ::
>>>>
>>>>>>
>>>>
>>>>>> * Hardware required: TRUE
>>>>
>>>>>> * Management Server + MySQL on CentOS 7.1
>>>>
>>>>>> * Two XenServer 6.2 hosts
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> :: Tests Suites Executed ::
>>>>
>>>>>>
>>>>
>>>>>> nosetests --with-marvin
>>>>
>>>>>> --marvin-config=/data/shared/marvin/mct-zone1-xen1-ISOLATED.cfg -s
>>>>>> -a
>>>>
>>>>>> tags=advanced,required_hardware=true
>>>>>> component/test_vpc_redundant.py
>>>>
>>>>>> component/test_routers_iptables_default_policy.py
>>>>
>>>>>> component/test_routers_network_ops.py
>>>>
>>>>>> component/test_vpc_router_nics.py
>>>>>> component/test_password_server.py
>>>>
>>>>>> component/test_router_dhcphosts.py
>>>>
>>>>>> smoke/test_loadbalance.py smoke/test_internal_lb.py
>>>>
>>>>>> smoke/test_ssvm.py smoke/test_vpc_vpn.py smoke/test_network.py
>>>>
>>>>>>
>>>>
>>>>>> :: Environment 2 ::
>>>>
>>>>>>
>>>>
>>>>>> * Hardware required: FALSE
>>>>
>>>>>> * Management Server + MySQL on CentOS 7.1
>>>>
>>>>>> * Two XenServer 6.2 hosts
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> :: Tests Suites Executed ::
>>>>
>>>>>>
>>>>
>>>>>> nosetests --with-marvin
>>>>
>>>>>> --marvin-config=/data/shared/marvin/mct-zone1-xen1-ISOLATED.cfg -s
>>>>>> -a
>>>>
>>>>>> tags=advanced,required_hardware=false smoke/test_routers.py
>>>>
>>>>>> smoke/test_reset_vm_on_reboot.py smoke/test_vm_life_cycle.py
>>>>
>>>>>> component/test_vpc_routers.py smoke/test_service_offerings.py
>>>>
>>>>>> component/test_vpc_offerings.py smoke/test_network_acl.py
>>>>
>>>>>> smoke/test_privategw_acl.py smoke/test_network.py
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> :: Summary ::
>>>>
>>>>>>
>>>>
>>>>>> * Tests executes: 75
>>>>
>>>>>> * Successfull tests: 72
>>>>
>>>>>> * Skipped tests: 6(*)
>>>>
>>>>>> * Failed tests: 5(**)
>>>>
>>>>>>
>>>>
>>>>>> (*) Tests were skipped because I had 2 hosts and the current logic
>>>>>> in
>>>>
>>>>>> the tests does not cope with that: it lists the hosts and takes
>>>>>> the
>>>>
>>>>>> one in index zero
>>>>
>>>>>> - host = hosts[0]
>>>>
>>>>>> (**) Failures and Exceptions being taken into counted
>>>>
>>>>>>
>>>>
>>>>>> :: Test results for Environment 1 ::
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> Create a redundant VPC with two networks with two VMs in each
>>>>>> network
>>>>
>>>>>> ... ===
>>>>
>>>>>> TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL |
>>> Status :
>>>>
>>>>>> FAILED ===
>>>>
>>>>>> FAIL
>>>>
>>>>>> Create a redundant VPC with two networks with two VMs in each
>>>>>> network
>>>>
>>>>>> and check default routes ... SKIP: Marvin configuration has no
>>>>>> host
>>>>
>>>>>> credentials to check router services Test iptables default
>>>>
>>>>>> INPUT/FORWARD policy on RouterVM ... === TestName:
>>>>
>>>>>> test_02_routervm_iptables_policies | Status : SUCCESS === ok Test
>>>>
>>>>>> iptables default INPUT/FORWARD policies on VPC router ... === TestName:
>>>>
>>>>>> test_01_single_VPC_iptables_policies | Status : SUCCESS === ok
>>>>>> Test
>>>>
>>>>>> redundant router internals ... === TestName:
>>>>
>>>>>> test_01_isolate_network_FW_PF_default_routes_egress_true | Status :
>>>>
>>>>>> SUCCESS === ok Test redundant router internals ... === TestName:
>>>>
>>>>>> test_02_isolate_network_FW_PF_default_routes_egress_false | Status :
>>>>
>>>>>> SUCCESS === ok Test redundant router internals ... === TestName:
>>>>
>>>>>> test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status :
>>>>
>>>>>> SUCCESS === ok Test redundant router internals ... === TestName:
>>>>
>>>>>> test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status :
>>>>
>>>>>> SUCCESS === ok Create a VPC with two networks with one VM in each
>>>>
>>>>>> network and test nics after destroy ... === TestName:
>>>>
>>>>>> test_01_VPC_nics_after_destroy | Status : SUCCESS === ok Create a
>>>>>> VPC
>>>>
>>>>>> with two networks with one VM in each network and test default
>>>>>> routes
>>>>
>>>>>> ... === TestName: test_02_VPC_default_routes | Status : SUCCESS
>>>>>> ===
>>>>
>>>>>> ok Check the password file in the Router VM ... === TestName:
>>>>
>>>>>> test_isolate_network_password_server | Status : SUCCESS === ok
>>>>>> Check
>>>>
>>>>>> that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
>>>>
>>>>>> TestName: test_router_dhcphosts | Status : SUCCESS === ok Test to
>>>>
>>>>>> create Load balancing rule with source NAT ... === TestName:
>>>>
>>>>>> test_01_create_lb_rule_src_nat | Status : SUCCESS === ok Test to
>>>>
>>>>>> create Load balancing rule with non source NAT ... === TestName:
>>>>
>>>>>> test_02_create_lb_rule_non_nat | Status : SUCCESS === ok Test for
>>>>
>>>>>> assign & removing load balancing rule ... === TestName:
>>>>
>>>>>> test_assign_and_removal_lb | Status : SUCCESS === ok Test to
>>>>>> verify
>>>>
>>>>>> access to loadbalancer haproxy admin stats page ... === TestName:
>>>>
>>>>>> test02_internallb_haproxy_stats_on_all_interfaces | Status :
>>>>
>>>>>> EXCEPTION === ERROR Test create, assign, remove of an Internal LB
>>>>
>>>>>> with roundrobin http traffic to 3 vm's ... === TestName:
>>>>
>>>>>> test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | Status :
>>>>
>>>>>> EXCEPTION === ERROR Test SSVM Internals ... === TestName:
>>>>
>>>>>> test_03_ssvm_internals | Status : SUCCESS === ok Test CPVM
>>>>>> Internals
>>>>
>>>>>> ... SKIP: Marvin configuration has no host credentials to check
>>>>
>>>>>> router services Test stop SSVM ... === TestName: test_05_stop_ssvm
>>>>>> |
>>>>
>>>>>> Status : SUCCESS === ok Test stop CPVM ... SKIP: Marvin
>>>>>> configuration
>>>>
>>>>>> has no host credentials to check router services Test reboot SSVM ...
>>>>
>>>>>> === TestName: test_07_reboot_ssvm | Status : SUCCESS === ok Test
>>>>
>>>>>> reboot CPVM ... SKIP: Marvin configuration has no host credentials
>>>>>> to
>>>>
>>>>>> check router services Test destroy SSVM ... SKIP: Marvin
>>>>
>>>>>> configuration has no host credentials to check router services
>>>>>> Test
>>>>
>>>>>> destroy CPVM ... === TestName: test_10_destroy_cpvm | Status :
>>>>
>>>>>> SUCCESS === ok Test Remote Access VPN in VPC ... === TestName:
>>>>
>>>>>> test_vpc_remote_access_vpn | Status : FAILED === FAIL Test VPN in
>>>>>> VPC
>>>>
>>>>>> ... === TestName: test_vpc_site2site_vpn | Status : EXCEPTION ===
>>>>
>>>>>> ERROR Test for port forwarding on source NAT ... === TestName:
>>>>
>>>>>> test_01_port_fwd_on_src_nat | Status : SUCCESS === ok Test for
>>>>>> port
>>>>
>>>>>> forwarding on non source NAT ... === TestName:
>>>>
>>>>>> test_02_port_fwd_on_non_src_nat | Status : SUCCESS === ok Test for
>>>>
>>>>>> reboot router ... === TestName: test_reboot_router | Status :
>>>>>> SUCCESS
>>>>
>>>>>> === ok Test for Router rules for network rules on acquired public
>>>>>> IP
>>>>
>>>>>> ... === TestName:
>>>>
>>>>>> test_network_rules_acquired_public_ip_1_static_nat_rule | Status :
>>>>
>>>>>> SUCCESS === ok Test for Router rules for network rules on acquired
>>>>
>>>>>> public IP ... === TestName:
>>>>
>>>>>> test_network_rules_acquired_public_ip_2_nat_rule | Status :
>>>>>> SUCCESS
>>>>
>>>>>> === ok Test for Router rules for network rules on acquired public
>>>>>> IP
>>>>
>>>>>> ... === TestName:
>>>>
>>>>>> test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status :
>>>>
>>>>>> SUCCESS === ok
>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --
>>>>>> -
>>>>
>>>>>> -
>>>>
>>>>>> Ran 33 tests in 9352.773s
>>>>
>>>>>>
>>>>
>>>>>> FAILED (SKIP=5, errors=3, failures=2)
>>>>
>>>>>> (END)
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> :: Test results for Environment 2 ::
>>>>
>>>>>>
>>>>
>>>>>> Test router internal advanced zone ... SKIP: Marvin configuration
>>>>>> has no host
>>>>
>>>>>> credentials                            to check router services
>>>>
>>>>>> Test restart network ... === TestName:
>>>>
>>>>>> test_03_restart_network_cleanup | Status
>>>>
>>>>>> : SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test router basic setup ... === TestName: test_05_router_basic |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test router advanced setup ... === TestName:
>>>>>> test_06_router_advanced |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test stop router ... === TestName: test_07_stop_router | Status :
>>>>
>>>>>> SUCCESS === ok Test start router ... === TestName:
>>>>
>>>>>> test_08_start_router | Status : SUCCESS === ok Test reboot router ...
>>>>
>>>>>> === TestName: test_09_reboot_router | Status : SUCCESS === ok Test
>>>>
>>>>>> reset virtual machine on reboot ... === TestName:
>>>>
>>>>>> test_01_reset_vm_on_reboot | Status : SUCCESS === ok Test advanced
>>>>
>>>>>> zone virtual router ... === TestName: test_advZoneVirtualRouter |
>>>>
>>>>>> Status : SUCCESS === ok Test Deploy Virtual Machine ... === TestName:
>>>>
>>>>>> test_deploy_vm | Status : SUCCESS === ok Test Multiple Deploy
>>>>>> Virtual
>>>>
>>>>>> Machine ... === TestName: test_deploy_vm_multiple | Status :
>>>>>> SUCCESS
>>>>
>>>>>> === ok Test Stop Virtual Machine ... === TestName: test_01_stop_vm
>>>>>> |
>>>>
>>>>>> Status : SUCCESS === ok Test Start Virtual Machine ... === TestName:
>>>>
>>>>>> test_02_start_vm | Status : SUCCESS === ok Test Reboot Virtual
>>>>
>>>>>> Machine ... === TestName: test_03_reboot_vm | Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test destroy Virtual Machine ... === TestName: test_06_destroy_vm
>>>>>> |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test recover Virtual Machine ... === TestName: test_07_restore_vm
>>>>>> |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test migrate VM ... === TestName: test_08_migrate_vm | Status :
>>>>
>>>>>> SUCCESS === ok Test destroy(expunge) Virtual Machine ... ===
>>>>
>>>>>> TestName: test_09_expunge_vm | Status : SUCCESS === ok Test
>>>>
>>>>>> start/stop of router after addition of one guest network ... ===
>>> TestName:
>>>>
>>>>>> test_01_start_stop_router_after_addition_of_one_guest_network |
>>>>>> Status
>>> :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test reboot of router after addition of one guest network ... ===
>>> TestName:
>>>>
>>>>>> test_02_reboot_router_after_addition_of_one_guest_network | Status :
>>>>
>>>>>> SUCCESS === ok Test to change service offering of router after
>>>>
>>>>>> addition of one guest network ... === TestName:
>>>>
>>>>>> test_04_chg_srv_off_router_after_addition_of_one_guest_network |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test destroy of router after addition of one guest network ... ===
>>> TestName:
>>>>
>>>>>> test_05_destroy_router_after_addition_of_one_guest_network | Status :
>>>>
>>>>>> SUCCESS === ok Test to stop and start router after creation of VPC
>>>>
>>>>>> ... === TestName:
>>>>
>>>>>> test_01_stop_start_router_after_creating_vpc | Status : SUCCESS
>>>>>> ===
>>>>
>>>>>> ok Test to reboot the router after creating a VPC ... === TestName:
>>>>
>>>>>> test_02_reboot_router_after_creating_vpc | Status : SUCCESS === ok
>>>>
>>>>>> Tests to change service offering of the Router after ... === TestName:
>>>>
>>>>>> test_04_change_service_offerring_vpc | Status : SUCCESS === ok
>>>>>> Test
>>>>
>>>>>> to destroy the router after creating a VPC ... === TestName:
>>>>
>>>>>> test_05_destroy_router_after_creating_vpc | Status : SUCCESS ===
>>>>>> ok
>>>>
>>>>>> Test to create service offering ... === TestName:
>>>>
>>>>>> test_01_create_service_offering | Status : SUCCESS === ok Test to
>>>>
>>>>>> update existing service offering ... === TestName:
>>>>
>>>>>> test_02_edit_service_offering | Status : SUCCESS === ok Test to
>>>>
>>>>>> delete service offering ... === TestName:
>>>>
>>>>>> test_03_delete_service_offering | Status : SUCCESS === ok Test
>>>>>> create
>>>>
>>>>>> VPC offering ... === TestName: test_01_create_vpc_offering |
>>>>>> Status
>>>>
>>>>>> : SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test VPC offering without load balancing service ... === TestName:
>>>>
>>>>>> test_03_vpc_off_without_lb | Status : SUCCESS === ok Test VPC
>>>>
>>>>>> offering without static NAT service ... === TestName:
>>>>
>>>>>> test_04_vpc_off_without_static_nat | Status : SUCCESS === ok Test
>>>>>> VPC
>>>>
>>>>>> offering without port forwarding service ... === TestName:
>>>>
>>>>>> test_05_vpc_off_without_pf | Status : SUCCESS === ok Test VPC
>>>>
>>>>>> offering with invalid services ... === TestName:
>>>>
>>>>>> test_06_vpc_off_invalid_services | Status : SUCCESS === ok Test
>>>>
>>>>>> update VPC offering ... === TestName: test_07_update_vpc_off | Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>> Test list VPC offering ... === TestName: test_08_list_vpc_off |
>>>>
>>>>>> Status : SUCCESS === ok test_09_create_redundant_vpc_offering
>>>>
>>>>>> (integration.component.test_vpc_offerings.TestVPCOffering) ... ===
>>> TestName:
>>>>
>>>>>> test_09_create_redundant_vpc_offering | Status : SUCCESS === ok
>>>>
>>>>>> test_privategw_acl
>>> (integration.smoke.test_privategw_acl.TestPrivateGwACL) ...
>>>>
>>>>>> === TestName: test_privategw_acl | Status : SUCCESS === ok Test
>>>>>> for
>>>>
>>>>>> delete account ... === TestName: test_delete_account | Status :
>>>>
>>>>>> SUCCESS === ok Test for Associate/Disassociate public IP address
>>>>>> for
>>>>
>>>>>> admin account ... ===
>>>>
>>>>>> TestName: test_public_ip_admin_account | Status : SUCCESS === ok
>>>>>> Test
>>>>
>>>>>> for Associate/Disassociate public IP address for user account ...
>>>>>> ===
>>>>
>>>>>> TestName: test_public_ip_user_account | Status : SUCCESS === ok
>>>>>> Test
>>>>
>>>>>> for release public IP address ... === TestName: test_releaseIP |
>>> Status :
>>>>
>>>>>> SUCCESS ===
>>>>
>>>>>> ok
>>>>
>>>>>>
>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --
>>>>>> -
>>>>
>>>>>> -
>>>>
>>>>>> Ran 42 tests in 5463.487s
>>>>
>>>>>>
>>>>
>>>>>> OK (SKIP=1)
>>>>
>>>>>> (END)
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> On 05 Nov 2015, at 20:13, Nux! <nux@li.nux.ro<mailto:nux@li.nux.ro
>>> <mailto:nux@li.nux.ro%3cmailto:nux@li.nux.ro>>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> Installation on CentOS 6 mgmt and HVs worked great, added some
>>>>
>>>>>> templates, deployed some instances, no issues.
>>>>
>>>>>> I'll get back if I hit problems.
>>>>
>>>>>>
>>>>
>>>>>> Lucian
>>>>
>>>>>>
>>>>
>>>>>> --
>>>>
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>>>>
>>>>
>>>>>> Nux!
>>>>
>>>>>> www.nux.ro<http://www.nux.ro/<http://www.nux.ro%3chttp:/www.nux.ro
>>>>>> />
>>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> ----- Original Message -----
>>>>
>>>>>> From: "Nux!"
>>>>>> <nux@li.nux.ro<mailto:nux@li.nux.ro<mailto:nux@li.nux.ro%3cmailto:
>>>>>> nu
>>>>>> x@li.nux.ro>>>
>>>>
>>>>>> To:
>>>>>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org<mailto:
>>>>>> de v@cloudstack.apache.org%3cmailto:dev@cloudstack.apache.org>>
>>>>
>>>>>> Sent: Thursday, 5 November, 2015 08:48:38
>>>>
>>>>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>>>
>>>>
>>>>>> Thanks Remi!
>>>>
>>>>>>
>>>>
>>>>>> --
>>>>
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>>>>
>>>>
>>>>>> Nux!
>>>>
>>>>>> www.nux.ro<http://www.nux.ro<http://www.nux.ro%3chttp:/www.nux.ro>
>>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> ----- Original Message -----
>>>>
>>>>>> From: "Remi Bergsma"
>>>>
>>>>>> <RBergsma@schubergphilis.com<mailto:RBergsma@schubergphilis.com<ma
>>>>>> il
>>>>>> to:RBergsma@schubergphilis.com%3cmailto:RBergsma@schubergphilis.co
>>>>>> m>
>>>>>>>>
>>>>
>>>>>> To:
>>>>>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org<mailto:
>>>>>> de v@cloudstack.apache.org%3cmailto:dev@cloudstack.apache.org>>
>>>>
>>>>>> Sent: Wednesday, 4 November, 2015 20:45:59
>>>>
>>>>>> Subject: Re: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>>>
>>>>
>>>>>> Kicked off some Jenkins builds:
>>>>
>>>>>>
>>>>
>>>>>> CentOS 6 packages:
>>>>
>>>>>> http://jenkins.buildacloud.org/view/parameterized/job/cloudstack-r
>>>>>> pm
>>>>>> -
>>>>
>>>>>> packages-with-branch-parameter/lastSuccessfulBuild/artifact/dist/r
>>>>>> pm
>>>>>> b
>>>>
>>>>>> uild/RPMS/x86_64/
>>>>
>>>>>>
>>>>
>>>>>> CentOS 7 packages:
>>>>
>>>>>> http://jenkins.buildacloud.org/view/parameterized/job/cloudstack-r
>>>>>> pm
>>>>>> -
>>>>
>>>>>> packages-with-branch-parameter-centos7/lastSuccessfulBuild/artifac
>>>>>> t/
>>>>>> d
>>>>
>>>>>> ist/rpmbuild/RPMS/x86_64/
>>>>
>>>>>>
>>>>
>>>>>> Ubuntu Trusty packages:
>>>>
>>>>>> http://cloudstack.apt-get.eu/ubuntu/dists/trusty/4.6/pool/
>>>>
>>>>>>
>>>>
>>>>>> SystemVM template:
>>>>
>>>>>> http://jenkins.buildacloud.org/view/parameterized/job/parameterize
>>>>>> d-
>>>>>> s
>>>>
>>>>>> ytemvm/lastSuccessfulBuild/artifact/tools/appliance/dist/
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> You can always build packages from the source:
>>>>
>>>>>> cd packaging
>>>>
>>>>>> ./package.sh -h
>>>>
>>>>>>
>>>>
>>>>>> Happy testing!
>>>>
>>>>>>
>>>>
>>>>>> Regards,
>>>>
>>>>>> Remi
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> On 04/11/15 18:12, "Remi Bergsma"
>>>>
>>>>>> <RBergsma@schubergphilis.com<mailto:RBergsma@schubergphilis.com
>>> <mailto:RBergsma@schubergphilis.com%3cmailto:RBergsma@schubergphilis.c
>>> om>>>
>>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> The jobs failed due to the git clone failing (time out). I also
>>>>
>>>>>> experience it is quite slow at the moment.
>>>>
>>>>>>
>>>>
>>>>>> It is mirrored here (same commit id):
>>>>
>>>>>> https://github.com/apache/cloudstack/tree/4.6.0-RC20151104T1522
>>>>
>>>>>>
>>>>
>>>>>> Regards,
>>>>
>>>>>> Remi
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> On 04/11/15 17:17, "Rajani Karuturi"
>>>>
>>>>>> <Rajani.Karuturi@citrix.com<mailto:Rajani.Karuturi@citrix.com<mailto:
>>> Rajani.Karuturi@citrix.com%3cmailto:Rajani.Karuturi@citrix.com>>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> I started jenkins builds for cloudstack RPM packages and systemvm
>>>>
>>>>>> templates for this branch here
>>>>
>>>>>>
>>>>
>>>>>> http://jenkins.buildacloud.org/view/parameterized/job/cloudstack-r
>>>>>> pm
>>>>>> -
>>>>
>>>>>> packages-with-branch-parameter/19/console
>>>>
>>>>>> http://jenkins.buildacloud.org/view/parameterized/job/parameterize
>>>>>> d-
>>>>>> s
>>>>
>>>>>> ytemvm/3/console
>>>>
>>>>>>
>>>>
>>>>>> We can use them once the build is complete.
>>>>
>>>>>>
>>>>
>>>>>> ~Rajani
>>>>
>>>>>>
>>>>
>>>>>> On 04-Nov-2015, at 8:58 PM, Nux!
>>>>
>>>>>> <nux@li.nux.ro<mailto:nux@li.nux.ro<mailto:nux@li.nux.ro%
>>> 3cmailto:nux@li.nux.ro>><mailto:nux@li.nux.ro>> wrote:
>>>>
>>>>>>
>>>>
>>>>>> Hi,
>>>>
>>>>>>
>>>>
>>>>>> Has jenkins built rpms for this somewhere?
>>>>
>>>>>>
>>>>
>>>>>> --
>>>>
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>
>>>>>>
>>>>
>>>>>> Nux!
>>>>
>>>>>> www.nux.ro<http://www.nux.ro><http://www.nux.ro<http://www.nux.ro%
>>>>>> 3c http:/www.nux.ro%3e%3chttp:/www.nux.ro>>
>>>>
>>>>>>
>>>>
>>>>>> ----- Original Message -----
>>>>
>>>>>> From: "Remi Bergsma"
>>>>
>>>>>> <RBergsma@schubergphilis.com<mailto:RBergsma@schubergphilis.com<ma
>>>>>> il
>>>>>> to:RBergsma@schubergphilis.com%3cmailto:RBergsma@schubergphilis.co
>>>>>> m>
>>>>>>>>
>>>>
>>>>>> To:
>>>>>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org<mailto:
>>>>>> de v@cloudstack.apache.org%3cmailto:dev@cloudstack.apache.org>>
>>>>
>>>>>> Sent: Wednesday, 4 November, 2015 14:55:11
>>>>
>>>>>> Subject: [VOTE] Apache CloudStack 4.6.0
>>>>
>>>>>>
>>>>
>>>>>> Hi all,
>>>>
>>>>>>
>>>>
>>>>>> I've created a 4.6.0 release candidate, with the following
>>>>>> artifacts
>>>>
>>>>>> up for a
>>>>
>>>>>> vote:
>>>>
>>>>>>
>>>>
>>>>>> Git Branch and Commit SH:
>>>>
>>>>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlo
>>>>>> g;
>>>>>> h
>>>>
>>>>>> =4.6.0-RC20151104T1522
>>>>
>>>>>>
>>>>
>>>>>> Commit: b0ebe68e375432b28eef031ab62ccd5831234c77
>>>>
>>>>>>
>>>>
>>>>>> Source release (checksums and signatures are available at the same
>>>>
>>>>>> location):
>>>>
>>>>>> https://dist.apache.org/repos/dist/dev/cloudstack/4.6.0/
>>>>
>>>>>>
>>>>
>>>>>> PGP release keys (signed using A47DDC4F):
>>>>
>>>>>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>>>>
>>>>>>
>>>>
>>>>>> Vote will be open for at least 72 hours.
>>>>
>>>>>>
>>>>
>>>>>> For sanity in tallying the vote, can PMC members please be sure to
>>>>
>>>>>> indicate "(binding)" with their vote?
>>>>
>>>>>>
>>>>
>>>>>> [ ] +1  approve
>>>>
>>>>>> [ ] +0  no opinion
>>>>
>>>>>> [ ] -1  disapprove (and reason why)
>>>>
>>>>
>>> Find out more about ShapeBlue and our range of CloudStack related
>>> services
>>>
>>> IaaS Cloud Design & Build<
>>> http://shapeblue.com/iaas-cloud-design-and-build//>
>>> CSForge – rapid IaaS deployment
>>> framework<http://shapeblue.com/csforge/>
>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>>> CloudStack Software Engineering<
>>> http://shapeblue.com/cloudstack-software-engineering/>
>>> CloudStack Infrastructure Support<
>>> http://shapeblue.com/cloudstack-infrastructure-support/>
>>> CloudStack Bootcamp Training Courses<
>>> http://shapeblue.com/cloudstack-training/>
>>>
>>> This email and any attachments to it may be confidential and are
>>> intended solely for the use of the individual to whom it is addressed.
>>> Any views or opinions expressed are solely those of the author and do
>>> not necessarily represent those of Shape Blue Ltd or related
>>> companies. If you are not the intended recipient of this email, you
>>> must neither take any action based upon its contents, nor copy or show
>>> it to anyone. Please contact the sender if you believe you have
>>> received this email in error. Shape Blue Ltd is a company incorporated
>>> in England & Wales. ShapeBlue Services India LLP is a company
>>> incorporated in India and is operated under license from Shape Blue
>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>>> Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA
>>> Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>>
>> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Mime
View raw message