fuel-dev team mailing list archive

[Nikolay Markov <nmarkov@xxxxxxxxxxxx>]

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 <rmoe@xxxxxxxxxxxx> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Best regards,
Nick Markov