poddm opened a new pull request, #13662:
URL: https://github.com/apache/cloudstack/pull/13662

   ---
   ### Description
   
   This PR makes the management server node id (`msid`) stable across restarts 
by adding an opt-in mode that derives it from the node FQDN instead of the host 
MAC address.
   
   By default, `ManagementServerNode` derives the `msid` from the host hardware 
MAC address (`MacAddress.getMacAddress().toLong()`). In environments where the 
MAC address is not stable across restarts (e.g. certain 
virtualized/containerized hosts), the `msid` changes on restart. This orphans 
the `mshost` row and breaks any state keyed on the node id — async jobs, HA 
work (`fk_op_ha_work__mgmt_server_id`), and router/stats ownership.
   
   This change:
   - Adds an opt-in FQDN mode: when the environment variable 
`CLOUDSTACK_MSID_FROM_FQDN=true` (or the system property 
`cloudstack.msid.from.fqdn=true`) is set, the `msid` is derived from a SHA-256 
hash of the node's canonical FQDN, which stays stable across restarts. Default 
behavior (MAC-based) is unchanged.
   - Fails cleanly: if the FQDN cannot be resolved, `ManagementServerNode` 
records the cause and returns an invalid id (`0`) rather than silently 
reverting to the unstable MAC-based id. The invalid id makes the 
system-integrity `check()` fail startup cleanly instead of raising an 
`ExceptionInInitializerError` from static initialization.
   - Centralizes node-identity access: all consumers now obtain the id from 
`ManagementServerNode.getManagementServerId()` so they agree on the same value 
— `StatsCollector`, `ManagementServerImpl`, `NetworkUsageManagerImpl`, 
`VirtualNetworkApplianceManagerImpl`, and `CloudZonesStartupProcessor` 
(previously some called `MacAddress.getMacAddress().toLong()` directly).
   - Logs the resolved id and its source (`mac-address` / `fqdn:<name>`) at 
startup for observability.
   
   <!-- Fixes: # -->
   
   ### Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [x] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   - [ ] Build/CI
   - [ ] Test (unit or integration test code)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Feature/Enhancement Scale
   
   - [ ] Major
   - [x] Minor
   
   #### Bug Severity
   
   - [ ] BLOCKER
   - [ ] Critical
   - [ ] Major
   - [ ] Minor
   - [ ] Trivial
   
   ### Screenshots (if appropriate):
   
   N/A
   
   ### How Has This Been Tested?
   
   - Added `ManagementServerNodeTest` covering both derivation modes (MAC-based 
default and FQDN-based opt-in), including the failure path that yields an 
invalid id.
   - Verified default (MAC) behavior is unchanged when the env var/system 
property is unset.
   - Verified that with `CLOUDSTACK_MSID_FROM_FQDN=true`, the derived id is 
positive, non-zero, and identical across restarts for the same FQDN.
   - Verified that all updated consumers resolve the same id via 
`ManagementServerNode.getManagementServerId()`.
   
   #### How did you try to break this feature and the system with this change?
   
   - Enabled FQDN mode on a host with an unresolvable/misconfigured hostname to 
confirm startup fails cleanly (integrity check throws with the recorded cause) 
rather than reverting to an unstable id or throwing 
`ExceptionInInitializerError`.
   - Checked truthy parsing variants (`true`, `1`, `yes`, mixed case, 
surrounding whitespace) and confirmed unset/`false`/empty values keep the 
default MAC-based behavior.
   - Confirmed the 48-bit derived id is masked positive and never `0` for a 
valid FQDN.


-- 
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]

Reply via email to