Author Topic: Problems with Central Worker Configuration  (Read 3868 times)

sosborne76

  • Sr. Member
  • ****
  • Posts: 41
Problems with Central Worker Configuration
« on: November 08, 2010, 03:26:17 PM »
I have already fixed this particular issue but thought I would raise it for peoples reference.

I had a bunch of workers locally configured to use a particular proxy account. This account I later had need to change. At this point I used the GUI to centrally configure all of the workers with the new account info and password. I did some testing and all was good. I then did some administration and house keeping on one particular worker which later went into panic. One of the things I had done was to delete the local account that previously was used as proxy. To fix the issue I modified the qb.conf locally on the worker machine in line with the central configuration.

From this behaviour I assume that a worker will start using a local configuration before a central configuration is applied.

jburk

  • Administrator
  • *****
  • Posts: 493
Re: Problems with Central Worker Configuration
« Reply #1 on: November 08, 2010, 04:43:29 PM »
A couple of things contributed to this behavior.

The worker normally does load its local config first, and then ask the supervisor for any remote config values.  These remote config values then override the local values.

You can control this behavior (remote config trumps local) by specifying a "worker_lookup" value in the worker's local qb.conf:

worker_lookup = local,supervisor   # this is the default

or

worker_lookup = supervisor,local 

When you use "supervisor,local", any non-default settings in the worker's local qb.conf will cause the corresponding value in the remote config to be ignored; non-default local config settings trump the remote config.


The proxy_account is a bit special as you've found out.  The worker will check for the existence of the proxy_account as soon as it reads the local config, and not wait to see if the remote config has a value that will be used in it's place.

We saw this behavior in a case a couple of weeks ago, and consider this a bug that will be fixed in a future release.  The desired behavior should be "wait and check the remote config before panic'ing due to a missing proxy_account".