Name validations for compute resources

[Rohan]

There is no consistent validation for the 'name' parameter across compute resources. The following characters need to be validated in the input:

1. One more whitespaces (like ' ' or ' ') -
2. Leading or trailing whitespaces (like ' test123 ')

Currently flavor name, volume name, role name, group name, security group name and keypair name accept input in each of the two cases (no validation).

Adding the two cases above to name parameter validation would be useful.
It makes sense to move this validation code to a common utility that can be used across all Create resource methods.
Although the 'name' is not as significant the resource's ID, it does act as a label for the resource and should be validated properly.

For example, from the dasbhboard, a role with a blank name, i.e single whitespace string like ' ' can be created. This get's stored in the keystone db as NULL and appears in the dashboard roles drop down during Create User as None. This behavior should be fixed.

Refer: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3086 _validate_new_keypair() can be moved to a common utility to provide 'name' field validations.

[Sumanth Nagadavalli (sumanth-nagadavalli)]

I think we should look at its bigger picture. I want to ask the following questions,

1. Should we also look into the extra spaces in other resources?

2. What are the other restrictions we should put on a resource's name, apart from extra spaces?

3. Should we define a guideline for names, ids etc while creating resources?

[Rohan (kanaderohan)]

I agree that there is no guideline stating acceptable names/ids while creating/updating resources.

This guideline should be implemented in a separate blueprint itself.

[Rohit Karajgi (rohitk)]

Added Keystone as an affected project since Blank role names (like (' ')are accepted and stored in database as NULL,
and show on the dashboard drop down list as "None". Such role names should be validated.

[Xiaoxi Chen (xiaoxi-chen)]

Could we move this validation to OSLO ?

[Dolph Mathews (dolph)]

UTR against keystone directly (sounds like a bug between horizon and keystoneclient?). Attempting to create a role with a single space as the name behaves as expected (the name is stored correctly in the sql driver, not as a null value).

POST http://localhost:35357/v3/roles
{"role": {"name": " "}}

{
  "role": {
    "id": "9cf9fc40486947539a10400e638b9e65",
    "links": {
      "self": "http://localhost:5000/v3/roles/9cf9fc40486947539a10400e638b9e65"
    },
    "name": " "
  }
}

GET http://localhost:35357/v3/roles

{
  "roles": [
    {
      "id": "9cf9fc40486947539a10400e638b9e65",
      "links": {
        "self": "http://localhost:5000/v3/roles/9cf9fc40486947539a10400e638b9e65"
      },
      "name": " "
    }
  ],
  "links": {
    "self": "http://localhost:5000/v3/roles",
    "next": null,
    "previous": null
  }
}

[Rohit Karajgi (rohitk)]

Hi Dolph,

Should whitespace only role names be allowed? Please see attached horizon screenshot where this could be confusing to a user.

[Rohit Karajgi (rohitk)]

I've compiled a matrix showing the impact across various Create API for three categories of invalid input here:
https://docs.google.com/file/d/0BwufSlaYow2GaUx5U0lFQVZ0czg/edit?usp=sharing.

In my opinion, for the "name" field, a common validation logic should be applied to all the above resources.
So all the cases where the Invalid input is Accepted, should be correctly validated and disallowed.

[Rohit Karajgi (rohitk)]

Ideally, a resource's name should be restricted by the following validations:
* Length is >0 and <=255
* Characters fall within the set [a-zA-Z0-9_.- ]
* No leading and/or trailing white spaces

[Dolph Mathews (dolph)]

> Should whitespace only role names be allowed?

> Characters fall within the set [a-zA-Z0-9_.- ]

I'm opposed to mandating that services arbitrarily constrain user-facing labels to a particular character set, etc, beyond what is absolutely necessary (e.g. maximum length as dictated by the persistence mechanism in use by a particular deployment).

[Rohit Karajgi (rohitk)]

Updated doc link (from comment #7) to https://docs.google.com/file/d/0BwufSlaYow2GOGNwdm5ubEc0M2s

[Rohit Karajgi (rohitk)]

https://docs.google.com/file/d/0BwufSlaYow2GUUZJVlJYVGM2VVU/edit?usp=sharing is updated with some more clarity.

> I'm opposed to mandating that services arbitrarily constrain user-facing labels to a particular character set, etc, beyond what is absolutely necessary

I agree that user facing labels need not be overly validated, however what I am concerned about is the standardization of validation across API.
For example, in Keystone, referring to the above spreadsheet, create tenant and create user reject input that is just one or more white spaces, where we can create a group or a role with such input.
Similarly, leading or trailing white spaces are stripped from the input in the case of create user and tenant, but not so for group and role.
Such deviations could be rectified with some minor fixes. Thoughts?

[Ben Nemec (bnemec)]

IMHO this is not a bug in Oslo, but a feature request. Please open a blueprint against Oslo to track this work (I do agree that common code to do validation is a good idea) Obviously there is some significant discussion needed first, so I would also suggest sending something to openstack-dev on this topic.

Thanks.

[Rohit Karajgi (rohitk)]

Most of the thoughts seem to be in the direction of having the validations done by Oslo,
I have created a blueprint to track this feature: https://blueprints.launchpad.net/oslo/+spec/api-validation-utility.
Implementation is already in good progress and there should be a patch for Oslo soon.

[Dolph Mathews (dolph)]

Unassigning due to inactivity.

[Sean Dague (sdague)]

There are ongoing discussions on the mailing list right now about this. I think it's not a bug per say (actually current Nova behavior is what's asked for).

[Sean McGinnis (sean-mcginnis)]

Closing stale bug. If this is still an issue please reopen.

[Steve Martinelli (stevemar)]

marking keystone as invalid since we have a duplicate bug here: 1519580 and we now use JSON schema validation for our v3 calls