We've had a use case on occasion for blacklisting a system's ability to install a particular release, or newer, on the excluded families tab. For instance - we have an older prototype that is still useful for testing, but the hardware isn't supported in kernels post 2.6.32-179.el6, causing it to fail on RHEL6.2 and greater. There are still cases where we'd test older releases (and, it seems to still be supported in RHEL5), but we'll have to blacklist every release on the RHEL6 tree from here on out, by hand, per system.
because version releases are not numerical and we have rhel and fedora which have overlapping numbers.. Can we instead support flipping the exclude to a include list? I think the default exclude is the most common but we could support turning it into an include list as well. You would have to pick per system if you want exclude or include, you wouldn't be able to pick from both.
(In reply to comment #1) > because version releases are not numerical and we have rhel and fedora which > have overlapping numbers.. Can we instead support flipping the exclude to a > include list? I think the default exclude is the most common but we could > support turning it into an include list as well. You would have to pick per > system if you want exclude or include, you wouldn't be able to pick from both. Per our little chat: -The radio button toggles make sense, given the complexity of a per-major-release include/exclude -The ability for beaker to "do the right thing" and properly convert an include list to an exclude list (and vice versa) as you switch between excludes and includes would go a long way towards making this even better.
Hello, thank you for opening issue in Beaker project. This issue was marked with component "web ui". As we are not planning to address any further issues in current UI, due to technical stack and not being able to work with Python 3 codebase, I'm closing this issue as WONTFIX. New UI will be reimplemented within new versions of Beaker. If you have any questions feel free to reach out to me. Best regards, Martin <martin.styk>