Description of problem: The "Reserve" UI section of the WebUI schedules jobs on systems with systype Resource. This makes it currently impossible to have a pool of machines separated from the main pool, which was previously possible ie. with a custom key-value and non-Machine systype. The "show systems" button doesn't seem to list those systems, but actually doing "auto pick system" can use them for reservation. Version-Release number of selected component (if applicable): 0.17 How reproducible: should be easy to reproduce using a user with access to just a few machines Steps to Reproduce: 1. open the Scheduler->Reserve section of the WebUI 2. select any matching tree 3. select architecture supported by the machine 4. click "Auto pick system" Actual results: systems with non-Machine systype can be (by default) reserved Expected results: only Machine systems can be (by default) reserved Additional info:
Limiting "Auto pick system" to Machine systems in Automated mode makes sense to me. We should also document that in the architecture guide as a general principle: if Beaker is picking the system implicitly, then we limit the pool to Machine+Automated. If users are choosing systems by name (whether through the web UI or via "force"), then we can be more permissive.
The hack to inject <system_type/> into <hostRequires/> when it's not present, does not seem to be taking effect. Currently not sure what has gone wrong but I am assuming it's a regression in 0.17.
(In reply to Dan Callaghan from comment #3) > The hack to inject <system_type/> into <hostRequires/> when it's not > present, does not seem to be taking effect. Currently not sure what has gone > wrong but I am assuming it's a regression in 0.17. Yes, sorry for not making that clear, it wasn't happening prior to 0.17.
The problem was introduced with this commit in Beaker 0.17.0 (early return from _get_host_requires): https://git.beaker-project.org/cgit/beaker/commit/?id=493a56da22981c58bfe3d0ed9a16d830966c7513 However I am not really happy with the magic <system_type/> injection happening in the getter for Recipe.host_requires (because of this exact reason, it is too easy to miss it). For release-0.17 we can fix up the logic for _get_host_requires but for develop I would prefer to move the <system_type/> injection to job submission time, to make it more explicit.
(In reply to Dan Callaghan from comment #5) > For release-0.17 we can fix up the logic > for _get_host_requires but for develop I would prefer to move the > <system_type/> injection to job submission time, to make it more explicit. Actually on second thought we can never move it, because that will break cloning existing recipes which haven't already had <system_type/> injected.
On Gerrit: http://gerrit.beaker-project.org/3221
(In reply to Jiri Jaburek from comment #0) > Steps to Reproduce: > 1. open the Scheduler->Reserve section of the WebUI > 2. select any matching tree > 3. select architecture supported by the machine > 4. click "Auto pick system" > > Actual results: > systems with non-Machine systype can be (by default) reserved > > Expected results: > only Machine systems can be (by default) reserved The behaviour can be verified more reliably by just looking at the <hostRequires/> in the cloned job. Step 5. clone the job which was submitted through Reserve Workflow Actual results: Job contains <hostRequires/> meaning that the scheduler may pick non-Machine systems. Expected results: Job contains <hostRequires><system_type value="Machine"/></hostRequires> so that the scheduler only picks Machine system type.
beaker-0.17.2 has been released.