ok, so we might decide that the best way forward is to always create changes related to this on the oldest branch possible.
On Tue, Jun 30, 2026 at 8:52 AM Abhishek Kumar <[email protected]> wrote: > > New Exception constructor is optional only. > I think the conflicts should only be there when some change is made in > the error messages which are already migrated. > > On Mon, 29 Jun 2026 at 14:10, Daan Hoogland <[email protected]> wrote: > > > > good point, > > > > On Mon, Jun 29, 2026 at 10:05 AM Abhishek Kumar <[email protected]> wrote: > > > > > > Thanks Daan. > > > > > > Moving to main/4.24 is not a problem. Though I've some changes in the > > > draft to use the new exception creation structure for VM-related > > > operations (mainly in classes: UserVmManagerImpl, > > > UnmanagedVMsManagerImpl, VirtualMachineManagerImpl). > > > With about 700 occurrences, I'm concerned they will cause regular > > > merge conflicts until the 4.20/4.22 EOL. > > > I'll move the changes to target main branch for now and see how it goes. > > > > maybe we can split the PR into the structural bit and the utility, Or > > make the use of the new Exception constructor optional? > > > > > > > > Regards, > > > Abhishek > > > > > > On Fri, 26 Jun 2026 at 13:37, Daan Hoogland <[email protected]> > > > wrote: > > > > > > > > hey Abhishek, > > > > not much reaction yet. I like the idea and think, as this is out of > > > > scope for the initial work, we should plan to convert error reporting > > > > after this is in. > > > > one remark. Your PR is targeting 22, is 24 more in order? > > > > > > > > On Wed, Jun 17, 2026 at 8:30 AM Abhishek Kumar <[email protected]> > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > I would like to seek feedback from the community on a framework-level > > > > > improvement around API error handling, consistency, customization, and > > > > > localization in CloudStack. > > > > > > > > > > The goal of this effort is to provide a more structured and consistent > > > > > approach to error reporting while maintaining backward compatibility > > > > > with > > > > > existing API clients. The proposal introduces stable error message > > > > > keys, > > > > > structured metadata, customizable message templates, and support for > > > > > localized and role-aware error messages. > > > > > > > > > > The design proposal is available here: > > > > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Error+Message+Consistency%2C+Customization%2C+and+Localization+Framework > > > > > > > > > > A reference implementation is available in the following PR: > > > > > > > > > > https://github.com/apache/cloudstack/pull/12336 > > > > > > > > > > Given that this is a framework-level change that could influence how > > > > > errors > > > > > are surfaced across CloudStack APIs going forward, I would appreciate > > > > > feedback on the overall design and architecture before proceeding > > > > > further. > > > > > > > > > > Comments, suggestions, concerns, or alternative approaches are all > > > > > welcome. > > > > > > > > > > Thanks, > > > > > Abhishek > > > > > > > > > > > > > > > > -- > > > > Daan > > > > > > > > -- > > Daan -- Daan
