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

Reply via email to