bhouse-nexthop opened a new pull request, #14641: URL: https://github.com/apache/cloudstack/pull/14641
### Description `updateConfiguration` with a scope id returned the global value of the setting in its response, not the value that was just set. The scoped value itself was stored correctly. `ConfigurationManagerImpl.updateConfiguration(UpdateCfgCmd)` returns `_configDao.findByName(name)`, the global `configuration` row. Since #11770, `UpdateCfgCmd.setResponseValue()` takes the response value from that object rather than from the request, so a scoped update answered with the global value. When a scope is given, the returned object now carries the value set in that scope. That value is the one the inner `updateConfiguration(...)` returns, after normalization. The object is only used to build the response and is not persisted. Updates without a scope are unchanged. This only affects main. 4.22 still echoes the value from the request. Fixes #14638 ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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 - [x] Test (unit or integration test code) ### Feature/Enhancement Scale or Bug Severity #### Bug Severity - [ ] BLOCKER - [ ] Critical - [ ] Major - [x] Minor - [ ] Trivial ### How Has This Been Tested? Unit tests in `ConfigurationManagerImplTest`: - `updateConfigurationWithScopeReturnsValueSetInScope`: a cluster-scoped update of `drs.algorithm` to `condensed`, with a global value of `balanced`, returns `condensed`. It fails without the fix (`expected:<condensed> but was:<balanced>`). - `updateConfigurationWithoutScopeReturnsConfigurationRowUnchanged`: a global update returns the `configuration` row as it was, and doesn't change its value. `ConfigurationManagerImplTest`, `ConfigurationManagerTest` and both `UpdateCfgCmdTest` classes pass. The bug was found on a lab build of main. A cluster-scoped `drs.algorithm` update answered with the global value, while `listConfigurations` with the same `clusterid` showed the new one. The fix hasn't been run in the lab yet. #### How did you try to break this feature and the system with this change? - Encrypted (Hidden or Secure) settings: `ConfigurationVO.setValue()` encrypts and `getValue()` decrypts, and `UpdateCfgCmd` encrypts the value again for the response, as before. - Boolean settings: the returned value is the lowercased one that was stored. - Implicit scope for a domain admin or a user calling without a scope id: they now get the value they set in their domain or account, not the global one. - The configuration DAO has no entity cache, so changing the value on the returned object can't leak into other lookups. -- 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]
