Add support for DSC 2.2 Versions

[mshuler]

It appears the current AMI only attempts to install dsc21 and fails on cassandra version 2.2.0 existing in the "stable" repo.

Better yet, the DSC deb repositories have been split into major.minor repos ("stable" will still be around for a while with all versions):

# DSC - Public
#deb https://debian.datastax.com/community stable main
#deb https://debian.datastax.com/community 1.2 main
#deb https://debian.datastax.com/community 2.0 main
#deb https://debian.datastax.com/community 2.1 main
#deb https://debian.datastax.com/community 2.2 main

Perhaps, the major.minor could be used from passed-in --release x.x.x and sources.list prepared accordingly, which will also prevent future unintended major.minor upgrades. A default could be selected as the current "production" major.minor, such as 2.1 today.

[piotrwest]

I've got the same problem.
Furthermore, even if I specify the release in AMI as follows:
--clustername cassandra --totalnodes 3 --version community --release 2.1
the script knows that I want to use release 2.1:
[INFO] Started with user data set to:
[INFO] --clustername cassandra --totalnodes 3 --version community --release 2.1
however it still tries to install dsc20:
[EXEC] 07/21/15-13:05:12 sudo apt-get install -y python-cql datastax-agent dsc20:
and fails:
The following packages have unmet dependencies:
dsc20 : Depends: cassandra (= 2.0.16) but 2.2.0 is to be installed
It doesn't help if I specify the release as 2.1.0.

I think simillar issue was reported here: #80 and here: SO: EC2 AMI 2.4 Issue and fixed (temporarily) here: DataStax: AMI 2.4 error.

Maybe it will be good to allow to specify custom dsc and cassandra version in AMI params?

[mlococo]

Proposed fix committed to dev-2.5 and dev-2.6. Will test today and release today.

[mlococo]

In response to the comments @mshuler, we already do major.minor detection if a version is passed in. Our current default is to install the "latest" from stable if nothing is passed in (which means things break when the package name of "latest" changes). I'm open to PR's that improve the way we handle the default package versioning... but it's currently moderately messy and I don't have cycles to go back and clean it up.

A semi-related open-issue is parsing dependency versions (we currently manually maintain lists of all the versions in our source-code), which is in #77

[mlococo]

Pushed.

Tested with 2.2.0, 2.1.8, and no release supplied:

--clustername test1
--totalnodes 1
--version community
--release 2.2.0
--forcecommit b6de162

--clustername test2
--totalnodes 1
--version community
--release 2.1.8
--forcecommit b6de162

--clustername test3
--totalnodes 1
--version community
--forcecommit b6de162