Unibrow: Uniform Bootstrap Operation
(UNIBROw comes from UNIform BootstRap Operation)
Matt Ingenthron <firstname.lastname@example.org>
28 August 2013
SDK Development Team
email@example.com mailing list
Change the bootstrapping of all clients to have consistent behavior. Allow for both deterministic and random bootstrapping from a cluster and for dynamic updates to the bootstrap list past the initial list supplied by the application developer/operator.
Current bootstrapping can vary from client to client. Project CCCP will get to a much more regular and long-term-supportable approach, but it would be good to have a short term approach to cover a few things. First, it would be good for all client libraries to handle bootstrapping in the same way. Second, currently there are some situations where random bootstrapping, by which we mean selecting a bootstrap node at random, is preferred to deterministic bootstrapping. Some clients support this already and do it by default, where other clients do only deterministic bootstrapping. Third, we want the ability to change the bootstrap list without a restart of an application. It is somewhat complicated from a maintenance perspective to do a complete cluster swap currently, as the application needs to be reconfigured/restarted first. Notably, the Java client can't currently handle a complete cluster swap and has no (built-in) method of configuration which can be done dynamically.
The UNIBROw project assumes that it can be delivered over the regular release cycle of the client libraries. It also has no dependencies on changes to the Couchbase Cluster.
See description above.
The market is any deployment which may likely need to do a full cluster swap. This is quite possible in cloud deployments. For instance, at one point Amazon asked all of their customers in a given region to "move" to new instances. They gave some notice, but it was still intrusive. This kind of use case can come up with clusters for version upgrades, deployments in certain environments, etc.
The changes and feature tests will be integrated in each client library and tested.
Situational tests around full cluster tests will be carried out.
This project would be a simple set of changes per client library. In the end, each client library must have a way to configure...
- A list of bootstrap URIs (this already exists)
- A way to configure the client to use those URIs either...
- In order supplied (thus, every client will deterministically have the same configuration)
- In a random order (thus, clients could end up in different places if not all of the URIs go to the same cluster)
- A configuration file approach, idiomatic to the platform (i.e. yaml for Ruby, properties files for Java) which can allow for the reconfiguration of URIs without restarting the application.
Project CCCP is the long term solution which has been accepted, but requires a bigger set of changes.
Phase one, changes to libcouchbase, the Java client and the Python client. Phase two, changes to the PHP client, the Ruby client and the node.js client.
Changes to moxi to be UNIBROw compliant.
Any testing with load balancers for traffic.
Any attempt to compensate for misconfigured or unusual DNS/hostname configurations. In the current implementation, the cluster and cluster configuration control node hostnames (or IP addresses, which we unfortunately default to) and publish this via the configuration. A consistent set of name resolution for the hosts participating in the cluster and client-side application logic are expected. Note MB-8985 covers documentation changes for this.
New configuration options for either random or ordered selection of a URI.
Configuration files to be defined/documented per client library.
Updates to each client library's documentation on how to use the new configuration options and the new configuration files.
To migrate to the new approach, software developers may need to make changes to their client configuration and/or software. The specific changes are not to be covered in the scope of this document.
There is no administration impact anticipated, other than possibly needing to deploy new client libraries and optionally enable this functionality with new configuration files and/or small code changes.
New dot-minor versions of all components mentioned would be required. Given that no existing interfaces are expected to be removed, there is no additional impact over a regular dot-minor upgrade.
None, though documentation should indicate the proper permissions for configuration files.
Phase one in mid September. Phase two as other SDKs are updated.
Estimated as a day or two per client library, plus changes to SDKQE test cycles which are just in number of arguments.
This project is small enough that no prototype is required.
Initial publication for REVIEW on 27 August, 2013.