<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi, developers,<br><br></div>For fixing bug <a href="https://launchpad.net/bugs/1304886">https://launchpad.net/bugs/1304886</a>, I uploaded a patch <a href="https://review.openstack.org/#/c/86501/">https://review.openstack.org/#/c/86501/</a>, 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.<br>
<br></div>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:<br><br></div>* reject user's request with 400, so force user to provide unique list<br>
</div>* accept such request but remove duplicate ids for the user<br><br></div>the problem is that<br>* 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<br>
</div>* 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.<br>
<br></div>here is an existent example of accept such problematical request which provided by Ildiko Vancsa: <a href="https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904">https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904</a><br>
</div>or search 'def statistic' in that file if LOC is changed<br><br></div><div>can you provide your opinion, or directly review that patch please?<br><br></div>thanks<br><div><div><a href="https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py#L904"></a></div>
</div></div>