While extending the test coverage in PR #155 I tried to drive the 8.10 → 8.19 step of elasticsearch_upgrade_8to9_single through the role instead of the test bypassing it with package: state: latest + service: restarted. Setting elasticstack_version: latest with the same elasticstack_release: 8 looked like it should do the right thing, but the result was the cluster stayed pinned at 8.10.0 — no upgrade ran.
Reading roles/elasticsearch/tasks/elasticsearch-upgrade-detection.yml, the rolling-upgrade flag _elasticsearch_needs_rolling_upgrade only goes true under two conditions: elasticstack_version is set to a specific value strictly higher than what's installed, or elasticstack_release differs from the installed major. The latest mode falls through both. The intent in the comments is that the regular package task picks it up with state: latest and then "a rolling restart is triggered post-install", but the post-install detection path doesn't appear to be wired up — I couldn't find it.
The practical effect: anyone using elasticstack_version: latest to get patch bumps within the same major won't see ES restart, even when a newer 8.x is available. They may not notice if the role then says everything is fine; with a stale apt/yum cache they may not even pull a newer package.
For PR #155 I reverted that test to the original direct package + service approach, but the gap is worth tracking on the role side. A "latest mode same-major" detection — compare the installed version after the package task to what was installed before, and route through the rolling-upgrade path if it changed — would close it.
While extending the test coverage in PR #155 I tried to drive the 8.10 → 8.19 step of
elasticsearch_upgrade_8to9_singlethrough the role instead of the test bypassing it withpackage: state: latest+service: restarted. Settingelasticstack_version: latestwith the sameelasticstack_release: 8looked like it should do the right thing, but the result was the cluster stayed pinned at 8.10.0 — no upgrade ran.Reading
roles/elasticsearch/tasks/elasticsearch-upgrade-detection.yml, the rolling-upgrade flag_elasticsearch_needs_rolling_upgradeonly goes true under two conditions:elasticstack_versionis set to a specific value strictly higher than what's installed, orelasticstack_releasediffers from the installed major. Thelatestmode falls through both. The intent in the comments is that the regular package task picks it up withstate: latestand then "a rolling restart is triggered post-install", but the post-install detection path doesn't appear to be wired up — I couldn't find it.The practical effect: anyone using
elasticstack_version: latestto get patch bumps within the same major won't see ES restart, even when a newer 8.x is available. They may not notice if the role then says everything is fine; with a stale apt/yum cache they may not even pull a newer package.For PR #155 I reverted that test to the original direct
package+serviceapproach, but the gap is worth tracking on the role side. A "latest mode same-major" detection — compare the installed version after the package task to what was installed before, and route through the rolling-upgrade path if it changed — would close it.