[DOCS-7012] Ops Manager 2.0 upgrade procedure missing step leads to upgrade failure Created: 21/Jan/16  Updated: 17/May/17  Resolved: 13/Feb/16

Status: Closed
Project: Documentation
Component/s: Ops Manager
Affects Version/s: ops-manager-2.0.0
Fix Version/s: 01112017-cleanup

Type: Bug Priority: Blocker - P1
Reporter: Emilio Scalise Assignee: Anthony Sansone (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:
Days since reply: 6 years, 39 weeks ago

 Description   

Hi,

The upgrade guide for Ops Manager 2.0 should be improved to cover upgrading installations where there are dedicated Backup Daemon hosts running Ops Manager 1.8 or 1.6.

In particular there is a step missing before step 6. Starting the mongodb-mms service on each machine will use the default conf-mms.properties file that includes the parameter:

mongo.mongoUri=mongodb://127.0.0.1:27017/?maxPoolSize=150

The service mongodb-mms would not start on all the hosts that are not running an application database on the same machine (127.0.0.1), port 27017:

# service mongodb-mms start
Starting pre-flight checks
Failure to connect to configured mongo instance: Config{loadBalance=false, encryptedCredentials=false, ssl='false', dbNames='[mmsdb, mmsdbprovisionlog, mmsdbautomation, mmsdbserverlog, mmsdbpings, mmsdbprofile, mmsdbrrd, mmsdbconfig, mmsdbjobs, mmsdbagentlog, mmsdbbilling, backuplogs, mmsdbautomationlog, cloudconf, backupdb, mmsdbprovisioning, mmsdbqueues]', uri=mongodb://127.0.0.1:27017/?maxPoolSize=150} Error: { "serverUsed" : "127.0.0.1:27017" , "ok" : 0.0 , "errmsg" : "not authorized on admin to execute command { listDatabases: 1 }" , "code" : 13}
Pre-flight checks failed. Service can not start.

If there is a different MongoDB database running on 127.0.0.1:27017 that is not the application database (this can be possible for any reason, for example it could be the blockstore database), the result would be even worse: the Ops Manager application databases will be generated like on a fresh install on the wrong application database.

I believe that there should be a step between step 5 and step 6 that includes instruction on how to configure correctly the mongo.mongoUri parameter with the correct value before starting the mongodb-mms service from version 2.0 for the first time.

Kind regards,
Emilio



 Comments   
Comment by Anand Mohan [ 17/May/17 ]

http services is not coming up when we start ops manager in windows.
can you give some sample conf file . so that it will be helpful

Comment by Emilio Scalise [ 22/Jan/16 ]

Hi Bob,

So you added on step 3:

If the server runs only a Backup Daemon and does not have a conf-daemon.properties file, copy the properties file from an existing Ops Manager Application server to this server.

This should be sufficient to have a conf-mms.properties file. Perhaps you don't have the path /opt/mongodb/mms/conf at this time (before installing the new Ops Manager 2.0 RPM), so it will not work.
The Backup Daemon used the path /opt/mongodb/mms-backup-daemon/.

and a new step 6:

Configure each Backup Daemon server with the correct mongo.mongoUri value.
Copy the mongo.mongoUri string from the backed-up conf-mms.properties file to the new conf-mms.properties file.

This should be valid for all the Ops Manager servers, also the ones that will be used as Application Servers:

Configure each Ops Manager server with the correct mongo.mongoUri value.
Copy the mongo.mongoUri string from the backed-up conf-mms.properties file to the new conf-mms.properties file.

What about the other upgrade guides (DEB Package, Archive on Linux and Windows)? They need similar modifications for the conf-mms.properties file part.

For example step 6 let you start the service before taking care of the configuration files.

I believe that before publishing the upgraded guide someone should test it in practice accurately and step by step. If possible the MMS Team should review those procedures in my opinion.

Kind regards,
Emilio

Generated at Thu Feb 08 07:53:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.