Kerberos and KerberosSampler unexpected sampler selection about dwave-hybrid

[spakin]

The problem appears to come from hybrid/samplers.py, line 80. This line does a

qpu_sampler = DWaveSampler(solver=dict(qpu=True))

instead of querying the configuration file. I haven't yet checked the DWaveSampler code, but based on my observations, the above appears to be returning the alphabetically first solver instead of the solver that appears first in dwave.conf. The following replacement code returns the sampler I'd expect:

with Client.from_config(client="qpu") as client:
    qpu_sampler = client.get_solver()

I'm thinking that DWaveSampler is perhaps at fault here. Given a set of filters, it should return the first match in the configuration file, not an arbitrary match.

[randomir]

The solver=dict(qpu=True) part is actually a (temporary) fix for currently unexpected (unwanted) behavior of DWaveSampler (see dwavesystems/dwave-system#288) -- by default it will not filter-out non-QPU solver.

Nevertheless, the configuration file is queried (unless explicitly skipped with config_file=False on Client construction), it's just that solver definition is overridden. However, ordering of profiles (after first) is not relevant, since the first profile is used by default, unless explicitly specified with profile on Client construction or DWAVE_PROFILE env var.

With introduction of feature-based solver filtering (check examples at the end), ordering of solvers is determined with order_by argument in get_solver/get_solvers (defaulting to pick the solver with least avg_load).

In short, by specifying client type (in code or config) and not specifying solver (in code), solver can be defined via config or environment. (That the behavior we'll have in DWaveSampler after dwavesystems/dwave-system#288).

[spakin]

Nevertheless, the configuration file is queried (unless explicitly skipped with config_file=False on Client construction), it's just that solver definition is overridden. However, ordering of profiles (after first) is not relevant, since the first profile is used by default, unless explicitly specified with profile on Client construction or DWAVE_PROFILE env var.

It looks like what's actually happening is that my first profile is chosen, but the solver specified in that profile is being ignored. Is that what you mean by "that solver definition is overridden"? It's possible that my least loaded solver is what's getting selected—above I had guessed alphabetically first—but in my case it's least loaded because it's an inferior solver (a D-Wave 2X compatibility mode solver). Setting DWAVE_API_SOLVER in my environment doesn't seem to help. Will this be fixed with dwavesystems/dwave-system#288?

[randomir]

Yes, solver kwarg overrides DWAVE_API_SOLVER env var, which overrides solver read from config files. Same rule applies to other variables as well (token, endpoint, client, etc).

dwavesystems/dwave-system#288 will eliminate the need to supply solver kwarg if you need a QPU solver, in turn allowing environment or config file variable to determine the solver used (BTW, it will still be possible to fail with SolverNotFoundError exception if solver from config is non-QPU, when DWaveSampler will implicitly use client="qpu").

In the meantime, I'll patch Kerberos to use:

qpu_sampler = DWaveSampler(client="qpu")

effectively simulating dwavesystems/dwave-system#288, and resolving this issue.

Config subsystem in dwave-cloud-client/Ocean is quite different from the one in the old SAPI client. It's layered and hierarchical with profiles across multiple config files being inherited/extended, environment overriding config file, and code overriding everything. I hope Client.from_config and client configuration section provide enough details (if not, please let us know).