For an apache project, a VOTE on a release candidate is a very important process. By voting (particularly for PMC members and committers), you are saying to the world that "yes, I have download, verified and tested using the project's procedure for testing". Your +1, 0 or -1 vote is an indication of the success of the steps listed. The more time that each individual spends reviewing the artifacts, the higher confidence we can have in the release.
Test the Build
rm -Rf /tmp/cloudstack-cloudmonkey
Download the artifacts:
mkdir /tmp/cloudstack-cloudmonkey; cd /tmp/cloudstack-cloudmonkey wget --no-check-certificate https://dist.apache.org/repos/dist/release/cloudstack/KEYS wget --no-check-certificate https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.1.0/apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2 wget --no-check-certificate https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.1.0/apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2.asc wget --no-check-certificate https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.1.0/apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2.md5 wget --no-check-certificate https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.1.0/apache-cloudstack-cloudmonkey-5.1.0-src.tar.bz2.sha
Install gpg (if needed): sudo apt-get install gpg
Import keys:
This can be done by importing the keys stored in the source distribution's KEYS file: gpg --import KEYS
Alternatively, you could download the signing keys (ID's found in the KEYS file) individually via a keyserver. Ex: gpg --recv-keys CC56CEA8
Verify signatures and hash files:
gpg --verify apache-cloudstack-4.3.0-src.tar.bz2.asc
This command should return "Good Signature".
gpg --print-md MD5 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-src.tar.bz2.md5 gpg --print-md SHA512 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-src.tar.bz2.sha
Each of these commands should return no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
Get the commit hash from the VOTE email (ex: 4cd60f3d1683a3445c3248f48ae064fb573db2a1). The value will change between releases.
Create two new temporary directories:
mkdir /tmp/cloudstack/git mkdir /tmp/cloudstack/tree
Pull down the git repo:
git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git /tmp/cloudstack/git cd /tmp/cloudstack/git git archive --format=tar --prefix=/tmp/cloudstack/tree/ <commit-hash> | tar Pxf -
Unpack the release artifact:
cd /tmp/cloudstack tar xvfj apache-cloudstack-4.3.0-src.tar.bz2
Compare the contents of the release artifact with the contents pulled from the repo:
diff -r /tmp/cloudstack/apache-cloudstack-4.3.0-src /tmp/cloudstack/tree
Nothing should be different.
cd /tmp/cloudstack/apache-cloudstack-4.3.0-src mvn --projects='org.apache.cloudstack:cloudstack' org.apache.rat:apache-rat-plugin:0.8:check
The build should FAIL if there are any non-compliant files that are not specifically excluded from the ASF license header requirement. You can optionally review the target/rat.txt file after the run completes. If the build passes, RAT is saying that we are compliant and this test passes.
Note: If you're on Ubuntu and using the PPA:natecarlson/maven3 (viz. Installing tools above), you've to use mvn3 instead of mvn, so mvn3 -P deps
mvn -P developer,systemvm clean install mvn -P developer -pl developer,tools/devcloud -Ddeploydb mvn -pl :cloud-client-ui jetty:run
Once the management server starts on your local machine, execute the following commands to bring up a basic zone using the devcloud2 VM:
Deploy DevCloud (make sure mysql-connector-python is installed and that the management server is running)
$ mvn -P developer -pl tools/devcloud -Ddeploysvr
Or, if the above does not work, maybe you're running mvn in debug mode using some MAVEN_OPTS, try marvin:
$ cd tools/devcloud; python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
The above will deploy a zone with settings defined in tools/devcloud/devcloud.cfg which sets some global settings and will take some time. After this, you should restart management server and destroy any system vms which may have started for the global settings to take effect.
Access web UI: http://localhost:8080/client, and login with admin/password. You can tell if the SSVM has been started by navigating to the Infrastructure page, and clicking on System VMs. There should be 2 listed, and their status needs to be displayed as "Started".
Add a new instance:
Test other functionality, to suite your tastes (and perhaps using non-DevCloud infrastructure.
In a separate terminal run:
mvn -Pawsapi -pl :cloud-awsapi jetty:run
Via the UI:
1. Destroy any running instances
2. Rename the tinyoffering compute offering 'm1.small'
Then using the access key and secret key of your admin user run the following python script:
#!/usr/bin/env python import boto import boto.ec2 accesskey="2IUSA5xylbsPSnBQFoWXKg3RvjHgsufcKhC1SeiCbeEc0obKwUlwJamB_gFmMJkFHYHTIafpUx0pHcfLvt-dzw" secretkey="oxV5Dhhk5ufNowey7OVHgWxCBVS4deTl9qL0EqMthfPBuy3ScHPo2fifDxw1aXeL5cyH10hnLOKjyKphcXGeDA" region = boto.ec2.regioninfo.RegionInfo(name="ROOT", endpoint="localhost") conn = boto.connect_ec2(aws_access_key_id=accesskey, aws_secret_access_key=secretkey, is_secure=False, region=region, port=7080, path="/awsapi", api_version="2012-08-15") images=conn.get_all_images() print images res = images[0].run(instance_type='m1.small',security_groups=['default'])
If the keys have changed, using the above script verbatim won't work. Make sure to update the keys.
If we made it this far, the release has at least been reasonably "smoke tested".