Add support for 'root' actions to Cassandra

Implement root enable (with password)/disable and show calls in the
Cassandra guest agent.
Also include datastore-agnostic scenario tests for the root actions.

Change-Id: I87d2467ef062d8395bbdb291779a5db549205461
Implements: blueprint cassandra-root-enable

specs/mitaka/cassandra-root-enable.rst

@@ -0,0 +1,193 @@
+..
+    This work is licensed under a Creative Commons Attribution 3.0 Unported
+    License.
+
+    http://creativecommons.org/licenses/by/3.0/legalcode
+
+    Sections of this template were taken directly from the Nova spec
+    template at:
+    https://github.com/openstack/nova-specs/blob/master/specs/juno-template.rst
+
+..
+    This template should be in ReSTructured text. The filename in the git
+    repository should match the launchpad URL, for example a URL of
+    https://blueprints.launchpad.net/trove/+spec/awesome-thing should be named
+    awesome-thing.rst.
+
+    Please do not delete any of the sections in this template.  If you
+    have nothing to say for a whole section, just write: None
+
+    Note: This comment may be removed if desired, however the license notice
+    above should remain.
+
+
+=======================================
+Support for 'root' actions to Cassandra
+=======================================
+
+Implement root enable (with password)/disable and show calls in the Cassandra
+guest agent.
+Also include datastore-agnostic scenario tests for the root actions.
+
+Launchpad Blueprint:
+https://blueprints.launchpad.net/trove/+spec/cassandra-root-enable
+
+
+Problem Description
+===================
+
+Continuing the work on add user/database support for Cassandra
+guests [1]_ we should also enable the Trove users to create superuser accounts.
+
+
+Proposed Change
+===============
+
+The Cassandra's superuser is called 'cassandra'.
+It comes with any new Cassandra installation, but it can be deleted.
+
+In Cassandra only SUPERUSERS can create other users and grant permissions to
+database resources.
+Trove uses the 'os_admin' superuser to perform its administrative tasks. [1]_
+The users it creates are all 'normal' (NOSUPERUSER) accounts.
+
+The built-in 'cassandra' superuser is proactively removed on prepare as it is
+not needed.
+
+During normal operation (no 'root' enabled), there should be only
+one superuser in the system (os_admin). The 'root' is therefore **not**
+enabled.
+
+Configuration
+-------------
+
+None
+
+Database
+--------
+
+None
+
+Public API
+----------
+
+None
+
+Public API Security
+-------------------
+
+None
+
+Python API
+----------
+
+None
+
+CLI (python-troveclient)
+------------------------
+
+None
+
+Internal API
+------------
+
+None
+
+Guest Agent
+-----------
+
+The 'enable' action will be implemented by creating a new superuser
+('cassandra') and granting it full access to all
+keyspaces. The username ('cassandra') and password (user-supplied or random
+otherwise) will be returned back to the client.
+
+Now on, there will be more than one superuser accounts in the system and
+the 'root' will hence be reported as 'enabled'.
+
+The 'disable' action will merely reset the user's password to a new random
+string without exposing it to the end-user. The account itself **will not** be
+removed so the *root-show* will keep reporting root as 'enabled' as it should.
+
+When a backup is restored the presence of superusers other than 'os_admin'
+will be checked and the root-status of the new instance will be reported as
+'enabled' if there are any.
+
+Note that a superuser cannot remove its *super* privileges or delete itself.
+It should therefore not be possible to bypass the root check by creating a new
+superuser, deleting the old one and restoring the state into a new instance.
+
+Once having the superuser access to the database the end-user could of course
+alter/drop the 'os_admin', but doing that would render the instance
+unmanageable from Trove.
+
+Alternatives
+------------
+
+None
+
+
+Dashboard Impact (UX)
+=====================
+
+None
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  Petr Malik <pmalik@tesora.com>
+
+Milestones
+----------
+
+Mitaka
+
+Work Items
+----------
+
+* Implement root-related calls in the Cassandra manager.
+
+* Add datastore-agnostic scenario tests to exercise the new functionality.
+
+
+Upgrade Implications
+====================
+
+None
+
+
+Dependencies
+============
+
+This implementation largely depends on work done as a part of
+blueprint cassandra-database-user-functions [1]_
+
+
+Testing
+=======
+
+* Manager unittests will be added where appropriate.
+
+* Datastore-agnostic scenario tests to exercise the related functionality will
+  be implemented.
+
+
+Documentation Impact
+====================
+
+Document the newly enabled functionality for the Cassandra datastore.
+
+
+References
+==========
+
+.. [1] Cassandra user/database implementation review: https://review.openstack.org/#/c/206739/
+
+Appendix
+========
+
+None