Reaper 1.4.5 keeps small datacenters visible
Reaper adjusts datacenter widths in its cluster display and improves executable JAR discovery. The same release adds method-based permissions to its REST endpoints.
A cluster display can make a small datacenter difficult to see precisely because it is small. Reaper's datacenter component calculated its width as a percentage of the cluster's total load. That makes a proportional display, but a datacenter with little of the total receives little space for its own information. Reaper 1.4.5 adds a minimum width to that calculation.
The release published on 26 August includes this interface correction alongside startup-script changes. Its authorization changes also deserve attention. Reaper now distinguishes a read-only user role from an operator role when checking several REST endpoint families. The patch release affects how people observe and control the service, even though it introduces no new Cassandra repair algorithm.
I like Cassandra for the difficult availability problem it addresses across active locations. An administrative tool needs to represent those locations clearly even when their current data volumes differ. The smaller datacenter still belongs to the topology an operator is trying to understand.
A display percentage becomes a minimum width
The datacenter component patch changes one expression in cluster-list.jsx. Previously, width followed the datacenter's share of total load. The replacement expression takes the larger of that percentage and 33.
Expressed as the calculation used by the patch, the relevant line is:
width: Math.max(33, ((dcSize / this.props.totalLoad) * 100)) + "%"
This is a presentation rule. It does not change the load measurements or redistribute Cassandra data. The component gives a datacenter a minimum share of horizontal space even when its measured load would produce a smaller width. Consequently, the display cannot be interpreted as a strictly proportional chart after this change.
That is a reasonable tradeoff for a component whose contents need to remain visible. Proportional area and readable topology are different requirements. If the area alone carries quantitative meaning, changing the minimum would distort that meaning. If the component must also show information about each datacenter, a minimum can preserve the information the user needs to act on.
The patch is explicitly a backport to the 1.4 branch. Its scope is narrow enough to describe without treating every multi-datacenter behavior as repaired. The changed code establishes a minimum rendered width. It does not establish changes to cross-datacenter repair selection or network behavior.
Finding the runnable artifact
The startup-script correction changes how the launcher finds the Reaper JAR. It replaces path matching with a regular expression that matches the artifact's filename and escapes the dot before jar. The same selection applies while searching the project tree and the shared installation directories.
The release also includes an earlier change excluding source JARs from the classpath and improving discovery from a project directory. Together, these entries address a practical packaging distinction. A source archive or Javadoc archive can share an artifact prefix with the executable without being the file the launcher should select.
The final filename pattern ends with a restricted character class immediately before .jar. That prevents the source and Javadoc suffixes named in the release notes from satisfying the runnable-artifact pattern. The script still has separate paths for a project-tree artifact and an installed artifact. The change improves file selection within those paths.
I regard launcher behavior as part of a service's operational interface. A release can contain the correct application code and still be difficult to run if the surrounding script picks the wrong file. Here the source change makes the artifact-selection rule visible, so the fix can be understood beyond the changelog's general description.
Reading and operating get different roles
The authorization commit introduces RestPermissionsFilter, derived from Shiro's HTTP-method permission filter. Configuration assigns operator the wildcard permission and assigns user the read permission. The release describes those roles as read/write and read-only respectively.
The configured endpoint families include clusters, repair schedules, repair runs and snapshots. Their filter chains perform JWT verification and then apply the resource-specific REST permissions filter. Authentication establishes the subject, while the additional filter checks the permitted action for the HTTP method. The source explicitly builds a JWT-backed subject when there is no existing authenticated subject.
That separation is useful for a repair service. Viewing the current state and changing it are different administrative privileges. A valid token alone does not express which of those privileges should apply. The new filter gives the configured role a part in that decision for the listed resources.
The commit also updates user definitions. The existing example administrator receives the operator role, and the packaged resource configuration adds a read-only example user. For environment-configured users, the Docker script appends the operator role when creating an environment-configured authentication user. An installation carrying its own Shiro configuration needs to account for the role assignments and endpoint rules introduced by this change.
These are Reaper permissions, separate from Cassandra's database permissions. The release concerns access to the repair management service and its API. The new role distinction permits observation without granting the same configured authority to modify repair runs or schedules, while the interface and launcher corrections make the service easier to inspect and start.