ceph-iscsi: add erasure pool support by xiubli · Pull Request #237 · ceph/ceph-iscsi

xiubli · 2021-06-21T09:06:52Z

Erasure coded pools do not support omap, will just store the data
in ec pool, and their metadata will be in 'rbd' replicated pool.

Signed-off-by: Xiubo Li xiubli@redhat.com

xiubli · 2021-06-25T02:54:57Z

@idryomov

All my tests worked well till now. Please review, thanks.

idryomov · 2021-06-27T19:08:45Z

+            if self.is_erasure_pool:
+                _pool = settings.config.pool
+                data_pool = self.pool
+            with cluster.open_ioctx(_pool) as ioctx:


I'm not sure doing it this way is a good idea. Constraining the metadata pool to SYS_SETTINGS.pool seems unnecessarily restrictive. Why not add an optional data_pool parameter to the create RPC, allowing the user to specify both pools?

Yeah, this also looks good to me.

idryomov · 2021-06-27T19:14:02Z

+        store_type = json.loads(data)[0]['osd_objectstore']
+        self.logger.debug(f"pool ({self.pool}) objectstore type is ({store_type})")
+        if store_type not in ['bluestore', 'filestore']:
+            self.logger.error("Only bluestore/filestore objectstores allowed for erasure pool")


This check is bogus because one can have a cluster with OSDs backed by different stores. Querying just one OSD isn't going to do it.

But then I don't understand the need to check osd_objectstore at all. Why ensuring that EC overwrites are enabled isn't enough?

This check is bogus because one can have a cluster with OSDs backed by different stores. Querying just one OSD isn't going to do it.

Okay.

But then I don't understand the need to check osd_objectstore at all. Why ensuring that EC overwrites are enabled isn't enough?

From https://docs.ceph.com/en/latest/rados/operations/erasure-code/#erasure-coding-with-overwrites, I think maybe we should only allow the bluestore ?

If my understanding is correct, it will only works well for bluestore ?

I don't think we should be trying to limit it beyond what is allowed by librbd. When creating an image with a separate data pool, librbd ensures that the specified pool supports overwrites.

The user wouldn't be able to set allow_ec_overwrites on a filestore-backed pool without also messing with mon_debug_no_require_bluestore_for_ec_overwrites. If they do that, they are on their own ;)

xiubli · 2021-07-26T05:56:33Z

Add one ecpool= option when creating the disk:

/> disks/ create image=block14 pool=datapool ecpool=ecpool size=1M

Without the ecpool= specified, it will use the pool= to save both metadata and data. Or it will use the pool= to save the metadata and use the ecpool= to save the data.

For the image with the ecpool= specified it will display the disks like: <replicated pool name>/<erasure pool name>/<image name>

[root@node01 ceph-iscsi]# gwcli ls
o- / ......................................................................................................................... [...]
  o- cluster ......................................................................................................... [Clusters: 1]
  | o- ceph .......................................................................................................... [HEALTH_WARN]
  |   o- pools .......................................................................................................... [Pools: 6]
  |   | o- cephfs.a.data ......................................................... [(x3), Commit: 0.00Y/29819642K (0%), Used: 0.00Y]
  |   | o- cephfs.a.meta ....................................................... [(x3), Commit: 0.00Y/29819642K (0%), Used: 134000b]
  |   | o- datapool ............................................................... [(x3), Commit: 3M/29819642K (0%), Used: 418943b]
  |   | o- device_health_metrics ................................................. [(x3), Commit: 0.00Y/29819642K (0%), Used: 0.00Y]
  |   | o- ecpool ................................................................. [(3+1), Commit: 0.00Y/59639284K (0%), Used: 24K]
  |   | o- rbd ................................................................. [(x3), Commit: 0.00Y/29819642K (0%), Used: 103304b]
  |   o- topology ................................................................................................ [OSDs: 3,MONs: 3]
  o- disks .......................................................................................................... [3M, Disks: 3]
  | o- datapool .................................................................................................... [datapool (3M)]
  |   o- block14 ............................................................................ [datapool/ecpool/block14 (Online, 1M)]
  |   o- block15 ................................................................................... [datapool/block15 (Online, 1M)]
  |   o- block16 ............................................................................ [datapool/ecpool/block16 (Online, 1M)]
  o- iscsi-targets ............................................................................... [DiscoveryAuth: None, Targets: 1]
    o- iqn.2003-01.com.redhat.iscsi-gw:ceph-gw ........................................................... [Auth: None, Gateways: 2]
      o- disks .......................................................................................................... [Disks: 3]
      | o- datapool/block15 ................................................................................ [Owner: node01, Lun: 0]
      | o- datapool/ecpool/block14 ......................................................................... [Owner: node02, Lun: 1]
      | o- datapool/ecpool/block16 ......................................................................... [Owner: node01, Lun: 2]
      o- gateways ............................................................................................ [Up: 2/2, Portals: 2]
      | o- node01 ............................................................................................ [172.16.219.128 (UP)]
      | o- node02 ............................................................................................ [172.16.219.138 (UP)]
      o- host-groups .................................................................................................. [Groups : 0]
      o- hosts ....................................................................................... [Auth: ACL_ENABLED, Hosts: 0]

