Bring back riak_control

[hmmr]

Context and rationale

Riak used to have a web-based control panel called riak_control, which at some point was removed from riak.

Although all administrative tasks are meant to be done via CLI (i.e., riak admin), indications are customers will appreciate a GUI version of some of the functionality provided by riak admin. Also, GUI allows for better presentation of certain elements than CLI.

With the new riak_control exposing controls in a browser, it becomes possible for operators to enable users to perform administrative tasks without giving them ssh access to the boxes running riak.

At TI Tokyo, after a successful and rewarding experience with a similar project in Elm (riak_cs_control, featured here), we had an idea of making riak_control likewise great again.

Architecture and design

In this rewrite, it is a single-page web app, written in Elm. When compiled and built and packaged, it exists as a bunch of JS files, assets and an entry-point html, served by a standard Python httpd. On the riak side, it will need some new webmachine handlers, to be submitted in a separate PR.

No intention for riak_control to be included in OpenRiak

Importantly, the new riak_control is a nodejs project, totally alien to the rebar3-orchestrated building infrastructure. It is therefore decoupled from OpenRiak; there is no reason or ultimate intention to reintroduce it to OpenRiak.

Features

Currently, our riak_control will:

• show node version and uptime, and do a ping:

• present an overview of cluster nodes, with controls to stage join, leave, stop, replace (i.e., riak admin cluster operations):

• show the status of tictacaae trees:

• view and manage users, groups and permissions:

Security

Users of riak_control will need to:

• be created first via riak admin security add-user userone;
• assigned a riak_kv.riak_control privilege, with riak admin security grant riak_kv.riak_control on any to userone.

Current status

This is an early preview. We aim to match and replicate the features of the original riak_control (which we have more or less covered); but also, we feel it's time to ask for new features and ideas from the community.

[martinsumner]

Related to this, I've raised an issue against leveled - martinsumner/leveled#478.

To support this type of view into cluster health it would be good to make it easier to interrogate via function calls the status of other areas of Riak.

[hmmr]

Following rounds of discussion, we propose a new approach, in which:

• we define a formal set of HTTP API requests, AWS-style;
• expose that API via a separate, dedicated app, riak_admin_api, with its own controls in riak.conf and CLI commands;
• have a separate security subsystems, also managed by riak_admin_api, which is independent from the traditional riak users, groups and grants.

The external riak_control app, a reference app making use of the Riak Admin API, has been updated to work with riak_admin_api (all the screenshots above remain actual).

OpenRiak/riak_kv#125 and related PRs are superseded by OpenRiak/riak#35, OpenRiak/riak_kv#152, OpenRiak/riak_test#28, OpenRiak/riak_core#47.