Add replication strategy support (#1)

[markglh]

• Added support for configurable replication strategy when creating the keyspace. A valid config will look like:

Simple Strategy

pillar.faker {
    development {
        cassandra-seed-address: "127.0.0.1"
        cassandra-keyspace-name: "pillar_development"
        replicationStrategy: "SimpleStrategy"
        replicationFactor: 0
    }
}

Network Topology Strategy

pillar.faker {
    development {
        cassandra-seed-address: "127.0.0.1"
        cassandra-keyspace-name: "pillar_development"
        replicationStrategy: "NetworkTopologyStrategy"
        replicationFactor: [
            {dc1: 2},
            {dc2: 3}
        ]
    }
}

• Added CassandraUnit to enable testing & CI without a local Cassandra:
  https://github.com/jsevellec/cassandra-unit
• Tweaked README
• Set the default consistencyLevel to QUORUM. This ensures that the migrations are immediately consistent (both read and write will use QUORUM). High consistency here is essential to ensure that we always read the latest migrations and don't try to re-apply. Additionally, performance is not a concern as this are executed as a one-off.

We deliberately didn't make the consistency level configurable as we don't believe it adds value, there isn't a valid reason to use a lower consistency level than QUORUM here.

[markglh]

Credit for the initial work goes to @j-potts

[markglh]

not required now we're using cassandra-unit

[markglh]

This gives us an embedded cassandra

[markglh]

@lichtsprung we also have another pr almost ready to go which build on this one, adding quorum consistency for the migrations. This is essential when running against several nodes.

[lichtsprung]

@markglh Awesome! I will try to review both PRs this Friday :)

[markglh]

@lichtsprung that's great, thanks! We'll raise the second PR later today then so it's ready for you. It builds upon this one so probably best to review + merge this one before reviewing the second

[markglh]

I've merged the consistency level changes into this pr as they kind of go hand in hand and are fairly trivial.
See here: 2a95614

[lichtsprung]

@markglh I agree with that you don't want to use a lower consistency level than QUORUM but what if you need LOCAL_QUORUM consistency?

[markglh]

If it's a single DC then we'd effectively have LOCAL_QUORUM anyway, however with multiple DC's my thinking was that you would always want these schema changes replicating across all of them as they're obviously pretty important. I was actually toying with EACH_QUORUM but I'm not sure if that's necessary.

Are you thinking we may want LOCAL_QUORUM under some circumstances? @lichtsprung

[markglh]

To elaborate on the multiple DC thing, my thinking was that having inconsistent keyspaces across DC's could potentially be a major issue if applications start running before they're consistent

[lichtsprung]

@markglh Not sure. Was just wondering if there might be a (good) reason for using some variant of QUORUM.

I think I'd prefer EACH_QUORUM in a multi DC setting though.

[lichtsprung]

...Not sure if this is really an issue or necessary for a multiple DCs.

@markglh We can merge this version and see if anyone complains that they need some higher consistency level for whatever reason.

[markglh]

@lichtsprung works for me. If feedback is that we want this configurable we can make the change. Would you like it changing to EACH_QUORUM before the merge?

[lichtsprung]

@markglh Let me ask our ops team. If they prefer something other than quorum, we need to make it configurable.

[lichtsprung]

@markglh I'll publish a new version on Monday.

[markglh]

@lichtsprung that's great, thanks!!