idryomov · 2021-12-14T16:45:29Z

+  |   o- disk_1 ........................................................... [rbd/disk_1 (1G)]
+  |   o- disk_2 ........................................................... [rbd/disk_2 (2G)]
+  |   o- disk_3 ........................................................... [rbd/disk_3 (2G)]
+  |   o- disk_4 ........................................................ [rbd/ec/disk_4 (1G)]


This makes it look like ec is somehow a sub-pool of rbd. For displaying here, I think it would be better to do <metadata pool>+<data pool>, i.e.

mypool/myimg for a "normal" image

mymetapool+mydatapool/myimg for an image with a separate data pool

Sure, this looks better, I will update it.

idryomov · 2021-12-14T17:12:16Z

+curl --user admin:admin -d mode=create
+     -X PUT http://192.168.122.69:5000/api/ecdisksnap/rbd/ec/image/new1
+curl --user admin:admin
+     -X DELETE http://192.168.122.69:5000/api/ecdisksnap/rbd/ec/image/new1


I may be missing something about REST or flask specifically, but I don't understand the need for a parallel set of EC APIs (disk vs ecdisk and disksnap vs ecdisksnap). Why not just add an optional ecpool parameter? This would mimic the "rbd create" CLI (--datapool option).

Thinking more about this, I think we should avoid tying this to EC at all. The actual feature that is being surfaced is a separate data pool. Let's call the new parameter datapool and

if not present, create a "normal" image

if present, get the type of the pool

if replicated, create with --datapool=<datapool>

if EC, validate EC pool (bluestore && allow_ec_overwrites=true) and create with --datapool=<datapool>

Sounds good. Let me try this.

idryomov · 2021-12-14T17:42:10Z

+        bluestore = False
+        for _osd in json.loads(data):
+            store_type = _osd['osd_objectstore']
+            self.logger.debug(f"pool ({self.pool}) objectstore type is ({store_type})")


This is checking the objectstore type of the OSD, not the pool, so the log message is misleading.

Will fix it.

idryomov · 2021-12-14T17:43:47Z

+        if err:
+            self.logger.error(f"Cannot get allow_ec_overwrites from pool ({self.pool})")
+            return err
+        self.logger.debug(f"erasure pool ({self.pool}) allow_ec_overwrites is enabled")


The actual check seems to be missing. What if allow_ec_overwrites is disabled?

Sorry, I didn't get this, could you explain more ?

If the allow_ec_overwrites is disabled, it should abort the image creation should fail.

I don't see where the actual value returned by "ceph osd pool get POOL allow_ec_overwrites" is checked. It can be true or false but the code here doesn't seem to look at it. It only checks whether the command itself succeeds or not.

Okay, get it. Will fix it.

Signed-off-by: Xiubo Li <xiubli@redhat.com>

