mgr/dashboard_v2: Add RBD create functionality #20751

s0nea · 2018-03-06T16:02:13Z

This pull request adds a basic RBD create functionality to the REST API. It enables
the POST request of the http://< host >:< port >/api/rbd API endpoint.

The commit adds also related tests.

Signed-off-by: Tatjana Dehler tdehler@suse.com

jcsp · 2018-03-06T16:18:26Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+            self.rbd = rbd.RBD()
+
+        # Get input values
+        size = data.get('size', 4 * 1024 ** 3)


I'm not sure it makes sense to have a default size for RBD images on the backend: shouldn't the creator always have an idea of how big they want their image?

This code is inspired by the related openATTIC RBD model: https://github.com/openattic/openattic/blob/master/backend/ceph/models.py#L806
There we defined a default value. But I agree, we can remove it.

I'd also vote for making size mandatory here.

rjfd · 2018-03-06T16:28:14Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+
+        # Set features
+        feature_bitmask = self._format_features(features) if len(features) > 0 \
+            else 61  # FIXME: hardcoded int


please remove this hardcoded value. If the user does not choose any feature then pass feature_bitmask = None, and librbd will take care of setting the default image features.

Yes, will do

rjfd · 2018-03-06T16:31:39Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+
+        # Get input values
+        size = data.get('size', 4 * 1024 ** 3)
+        obj_size = data.get('obj_size', 2 ** 22)


please don't set a default value to obj_size and let librbd python binding take care of that. If obj_size is not specified then order = None.

ricardoasmarques

Define a response format that can be used by the frontend.

ricardoasmarques · 2018-03-07T00:44:48Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+            else 61  # FIXME: hardcoded int
+
+        ioctx = mgr.rados.open_ioctx(data['pool_name'])
+        self.rbd.create(ioctx, data['name'], size, order=order, old_format=False,


IMO, instead of returning empty responses, we should return responses that contains useful information that can be used to increase the front-end usability.

What about this?
{ success: true }
and
{ success: false, message: "Image myrbd already exists in pool mypool", }

Note: This example can be implemented by catching the ImageExists exception.

If the backend does not catch this kind of exceptions, the best that frontend can do is displaying a generic error message that results from the "500 - Internal Server Error", without useful information to the user.

Yes, I agree with you.

This is a kind of input validation right? - Validating if the submitted image name is usable. I talked to @sebastian-philipp about that and he told me that we will possible do the input validation on another layer and not in the Python code. That's why I left it out in this pull request. If we all agree on doing it on the API layer, I will be happy to add it.
Or is it not that kind of input validation you meant @sebastian-philipp?

If rbd creation fails, it will raise an exception which generates a standard JSON error with a status code != 201, thus { success: true } or success: false is not necessary here.

But I agree that we should return something useful. What about serializing the new RBD?

I think we should differentiate between general python exceptions, that may occur due to a bug, and RBD exceptions that are thrown by the RBD.create function.

For python exceptions, those are already handled by our infrastructure that outputs a JSON with the traceback and status code 500.
For RBD, we should always return status code 200, and a JSON message similar to what @ricardoasmarques is proposing, where we specify a success flag, which will be true if the image was created, and false otherwise. In case of an RBD exception there are two approaches to communicate the error to the frontend:

a) return a string message with information about the error;
b) return an integer code (available in all RBD exceptions) that describes the error

I'm in favor of the second approach (b) because that way the frontend can actually generate a string message that can be translated into several languages.

Great, using an integer code (approach b) looks good.

We should make use of HTTP status codes:

Code Meaning

201 Created

400 Validation Error

500 Internal Server Error

there is no need for any additional status Boolean in the response.

Our JSON exception handler already provides a standard way to generate error responses and we should make use of it as much as possible. Instead of defining new ways to return non-successful replies. This way, we only have only one JSON structure for errors.

@sebastian-philipp I don't think an RBD create error fits in one of those three status code.
If we get an error because we are trying to create an image that already exists, it's not a validation error, nor an internal server error.

@rjfd I thought this would be a validation error, because the given image name is wrong (already in use), so status 400 - Bad Request? And yes, I agree, we should provide more information there, like "Can't create image 'xy' because it already exists."

