puppetdb "

[Steve Huston]

I upgraded via the Puppet repos from puppetdb-6.9.1-1.el7.noarch
(Installed 3/12) to puppetdb-6.10.0-1.el7.noarch today, and restarting
puppetdb fails with this error:

Your PuppetDB database contains a schema migration numbered 1, but
this version of PuppetDB does not recognize that version.

Sure enough (trimmed):

puppetdb=> SELECT * FROM schema_migrations;
version | time
---------+-------------------------
1 | 2015-02-27 14:48:32.445
2 | 2015-02-27 14:48:32.452
...
72 | 2020-02-14 15:16:19.01
73 | 2020-02-14 15:16:20.313
(73 rows)

Looking in migrate.clj, though I'm not familiar with the language, it
seems that between the commits for 6.9.1 and 6.10.0 some things were
changed including the addition of a migration number '00' for testing
for the presence of the table. But the rest of the numbers only start
at 28. It almost seems as if adding the 00 but not 01..27 has caused
the test for unknown migrations to trigger, but again I'm not familiar
with the language so just trying to see what's going on.

--
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
Princeton University | ICBM Address: 40.346344 -74.652242
345 Lewis Library |"On my ship, the Rocinante, wheeling through
Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852 | headlong into mystery." -Rush, 'Cygnus X-1'

[Steve Huston]

A follow-up after a bit more searching. And an apology for a crap
subject line, I was called away to do other things and forgot to come
back to finish typing it :P

This commit seems to have fixed situations like mine previously:
https://github.com/puppetlabs/puppetdb/commit/5e15c6fadb4fdc4c636b5eddc7a302043da68a20

If I'm reading it right, starting at line 454 it gathers a list of
migrations from 1 to the lowest number recorded in known-migrations
(which is a sorted list of the items in migrations). It then
essentially ignores them, treating them as accepted but not allowing
for upgrades from them because they're too old.

But then when this commit was added a couple months ago:
https://github.com/puppetlabs/puppetdb/commit/a3a71a22906186a5092c720119b690720ca69937

That now adds a number 00, so the list to ignore is essentially empty
since 00 is the lowest number in known-migrations and anything from
01..27 is now simply unknown. Now line 2083 triggers saying that
migration number 1 is in the table and it doesn't know what to do with
it.

I believe my options as a workaround are to either delete numbers
01..27 from the database by hand, or to edit migrate.clj and insert
above line 1952:
01 (fn [] true)
02 (fn [] true)
03 (fn [] true)
...

[Zachary Kent]

Hi Steve, 

Thank you for such a thorough explanation of the issue you were seeing. We're

fixing this now and will put out a new version of PuppetDB with a fix ASAP 

(likely in the next couple days).

The two options you mentioned as possible workarounds would both get the 

job done and seem low risk, but it may be worth waiting for the version we're 

planning on releasing soon if you're able.  

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CANnpg5RUKP-8%3DABmGsAPmcRFm_wEAYyxcKLnY7HEEoE6ojKuZQ%40mail.gmail.com.

[Steve Huston]

On Tue, May 5, 2020 at 1:01 PM Zachary Kent <zachar...@puppet.com> wrote:
> Thank you for such a thorough explanation of the issue you were seeing. We're
> fixing this now and will put out a new version of PuppetDB with a fix ASAP
> (likely in the next couple days).

Glad I could help!

> The two options you mentioned as possible workarounds would both get the
> job done and seem low risk, but it may be worth waiting for the version we're
> planning on releasing soon if you're able.

Knowing there's a solution in the pipeline, I can wait a little bit
for it. We're not deploying a lot of new machines at the moment :D