Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-61655

Unify bucket config validation



    • 0


      Current State

      Currently the bucket configuration exists in two places:

      1) ns_server (for REST API validation)
      2) kv_engine

      If ns_server passes an invalid bucket configuration to kv_engine when creating a bucket then the bucket will fail to be create in memcached, even though the config has been accepted by ns_server. This will result in the bucket/node(s) remaining unhealthy/yellow in the UI.


      Bucket config validation must be implemented in two different places. It can be time consuming and non-trivial to implement in ns_server as each parameter is implemented individually in code. We've seen bugs in the past where validation was not correct, even though kv_engine originally accepted the configuration.


      Perform bucket configuration validation in a single place, kv_engine. kv_engine owns the bucket configuration, and are already capable of relational validation of bucket configuration. ns_server would take a proposed configuration from the user via the REST API, and ask kv_engine to validate it. On successful validation ns_server would accept the configuration and use it to create or update a bucket. On validation failure ns_server would forward any error messages provided by kv_engine on to the user.

      Potential Concerns

      Cluster compat mode checks performed by ns_server can validate that the whole cluster is in some state to support some given parameter, kv_engine can only validate the configuration as the code on the current node understands it. To achieve similar validation checks ns_server could perhaps validate the configuration against all kv_engine nodes in the cluster.

      Potential backwards compat handling could be tricky. I'm not sure it's much different to how it should work currently, but warrants more thought.

      If we expose the entire bucket configuration to the user via the REST API then they may change settings that we would like them not to (unless recommended by support).

      Additional Benefits

      Users would now be able to specify and set any parameters via the REST API, i.e. the extra_config_string that ns_server supports to pass additional parameters to kv_engine via diag/eval would no longer be necessary.


        No reviews matched the request. Check your Options in the drop-down menu of this sections header.



            owend Daniel Owen
            ben.huddleston Ben Huddleston
            0 Vote for this issue
            1 Start watching this issue



              Gerrit Reviews

                There are no open Gerrit changes