Bug 1004821 - oo-admin-upgrade isn't compatible with oo-admin move running at the same time
oo-admin-upgrade isn't compatible with oo-admin move running at the same time
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Dan Mace
libra bugs
Depends On:
  Show dependency treegraph
Reported: 2013-09-05 10:38 EDT by Thomas Wiest
Modified: 2015-05-14 19:27 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-06 15:13:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Wiest 2013-09-05 10:38:04 EDT
Description of problem:
Before the recent oo-admin-upgrade data structure refactor, oo-admin-move could be run while oo-admin-upgrade was running (as long as it ran after oo-admin-upgrade gathered it's initial data).

This is important because oo-admin-upgrade runs can take over a week (with re-runs, hotfixes, etc).

Now, however, that's not the case.

Here's what Dan Mace said on IRC:
(09/05/2013 10:32:01 AM) danmace: twiest: the new upgrader caches all that information between runs now; so that could be an issue. we can clear it prior to a followup run though

I don't believe simply clearing it between runs is sufficient, though, because an oo-admin-upgrade run can take over a day to run, which is a long period of time in which oo-admin-move could be run as well.

We really need both scripts to be compatible with each other.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. This is a race condition, so it's hard to repro
2. Run both at the same time and see if some gears are either missed or errored out

Actual results:
We're not able to run both oo-admin-upgrade and oo-admin-move at the same time.

Expected results:
Before the refacter we were able to and we need that functionality back.
Comment 1 Abhishek Gupta 2013-09-06 13:24:36 EDT
Moving it to the node team to drive this fix. If any changes are required on the broker side, just let me or Rajat know.
Comment 2 Dan Mace 2013-09-06 15:13:14 EDT
Upon further investigation, the refactored upgrade code retains the just-in-time Mongo lookup of a gear prior to upgrading to identify its node. So, there is no regression- gears which have moved between upgrades will be reached at their new location during subsequent runs.

Note You need to log in before you can comment on or make changes to this bug.