fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00495
Re: Help in understanding of separated handler for node assignment
Disagree,
>> doesn't think this is a necessary patch
It's necessary because it fixes user's problem.
>> necessity of future use of it in UI
We need such handlers which implement business logic to make our api
simpler for clients.
Right now we have hardcoded assignment logic on each client, as result we
already have
several bugs related to nodes assignment.
Also we are implicitly trying to guess what user was trying to do, for
example [0] if user set cluster_id to None we also reset pending_roles.
It's not obvious side effect from api user point of view.
[0]
https://github.com/stackforge/fuel-web/blob/stable/4.0/nailgun/nailgun/api/handlers/node.py#L96
On Mon, Feb 17, 2014 at 1:40 PM, Nikolay Markov <nmarkov@xxxxxxxxxxxx>wrote:
> Actually, I am the one who doesn't think this is a necessary patch,
> and I also really doubt the necessity of future use of it in UI.
>
> As for me, our priority should be making API as transparent and easy
> as possible without making separate handlers for plugging holes of our
> own code gaps. So, I look at this handler as a temporary solution for
> this release, until we move all logic on assignment to and object and
> then it will be accessible through existing handlers, not through an
> extra one.
>
> That's just my opinion, no offence.
>
> On Mon, Feb 17, 2014 at 1:06 PM, Mike Scherbakov
> <mscherbakov@xxxxxxxxxxxx> wrote:
> > Thanks for clarification. Let's see if it can be done before code freeze.
> >
> >
> > On Mon, Feb 17, 2014 at 12:57 PM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:
> >>
> >> Hi Mike,
> >>
> >> Yes, I think we need to merge it in 4.1 release, I see several reasons
> for
> >> that:
> >>
> >> 1. node deletion (unassignment) via CLI is broken
> >> 2. in the current release this new handler will use only CLI, in future
> >> release UI will be able to switch on this api too for node
> >> assignment\unassignment
> >> 3. this patch is not so huge and it doesn't change current business
> logic
> >>
> >> Thanks,
> >>
> >>
> >> On Mon, Feb 17, 2014 at 12:45 PM, Mike Scherbakov
> >> <mscherbakov@xxxxxxxxxxxx> wrote:
> >>>
> >>> Thanks Alex.
> >>> Do we really want to land this in 4.1? We are too close to the release
> >>> date to accept new things or such kind of changes, and I would
> postpone it
> >>> to 5.0 if we have nothing heavy dependent on it..
> >>>
> >>> What's your opinion, Fuelers?
> >>>
> >>>
> >>> On Fri, Feb 14, 2014 at 3:31 PM, Alexander Notchenko
> >>> <anotchenko@xxxxxxxxxxxx> wrote:
> >>>>
> >>>> I updated description of BP.
> >>>>
> https://blueprints.launchpad.net/fuel/+spec/create-separate-handler-for-node-assignment
> >>>> Write me if there will be any other questions.
> >>>>
> >>>>
> >>>> On Fri, Feb 14, 2014 at 12:50 AM, Mike Scherbakov
> >>>> <mscherbakov@xxxxxxxxxxxx> wrote:
> >>>>>
> >>>>> Folks,
> >>>>> I'm running through blueprints, and can't quite get what is this
> >>>>> blueprint about:
> >>>>>
> https://blueprints.launchpad.net/fuel/+spec/create-separate-handler-for-node-assignment
> >>>>>
> >>>>> Alex, you are assigned to it and there is even patchset on review..
> can
> >>>>> you give please insight on it - why do we need separated handler?
> >>>>> Unfortunately blueprint description was quite unhelpful for me to
> get the
> >>>>> idea.
> >>>>>
> >>>>> Thanks,
> >>>>> --
> >>>>> Mike Scherbakov
> >>>>> #mihgen
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Mike Scherbakov
> >>> #mihgen
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >
> >
> >
> > --
> > Mike Scherbakov
> > #mihgen
> >
> > --
> > 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
>
References