Prefs flip back and forth when using account manager

[TheAspens]

If you have a host that is configured to use an account manager and you update your global preferences at a project website, then each time the host contacts the project servers, it will receive and start using the global preferences updated at the project website. When it next syncs with the account manager, it will receive the prefs from the account manager and start using those.

This back and forth will continue until the preferences are updated at the account manager so that the mod_time field for the account manager prefs are more recent then the prefs from the project website.

This can be fixed in either of the following two ways:

• Modify the client in cs_scheduler.cpp CLIENT_STATE::make_scheduler_request() so that it sends a flag to the project indicating that the host is being managed by an account manager. The server code in would also need to be modified in handle_request.cpp handle_global_prefs() so that this flag was read and if the flag was set, the project would not send its db prefs to the client.

or

• Modify the client so that if it is being managed by BAM and it receives global prefs from a project, it simply discards them and does not use them.

[ChristianBeer]

The prefs propagation does not distinguish between prefs received by project or account manager. It reads the <mod_time> field and uses the newest set of preferences. If you are using an account manager you should not change the preferences on individual projects. This is not clearly stated when adding an account manager. Adding a flag to both server and client is not feasible because of backwards compatibility. Adding some logic to the Client to ignore newer global preferences from a project when the Client is attached to an account manager seems to be the better option. But there could be the case where the global prefs send by the project actually are from the account manager and thus should be considered. Detecting this seems easy as the prefs send by the project contain the <source_*> tags where the client can check where the prefs actually come from.

[TheAspens]

On the project servers, the check for mod_time is what is the deciding factor. However, BAM always sends prefs no matter what the mod_time is of their prefs or the client prefs. Additionally, the prefs from BAM contain the <host_specific/> tag. Because the prefs from BAM use the host_specific tag, the client will not send them to project servers and thus these preferences do not participate in preferences propagation (see client/cs_scheduler.cpp line 170).

The system should behave in an understandable way even if users do the "wrong" thing. Going with the second option above and including your check for the source of the prefs, this would mean that if a host receives prefs from a project and they are not from the account manager that is currently managing the host, then the client should discard prefs and put a message on the log stating "newer prefs from World Community Grid not used because this host is being managed by BAM". This would make the behavior of the system easily understandable by the end user.

It would also be helpful if there was a way to present the user on the website information that indicated that they should be going to the account manager to change their prefs rather than doing them on the project website. If account manager prefs propagated, then it would be easy to provide a warning message to the user saying something like "These preferences originated at BAM. If you are still using BAM, then your devices that are managed by BAM will only use preferences that originated by BAM and will not use the changes that you make here."

[ChristianBeer]

Interesting. I didn't know about the host_specifc tag, it seems to be another undocumented feature (http://boinc.berkeley.edu/trac/wiki/PrefsImpl). But your proposal with adding messages seems feasible. The web code also knows where the preferences come from so there could be a message that informs the user that he may better use the account manager since the last preferences came from there.

[jaredmulconry]

This issue has plagued me since I signed up for BOINCstats BAM! to manage my work preferences almost 2 years ago. Any indication on when this might be addressed? I'm a bit tired of manually updating work preferences on each machine because my preferences keep getting overwritten by WCG.