<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 22, 2021 at 5:43 PM Stephen Finucane <<a href="mailto:stephenfin@redhat.com">stephenfin@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
We have an interesting problem that I wanted to poll opinions on. In OSC 5.5.0,<br>
we closed most of the gaps between novaclient and openstackclient. As part of<br>
these changes, we introduced validation of a number of requests such as<br>
validating enum-style values. For example, [1][2][3]. This validation already<br>
occurs on the server side, but by adding it to the client side we prevent users<br>
sending invalid requests to the server in the first place and allow users to<br>
discover the correct API behaviour from the client rather than having to read<br>
the API docs or use trial and error.<br>
<br>
Now, an issue has been opened against OSC. Apparently someone has been relying<br>
on a bug in Nova to pass a different value to the API that what the schema<br>
should have allowed, and they are dismayed that the client no longer allows them<br>
to do this. They have asked [4][5] that we relax the client-side validation to<br>
allow them to continue relying on this bug. As you can probably tell from my<br>
comments, this seems to me to be an open and shut case: you shouldn't fork an<br>
OpenStack API and you shouldn't side-step validation. However, I wanted to see<br>
if anyone disagreed and thought there was merit in loose or no validation of API<br>
requests made via our clients.<br>
<br>
Let me know what you think,<br>
Stephen<br>
<br>
[1] <a href="https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1789-L1808" rel="noreferrer" target="_blank">https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1789-L1808</a><br>
[2] <a href="https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1907-L1921" rel="noreferrer" target="_blank">https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1907-L1921</a><br>
[3] <a href="https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server_group.py#L62-L67" rel="noreferrer" target="_blank">https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server_group.py#L62-L67</a><br>
[4] <a href="https://storyboard.openstack.org/#!/story/2008975" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2008975</a><br>
[5] <a href="https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a210a58008b631521025be7f3eb" rel="noreferrer" target="_blank">https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a210a58008b631521025be7f3eb</a><br>
<br>
<br></blockquote><div>Hi all,</div><div><br></div><div>My quick two cents in perspective of what we have been doing in Glance for multiple years already.</div><div><br></div><div>Fail as early as possible. We do have checks on the API layer already way before we hit the code that would fail to recognize patterns we know would fail later on. We do extend this to the client as well. Specially as glanceclient may send multiple requests to the API for single user command we try to identify possible issues in advance. Good example of this is during image creation. If a user makes clent call that would result an active image but is missing, say either of the disk or container formats, we do know that activating said image would fail and we fail it to the user already on the client before sending a single request to the API. Makes it fast, we do not create image resources that would not get used in the case the user just reruns the same command with missing information and everyone wins.</div><div><br></div><div>We have been advocates of extending our "Fail early" attitude to the client for a very long time and I think it's a good practise.</div><div><br></div><div>- Erno "jokke" Kuvaja<br></div></div></div>