Include the URL of your launchpad blueprint:
Since there is the ability to enable a root user on an instance the ability to disable the root user should be provided as well.
Currently, the root user can be enabled on an instance. It is expected that the root user can also be disabled.
Disabling the root user should not change the ability of the command root-show to determine if the root user has ever been enabled.
This change will add a new root-disable command.
The command will remove the root user from the specified instance. No changes will be made in the root_enable_history table from the execution of the command. This ensures the root-show command will continue to operate as expected.
Python API in class Root:
- def delete(self, instance):
“”“Implements root-disable API.
Removes the root user for the specified db instance.
param instance: The instance from which the root user is removed from
trove root-disable <instance>
The appropriate root disable method will added only for MySQL. All other datastores will also need to have the appropriate not implemented error.
Another option is root-disable will simply call root-enable and not return the password back to the user. This alternative also has no impact on the root-show.
However, an operator may believe the root user to be completely removed from the database after the root-disable call is made. Leaving the root user may not be what the operator is expecting.
Some concerns were raised during the discussion of this blueprint. The full details can be found here https://review.openstack.org/#/c/189837/.
In summary the concerns revolved around the fact that after the user performs a root enable the following issues can occur.
It was determined that adding the root-disable command does not cause or make the concerns raised above to be any worse than already exists.
Add to existing root enable tests to test disabling the root user.
New root-disable command needs to be added to the API documentation.