Document the "customreservation" parameter about comboami

[joaquincasares]

Sorry, we won't be documenting this parameter as well as the few others you may see in the source. They were community contributions/ideas that worked for very specific short-lived use cases, but we're unsure how reliable they will be in the future since they have never been tested after the initial commit.

However, feel free to use the parameter and contribute fixes.

The main issues I have in mind with the customreservation parameter will be an improper seed lists (where one dc may never know of the other dc, but will still ring), possible need for setting the broadcast/listen_addresses (where broadcast_address may need to be the public IP and the listen_address be the private IP), token assigment issues (where there may be token conflicts), and token placement issues (where the nodes will need to alternate around the ring, but instead may be split in halves). Also, if one AZ starts up with greater than a 10 minute difference the cluster will not ring properly.

But feel free to work under if options['customreservation']: logic and provide the fixes there and I'll be happy to accept them. That way if any one else uses the AMI, they're ensured to keep with same code path that has always run and you'll be able to have the logic for your specific use case, which will hopefully be broad enough for others to use as well in the future.

I'll be closing this issue, but feel free to continue discussing what you're trying to accomplish and code here and I'll be happy to help.

Cheers!

[ablundgren]

I believe that this, or some other work around is going to be needed to make this work in a VPC environment. If you don't have it, I don't see how you can support the VPC deployments.

I saw in your other posts that you wanted to remove the limitations from the documentation. Is there something else in the works that would allow this?

[joaquincasares]

Those are two separate issues.

The first, VPC support, is what you and I have been trying to cover. As of now it seems as though the AMIs work on VPCs without any additional work? If so, I'll update our docs team to remove that limitation.

The second, multi-AZ support, has been discussed although is not reliable without an external tool to manage the two distinct cluster reservations. The reason for this is due to how EC2 restricts launching a reservation of AMIs within a single region. The fact that you're having to issue two create commands/workflows within a 10 minute window highlights the fact that we're already performing a workaround. Do keep in mind that we're fine providing this workaround through the AMI, but ensuring and maintaining this functionality is out of scope of the AMI.

If you wish to get true multi-AZ support, you may want to take a look at OpsCenter Enterprise. OpsCenter will allow you to provision clusters/nodes within specified AZs for a production-level deployment.

You should also note that the AMI's intended purpose was initially for launching quick developmental clusters that would automatically update, install, and provision themselves with many best practices without much effort. However, if you would like to add additional (non-maintained) functionality that would allow multi-AZ clusters, I would be happy to accept it as I'm sure members of the community would also enjoy this.

[ablundgren]

Fair enough.

As to working with a VPC, you requested some additional nodetool ring output that you wanted to validate in the other thread. I sent that out of github, to your email address listed here. If that looks good to you, then I think it is working. I will know more in a few weeks as we load more data into it, but I have been able to create a keyspace and drop some information into it w/o a problem.

For the customreservation paramter, I think it would save time if there were a note about this parameter some place, it took reading the py script to find it. (Someone here had heard about it, but forgotten what it was.) Even a note in the documentation saying that there are additional undocumented/unsupported arguments in the code would be helpful.

[joaquincasares]

Okay that sounds great. I'll open up a ticket for our docs team to update that message.

I'm against documentation for this parameter outside of what currently exists (https://github.com/riptano/ComboAMI/blob/2.4/ds2_configure.py#L197). The reason being that those who would like to utilize this parameter need to understand what they're doing. It has a few other applications that may be useful for testing but ultimately won't work as one might hope. I'd rather people reach out if they're interested, like yourself, and I'll educate them as to how it's used and the caveats that they may want to handle before using it in practice. Keeping these in check ensures someone doesn't accidently shoot themselves in the foot at the start of their Cassandra deployment even if it requires just a bit of my time.

Think of the options below line 186 as fragmented pieces of code that may be useful as a starting point for future ideas rather than supported options.

Hope this clarification helps. :)