It will return 400 error code when a disk is not assigned to any target. Signed-off-by: Xiubo Li <xiubli@redhat.com>

idryomov · 2022-01-03T09:33:43Z

-  |   o- disk_5 ............................................................... [disk_5 (2G)]
+  |   o- disk_1 ........................................................... [rbd/disk_1 (1G)]
+  |   o- disk_2 ........................................................... [rbd/disk_2 (2G)]
+  |   o- disk_3 ........................................................... [rbd/disk_3 (2G)]


let's name the pool "rep" here (instead of "rbd")

idryomov · 2022-01-03T09:34:24Z

+  |   o- disk_1 ........................................................... [rbd/disk_1 (1G)]
+  |   o- disk_2 ........................................................... [rbd/disk_2 (2G)]
+  |   o- disk_3 ........................................................... [rbd/disk_3 (2G)]
+  |   o- disk_4 ........................................................ [rbd+ec/disk_4 (1G)]


... and then here it would be "rep+ec", highlighting the difference

Will do that.

idryomov · 2022-01-03T09:40:53Z

+store the metadata only.
+
+When creating a disk and disk snapshot, for rest api there has a litte different for erasure pool.
+Which is you need to use "<pool>+<datapool>" format instead of "<pool>" in URL:"http://.../<pool>/...":


Why? An image with a separate data pool is still unique within its metadata pool. For example, if one creates "rep/foo" (i.e. image "foo" in pool "rep"), they won't be able to create "rep+ec/foo". A different format in the URL shouldn't be necessary, the "datapool" parameter should be enough.

I think the only place for "metadatapool+datapool" notation is the CLI output where we try to be user friendly by making these details stand out. Everywhere else, including in URLs, we should use a conventional image spec (metadatapool/image/snap).

Okay, let's just use the datapool par here.

Just the metadata pool.

Yeah, I mean use the datapool par instead of rep+ec style.

What do you mean by "par"? Part?

idryomov · 2022-01-03T09:53:05Z

+        if err:
+            self.logger.error(f"Cannot get allow_ec_overwrites from pool ({self.pool})")
+            return err
+        self.logger.debug(f"erasure pool ({self.pool}) allow_ec_overwrites is enabled")


I don't see where the actual value returned by "ceph osd pool get POOL allow_ec_overwrites" is checked. It can be true or false but the code here doesn't seem to look at it. It only checks whether the command itself succeeds or not.

idryomov · 2022-01-03T10:02:45Z

+                break
+
+        if not bluestore:
+            return None


Did you intend for filestore (or any other objectstore except bluestore) to not produce an error? This entire function seems buggy to me because when it is called, None is interpreted as success.

Will fix it.

idryomov · 2022-01-03T10:28:41Z

+    except ValueError:
+        pool = pools
+        pass
+    return pool, datapool, image


I commented on the README, but just to reiterate, parse_disk_meta shouldn't be needed.

No, even we remove the rep+ec style this still will be needed in other places. Such as when loading and parsing the configures from the rbd pool.

Can you give a specific example? Like I said, I think rep+ec should come up only when pretty-printing. It shouldn't leak outside of that and therefore should never be parsed.

Such as from the logs:

