f7c688b8ef
This aims to fix the issue described in bug 1664931 where a rebuild fails to validate the existing host with the scheduler when a new image is provided. The previous attempt to do this could cause rebuilds to fail unnecessarily because we ran _all_ of the filters during a rebuild, which could cause usage/resource filters to prevent an otherwise valid rebuild from succeeding. This aims to classify filters as useful for rebuild or not, and only apply the former during a rebuild scheduler check. We do this by using an internal scheduler hint, indicating our intent. This should (a) filter out all hosts other than the one we're running on and (b) be detectable by the filtering infrastructure as an internally-generated scheduling request in order to trigger the correct filtering behavior. Closes-Bug: #1664931 Change-Id: I1a46ef1503be2febcd20f4594f44344d05525446
21 lines
1.1 KiB
YAML
21 lines
1.1 KiB
YAML
---
|
|
fixes:
|
|
- |
|
|
The fix for `OSSA-2017-005`_ (CVE-2017-16239) was too far-reaching in that
|
|
rebuilds can now fail based on scheduling filters that should not apply
|
|
to rebuild. For example, a rebuild of an instance on a disabled compute
|
|
host could fail whereas it would not before the fix for CVE-2017-16239.
|
|
Similarly, rebuilding an instance on a host that is at capacity for vcpu,
|
|
memory or disk could fail since the scheduler filters would treat it as a
|
|
new build request even though the rebuild is not claiming *new* resources.
|
|
|
|
Therefore this release contains a fix for those regressions in scheduling
|
|
behavior on rebuild while maintaining the original fix for CVE-2017-16239.
|
|
|
|
.. note:: The fix relies on a ``RUN_ON_REBUILD`` variable which is checked
|
|
for all scheduler filters during a rebuild. The reasoning behind
|
|
the value for that variable depends on each filter. If you have
|
|
out-of-tree scheduler filters, you will likely need to assess
|
|
whether or not they need to override the default value (False)
|
|
for the new variable.
|