Add note about reschedules and num_attempts in filter_properties
The "retry" entry in filter_properties is not set if reschedules
are disabled, which happens in these cases:
1. [scheduler]/max_attempts=1
2. The server is forced to a specific host and/or node.
More times than I'd like to admit, I've had to re-learn that
filter_properties['retry']['num_attempts'] will always be >1 in
conductor build_instances during a reschedule because if
reschedules are disabled, the compute service aborts the build
on failure and we don't even get back to conductor.
This change adds a note since it's hard to keep in your head how
the retry logic is all tied together from the API, superconductor,
compute and cell conductor during a reschedule scenario.
Reviewed: https:/ /review. openstack. org/582412 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=276130c6d16 37f8e0f39ba274e 2619a115a8fa1a
Committed: https:/
Submitter: Zuul
Branch: master
commit 276130c6d1637f8 e0f39ba274e2619 a115a8fa1a
Author: Matt Riedemann <email address hidden>
Date: Thu Jul 12 18:25:07 2018 -0400
Add note about reschedules and num_attempts in filter_properties
The "retry" entry in filter_properties is not set if reschedules
are disabled, which happens in these cases:
1. [scheduler] /max_attempts= 1
2. The server is forced to a specific host and/or node.
More times than I'd like to admit, I've had to re-learn that properties[ 'retry' ]['num_ attempts' ] will always be >1 in
filter_
conductor build_instances during a reschedule because if
reschedules are disabled, the compute service aborts the build
on failure and we don't even get back to conductor.
This change adds a note since it's hard to keep in your head how
the retry logic is all tied together from the API, superconductor,
compute and cell conductor during a reschedule scenario.
Change-Id: I83536b179000f4 1f9618a4b6f2a16 b4440fd61ba
Related-Bug: #1781286