Bug 1330948 - Allowed/denied characters for cluster, pool, device name and other user editable fields
Summary: Allowed/denied characters for cluster, pool, device name and other user edita...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Storage Console
Classification: Red Hat
Component: UI
Version: 2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3
Assignee: sankarshan
QA Contact: sds-qe-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-27 11:06 UTC by Daniel Horák
Modified: 2017-03-23 04:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-23 04:12:14 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Daniel Horák 2016-04-27 11:06:29 UTC
Description of problem:
  Creation of cluster, pool or device fails if name contains some "special" character like: space or character with diacritics (e.g. ěščřžýáíéůú).

Version-Release number of selected component (if applicable):
  rhscon-ui-0.0.26-1.el7.noarch
  rhscon-ceph-0.0.9-1.el7.x86_64
  rhscon-core-0.0.12-1.el7.x86_64
  rhscon-agent-0.0.4-1.el7.noarch  

How reproducible:
  100%

Steps to Reproduce:
1. Prepare few servers for USM Ceph cluster accordingly to the documentation.
2. Try to create cluster with name containing some of the problematic character, e.g.:
    Test Cluster A
    ěščřžýáíé
    etc.
3. Create cluster with correct name.
4. Try to create storage pool/device similarly as cluster in step 2.

Actual results:
  The cluster/pool/device creation fails on some point of the creation process.

Expected results:
  The web UI/REST API doesn't allow submitting the request with problematic characters in some input field.

Additional info:
  Which characters are allowed in the form fields around the skyring web UI/REST API fields?
  Please consider this topic also for other places - e.g. user login name.

Comment 2 Nishanth Thomas 2016-04-27 11:32:18 UTC
Have you tried this from the REST browser or UI?
ideally the validations are supposed to be at UI level and the REST API(core) will not do any validations.

Comment 4 Daniel Horák 2016-04-27 12:43:09 UTC
I've tried it via web UI.

I think/agree, that there might be some limitation for the names (because for example cluster name is used also for the ceph configuration file name), but I think it should be covered/validated on both layers - web UI and also in REST API.

Comment 5 Nishanth Thomas 2016-05-14 13:39:14 UTC
I doubt we have the bandwidth to take this up for the current release, a good candidate to move to nect release

Comment 8 Nishanth Thomas 2016-06-03 08:04:55 UTC
Yes I agree, probably we will try to incorporate the straight forward cases if we have time. setting the severity to low.

In any case this need to be documented and we should provide set of valid names for cluster/pools etc.

Comment 9 Nishanth Thomas 2016-06-17 10:46:07 UTC
Per bug scrub meeting, this is low priority, moving to 3.0

Comment 11 Martin Bukatovic 2016-07-04 15:41:16 UTC
Looking at ceph documentation[1], cluster name should be "simple string without
spaces". The full description of cluster name follows:

> Cluster Name: Ceph clusters have a cluster name, which is a simple string
> without spaces. The default cluster name is ceph, but you may specify a
> different cluster name. Overriding the default cluster name is especially
> useful when you are working with multiple clusters and you need to clearly
> understand which cluster your are working with.
> 
> For example, when you run multiple clusters in a federated architecture, the
> cluster name (e.g., us-west, us-east) identifies the cluster for the current
> CLI session. Note: To identify the cluster name on the command line interface,
> specify the a Ceph configuration file with the cluster name (e.g., ceph.conf,
> us-west.conf, us-east.conf, etc.). Also see CLI usage (ceph --cluster
> {cluster-name}).

So if RHSC 2.0 allows a user to create a cluster with space in it's name, it
blatantly goes agains ceph expectations. which means that RHSC 2.0 would allow
admin to create a ceph cluster in unsupported/untested configuration.

Based on this fact, I'm asking to reevaluate.

[1] http://docs.ceph.com/docs/master/install/manual-deployment/


Note You need to log in before you can comment on or make changes to this bug.