Getting message about newer DB schema after upgrading to Director 1.7.2

Hi there,
I just upgraded our director-1.7.1 to 1.7.2.
Now I get the message

Your DB schema (migration #169) is newer than your code base. Downgrading Icinga Director is not supported and might lead to unexpected problems.

A little strange as we 1.7.2 is the latest and we never had something newer as 1.7.1 running?
Any ideas how to solve this?
Thanks,
M.

Hi,

what’s the source of your director package?

I run into a similar problem by using the master branch from github. The master branch is bleeding edge and migrates DB to a higher schema version than director 1.7.2 expects.

Since there are no rollback scripts for schema migrations, there are two ways:

  • stay on newer branch (if it works for you)
  • restore a DB and director backup with old version and apply director 1.7.2 package
    Manually undoing the DB migrations to reach the needed schema version is no recommend.

Cheers,
Manfred

1 Like

Hi @a1mw
I just fetched from https://github.com/Icinga/icingaweb2-module-director/archive/v1.7.2.zip and extracted that. And usually I always did that before on the same way…strange huh? :thinking:
Best,
Matthias

Hi All,

We just upgraded our Icinga director module from 1.6.x to 1.7.2. And we faced the similar issue while migrating the schema.

Your DB schema (migration #160) is newer than your code base. Downgrading Icinga Director is not supported and might lead to unexpected problems.

You might be running the latest director package with old schema. Please replace them with latest schema & apply below set of commands.

$ sudo icingacli director migration run --verbose
$ sudo icingacli director migration pending --verbose
$ sudo icingacli director kickstart run

We ran into the issue of database tables which were already existing while doing the migration run.

# icingacli director migration run --verbose
ERROR: RuntimeException in /usr/share/icingaweb2/modules/director/library/Director/Db/Migration.php:60 with message: Migration 161 failed (SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'icinga_scheduled_downtime_inheritance' already exists) while running CREATE TABLE icinga_scheduled_downtime_inheritance.......

In such cases, you need to drop the tables which are already present in the database and run the command again. Then run the above set of command & restart the icinga-director daemon. It should do the trick by then :slight_smile:

I hope this helps a bit.

Thanks
Sam

1 Like

Hi @sambhav
thanks for that hint…for me that didn’t work out…all commands didn’t gave any output :frowning:
At least the build in commands where updated / created. But the schema error is still showing up.
I think it might only get fixed when next version is above the one in my schema.
Best,
Matthias

@blindzero: @a1mw perfectly nailed your problem. You have once been working on the master (development) branch which is obviously always ahead in time. The notice you’re seeing is there to inform people about this (potential) issue. This warning has been introduced with v1.7.1:
https://github.com/Icinga/icingaweb2-module-director/issues/1992

So, it states that your DB schema is newer than your code base, so you might eventually face issues. As @a1mw already proposed, download a current master and you should be fine. I checked the schema differences between v1.7.2 and migration #169: 169 itself would be fine, but 168 introduced changes that might cause issues with DataFields. A new property has introduced, and the code in v1.7.x doesn’t know about this. So it will probably complain and fail in some places of the UI.

Please stay on the master version you picked unless the next feature release, that will be v1.8 - from then on you can once again stick to release tags. v1.7.3 will be released very soon, please do not try to “upgrade” to that version. It is technically older than the master form months ago. Support-Branches and Point-Releases get only cherry-picked important bug fixes.

And I don’t want to be impolite, but anyone reading this please ignore the suggestion proposed by @sambhav. Manually dropping/changing tables should never be required.

Cheers,
Thomas