Open Stack

thanks for the quick reply :)


On Mon, Apr 14, 2014 at 9:23 PM, Julien Danjou <julien at danjou.info> wrote:

> On Mon, Apr 14 2014, ZhiQiang Fan wrote:
>
> > Hi, developers,
> >
> > For fixing bug https://launchpad.net/bugs/1304886, I uploaded a patch
> > https://review.openstack.org/#/c/86501/, when review this patch, there
> are
> > two different kinds of opinions, I don't know which is the better choice,
> > so I ask for help here.
> >
> > The patch aims at disallow user specify duplicate alarm ids in
> combination
> > rule to reduce unnecessary alarm evaluate. We can avoid such input in two
> > ways:
> >
> > * reject user's request with 400, so force user to provide unique list
> > * accept such request but remove duplicate ids for the user
> >
> > the problem is that
> > * the server side actually has no error, it just considers the efficiency
> > problem (and the efficiency improvement is tiny), so reject the request
> > seems a bit rude
> > * the user provide a bad request but we accept, which will cause the user
> > think he is doing a right thing, although he can check the return result
> > and find something different, but from my experience, I usually only
> check
> > response status code, and will not check each attribute carefully.
> >
> > here is an existent example of accept such problematical request which
> > provided by Ildiko Vancsa:
> >
> https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904
> > or search 'def statistic' in that file if LOC is changed
> >
> > can you provide your opinion, or directly review that patch please?
>
> "Be conservative in what you do, be liberal in what you accept from
> others"
>
> So I would tend to convert the list to a set and not raise any error. If
> the user wants to have extra verification, it can compare what it sent
> to what it got in response.
>
> --
> Julien Danjou
> ;; Free Software hacker
> ;; http://julien.danjou.info
>



-- 
blog: zqfan.github.com
git: github.com/zqfan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/c7a19b08/attachment.html>