[SPDK] RPC Naming

[SPDK] RPC Naming

[Harris, James R]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

There has been quite a bit of chatter recently about the SPDK RPCs – lack of meaningful error codes in a lot of the RPCs, and at least one RPC returning data in an array with different “types”.  Another sore point is the naming of the RPCs themselves.


  1.  construct v. create (the vast majority use “construct”)
  2.  destruct v. delete v. destroy (the vast majority use “delete”)
  3.  most contain their associated component name in the RPC names, but some of the oldest ones from iscsi do not
  4.  most do not follow a noun_verb(_object) naming convention
  5.  minor nits like “construct_nvme_bdev” – this really attaches an nvme controller, which then creates bdevs for each namespace (there could be many)

I’ve put out a patch series (https://review.gerrithub.io/c/spdk/spdk/+/453036) with suggested names for all of our existing RPCs – there are almost 150 of them now.  All of the old names would still be valid, but deprecated.  We could keep the old names around as aliases for as long as needed.

The patch series has an example of how the get_rpc_methods RPC would be converted to rpc_get_methods, and converts the previously deprecated get/set/clear_trace_flag RPCs to use this new framework.  Thanks to Ben Walker for his help on making some of the Python infrastructure for this simpler than I originally coded it.

If you have an interest in the SPDK RPC API, please take some time and review this patch set.

Thanks,

-Jim

Re: [SPDK] RPC Naming

[Harris, James R]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

My intention is that the old names could stick around for years if necessary.  But we will want to update the Cinder driver at some point to use the new names.

-Jim


On 5/9/19, 7:03 AM, "SPDK on behalf of Szwed, Maciej" <spdk-bounces(a)lists.01.org on behalf of maciej.szwed(a)intel.com> wrote:

    Hi Jim,
    "We could keep the old names around as aliases for as long as needed." - that might be very long. For example: Cinder driver uses RPC calls and chaning it in this driver may cause that some older user setups may stop working. We have to be very careful about such changes - I'm sure you are aware of that, but I just wanted point that in case somebody else may have similar situation but not be fully aware.
    
    Maciek
    
    -----Original Message-----
    From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
    Sent: Wednesday, May 8, 2019 1:10 AM
    To: Storage Performance Development Kit <spdk(a)lists.01.org>
    Subject: [SPDK] RPC Naming
    
    There has been quite a bit of chatter recently about the SPDK RPCs – lack of meaningful error codes in a lot of the RPCs, and at least one RPC returning data in an array with different “types”.  Another sore point is the naming of the RPCs themselves.
    
    
      1.  construct v. create (the vast majority use “construct”)
      2.  destruct v. delete v. destroy (the vast majority use “delete”)
      3.  most contain their associated component name in the RPC names, but some of the oldest ones from iscsi do not
      4.  most do not follow a noun_verb(_object) naming convention
      5.  minor nits like “construct_nvme_bdev” – this really attaches an nvme controller, which then creates bdevs for each namespace (there could be many)
    
    I’ve put out a patch series (https://review.gerrithub.io/c/spdk/spdk/+/453036) with suggested names for all of our existing RPCs – there are almost 150 of them now.  All of the old names would still be valid, but deprecated.  We could keep the old names around as aliases for as long as needed.
    
    The patch series has an example of how the get_rpc_methods RPC would be converted to rpc_get_methods, and converts the previously deprecated get/set/clear_trace_flag RPCs to use this new framework.  Thanks to Ben Walker for his help on making some of the Python infrastructure for this simpler than I originally coded it.
    
    If you have an interest in the SPDK RPC API, please take some time and review this patch set.
    
    Thanks,
    
    -Jim
    
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    _______________________________________________
    SPDK mailing list
    SPDK(a)lists.01.org
    https://lists.01.org/mailman/listinfo/spdk
    

Re: [SPDK] RPC Naming

[Szwed, Maciej]

[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]

Hi Jim,
"We could keep the old names around as aliases for as long as needed." - that might be very long. For example: Cinder driver uses RPC calls and chaning it in this driver may cause that some older user setups may stop working. We have to be very careful about such changes - I'm sure you are aware of that, but I just wanted point that in case somebody else may have similar situation but not be fully aware.

Maciek

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
Sent: Wednesday, May 8, 2019 1:10 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] RPC Naming

There has been quite a bit of chatter recently about the SPDK RPCs – lack of meaningful error codes in a lot of the RPCs, and at least one RPC returning data in an array with different “types”.  Another sore point is the naming of the RPCs themselves.


  1.  construct v. create (the vast majority use “construct”)
  2.  destruct v. delete v. destroy (the vast majority use “delete”)
  3.  most contain their associated component name in the RPC names, but some of the oldest ones from iscsi do not
  4.  most do not follow a noun_verb(_object) naming convention
  5.  minor nits like “construct_nvme_bdev” – this really attaches an nvme controller, which then creates bdevs for each namespace (there could be many)

I’ve put out a patch series (https://review.gerrithub.io/c/spdk/spdk/+/453036) with suggested names for all of our existing RPCs – there are almost 150 of them now.  All of the old names would still be valid, but deprecated.  We could keep the old names around as aliases for as long as needed.

The patch series has an example of how the get_rpc_methods RPC would be converted to rpc_get_methods, and converts the previously deprecated get/set/clear_trace_flag RPCs to use this new framework.  Thanks to Ben Walker for his help on making some of the Python infrastructure for this simpler than I originally coded it.

If you have an interest in the SPDK RPC API, please take some time and review this patch set.

Thanks,

-Jim

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk