aruraghuwanshi opened a new pull request, #18973:
URL: https://github.com/apache/druid/pull/18973

   <!-- Thanks for trying to help us make Apache Druid be the best it can be! 
Please fill out as much of the following information as is possible (where 
relevant, and remove it when irrelevant) to help make the intention and scope 
of this PR clear in order to ease review. -->
   
   <!-- Please read the doc for contribution 
(https://github.com/apache/druid/blob/master/CONTRIBUTING.md) before making 
this PR. Also, once you open a PR, please _avoid using force pushes and 
rebasing_ since these make it difficult for reviewers to see what you've 
changed in response to their reviews. See [the 'If your pull request shows 
conflicts with master' 
section](https://github.com/apache/druid/blob/master/CONTRIBUTING.md#if-your-pull-request-shows-conflicts-with-master)
 for more details. -->
   
   <!-- Replace XXXX with the id of the issue fixed in this PR. Remove this 
section if there is no corresponding issue. Don't reference the issue in the 
title of this pull-request. -->
   
   <!-- If you are a committer, follow the PR action item checklist for 
committers:
   
https://github.com/apache/druid/blob/master/dev/committer-instructions.md#pr-and-issue-action-item-checklist-for-committers.
 -->
   
   ### Description
   
   With the default/current code, if there is more than one StatefulSet or 
Deployment belonging to the same NodeType (e.g. `historicals-hot` and 
`historicals-cold`), the rollout order keeps flapping non-deterministically 
when `rollingDeploy` is enabled. Within each node type, specs were appended 
from map iteration over `m.Spec.Nodes`, so the order can change between calls 
and across reconciles (e.g. sometimes `historicals-hot` first, sometimes 
`historicals-cold` first).
   
   When `getNodeSpecsByOrder` is called multiple times during a single rollout, 
the order returned for specs within the same NodeType can therefore change 
between calls. That leads to erroneous behavior: multiple 
StatefulSets/Deployments of that NodeType may undergo rollout at the same time 
instead of one completing before the next.
   
   This change enforces ordering and consistency by sorting specs by 
`ServiceGroup.key` within each node type before appending them to the ordered 
list. Rollout order is now stable and deterministic across reconciles: one 
StatefulSet/Deployment within the same NodeType is fully rolled out before the 
operator moves on to the next.
   
   #### Deterministic ordering in `getNodeSpecsByOrder`
   
   - Added a sort step per node type: after collecting specs by node type, we 
sort each slice by `ServiceGroup.key` (ascending) using Go’s `sort.Slice` 
before appending to the final ordered list.
   - Order across node types remains defined by `druidServicesOrder` 
(historical → overlord → middleManager → indexer → broker → coordinator → 
router). Within each node type, order is now deterministic by node spec key 
(e.g. `historicals-cold`, `historicals-hot`).
   
   #### Release note
   
   Druid Operator: When `rollingDeploy` is enabled, rollout order for multiple 
StatefulSets/Deployments of the same NodeType (e.g. `historicals-hot` and 
`historicals-cold`) is now deterministic and stable. One such resource is fully 
rolled out before the next, avoiding concurrent rollouts within the same 
NodeType.
   
   <hr>
   
   ##### Key changed/added classes in this PR
    * `druid-operator/controllers/druid/ordering.go` — `getNodeSpecsByOrder`
    * `druid-operator/controllers/druid/ordering_determinism_test.go` — unit 
tests for deterministic ordering
   
   <hr>
   
   <!-- Check the items by putting "x" in the brackets for the done things. Not 
all of these items apply to every PR. Remove the items which are not done or 
not relevant to the PR. None of the items from the checklist below are strictly 
necessary, but it would be very helpful if you at least self-review the PR. -->
   
   This PR has:
   
   - [ ] added documentation for new or modified features or behaviors.
   - [x] a release note entry in the PR description.
   - [ ] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [ ] added or updated version, license, or notice information in 
[licenses.yaml](https://github.com/apache/druid/blob/master/dev/license.md)
   - [ ] added comments explaining the "why" and the intent of the code 
wherever would not be obvious for an unfamiliar reader.
   - [x] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   - [ ] added integration tests.
   - [ ] been tested in a test Druid cluster.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to