187 2022-01-04 20:35:46,876 DEBUG [common.py:120:_read_config_object()] - _read_config_object reading the config object 188 2022-01-04 20:35:46,876 DEBUG [common.py:170:_get_ceph_config()] - (_get_rbd_config) config object contains 'b'{\n "created": "2021/12/21 02: 18:46",\n "discovery_auth": {\n "mutual_password": "",\n "mutual_password_encryption_enabled": false,\n "mutual_username": "",\n "password": "",\n "password_encryption_enabled": false,\n "username": ""\n },\n "disks": {\n "rbd+ecpool/bl ockX1": {\n "allocating_host": "node01",\n "backstore": "user:rbd",\n "backstore_object_name": "rbd.blockX1",\n "controls": {},\n "created": "2021/12/21 02:39:38",\n "datapool": "ecpool",\n "image": "blockX1",\n "owner": "node02",\n "pool": "rbd",\n "pool_id": 2,\n "updated": "2021/12/21 02:39:49",\n "wwn": "e121dbf4-10e2-4f60-83ca-4480da5875ce"\n },\n "rbd/blockX0": {\n "allocating_host": "node01",\n "backstore": "u ser:rbd",\n "backstore_object_name": "rbd.blockX0",\n "controls": {},\n "created": "2021/12/21 02:19:21",\n "datapool": null,\n "image": "blockX0",\n "owner": "node01",\n "pool": "rbd",\n "pool_id": 2,\n "updated": "2021/12/21 02:20:03",\n "wwn": "a0f1b2c6-ad93-4761-aa47-91ea9034a442"\n }\n },\n "epoch": 11,\n "ga teways": {\n "node01": {\n "active_luns": 1,\n "created": "2021/12/21 02:19:39",\n "updated": "2021/12/21 0 2:20:03"\n },\n "node02": {\n "active_luns": 1,\n "created": "2021/12/21 02:19:44",\n "updated": "20 21/12/21 02:39:49"\n }\n },\n "targets": {\n "iqn.2003-01.com.redhat.iscsi-gw:ceph-igw0": {\n "acl_enabled": true,\n "auth": {\n "mutual_password": "",\n "mutual_password_encryption_enabled": false,\n "mutua l_username": "",\n "password": "",\n "password_encryption_enabled": false,\n "username": ""\n },\n "clients": {\n "iqn.1994-05.com.redhat:client": {\n "auth": {\n "mutual _password": "",\n "mutual_password_encryption_enabled": false,\n "mutual_username": "",\n "password": "",\n "password_encryption_enabled": false,\n "username": ""\n },\n "group_name": "",\n "luns": {\n "rbd+ecpool/blockX1": {\n "lun_id": 1\n },\n "rbd/blockX0": {\n "lun_id": 0\n }\n }\n }\n },\n "controls": {},\n "created": "2021/12/21 02:19:33",\n "disks": {\n "rbd+ecpool/blockX1": {\n "lun_id": 1\n },\n "rbd/blockX0" : {\n "lun_id": 0\n }\n },\n "groups": {},\n "ip_list": [\n "172. 16.219.128",\n "172.16.219.138"\n ],\n "portals": {\n "node01": {\n "gateway _ip_list": [\n "172.16.219.128",\n "172.16.219.138"\n ],\n "ina ctive_portal_ips": [\n "172.16.219.138"\n ],\n "portal_ip_addresses": [\n "172.16.219.128"\n ],\n "tpgs": 2\n },\n "node02": {\n "gateway_ip_list": [\n "172.16.219.128",\n "172.16.219.138"\n ],\n "inactive_portal_ips": [\n "172.16.219.128"\n ],\n "portal_ip_addresses": [\ n "172.16.219.138"\n ],\n "tpgs": 2\n }\n },\n "u pdated": "2021/12/21 02:40:03"\n }\n },\n "updated": "2021/12/21 02:40:03",\n "version": 11\n}''

We can see:

