...

• SolrMetricsContext now as a rule is created for each child component, and it includes also the component's metric names and scope. This simplifies the management of metrics, obtaining metrics snapshots - and it was needed in order to construct fully-qualified component IDs for the resource API.
• SolrCache.warm(...) also re-sets the limits (such as maxSize and maxRamMB) using the old cache's limits - this is to preserve custom limits from the old instance when a new instance is a replacement for the old one.

...

The content of the pool configurations file is a serialization of `ResourceManagerAPIResourceManagerAPI.ResourcePoolConfigs`ResourcePoolConfigs, which is basically a map of pool names to their configurations. Each pool configuration consists of the following:

...

There are several pre-defined pools, which can be listed using the /cluster/resource API.

Example configuration in /resourceMgr/poolConfigs.json:

{
 'searcherDocumentCache' :
 {
  'maxRamMB' : 100
 }
}"configs":{
  "searcherUserCache":{
    "name":"searcherUserCache",
    "type":"cache",
    "poolParams":{},
    "poolLimits":{
      "maxSize": 1000,
      "maxRamMB":-1}},
...
}

Currently the Currently the PR doesn't use other configuration files or system properties.

...

The following operations are supported:

• Pool operations
  • Read API (GET):
    • (no payload):
  • LIST -
    • lists selected pools and their limits and parameters.
  • CREATE - create a new pool, with the provided limits (limit.<name>=<value>) and parameters (param.<name>=<value>).
  • DELETE - delete an existing pool (and unregister its components)
  • • Additional boolean request parameters are supported:
      • components - list also all components registered in the pool
      • limits - show limit values for each pool
      • params - show pool parameters
      • values - show current aggregated total values (resource usage) of all components in the pool
  • Write API (POST):
    • create - create a new pool, using the provided ResourcePoolConfig configuration, containing pool name, pool type, and it's initial parameters and resource limits.
    • delete - delete an existing pool (and unregister its components). The name of the pool to delete can be obtained from the string payload or from the path (eg. /cluster/resources/myPool)
    • setlimits
    SETLIMITS
    • - set, modify or delete existing pool(s) limits
    SETPARAMS
    • . The payload is a map of arbitrary key / value pairs.
    • setparams - set, modify or delete existing pool(s) parameters. The payload is a map of arbitrary key / value pairs.
• Component operations
  • Read API (GET):
    • (no payload):
  • LIST -
    • list components in specified pool(s) and their current resource limits
  • Write API (POST):
    • setlimits
    SETLIMITS
    • - set the current limits of specified component(s). Payload is a map of key
    -
    • / value pairs defining the updated limits.
    DELETE
    • delete - unregister specified components from the pool(s) 

Compatibility, Deprecation, and Migration Plan

...

Users can migrate to this framework gradually by specifying concrete resource limits in place of the defaults - the default settings create unlimited pools for searcher caches so the back-compat behavior remains the same.

...

Test Plan

An integration test TestCacheDynamics has been created to show the behavior of cache resource management under changing resource constraints. Obviously more tests are needed on a real cluster.

An integration test TestResourceManagerIntegration exercises the REST API. 

Ref Guide content

Most of the material in this SIP, plus example configurations, will become a new section in the Ref Guide. 

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.