@rjfd @sebastian-philipp while http error codes can be useful to relay what is happening on the backend side, only returning those codes results in the loss of much contextual knowledge those errors are unable to properly relay to the frontend.

Given the rbd-related exceptions are documented, it makes sense to catch them, handle them and relay their meaning in a meaningful way as a result. Return them with an http error code, sure, but don't simply ignore this semantic knowledge that will make it way easier for the front-end to properly relay the problem encountered to the user.

And if we presume this is the way, it makes sense to me to ensure that all operations follow a base format when returning to the user. E.g., a Json with a "success" field, being set to true or false, makes sense. Something down the lines of
{ status: { success: true, msg: "great success!", error: 0 }, wtv: "else", ... }

And similarly for an error message. Then use the appropriate http code to convey what's happening.

rjfd · 2018-03-07T17:01:30Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+                            features=feature_bitmask, stripe_unit=stripe_unit,
+                            stripe_count=stripe_count, data_pool=data_pool)
+            return {'success': True, 'detail': 'Image {!s} created successfully'.format(name)}
+        except (InvalidArgument, ImageExists) as e:


Why are you catching just these two exceptions?
I would catch rbd.OSError, which is the super class of rbd specific exceptions. Then I would also return to the frontend the rbd.OSError.errno integer code, so that we can cope with translation of error messages in the frontend.

Yes, I agree.

sebastian-philipp · 2018-03-07T20:10:01Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+            self.rbd.create(ioctx, name, size, order=order, old_format=False,
+                            features=feature_bitmask, stripe_unit=stripe_unit,
+                            stripe_count=stripe_count, data_pool=data_pool)
+            return {'success': True, 'detail': 'Image {!s} created successfully'.format(name)}


Why do you return a Boolean that is equal to cherrypy.response.status == 201?

That message should be generated in the frontend, cause translation is easier done there.

I've already been thru the mistake of adding such a superfluous success-boolean to an API with later regretting it again. We really shouldn't repeat this mistake.

Trust the HTTP status code. It's already well established. There is no need to invent something new here.

If we need to return the name here, then why not instead return the whole newly generated RBD instead?

I'm fine with using HTTP status codes if we can have a different status code for each of the following cases:

success (e.g., image created)

validation error (e.g., image_name was not provided)

Ceph library operation exception (e.g., every rbd.OSError)

unexpected exception (e.g., bug in the code)

But I still have a concern about using HTTP status codes to communicate the result, or error, of a Ceph library operation, when we start executing these operations asynchronously.

I'm preparing a PR where the above RBD create operation is executed asynchronously, and then the result of the operation will be communicated within a wrapper object that describes the async operation.
At the time that the rbd.create function returns, it is no longer possible to set the HTTP status code, and the asynchronous execution infrastructure will just return the return value of the async operation, or in case of an exception is raised, it stores the exception object.

Therefore, AFAICT we will not be able to use HTTP status codes for communicating operations results. So do you think it's worth the effort of using HTTP status codes in this PR since we will be changing that in a near future?

If we need to return the name here, then why not instead return the whole newly generated RBD instead?

What do you mean by "newly generated RBD"? Are you suggesting that we perform another rbd library call to fetch the image details and return it to the frontend? or just re-use the parameter values that we received from the frontend?

I would suggest the following status codes:

success (e.g., image created)
-> status 201?
validation error (e.g., image_name was not provided)
-> status 400? - because it's an error initiated by the user
Ceph library operation exception (e.g., every rbd.OSError)
-> status 500? - because it's an error caused by the server
unexpected exception (e.g., bug in the code)
-> status 500? - because it's an error caused by the server as well

@rjfd:

I'm preparing a PR where the above RBD create operation is executed asynchronously, and
then the result of the operation will be communicated within a wrapper object that describes the
async operation.

Does that mean this pull request will become unnecessary anyway?

Does that mean this pull request will become unnecessary anyway?

No, I'm using the code you've written for the RBD creation to test the asynchronous execution infrastructure.

sebastian-philipp · 2018-03-07T20:14:43Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+                            stripe_count=stripe_count, data_pool=data_pool)
+            return {'success': True, 'detail': 'Image {!s} created successfully'.format(name)}
+        except (InvalidArgument, ImageExists) as e:
+            return {'success': False, 'detail': str(e)}


