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
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
