Datagerry 2.2.0 upgrade caused database connection errro

Community Support
1

Hi,

I upgraded the 2.2.0 release from 2.1.0 on RHEL9.

Then I copied my cmdb.conf file back into the /etc/datagerry/cmdb.conf, started datagerry, and got:

Jul  5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO    ] --- DATAGERRY starting... (__main__.py)
Jul  5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO    ] --- Checking database connection with cmdb.conf data (__main__.py)
Jul  5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][CRITICAL] --- CMDBError: The section Database does not exist! (__main__.py)
Jul  5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO    ] --- DATAGERRY stopped! (__main__.py)

This is weird because the cmdb.conf contains the settings:

# ls -l /etc/datagerry/cmdb.conf
-rw-r--r--. 1 root root 798 Jul  8 11:11 /etc/datagerry/cmdb.conf

# cat /etc/datagerry/cmdb.conf
[Database]
host = 127.0.0.1
port = 27017
database_name = datagerry
tls=false

[WebServer]
host = 0.0.0.0
port = 4000

[MessageQueueing]
host = 127.0.0.1
port = 5672
username = guest
password = NothingHereToSee
exchange = datagerry.eventbus
connection_attempts = 2
retry_delay = 6

Did the format change between 2.1.0 and 2.2.0?

2

Hey @sink1

in earlier versions were:
database_name = cmdb

3

Hi,

Our database name did not change.

In 2.1.0 we have a database called datagerry in mongod.
In 2,.2.0 we have a database called datagerry in mongod.

Nothing changed on any of our mongodb databases:

test> show dbs
admin      40.00 KiB
config     72.00 KiB
datagerry  39.38 MiB
local      72.00 KiB
test> use datagerry;
switched to db datagerry

I copied a known working configuration into the 2.2.0 installation that has this:

[Database]
host = 127.0.0.1
port = 27017
database_name = datagerry
tls=false

Or do you mean that Becom have hardcoded the database names into 2.2.0?

4

I thought it was about the default settings

in section [MessageQueueing] use entry:

use_tls = ...

I’m wondering if this entry is compatible with the configuration:
in section [Database]

tls=false
5

Hi @sink1 ,
we have not changed anything in the cmdb.conf with the last release, we will have a look at it.

BR Adnan

6

Not sure if its related, but I am getting upgrade failures in the logs with updating via Docker also going from 2.1.0 to 2.2.0

image
image1920×1160 247 KB

7

And now my database is in read only mode :slight_smile:

[2024-08-13 14:13:11][ERROR   ] --- Something went wrong during the generation of the updater module. 
 Error: An empty update path is not valid., full error: {'index': 0, 'code': 56, 'errmsg': 'An empty update path is not valid.'} (__main__.py)
[2024-08-13 14:13:11][WARNING ] --- The update did not go through as expected - Status UpateStatus.ERROR (__main__.py)