You're returning here with a status code 201 Created

just re-raising the exception would (at least for now) provide the same information to the frontend.

(at least for now)

Because, our dashboard_v2.tools.json_error_page handler is not getting the Exception. Instead, it's getting str(e) and the traceback. IMO, some interestingly bad API design.

So, we should add an exception handler to RESTController.default instead, that knows what to do with Ceph exceptions.

doing something like this:

... except SomeException as e: return {'detail': str(e)}

is so generic, it shouldn't be implemented here. And in fact, it's duplicating our json_error_page.

I don't think it's good to start generalize at the first time we see this code pattern. Let's wait for more code to be in to understand how we should refactor the error handling.

ricardoasmarques

lgtm

rjfd

Please add a test for the case where you are trying to create an RBD image with the same name as an existing image.

rjfd · 2018-03-09T07:18:25Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+
+        # TODO: change to GET the specific RBD instead of the list as soon as it is available?
+        ret = self._get('/api/rbd/rbd')
+        rbd_names = [rbd['name'] for rbd in ret['value'] if 'name' in rbd]


why is the if 'name' in rbd test necessary? are you expecting to received an dictionary without the name key in the list of rbd images result?

I just wanted to be sure that the key I want to access is really there. But yes, it makes sense that the test will fail if the field has been renamed for example.

rjfd · 2018-03-09T07:19:16Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+        self._rbd_cmd(['rm', 'rbd/test_rbd'])
+
+    @authenticate
+    def test_create_data_pool(self):


please rename the test function to test_create_rbd_in_data_pool

rjfd · 2018-03-09T07:19:59Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+
+        # TODO: possibly change to GET the specific RBD (see above)
+        ret = self._get('/api/rbd/rbd')
+        rbd_names = [rbd['name'] for rbd in ret['value'] if 'name' in rbd]


same comment here as above

rjfd · 2018-03-09T07:25:35Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+        self.assertStatus(200)
+        self.assertIn('test_rbd', rbd_names)
+
+        self._rbd_cmd(['rm', 'rbd/test_rbd'])


Why are you removing the image inside the test? the images will be removed when you delete the pools in tearDownClass method.

Just to clean it up where it was created. I will remove this line.

rjfd · 2018-03-09T07:26:19Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+                'name': 'test_rbd_data_pool',
+                'size': 10240,
+                'data_pool': 'data_pool'}
+        self._post('/api/rbd', data)


you should also validate the result JSON

rjfd · 2018-03-09T07:26:35Z

qa/tasks/mgr/dashboard_v2/test_rbd.py

+        data = {'pool_name': 'rbd',
+                'name': 'test_rbd',
+                'size': 10240}
+        self._post('/api/rbd', data)


validate the result JSON

sebastian-philipp · 2018-03-09T11:45:10Z

src/pybind/mgr/dashboard_v2/controllers/rbd.py

