[Pulp-dev] #2186 (pulp-manage-db) options

[Michael Hrivnak]

On Thu, Dec 8, 2016 at 1:49 PM, Bihan Zhang <bizhang at redhat.com> wrote:

> The changes made for #2186 [0] 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: [1]) 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 [2] to prevent
> automated upgrade problems.
>
>
> [0] https://pulp.plan.io/issues/2186
> [1] https://github.com/werwty/pulp/commit/4f43a85dd568f4a0b5
> 0ae9b07bbec7138861e92b#diff-80e8b96df1f5da9a551bb6ff18dea352
> [2] https://pulp.plan.io/issues/2469
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161208/1a856859/attachment.htm>