Whirr
  1. Whirr
  2. WHIRR-155

Support multiple versions of Cassandra

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.3.0
    • Component/s: service/cassandra
    • Labels:
      None

      Description

      The release of Cassandra 0.7 is coming up, so I'm attaching a patch to the scripts that allows 0.7 to be deployed, and makes rc-1 the default.

        Issue Links

          Activity

          Hide
          Johan Oskarsson added a comment -

          I've just committed this. Thanks Stu!

          Show
          Johan Oskarsson added a comment - I've just committed this. Thanks Stu!
          Hide
          Stu Hood added a comment -

          Both 0001 and 0002 are good for commit: the scripts are capable of installing 0.6, 0.7 and 0.8-pre.

          Show
          Stu Hood added a comment - Both 0001 and 0002 are good for commit: the scripts are capable of installing 0.6, 0.7 and 0.8-pre.
          Hide
          Tom White added a comment -

          So shall I commit 0001, and leave 0002 for another issue?

          Show
          Tom White added a comment - So shall I commit 0001, and leave 0002 for another issue?
          Hide
          Stu Hood added a comment -

          I found a forwards compatible way to configure the seeds, so I squashed 0003 into 0001. This should be ready for commit.

          Show
          Stu Hood added a comment - I found a forwards compatible way to configure the seeds, so I squashed 0003 into 0001. This should be ready for commit.
          Hide
          Tom White added a comment -

          Thanks Stu. It's best to commit all these in one go (unless you want to create separate JIRAs), so can you let me know when they're ready to go in (i.e. when RC3 is out and tested)?

          How do you run the scripts in the second patch?

          Show
          Tom White added a comment - Thanks Stu. It's best to commit all these in one go (unless you want to create separate JIRAs), so can you let me know when they're ready to go in (i.e. when RC3 is out and tested)? How do you run the scripts in the second patch?
          Hide
          Stu Hood added a comment -

          0001 - Allows the deploy script to deploy 0.7, and allows overriding by specifying an alternate tarball URL
          0002 - Adds scripts that were necessary for the tests in CASSANDRA-1859

          0003 shouldn't be applied until 0.7-rc3 is available: the way that you specify the seeds changed between rc2 and rc3, so committing it now would break rc2 (the default).

          Show
          Stu Hood added a comment - 0001 - Allows the deploy script to deploy 0.7, and allows overriding by specifying an alternate tarball URL 0002 - Adds scripts that were necessary for the tests in CASSANDRA-1859 0003 shouldn't be applied until 0.7-rc3 is available: the way that you specify the seeds changed between rc2 and rc3, so committing it now would break rc2 (the default).
          Hide
          Tom White added a comment -

          Great. BTW you should generate patches with "git diff --no-prefix" so they can be applied with "patch -p0" for svn.

          Show
          Tom White added a comment - Great. BTW you should generate patches with "git diff --no-prefix" so they can be applied with "patch -p0" for svn.
          Hide
          Stu Hood added a comment -

          Thanks Tom: I'll post a 0003 to allow the version to be passed through.

          For now, I found a problem with 0001: /etc/profile is not executed in the context where bin/cassandra is called, so CASSANDRA_HOME/CONF don't end up getting set. 0002 is pretty ugly, but I'm posting it rather than leaving a completely broken patch.

          Show
          Stu Hood added a comment - Thanks Tom: I'll post a 0003 to allow the version to be passed through. For now, I found a problem with 0001: /etc/profile is not executed in the context where bin/cassandra is called, so CASSANDRA_HOME/CONF don't end up getting set. 0002 is pretty ugly, but I'm posting it rather than leaving a completely broken patch.
          Hide
          Tom White added a comment -

          This looks good to me. There's currently no mechanism for controlling the value of C_VERSION from the client, perhaps misleadingly, since it reads $1, but it's never set. To make this more useful we could pass in the version number in the call to this script in CassandraClusterActionHandler#beforeBootstrap, perhaps reading it from the "cassandra.version" property in ClusterSpec's configuration.

          Show
          Tom White added a comment - This looks good to me. There's currently no mechanism for controlling the value of C_VERSION from the client, perhaps misleadingly, since it reads $1, but it's never set. To make this more useful we could pass in the version number in the call to this script in CassandraClusterActionHandler#beforeBootstrap, perhaps reading it from the "cassandra.version" property in ClusterSpec's configuration.

            People

            • Assignee:
              Stu Hood
              Reporter:
              Stu Hood
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development