Open Stack

On Tue, Jun 22, 2021 at 5:43 PM Stephen Finucane <stephenfin at redhat.com>
wrote:

> Hey,
>
> We have an interesting problem that I wanted to poll opinions on. In OSC
> 5.5.0,
> we closed most of the gaps between novaclient and openstackclient. As part
> of
> these changes, we introduced validation of a number of requests such as
> validating enum-style values. For example, [1][2][3]. This validation
> already
> occurs on the server side, but by adding it to the client side we prevent
> users
> sending invalid requests to the server in the first place and allow users
> to
> discover the correct API behaviour from the client rather than having to
> read
> the API docs or use trial and error.
>
> Now, an issue has been opened against OSC. Apparently someone has been
> relying
> on a bug in Nova to pass a different value to the API that what the schema
> should have allowed, and they are dismayed that the client no longer
> allows them
> to do this. They have asked [4][5] that we relax the client-side
> validation to
> allow them to continue relying on this bug. As you can probably tell from
> my
> comments, this seems to me to be an open and shut case: you shouldn't fork
> an
> OpenStack API and you shouldn't side-step validation. However, I wanted to
> see
> if anyone disagreed and thought there was merit in loose or no validation
> of API
> requests made via our clients.
>
> Let me know what you think,
> Stephen
>
> [1]
> https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1789-L1808
> [2]
> https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server.py#L1907-L1921
> [3]
> https://github.com/openstack/python-openstackclient/blob/5.5.0/openstackclient/compute/v2/server_group.py#L62-L67
> [4] https://storyboard.openstack.org/#!/story/2008975
> [5]
> https://github.com/openstack/python-openstackclient/commit/ab0b1fe885ee0a210a58008b631521025be7f3eb
>
>
> Hi all,

My quick two cents in perspective of what we have been doing in Glance for
multiple years already.

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.

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.

- Erno "jokke" Kuvaja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210623/2a91b174/attachment-0001.html>