+        True
+        """
+        if not features or not isinstance(features, list):
+            logger.warning("Given RBD features list is empty or None.")


Either you expect _format_features to get None as features, then you should not log this at all, as it is already tested.

Or, I would not expect this funciton to silently returns None, and instead raises an exception.

Okay, will do.

rjfd · 2018-03-14T07:22:54Z

QA tests look good:
http://pulpito.ceph.com/rdias-2018-03-13_16:52:27-rados:mgr-wip-rdias-testing-distro-basic-mira/

The failed job is due to the impossibility of create an EC pool with overwrittes flag in non-bluestore cluster. We should fix the RBD test to avoid running that particular case when in the presence of a non-bluestore cluster.

In order to merge this PR we need at least to skip the test that uses the EC pool for now. @s0nea could you add @unittest.skip("requires bluestore cluster") to the test_create_rbd_in_data_pool function, and move the EC pool creation/deletion code from setUpClass / tearDownClass to the test_create_rbd_in_data_pool?

s0nea · 2018-03-14T07:46:35Z

@rjfd thank you for testing :) I'm going to adapt it.

This commit adds a basic RBD create functionality to the REST API. It enables the POST request of the http://<host>:<port>/api/rbd API endpoint. The commit adds also related tests. Signed-off-by: Tatjana Dehler <tdehler@suse.com>

rjfd

lgtm

mgr/dashboard_v2: Add RBD create functionality to the Python backend Reviewed-by: Ricardo Dias <rdias@suse.com> Reviewed-by: Sebastian Wagner <sebastian.wagner@suse.com> Reviewed-by: John Spray <john.spray@redhat.com> Reviewed-by: Ricardo Marques <rimarques@suse.com> (cherry picked from commit 78022e1) Signed-off-by: Ernesto Puerta <epuertat@redhat.com>

s0nea added feature dashboard labels Mar 6, 2018

s0nea requested review from jcsp, votdev, sebastian-philipp, p-se, ricardoasmarques and rjfd March 6, 2018 16:02

s0nea added the mgr label Mar 6, 2018

s0nea mentioned this pull request Mar 6, 2018

[WIP,DNM] mgr/dashboard_v2: Add RBD create functionality openattic/ceph#152

Closed

jcsp reviewed Mar 6, 2018

View reviewed changes

rjfd suggested changes Mar 6, 2018

View reviewed changes

ricardoasmarques suggested changes Mar 7, 2018

View reviewed changes

s0nea force-pushed the wip-mgr-dashboard_rbd_add branch 2 times, most recently from 21bcf89 to 4f9be36 Compare March 7, 2018 15:53

rjfd suggested changes Mar 7, 2018

View reviewed changes

sebastian-philipp suggested changes Mar 7, 2018

View reviewed changes

s0nea force-pushed the wip-mgr-dashboard_rbd_add branch from 4f9be36 to fcf3d9c Compare March 8, 2018 12:11

ricardoasmarques approved these changes Mar 8, 2018

View reviewed changes

rjfd suggested changes Mar 9, 2018

View reviewed changes

sebastian-philipp suggested changes Mar 9, 2018

View reviewed changes

s0nea force-pushed the wip-mgr-dashboard_rbd_add branch from fcf3d9c to 8e9570f Compare March 12, 2018 16:07

ricardoasmarques mentioned this pull request Mar 12, 2018

[DNM] mgr/dashboard: Add RBD create functionality (frontend) #20852

Closed

rjfd added needs-qa wip-rdias-testing and removed needs-qa labels Mar 13, 2018

sebastian-philipp approved these changes Mar 14, 2018

View reviewed changes

mgr/dashboard: Add RBD create functionality

5056cba

This commit adds a basic RBD create functionality to the REST API. It enables the POST request of the http://<host>:<port>/api/rbd API endpoint. The commit adds also related tests. Signed-off-by: Tatjana Dehler <tdehler@suse.com>

s0nea force-pushed the wip-mgr-dashboard_rbd_add branch from 8e9570f to 5056cba Compare March 14, 2018 09:39

rjfd approved these changes Mar 14, 2018

View reviewed changes

rjfd removed the wip-rdias-testing label Mar 14, 2018

LenzGr merged commit 78022e1 into ceph:master Mar 14, 2018

s0nea deleted the wip-mgr-dashboard_rbd_add branch October 12, 2018 06:29

mgr/dashboard_v2: Add RBD create functionality #20751

mgr/dashboard_v2: Add RBD create functionality #20751

Conversation

s0nea commented Mar 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ricardoasmarques left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s0nea Mar 7, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s0nea Mar 7, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sebastian-philipp Mar 7, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sebastian-philipp Mar 7, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sebastian-philipp Mar 7, 2018 • edited

Choose a reason for hiding this comment

sebastian-philipp Mar 7, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ricardoasmarques left a comment

Choose a reason for hiding this comment

rjfd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rjfd commented Mar 14, 2018

s0nea commented Mar 14, 2018

rjfd left a comment

Choose a reason for hiding this comment

s0nea Mar 7, 2018 •

edited

s0nea Mar 7, 2018 •

edited

sebastian-philipp Mar 7, 2018 •

edited

sebastian-philipp Mar 7, 2018 •

edited

sebastian-philipp Mar 7, 2018 •

edited

sebastian-philipp Mar 7, 2018 •

edited