Add target save and restore functionality

[sskaur]

This commit adds functionality to persist a gateway's state of SPDK and restore from it upon restarting. Relevant information for a restore is stored in a ceph object's OMAP.

Signed-off-by: Sandy Kaur [email protected]

[trociny]

Another thing to discuss. Do we really want to have a possibility to have several bdev per namespace? Is there a use case for this? Otherwise we could combine two commands bdev_rbd_create and subsystem_add_ns into one and would need to deal with "internal" bdev name (we could just pass the image spec to subsystem_add_ns).

The same question is actually about subsystem, i.e. if we want several namespaces per subsystem, though I can image this may be useful indeed.

[PepperJo]

Another thing to discuss. Do we really want to have a possibility to have several bdev per namespace? Is there a use case for this? Otherwise we could combine two commands bdev_rbd_create and subsystem_add_ns into one and would need to deal with "internal" bdev name (we could just pass the image spec to subsystem_add_ns).

The same question is actually about subsystem, i.e. if we want several namespaces per subsystem, though I can image this may be useful indeed.

Yes, both are desired. Multi-attach, i.e. same rbd bdev for two different namespaces although rare is a use-case for us.

[trociny]

I think we could do it this way:

nvme_gw_cli.py create_bdev -p rbd -i test will not return the bdev_name (like "Ceph0") to the user.
And instead of the current version:

nvme_gw_cli.py create_namespace -n nqn.2016-06.io.spdk:cnode1 -b Ceph0

we will use something like:

nvme_gw_cli.py create_namespace -n nqn.2016-06.io.spdk:cnode1 -p rbd -i test

And the gateway will keep internally the mapping between the current bdev names and image specs, while in the persistent config it will store image spec (bdev) -> list of namespaces mapping.

And, actually, the gateway might not provide create_bdev command. The bdev could be created automatically if it does not exist yet for this image.

[sskaur]

And the gateway will keep internally the mapping between the current bdev names and image specs, while in the persistent config it will store image spec (bdev) -> list of namespaces mapping.

For now I've gone ahead to require the --bdev name parameter for create_bdev in the cli as discussed. I'm open to changing this later if people think that's appropriate.

[trociny]

In general LGTM. There are some comments that might be address in this PR or in another PRs. I have plans to play with it and then may be will have some other comments.

And hope some other people will review and comment too.

[trociny]

Some comments about omap keys naming.

[sskaur]

I added ability to delete namespace, host, and listeners but the python SPDK RPC does not seem to have a method to delete a transport. @trociny I've created issues to keep track of comments that I didn't address in these new changes. You may want to comment on those issues to expand on what I've written.

[PepperJo]

I added ability to delete namespace, host, and listeners but the python SPDK RPC does not seem to have a method to delete a transport. @trociny I've created issues to keep track of comments that I didn't address in these new changes. You may want to comment on those issues to expand on what I've written.

We discussed in the past if create_transport is even necessary. We could implicitly create the transport on create_listener. The only problem I see is that the create_transport allows to specify options that are shared by all listeners. We don't use them yet but might want to in the future. On the other hand these transport specific features could also be part of the static config as they cannot be changed anyway (once initialized) but might be daemon-process/machine specific.

[PepperJo]

One other thing that we probably need to move to the static config of the daemon is the ip used for the listener since obviously it cannot be shared between GW nodes (in a group) or we have to add a GW node id for these kind of local options.

[sskaur]

@idryomov Do you mind taking a look at the status of this PR? I believe it is ready for final review/approval. Some topics brought up in this PR have spawned issues for further discussion before addressing in future PRs.

See: #10, #11, #12, #13, #14

[idryomov]

Much better, but I don't understand why allow_any_host and disable_allow_any_host were kept at the protocol level.