[Pulp-dev] #2186 (pulp-manage-db) options
mhrivnak at redhat.com
Thu Dec 8 22:25:17 UTC 2016
On Thu, Dec 8, 2016 at 1:49 PM, Bihan Zhang <bizhang at redhat.com> wrote:
> The changes made for #2186  was pulled from the 2.11.0 release
> yesterday, and we should talk about how to implement it for 2.12
> From what I can see there are 2 ways to move forward with #2186
> *1.* We can fix the pulp worker db record cleanup so that pulp_celerybeat
> exits cleanly (aka put this back: ) and make new changes to clean up
> pulp_workers with a SIGTERM handler in a 2.11.z release.
> We can then re-revert the commit and put the feature back in 2.12 with
> little effort.
We would also need a way for pulp-manage-db to know if a record in the
Worker collection was created by a version of pulp that does not do full
cleanup. As described in a previous email, one way would be to add some
kind of new field to the Worker model, such as the version of pulp the
worker was running.
> The original reason #2186 was implemented using the db records was so we
> can support a clustered pulp installation.
> But this approach would make migration to 2.12 more difficult, since users
> now have to upgrade to the 2.11.z release first before going to 2.12
Perhaps the original intent was lost. This feature was motivated primarily
by katello deployments (all of which are single-system), where users either
forgot to stop pulp services or didn't know that was a requirement before
running pulp-manage-db. The normal upgrade process for them handles it
automatically, but when manual intervention is required, that's where we've
seen people running pulp-manage-db while pulp services are running.
> *2. *We can rethinking our approach to #2186 and perform the check
> against the process list
> Upgrade-wise implementing it this way is a lot easier for users, since
> they can do a straight upgrade to 2.12 without going through an
> intermediary release.
> The downside is that in clustered environments this would not catch every
> potential error. But #2186 is a best effort story, and if this is the best
> effort I am ok with it.
This is easy and effective. I think we should do it, and augment/replace it
in the future with the worker checking.
> Regardless of which option we go with I think we should get the pulp
> worker db cleanup in.
> We should also have a --ignore-running-worker flag  to prevent
> automated upgrade problems.
>  https://pulp.plan.io/issues/2186
>  https://github.com/werwty/pulp/commit/4f43a85dd568f4a0b5
>  https://pulp.plan.io/issues/2469
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev