Hello Ryan, We're going towards moving all business logic from handlers to so-called "objects" or "REST objects" like they did it in Ironic. So, handlers are now becoming just simple access points and implement common logic for almost all cases. All they do is calling some object methods.
This is a part of refactoring which leads to three things: * Moving towards Oslo (and become closer to OpenStack community this way) * Get rid of "spaghetti" business logic and incapsulate it inside objects (especially DB actions). * Stabilizing our REST API - all handlers should inherit from a basic ones and just use custom validators and, for example, custom update() method of a corresponding object. This is actually a long and difficult process, so we're trying to do it step by step. That's why there are no particular bugs or blueprints linked to these PRs, however they exist on Launchpad and are included into our plans for 5.0. For example, https://blueprints.launchpad.net/fuel/+spec/nailgun-objects-flow . On Tue, Mar 18, 2014 at 3:29 AM, Ryan Moe <[email protected]> wrote: > I'm adding some new API handlers and came across the changes here: > https://review.openstack.org/#/c/66336/ and here: > https://review.openstack.org/#/c/72937/. These are fairly large changes that > were accompanied by a single line commit message and no link to a bug or > blueprint. > > What were the motivations behind these changes? How does this change the > process of adding new API handlers going forward? > > Thanks, > Ryan > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Best regards, Nick Markov -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
