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

[Kodiak Firesmith]

Thanks all.  I think I'm going to stand by on the pulp issue I have open to
see if a fix to my original migration problem appears first, since I'd of
course like to be current in my production instance, and the sanest path
forward.  I've already announced the outage, gotten Apache turned back on
to serve updates, and turned off further DB backups in case I do eventually
need to roll back to the last backup from before the upgrade.

Thanks for educating me on the db unit migration issues, that has allowed
me to make an educated decision to hold tight in case manually gzipping yum
metadata ends up being the way to advance beyond the broken unit.

 - Kodiak

On Mon, Apr 1, 2019 at 12:24 PM Tatiana Tereshchenko <ttereshc at redhat.com>
wrote:

> Hi Kodiak,
> Yes, it's either ok to change it in the DB directly or sometimes it's not
> ok/possible if migrations introduced any other changes than additive ones.
> From your traceback
> https://paste.fedoraproject.org/paste/wEIu5a3Tf8OejEzMNsXN9w, pulp
> migrated to 29, pulp_docker migrated to 6 and pulp_rpm was not able to
> migrate to 43.
>
> It's not safe to downgrade for pulp_docker, the change in migration 6 was
> not additive. Do you have docker content (or this plugin is just
> installed)? If you don't have docker content (manifest lists specifically),
> this migration can be downgraded.
> For pulp_rpm it's semi-safe to downgrade, it depends if no content
> migrated or some migrated and then it errored. You can check it by looking
> at the /var/lib/pulp/content/units and see if there are modulemd and
> modulemd_defaults directories and if there is any content there.
> For pulp it's fine, changes were only additive.
>
> Let me know if you are still trying to downgrade (if you have mongo DB
> backup, it is safer to use it),
> Tanya
>
>
> On Mon, Apr 1, 2019 at 4:39 PM 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/a09452d8/attachment.htm>