<div dir="ltr">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.  <div><br></div><div>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.</div><div><br></div><div> - Kodiak</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 1, 2019 at 12:24 PM Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com">ttereshc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Kodiak,</div><div>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.</div><div>From your traceback <a href="https://paste.fedoraproject.org/paste/wEIu5a3Tf8OejEzMNsXN9w" target="_blank">https://paste.fedoraproject.org/paste/wEIu5a3Tf8OejEzMNsXN9w</a>, pulp migrated to 29, pulp_docker migrated to 6 and pulp_rpm was not able to migrate to 43.</div><div><br></div><div>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.</div><div>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.</div><div>For pulp it's fine, changes were only additive.<br></div><div><br></div><div></div><div>Let me know if you are still trying to downgrade (if you have mongo DB backup, it is safer to use it),<br></div><div>Tanya<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 1, 2019 at 4:39 PM Kodiak Firesmith <<a href="mailto:kfiresmith@gmail.com" target="_blank">kfiresmith@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Pulp-List,<div>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").</div><div><br></div><div>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.</div><div><br></div><div>thanks!</div><div> - Kodiak</div></div>
_______________________________________________<br>
Pulp-list mailing list<br>
<a href="mailto:Pulp-list@redhat.com" target="_blank">Pulp-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a></blockquote></div>
</blockquote></div>