"disks": { "rep+ecpool/blockX1": { "lun_id": 1 }, ....

We will save the disks as rep+ec/image style.

Yeah, and also we can save the datapool by using one datapool: ecpool par in the config, for current code I think I need to change a lot or recode many places and won't benefit much from it.

[Edit]: this style could be easily to be used by the gwcli output.

No, we should save all disks in rep/image style, or, in other words, by the image spec. For the CLI, the image spec has the following format: pool/image@snap. In ceph-iscsi, I guess it is pool/image/snap (i.e. @ isn't used) but this minor difference is irrelevant here.

The pool in pool/image@snap is always the metadata pool. The (optional) data pool is never part of the spec. Let's not deviate from the rest of RBD in ceph-iscsi.

Hmmm, okay, let me recode it this week.

xiubli · 2022-01-06T06:55:44Z

@idryomov

Have fixed them all, the gwcli ls will be like:

[root@node02 ceph-iscsi]# gwcli ls
o- / ......................................................................................................................... [...]
  o- cluster ......................................................................................................... [Clusters: 1]
  | o- ceph .......................................................................................................... [HEALTH_WARN]
  |   o- pools .......................................................................................................... [Pools: 6]
  |   | o- cephfs.a.data ......................................................... [(x3), Commit: 0.00Y/28722104K (0%), Used: 0.00Y]
  |   | o- cephfs.a.meta ....................................................... [(x3), Commit: 0.00Y/28722104K (0%), Used: 134000b]
  |   | o- datapool ........................................................ [(x3), Commit: 0.00Y/28722104K (0%), Used: 3228247703b]
  |   | o- device_health_metrics ................................................. [(x3), Commit: 0.00Y/28722104K (0%), Used: 0.00Y]
  |   | o- ecpool .............................................................. [(2+2), Commit: 0.00Y/57444208K (0%), Used: 30788K]
  |   | o- rbd ................................................................. [(x3), Commit: 36M/28722104K (0%), Used: 12500238b]
  |   o- topology ................................................................................................ [OSDs: 3,MONs: 3]
  o- disks ......................................................................................................... [36M, Disks: 3]
  | o- rbd ............................................................................................................. [rbd (36M)]
  |   o- blockX0 ...................................................................................... [rbd/blockX0 (Unknown, 12M)]
  |   o- blockX1 ...................................................................................... [rbd/blockX1 (Unknown, 12M)]
  |   o- blockX2 ............................................................................... [rbd+ecpool/blockX2 (Unknown, 12M)]
  o- iscsi-targets ............................................................................... [DiscoveryAuth: None, Targets: 1]
    o- iqn.2003-01.com.redhat.iscsi-gw:ceph-igw0 ......................................................... [Auth: None, Gateways: 2]
      o- disks .......................................................................................................... [Disks: 2]
      | o- rbd/blockX0 ..................................................................................... [Owner: node01, Lun: 0]
      | o- rbd/blockX2 ..................................................................................... [Owner: node02, Lun: 1]
      o- gateways ............................................................................................ [Up: 2/2, Portals: 2]
      | o- node01 ............................................................................................ [172.16.219.128 (UP)]
      | o- node02 ............................................................................................ [172.16.219.138 (UP)]
      o- host-groups .................................................................................................. [Groups : 0]
      o- hosts ....................................................................................... [Auth: ACL_ENABLED, Hosts: 1]
        o- iqn.1994-05.com.redhat:client .................................................... [LOGGED-IN, Auth: None, Disks: 2(24M)]
          o- lun 0 ............................................................................... [rbd/blockX0(12M), Owner: node01]
          o- lun 1 ............................................................................... [rbd/blockX2(12M), Owner: node02]

Please take a look of this, all the Rest APIs still the same as before except add a datapool=<name> parameter for some of them.

I am still testing this version, not finished yet.

BTW, do you think we need to display the <rep>+<ec>/image under the iscsi-targets ?

xiubli · 2022-01-07T08:25:35Z

Till now all my tests work well.

idryomov · 2022-01-08T10:37:54Z

+          o- lun 0 ......................................... [rep/disk_2(2G), Owner: rh7-gw1]
+    o- iqn.2003-01.com.redhat.iscsi-gw:ceph-gw3 ................... [Auth: None, Gateways: 2]
+      o- disks ................................................................... [Disks: 1]
+      | o- rep/disk_4 ........................................... [Owner: rh7-gw2, Lun: 0]


Just wondering why this line isn't right-justified like others?

I just forgot to add the ... back after deleting the +ec since last version. Will fix it.

idryomov · 2022-01-08T10:38:00Z

+      o- host-groups ........................................................... [Groups : 0]
+      o- hosts ................................................ [Auth: ACL_ENABLED, Hosts: 1]
+        o- iqn.1994-05.com.redhat:rh7-client .......... [LOGGED-IN, Auth: None, Disks: 1(1G)]
+          o- lun 0 ...................................... [rep/disk_4(1G), Owner: rh7-gw1]


idryomov · 2022-01-08T11:23:46Z


            if kwargs['pool'] not in get_pools():
                return "pool name is invalid"
+            if datapool and datapool not in get_pools():


Store get_pools() result and use it here to avoid issuing the same RADOS RPC twice.

Sure, will fix it.

idryomov · 2022-01-08T11:40:11Z

        pool  : Pool and image name may contain a-z, A-Z, 0-9, '_', or '-'
-        image   characters.
+        datapool: Data pool name for erasure code pool may contain a-z, A-Z, 0-9, '_', or '-'
+        image :  characters.


The lines are mixed up here.

idryomov · 2022-01-08T11:42:39Z


-        self.logger.error("Invalid pool ({}). Must already exist and "
-                          "be replicated".format(pool))
+        self.logger.error(f"Invalid pool ({pool}), the type is ({pool_object.type})."


Suggested change

self.logger.error(f"Invalid pool ({pool}), the type is ({pool_object.type})."

self.logger.error(f"Invalid pool '{pool}', the type is '{pool_object.type}'."

Will fix it.

idryomov · 2022-01-08T12:09:57Z

        UINode.__init__(self, self.rbd_image, parent)

+        self.datapool = image_config.get('datapool', None)
+        self.is_erasure = True if self.datapool is not None else False


It looks like is_erasure is not used anywhere and could be removed. (And again, an image with a separate data pool isn't necessarily an EC image.)

Yeah, a stale parameter from old version, will remove it.

idryomov · 2022-01-08T12:41:27Z


    # activate disk
-    api_vars['mode'] = 'activate'
+    api_vars = {'mode': 'activate'}


This might drop controls key from the dictionary added just a couple of lines above. Did you intend to do that?

Good catch, will fix it.

idryomov · 2022-01-08T13:44:24Z

            self.remove_child(child)

-    def ui_command_attach(self, pool=None, image=None, backstore=None, wwn=None):
+    def ui_command_attach(self, pool=None, image=None, backstore=None, wwn=None, datapool=None):


Attach (i.e. adding an existing image to the gateway) shouldn't ask for datapool. Given that the parameter is optional, the user can always omit it even if the image has a separate data pool. So it is flawed from the get go.

Think of the datapool parameter like the size parameter: we ask for size only on create (and resize, but resize is irrelevant here). The same goes for data pool -- it only affects the creation of the image and should be asked for only on create.

Yeah, right, I just missed the create_image parameter. Will fix it.

idryomov · 2022-01-08T13:49:43Z

            if kwargs['pool'] not in get_pools():
                return "pool name is invalid"
+            if datapool and datapool not in get_pools():
+                return "datapool name is invalid"


This error message could be more precise: a pool with a given name just doesn't exist. The name itself may very well be valid (in the sense of consisting of valid characters, etc), there is a separate check and an error message for that below.

Sounds good and will fix it.

idryomov · 2022-01-08T14:06:03Z

+    def _erasure_pool_check(self):
+        # skip it and if no ecpool specified
+        if not self.datapool:
+            return True


A data pool doesn't have to be an EC pool. A user may want to create an image with a separate replicated pool. So two things:

_erasure_pool_check() should check the pool type and, only if the pool is EC, check whether allow_ec_overwrites is enabled

The objectstore check should be removed. As I already noted in ceph-iscsi: add erasure pool support #237 (comment), enabling allow_ec_overwrites on any object store other than bluestore isn't possible in normal configurations so allow_ec_overwrites check would be sufficient.

Sure, will fix it.

idryomov · 2022-01-08T14:14:30Z

BTW, do you think we need to display the <rep>+<ec>/image under the iscsi-targets ?

Probably not.

idryomov

I don't think you meant to include gwcli/storage.py.orig file in the PR. I can't see gwcli/storage.py diff because of that.

Signed-off-by: Xiubo Li <xiubli@redhat.com>

The erasure coded pool does not support omap, here we will just store the data in it and will store the metadata in a replicated pool. This will add a "datapool=<ec_pool_name>" parameter to specify the erasure coded pool to store the data when creating a disk, and the "pool=<name>", which is "rbd" as default, will be used to store the metadata only. The backstore object name is <pool>.<image> in the replicated pool, which is the same with the none-erasure image. Signed-off-by: Xiubo Li <xiubli@redhat.com>

xiubli · 2022-01-18T00:37:34Z

I don't think you meant to include gwcli/storage.py.orig file in the PR. I can't see gwcli/storage.py diff because of that.

Removed. Thanks.

xiubli · 2022-02-14T14:05:43Z

@idryomov Please take a look when you are free, thanks.

xiubli requested a review from idryomov June 21, 2021 09:07

xiubli added the feature label Jun 21, 2021

xiubli force-pushed the erasure branch 6 times, most recently from e61a60d to 949ca2d Compare June 25, 2021 02:52

idryomov requested changes Jun 27, 2021

View reviewed changes

xiubli force-pushed the erasure branch from 949ca2d to 1bc7adf Compare July 23, 2021 09:44

xiubli requested a review from idryomov July 23, 2021 09:48

xiubli mentioned this pull request Jul 26, 2021

gwcli: fix the erasure pool profile's display info #240

Merged

xiubli force-pushed the erasure branch 2 times, most recently from 104ad8f to c7c259c Compare November 5, 2021 02:09

xiubli requested a review from ideepika November 5, 2021 03:05

xiubli force-pushed the erasure branch 3 times, most recently from f1b8906 to a8daca9 Compare November 22, 2021 12:24

ideepika reviewed Dec 6, 2021

View reviewed changes

Comment thread README Outdated

Comment thread tmp/keyring Outdated

xiubli force-pushed the erasure branch from a8daca9 to a34ed5b Compare December 6, 2021 12:28

idryomov requested changes Dec 14, 2021

View reviewed changes

xiubli added 2 commits December 20, 2021 13:44

utils: make the run_shell_command a common helper

86188b5

Signed-off-by: Xiubo Li <xiubli@redhat.com>

ceph-iscsi: allow rollback snap even a disk isn't assigned to a target

b42a375

It will return 400 error code when a disk is not assigned to any target. Signed-off-by: Xiubo Li <xiubli@redhat.com>

xiubli force-pushed the erasure branch 4 times, most recently from adfe970 to 552209f Compare December 21, 2021 03:30

xiubli requested a review from idryomov January 1, 2022 01:20

idryomov requested changes Jan 3, 2022

View reviewed changes

xiubli force-pushed the erasure branch from 552209f to 68c0557 Compare January 6, 2022 06:54

xiubli requested a review from idryomov January 7, 2022 08:25

idryomov requested changes Jan 8, 2022

View reviewed changes

xiubli force-pushed the erasure branch 2 times, most recently from cb3a5a6 to 19c8683 Compare January 10, 2022 06:23

xiubli requested review from idryomov January 10, 2022 06:27

idryomov requested changes Jan 17, 2022

View reviewed changes

xiubli added 2 commits January 18, 2022 08:34

gwcli: make pool parameter required

256b2ba

Signed-off-by: Xiubo Li <xiubli@redhat.com>

xiubli force-pushed the erasure branch from 19c8683 to 18b4aee Compare January 18, 2022 00:35

	self.logger.error(f"Invalid pool ({pool}), the type is ({pool_object.type})."
	self.logger.error(f"Invalid pool '{pool}', the type is '{pool_object.type}'."

Uh oh!

Conversation

xiubli commented Jun 21, 2021

Uh oh!

xiubli commented Jun 25, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xiubli Jun 28, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

xiubli commented Jul 26, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xiubli Jun 28, 2021 •

edited

Loading

xiubli commented Jul 26, 2021 •

edited

Loading

xiubli Jan 4, 2022 •

edited

Loading

idryomov Jan 4, 2022 •

edited

Loading

xiubli commented Jan 6, 2022 •

edited

Loading