Merge lp:~benji/landscape-client/bug-1508110-resync-users-on-upgrade into lp:~landscape/landscape-client/trunk
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Benji York | ||||
Approved revision: | 832 | ||||
Merged at revision: | 829 | ||||
Proposed branch: | lp:~benji/landscape-client/bug-1508110-resync-users-on-upgrade | ||||
Merge into: | lp:~landscape/landscape-client/trunk | ||||
Diff against target: |
259 lines (+134/-5) 4 files modified
debian/landscape-client.postinst (+7/-0) landscape/monitor/tests/test_usermonitor.py (+69/-0) landscape/monitor/usermonitor.py (+52/-1) landscape/user/tests/helpers.py (+6/-4) |
||||
To merge this branch: | bzr merge lp:~benji/landscape-client/bug-1508110-resync-users-on-upgrade | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Chad Smith | Approve | ||
Simon Poirier (community) | Approve | ||
Review via email: mp+285353@code.launchpad.net |
Commit message
Add a complete refresh of user data after client install (remediation
for bug 1508110).
Description of the change
This branch is a remediation for bug 1508110 which caused incomplete
user data to be stored in LS.
Upon client install, the postinst script creates a flag file in the
client data directory which signals a complete refresh of user data.
Then when the usermonitor is triggered, it checks for the flag file
and if present sends a total refresh of user data (deleting the flag
file on completion).
Testing instructions:
- build a new set of packages (see "make package")
- stop the client on the test machine
- install -common and -client packages
- if you don't want to wait an hour for the full refresh to be
triggered, edit the run_interval class attribute in usermonitor.py
- verify that /var/lib/
- set "log_level = debug" in /etc/landscape/
- start the client
- wait run_interval seconds and verify that a complete refresh took
place via /var/log/
- verify that /var/lib/
removed
- if you were lucky enough to be testing with an account with
incomplete user data, verify that LS now lists complete user data
for the computer in question
Ok got through this, thank you.
Note 1:
Chatted a bit in IRC about the round trip between client sending this initial duplicate user data to OPL and whether we care about trimming that initial data to a single duplicated pair of user rows because we know it will likely all be thrown out anyway by OPL and re-requested.
Answer: We don't care about trimming the initial failed client user sync. Let the resync roundtrip from OPL handle things since this is a one time operation.
The OPL traceback and user scoped resynch request is here for reference. /pastebin. canonical. com/149414/
https:/
Marked needs fixing only to see the addressed postinst logic to handle upgrade path.