(Optional) Configuring a remote database
If you installed Turbonomic as a VM image (OVA or VHD), the image includes MariaDB for the historic database. While most installations use that instance, you can use an external MariaDB or MySQL database instead. In addition, you can install Turbonomic directly to a Red Hat OpenShift or Kubernetes cluster (instead of installing the VM image), and you can provide your own historical database.
For its historical database, Turbonomic supports long-term maintenance stable series of MariaDB (the minimum supported version is 10.6) and MySQL 8.0.x. This support includes comprehensive testing and quality control for Turbonomic usage.
Task overview
-
(Only applicable for Azure MySQL databases) Create the Azure Database for MySQL Flexible Server.
-
Configure a remote database server.
-
Configure Turbonomic.
Creating the Azure Database for MySQL flexible server
-
In the Azure portal, search for and select Azure Database for MySQL flexible servers and click Create.
Note:Azure Database for MySQL servers is scheduled for retirement 16 September 2024.
-
On the Basics tab, specify the project and server details based on the load requirements.
-
Specify the following information:
Fields Instructions Subscription Specify the Azure subscription used for billing. Resource Group Specify the container that holds related resources for an Azure solution. Server Name Specify a name for the MySQL server. Region Specify the Azure region where the server is created. Choose a region close to the users who will access the server.
MySQL Version Specify to use MySQL 8.0. Admin username Specify the primary administrator username for the server. Password Specify the administrator password. For more information, see the Azure documentation.
-
To specify the workload type, click Configure server next to Compute + storage. You can create an Azure Database for MySQL - Flexible Server in one of three different service tiers: Burstable, General Purpose, and Business Critical. The recommended configuration is to use General Purpose with compute size and storage size as shown in the following table.
Topology size Preferred Server type Storage size Less than 100 K Standard_D8ads_v5 (8 vCores, 32 GB memory, 12800 max iops)
500 GB 100 K-1 million Standard_D16ads_v5 (16 vCores, 64 GB memory, 20000 max iops)
2 TB Over 1 million Standard_D32ads_v5 (32 vCores, 128 GB memory, 20000 max iops)
3 TB -
(Optional) If you want to automatically provision and manage a standby replica in a different availability zone within one region, select Enable high availability. You can then select to use the zone redundant high availability mode to improve the availability.
Note:These settings might lead to a substantial increase in the cost. Current on-prem OVA deployments do not use high availability.
-
The default backup retention period is seven days. The backup retention is billed based on extra storage that is used for retaining backups. For more information, see the Azure documentation.
-
-
Click Save.
-
Configure networking options.
Add any firewall and private end-point details in the Networking tab.
-
Configure security options.
Configure any Azure key vault or user-managed identity that is used for the encryption in the Security tab. Otherwise, leave the default values.
-
Configure tags.
Add any tags for the deployment in the Tags tab.
-
Click Review + create to review your Azure Database for MySQL flexible server configuration.
-
Click Create to provision the server. Provisioning can take a few minutes.
Configuring a remote database server
Before you install Turbonomic, you must configure a remote database server for historical data. This configuration allows for high availability, backups, and handling larger IO demands for larger environments or from remote SQL Server queries. If you are not going to use an existing database server, you must first create a new database server.
You can configure a MariaDB, MySQL, or Azure MySQL database server. Refer to the steps for the database server you are configuring.
externalDBName
parameter. Remove the externalDbIP
parameter from the following examples and replace it with the externalDBName
parameter.Configuring MariaDB
Use only long-term maintenance stable series of MariaDB. The minimum supported version is 10.6.
-
Create a remote database with the following settings for a MariaDB 10.6.19 instance:
-
Cluster configuration - the main/replica where Turbonomic communicates to a single replica
-
Select network and security policies that allow communication between the Kubernetes cluster and the database server; the default DB port is 3306
-
Minimum memory - 8 GB memory and 2 vCPU
-
Storage - 100 GB (set to auto-increase) or provide 1024 GB (or 1 TB)
-
Encryption (SSL) is supported
-
-
Open the configuration file in an editor and change the values for these system variables.
Note:In Amazon Web Services (AWS), create a new Relational Database Service Parameter Group.
event_scheduler = ON sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION max_allowed_packet = 1GB log_bin_trust_function_creators = 1 character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci innodb_buffer_pool_size = <see the following note>
Note:The
innodb_buffer_pool_size
must be at least 4096 M (or 4G). Increase the value to support larger topologies. Refer to the following table for suggested values based on system memory.System memory (mem) innodb_buffer_pool_size mem <= 32GB
4G
mem > 32GB and mem <= 64GB
8G
mem > 64GB and mem <= 128GB
16G
mem > 128GB
32G
-
Save your changes.
-
Create a Turbonomic admin user that the deployment uses to create application users and grant privileges. You can define your own password, but it must be reflected in the Custom Resource (CR) files that are described in the next section.
Using a MySQL client or CLI, run the following commands, substituting your credentials against your database server:
CREATE USER 'turboadmin'@'%' IDENTIFIED BY 'vmturbo'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'turboadmin'@'%' WITH GRANT OPTION;
Note:If you are using an AWS Relational Database Service (RDS) or Azure Database service, see AWS RDS or Azure Database Service Configuration for steps to create the application database users, databases (empty schema), and grant privileges.
For information on using Kubernetes Secrets for DB app username and password credentials, see the Using Kubernetes secrets with a remote database section in this topic.
The database server is ready to be included in your Turbonomic installation.
-
After the database is configured, configure Turbonomic.
Configuring MySQL
MySQL version 5.7 reached EOL on 21 October 2023 and is no longer supported. Turbonomic supports MySQL 8.0.x as an alternative database server for MariaDB for running Turbonomic.
For more information, see Reference: Upgrading from MySQL 5.7 to 8.0.
-
Open the configuration file for editing.
Note:By default, with Rocky 9.3, the Configuration File is found at
/etc/my.cnf
. -
Modify the CR file to set the required server system variables.
event_scheduler = ON sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION max_allowed_packet = 1GB skip-log-bin log_bin_trust_function_creators = ON explicit_defaults_for_timestamp = OFF character-set-server = utf8mb4 collation-server = utf8mb4_general_ci innodb_buffer_pool_size = <see the following note>
Note:The
innodb_buffer_pool_size
must be at least 4096 M (or 4G). Increase the value to support larger topologies. Refer to the following table for suggested values based on system memory.System memory (mem) innodb_buffer_pool_size mem <= 32GB
4G
mem > 32GB and mem <= 64GB
8G
mem > 64GB and mem <= 128GB
16G
mem > 128GB
32G
If you are using an AWS Relational Database Service (RDS) or Azure Database service, see AWS RDS or Azure Database Service Configuration for steps to create the application database users, databases (empty schema), and grant privileges.
-
Save your changes.
-
Restart MySQL for the changes to take effect.
With Rocky 9.3, the following command restarts MySQL:
systemctl restart mysqld.service
-
After the database is configured, configure Turbonomic.
Configuring Azure MySQL Database
-
After the Azure MySQL database is created, make the following configuration changes in the Settings > Server Parameters section.
event_scheduler = ON sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION max_allowed_packet = 1073741824= log_bin_trust_function_creators = ON explicit_defaults_for_timestamp = OFF character_set_server = utf8mb4 collation_server = utf8mb4_general_ci sql_generate_invisible_primary_key = OFF innodb_buffer_pool_size = <see the following note>
Note:The
innodb_buffer_pool_size
must be at least 4096 M (or 4G). Increase the value to support larger topologies. Refer to the following table for suggested values based on system memory.Azure VM Memory (mem) innodb_buffer_pool_size mem = 32GB
4G
mem = 64GB
8G
mem = 128GB
16G
-
Save your changes.
Using Kubernetes secrets with a remote database
If you are using a remote database, you can use a Kubernetes Secret to store the database credentials and then specify it in your Turbonomic Custom Resource (CR) file.
For its historical database, Turbonomic supports long-term maintenance stable series of MariaDB (the minimum supported version is 10.6) and MySQL 8.0.x. This support includes comprehensive testing and quality control for Turbonomic usage.
Several options exist to configure the Turbonomic deployment to use Kubernetes Secrets that store database credentials. The option that works best for you depends on how you configure access to your remote database. Complete the following steps to use Opaque Type Kubernetes Secrets to obfuscate the database credentials that are required to connect to a remote database. The Turbonomic deployment looks for the DB-credentials Secret first by default.
For more information about Kubernetes Secrets, see the Kubernetes documentation. For information on how to use a webhook injection method that supports Kubernetes Secrets, see the Kubernetes Webhook documentation.
Scenario 1 - Single database user with default application users
This use case is applicable to any of the following database services where the user allows the Turbonomic application to manage its own application database users.
-
Allow Turbonomic to create application users with a default password
-
AWS Relational Database Service (RDS) services of MariaDB or MySQL
-
Google Cloud Storage services of MySQL
-
Bring your own MariaDB and MySQL server
-
In this scenario, the Turbonomic configuration needs to supply:
-
DB service endpoint
-
Connection properties for the MySQL dialect, secure access, and port
-
Global credentials of the DB root user
The global credentials are placed into a Kubernetes Secrets and the name of the Secret is referenced in the Turbonomic Custom Resource file.
-
Create the global user Kubernetes Secrets.
Modify the
stringData
field of theglobal-secret.yaml
to include thedb-creds
.The stringData field type allows you to enter the content in plain text, which is then converted to a Base64 encoded Secret when you create it on the Kubernetes cluster.
apiVersion: v1 kind: Secret metadata: name: globaldb type: Opaque stringData: db-creds: |- username: <yourDBUser> password: <yourUncodedDBUserPassword>
Where
-
name - the Secret name can be anything, but it must be the same as what is specified in the Turbonomic Custom Resource file.
-
username -
dbRootUsername
-
password -
dbRootPassword
; the password must be plain text
-
-
Apply the Secret.
Apply the Secret to the Turbonomic namespace before deploying Turbonomic.
kubectl create -f global-secret.yaml -n turbonomic
-
With a remote database, create the empty application database.
Even with a single global database, you must first create the empty application databases when you are using a remote database. Connect to your database with a db admin user and run the following commands.
create database action; create database auth; create database clustermgr; create database cost; create database group_component; create database market; create database plan; create database repository; create database suspend; create database topology_processor; create database vmtdb; create database actions_history; create database oauth2; create database sustainability;
-
Modify the Turbonomic Custom Resource file to use the Secret.
Update with the Custom Resource file
yaml
file as shown in the following example:global: externalDBName: yourDB.cloud.com dbSecretName: globaldb properties: global: enableSecureDBConnection: true sqlDialect: MySQL
Note:Ensure the
dbSecretName
is the same as the Secret name specified in theglobal-secret.yaml
. In this example, the Secret name isglobaldb
. -
Make any other configuration changes for your Turbonomic instance, then save the CR file.
-
Apply the changes that you made to the CR file.
For example, run the following command for VM image installations:
kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
Scenario 2 - Specifying all application users
This use case is applicable to the following scenarios where the user wants or needs to first create the application database users, and then provide this information to the Turbonomic deployment through the Custom Resource file.
-
Manage the password for app users (not use default)
-
Usernames that need to specify the DB instance in a multi-tenant database server
-
Azure RDS services (MySQL, MariaDB) which require that the username specify the DB instance
Note:Azure Database for MariaDB is scheduled for retirement by 19 September 2025. As part of this retirement, there is no extended support from Microsoft for creating new MariaDB server instances from the Azure portal beginning 19 January 2024. If you still need to create MariaDB instances to meet business continuity needs, you can use Azure CLI until 19 March 2024.
For more information, see the Azure documentation.
In this scenario, the Turbonomic configuration needs to supply:
-
DB service endpoint
-
Connection properties for the MySQL dialect, secure access, and port
-
Global credentials of the DB root user and Turbonomic admin user
-
Application users for action, auth, clustermgr, cost, group, market, plan orchestrator, repository, suspend, topology processor, vmtdb (history), actions_history, oauth2 and sustainability
All DB users must be defined in separate Kubernetes Secrets.
-
Create the global user Kubernetes Secrets.
Modify the
stringData
field of theglobal-secret.yaml
to include thedb-creds
.The stringData field type allows you to enter the content in plain text, which is then converted to a Base64 encoded Secret when you create it on the Kubernetes cluster.
apiVersion: v1 kind: Secret metadata: name: globaldb type: Opaque stringData: db-creds: |- username: <yourDBUser> password: <yourUncodedDBUserPassword>
Where
-
name - the Secret name can be anything, but it must be the same as what is specified in the Turbonomic Custom Resource file.
-
username -
DBRootUsername
Note:If required, the username will contain the DB name:
turboadmin@mydb
. -
password -
DBRootPassword
-
-
Apply the Secret.
Apply the Secret to the Turbonomic namespace prior to deploying Turbonomic.kubectl create -f global-secret.yaml -n turbonomic
-
Create the application user Secrets.
Modify the
action.yaml
so that each application user has their own Secret.apiVersion: v1 kind: Secret metadata: name: actiondb type: Opaque stringData: db-creds: |- username: <yourActionDBUser> password: <yourUnencodedActionDBUserPassword>
Where :
-
name - the Secret name can be anything, as long as it is the same as what is specified in the Turbonomic Custom Resource file.
-
username -
app component username
Note:If required, the username contains the db name:
action@mydb
. -
password -
app component username
; the password must be plain text
Define a Secret for the action, auth, clustermgr, cost, group, history, plan-orchestrator, repository, topology-processor, actions-history, oauth2 and sustainability components. In total, you create thirteen Secrets (twelve app secrets and one global secret).
-
-
Apply the Secrets.
Apply all Secrets to the Turbonomic namespace before deploying Turbonomic.
kubectl create -f action.yaml -n turbonomic
-
Modify the Turbonomic Custom Resource file to use the Secrets.
Update with the Custom Resource file
yaml
file as shown in the following example:global: externalDBName: yourDB.cloud.com dbSecretName: globaldb properties: global: enableSecureDBConnection: true sqlDialect: MySQL action-orchestrator: dbSecretName: actiondb auth: dbSecretName: authdb clustermgr: dbSecretName: clustermgrdb cost: dbSecretName: costdb group: dbSecretName: groupdb history: dbSecretName: historydb market: marketSecretName: marketdb plan-orchestrator: dbSecretName: plandb topology-processor: dbSecretName: topodb repository: dbSecretName: repodb suspend: dbSecretName: suspenddb actions-history: actions-history: actionhistorydb oauth2: dbSecretName: oauth2db sustainability: dbSecretName: sustainabilitydb
Note:If you have other properties that are defined for these components, you must combine them.
-
Make any other configuration changes for your Turbonomic instance, then save the CR file.
-
Apply the changes that you made to the CR file.
For example, run the following command for VM image installations:
kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
Encoding credentials
Opaque type Secrets can take as input for data field type values that are already Base64 encoded. Encode the Secrets by running the following command in a Linux / MacOS environment and place the output in your configuration file.
echo -n 'yourCredential' | base64
Configuring Turbonomic
After your database is configured properly, the next step is to declare access to it through the Turbonomic Custom Resource (CR) file.
-
Open the CR file for editing.
The location of the file depends on the type of Turbonomic installation that you are configuring.
-
VM Image installation of Turbonomic
Log in to an SSH terminal session of your Turbonomic instance as the System Administrator that you set up when you installed Turbonomic.
/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
-
Turbonomic on a Kubernetes node or node cluster
deploy/crds/charts_v1alpha1_xl_cr.yaml
-
Azure MySQL
kubectl edit xl -n <your Turbonomic namespace>
-
-
Modify the CR file to include the external database properties.
Add the entry to the CR file, by using the following example as a guide. This example also contains optional parameters. For a complete list of options, refer to the Custom Resource definition for the Turbonomic operator under
APIV3Schema
in theValidation
section of the CRD yaml here.Note:The
externalDBName
parameter creates an external type Kubernetes Secrets service, and therefore the DB name must be the Fully Qualified Domain Names (FQDN), not the short name. Optionally, you can use theexternalDbIP
parameter, which creates a Kubernetes Secrets endpoint and service.MariaDB configuration example:
spec: # Global settings global: repository: icr.io/cpopen/turbonomic tag: 8.15.0 externalDbIP: <MariaDB_host_IP> properties: global: dbRootUsername: <MariaDB_root_username> dbRootPassword: <MariaDB_root_complex_password>
MySQL and Azure MySQL configuration example:
spec: # Global settings global: repository: icr.io/cpopen/turbonomic tag: 8.15.0 externalDbIP: <MySQL_host_IP> properties: global: sqlDialect: MYSQL enableSecureDBConnection: true dbRootUsername: <MySQL_root_username> dbRootPassword: <MySQL_root_complex_password>
Note:If you are using an AWS RDS or Azure Database service, see AWS RDS or Azure Database Service Configuration for extra parameters to add to the CR file.
Alternatively, you can specify the database username and password by using Kubernetes Secrets or by using a vault + webhook injection method. For more information, see the Using Kubernetes secrets with a remote database section in this topic or this site.
(Azure MySQL databases) If the database IP is not available, specify the
externalDBName
instead. For example,externalDbName: MySQL_8.0_host_Name
. -
Save the changes to the CR.
-
Apply the changes that you made to the CR file.
Note:For Azure MySQL databases, the changes apply automatically after you save the changes and exit the live edit. You do not need to perform this step.
For example, run the following command for VM image installations:
kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml
AWS RDS or Azure database service configuration
If you are using a supported AWS RDS (MariaDB or MySQL) or Azure Database PaaS service, you must create the application databases and users and then provide this information to the Custom Resource file. You edit the CR file when you configure the database and again when you configure Turbonomic to use the external database.
Configuring the database
Create the application users and the empty databases that Turbonomic will use. Using a MySQL client or CLI, run the following commands against your database server.
You can define custom passwords but do not change the username.
create user 'action'@'%' identified by 'vmturbo';
create user 'auth'@'%' identified by 'vmturbo';
create user 'clustermgr'@'%' identified by 'vmturbo';
create user 'cost'@'%' identified by 'vmturbo';
create user 'group_component'@'%' identified by 'vmturbo';
create user 'market'@'%' identified by 'vmturbo';
create user 'plan'@'%' identified by 'vmturbo';
create user 'repository'@'%' identified by 'vmturbo';
create user 'suspend'@'%' identified by 'vmturbo';
create user 'topology_processor'@'%' identified by 'vmturbo';
create user 'history'@'%' identified by 'vmturbo';
create user 'actions_history'@'%' identified by 'vmturbo';
create user 'oauth2'@'%' identified by 'vmturbo';
create user 'sustainability'@'%' identified by 'vmturbo';
create database action;
create database auth;
create database clustermgr;
create database cost;
create database group_component;
create database market;
create database plan;
create database repository;
create database suspend;
create database topology_processor;
create database vmtdb;
create database actions_history;
create database oauth2;
create database sustainability;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON action.* TO 'action'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON auth.* TO 'auth'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON clustermgr.* TO 'clustermgr'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON cost.* TO 'cost'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON group_component.* TO 'group_component'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON market.* TO 'market'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON plan.* TO 'plan'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON repository.* TO 'repository'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON suspend.* TO 'suspend'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON topology_processor.* TO 'topology_processor'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON vmtdb.* TO 'history'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON actions_history.* TO 'actions_history'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON oauth2.* TO 'oauth2'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON sustainability.* TO 'sustainability'@'%';
GRANT PROCESS on *.* TO 'history'@'%';
GRANT PROCESS on *.* TO 'cost'@'%';
GRANT PROCESS on *.* TO 'group_component'@'%';
flush privileges;
Configuring Turbonomic
Modify the CR file to include the external database properties. Substitute your values for
dbRootUsername
and dbRootPassword
.
AWS RDS configuration example:
global:
externalDBName: yourDB.yourURL.com
properties:
global:
enableSecureDBConnection: true
dbRootUsername: <yourvalue>
dbRootPassword: <yourvalue>
action-orchestrator:
actionDbUsername: action
actionDbPassword: vmturbo
...
Azure configuration example:
global:
externalDBName: yourDB.yourURL.com
properties:
global:
enableSecureDBConnection: true
dbRootUsername: turboadmin@yourDB
dbRootPassword: <yourvalue>
action-orchestrator:
actionDbUsername: action@yourDB
actionDbPassword: vmturbo
...