Hi Daan, Thanks for the feedback. I also discussed this with some colleagues, and one idea is to target this to the 4.22 branch, as 4.20.x will EOL in 6 months. I don't have a strong preference, but 4.22 seems a good middle ground. With the current scenario, I'm open to target the changes to either 4.22 or main or 4.20 branch
Regards, Abhishek On Tue, 30 Jun 2026 at 13:59, Daan Hoogland <[email protected]> wrote: > > 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
