Description of problem: Scripts that make use of the output of bkr list-labcontrollers are unable to tell which of the lab controllers are enabled, so may not be able to make good decisions based on that output (i.e which lab to put a recipe in) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. bkr list-labcontrollers --enabled 2. 3. Actual results: Option doesn't exist Expected results: It would be nice if it did exist. Additional info:
http://gerrit.beaker-project.org/#/c/2997/
Out of interest, why does your recipe need to pick a particular lab controller (rather than letting Beaker pick one as normal)?
And wouldn't it make more sense to just never include the disabled lab controllers? They're disabled - they should be effectively invisible to everyone except the Beaker admins that may want to resurrect them.
There is a difference between removed lab controllers and disabled ones. Removal is expected to be permanent so we should fix bkr list-labcontrollers not to include them. Disablement is expected to be temporary (e.g. a few hours for an outage) so it doesn't make sense to always hide them in bkr list-labcontrollers. The patch in comment 2 is filtering out disabled lab controllers but I suspect the actualy use case probably just needs the removed ones to be filtered out. I'm still curious to hear why exactly this is needed though.
So this is useful when you have a wish to define which lab controller you want the recipe to run in (in terms of locality). This is useful when you have a script that does the job submissions for you and it does not have a set of known good lab controllers beforehand. Th problem is that you can't make a good decision unless you're confident that the list you've been returned are actually lab controllers that are currently working and can have recipes run on them.
Okay, so you're saying your script wants to get a list of lab controllers and then order them according to what's closest to you, and then submit a job restricted to that one lab? Fair enough I suppose. So in that case, just unconditionally omitting the removed lab controllers should be sufficient, right? No need for an --enabled switch. Can you please update your patch?
I'd rather not because that changes the default behaviour of the current implementation. That would go against our changing of API rules (as our CLI is an API) and so would not pass review. For those reasons I'm happy just to keep the default behaviour as it is for the foreseeable future, less hassle than what is needed to change the API.
I've added an additional clause to our API stability policy here http://gerrit.beaker-project.org/#/c/3000/. This allow us to implement the solution in comment#7 without undoing our own policy.
Ok, after further discussions with Dan, I've decided to change list-labcontrollers behaviour to just return non removed lab controllers.
So to clarify some offline discussions... The real issue here is indeed just that bkr list-labcontrollers is returning a bunch of old dead hostnames that were decomissioned years ago, but are still present in Beaker's database (marked as Removed). Ray has a patch which fixes it: http://gerrit.beaker-project.org/3022 Fixing this issue is not an API break in my opinion, because it does not change any parameter types, return types, or method names. Nor does it change the meaning of any methods. We *are* changing the behaviour of the lab_controllers XML-RPC method, but not in any way that contradicts the existing documented behaviour. And realistically, a reasonable person would expect the method not to return old decommissioned hostnames that don't even resolve anymore. Therefore we are not violating our API stability policy.
Beaker 0.16.2 has been released.