We got mongoDB running on openshift pods across 2 separate openshift clusters and it runs perfectly fine but we are now facing issue with doing mongoDB restore, and that has led to us now wanting to use automation agent to control the mongod process on the containers.

The major challenge we are facing is that we run into issues when automation agent runs rs.initiate() and as part of the process tries to gather the hostname of the pod by running hostname -f command. The trouble is we have to deal with separate openshift clusters and have got mongod replica set members split across separate openshift clusters so we use a global DNS name so that the hostnames are resolved at the DNS level and allows for communication to flow through across seperate openshift clusters.

We want to have a feature which would allow us to choose what hostnames the automation agent should use in order to create the replica set. We also feel, this would be a huge asset for anyone trying to control the mongod containers from the ops manager and would give mongoDB an edge when it comes to running databases on containers.

We are also happy to provide any assistance in this regard and want this feature to be considered on a high priority as it is a BLOCKER for us.

Clear default values for New Replica Set and Cluster Component names in UI

Replica Set and Cluster Component names cannot be changed after deployment.
The names are often overlooked while deploying and the defaults accepted configuring the names.
If the fields were blank but mandatory (maybe with examples below the field) customers would be forced to choose logical names for their deployments.

| Field | Current Default Value|
| - | - |
|Replica Set Id | myReplicaSet |
| - | - |
|Cluster Name | myCluster |
|Shard Name Prefix | myShard |
|Config Server Replica Set Name | configRS |

The following log messages are "info" level messages which can be found in the kubernetes logs from the ops-manager-db pods:

```sh
{"logType":"mongodb","contents":"2020-12-16T02:42:28.557+0000 I WRITE [conn7329] update monitoringstatus.config.agentSessions command: { q: { id: "mongodb-rs-1.mongodb-rs-svc.mongodb.svc.cluster.local-48cc126fc451d9fa2ffa7569363971f2-5fbedc8dc354771c77dd1932", s: "KHNA9JiqXcos5V0d" }, u: { $set: { s: "PRIMARY", p: true } }, multi: false, upsert: false } planSummary: IXSCAN { id: 1 } numYields:0 queryHash:6C451E2F planCacheKey:38AD5486 ok:0 errMsg:"E11000 duplicate key error collection: monitoringstatus.config.agentSessions index: cid1s_1 dup key: { cid: ObjectId('5fbedc8dc354771c77dd1932'), s: \"PRIMARY\" }" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 200ms"}

{"logType":"mongodb","contents":"2020-12-16T02:42:53.558+0000 I WRITE [conn129189] update backupagentstatus.backupAgentSessions command: { q: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: "unassigned", $or: [ { sessionKey: "5fd130ec9621b221acd18451" }, { heartbeat: { $lt: 1608086273347 } } ] }, u: { $set: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: "unassigned", sessionKey: "5fd130ec9621b221acd18451", heartbeat: 1608086573347, hostname: "mongodb-rs-0.mongodb-rs-svc.mongodb.svc.cluster.local", addr: "10.200.30.0" }, $inc: { callsSinceSuccess: 1 } }, multi: false, upsert: true } planSummary: IXSCAN { groupId: 1, tag: 1 } keysInserted:1 numYields:0 queryHash:5BA6C0B5 planCacheKey:AEFF88E2 ok:0 errMsg:"E11000 duplicate key error collection: backupagentstatus.backupAgentSessions index: groupId1tag_1 dup key: { groupId: ObjectId('5fbedc8dc354771c77dd1932'), tag: \"unassigned\" }" errName:DuplicateKey errCode:11000 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } }, Mutex: { acquireCount: { r: 1 } } } flowControl:{ acquireCount: 1 } storage:{} 209ms"}
```

Despite the fact that the word "error" is in these logs many times, and they have an error code, error name, and error message, this is considered an info level log.

This is because the letter I is after the date. This makes using regex really hard when trying to setup alerts and monitoring, if I wanted to exclude info level logs.

It would be great of instead of using a letter like I, W, or E, a word or abbreviation was used such as INFO, WARN or ERROR.

The Ops Manager Application Server Log Directory is typically located in /opt/mongodb/mms/logs/.

Currently, the log rotation of the Ops Manager log files /opt/mongodb/mms/logs/mms0.log, /opt/mongodb/mms/logs/daemon.log and /opt/mongodb/mms/logs/mms0-access.log are configured by default to rotate the log file every day and compress it with a retention of 30 days. After 30 days the compressed files are deleted.

Please allow the configuration of these log rotation settings through the Ops Manager Web UI.

Currently, this can only be done manually. The default installation of Ops Manager includes a file in /opt/mongodb/mms/conf called logback.xml. This is the file that the library uses to configure Ops Manager logs and log rotation for /opt/mongodb/mms/logs/mms0.log and /opt/mongodb/mms/logs/daemon.log. By default this is configured with the following settings:

`

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

    <file>${log_path}.log</file>

    <encoder class="com.xgen.svc.mms.util.HeaderPatternLayoutEncoder$Classic">

        <pattern>

            %d{"yyyy-MM-dd'T'HH:mm:ss.SSSZ"} [%thread] %XF{groupId, "gid:%s "}%XF{jobId, "jobId:%s "}%-5level %logger [%file.%method:%line] - %msg%n

        </pattern>

    </encoder>

    <!-- Rollover the logs once per day, keep 30 days, compressed -->

    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

        <fileNamePattern>${log_path}.%d{yyyyMMdd}.log.gz</fileNamePattern>

        <maxHistory>30</maxHistory>

    </rollingPolicy>

</appender>

`

The file /opt/mongodb/mms/conf/logback-access.xml controls rotation of the /opt/mongodb/mms/logs/mms0-access.log. It has the same <!-- Rollover the logs once per day, keep 30 days, compressed --> policy.

The logs will be compressed and rotated each day and deleted after 30 rolling days. If you modify the maxHistory option to 10, this should delete the files after 10 days. Please note that any upgrade of Ops Manager may overwrite this change with a new configuration file. Additionally, after modifying these values you will need to restart Ops Manager.

The /opt/mongodb/mms/logs/mms-migration.log, mms0-startup.log and daemon-startup.log log files are not rotated as it contains only some log entries generated during the startup/migration phases of the Ops Manager Application Server processes.