[Pulp-list] Process for sane downgrade / bailing failed upgrade?

[Dennis Kliban]

I was corrected on IRC. The '28' should actually be an integer 28.

 db.migration_trackers.update({'name': 'pulp.server.db.migrations'}, {$set:
{'version': 28}})

However, you should probably not do this as pointed out by Tatiana.

On Mon, Apr 1, 2019 at 12:11 PM Dennis Kliban <dkliban at redhat.com> wrote:

> This information is stored in the migration_trackers collection in mongo.
> You can update that one migration tracker back to 28 by running this query:
>
>  db.migration_trackers.update({'name': 'pulp.server.db.migrations'},
> {$set: {'version': '28'}})
>
> On Mon, Apr 1, 2019 at 10:39 AM Kodiak Firesmith <kfiresmith at gmail.com>
> wrote:
>
>> Hi Pulp-List,
>> Due to my last email about the 2.18.1 migration traceback, I attempted to
>> get back in business by downgrading to the 2.16.3 package set, which went
>> fine after I found all of the packages and put them into a local file:///
>> repo, but after downgrading, pulp wouldn't start due to an internal server
>> error, with a recommendation that I re-run pulp-manage-db (as apache),
>> which I attempted to do, but it appears that even if the migration to a
>> later version fails, you can't migrate your way back ("the database for
>> migration package pulp.server.db.migrations is at version 29, which is
>> larger than the latest version available, 28").
>>
>> So I guess my question is, when you encounter a showstopper during the
>> last failed upgrade, and roll back to a prior version, are you into
>> database recovery territory?  And if so, is there guidance for such a task,
>> as I'm certainly no MongoDB guy.
>>
>> thanks!
>>  - Kodiak
>> _______________________________________________
>> Pulp-list mailing list
>> Pulp-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20190401/07bdbe8c/attachment.htm>