Add the ability to trash an image as part of namespace deletion

[paulrobe]

As per discussion with Aviv Caro the Vsphere Plugin team are requesting the addition of a --rbd-trash-image flag to the delete namespace grpc/cli call as a counterpart to the equivalent --rbd-create-image that we currently use in the create namespace call.

[gbregman]

@paulrobe the question is should the gateway delete all RBD images when a namespace is deleted or just ones created by it? While it's quite safe for the gateway to create RBD images it's a little risky to delete them. As it is now there is no way for the gateway to distinguish between images created by itself and images created externally by the user.

[paulrobe]

Just the image with the same name as the namespace that was initially created when we created the datastore/namespace. Maybe I'm ignorant but my understanding was when we create a namespace with the option "create_image" that creates an RBD image with the same name so we're just looking to add the converse functionality where we call Delete /api/nvmeof/subsystem/{nqn}/namespace/{nsid} with an equivalent"trash_image = true"which is passed on to you via a grpc call with --rbd-trash-image and then said image is moved to the trash.

Does that make sense or am I mistaken about something? (certainly possible)

[gbregman]

@paulrobe the image name is passed by the user so we don't have any control on it. Anyway, I'll add a record of these image names to the gateway's state so it will know to only delete them and not externally created images.

[paulrobe]

In this case the user will be the RESTAPI right so we just need to make sure that's passing the image name right?

[gbregman]

Yes. I guess we can add a feature to automatically generate an image name as well. In any case we'll need to at least get a pool name.

[gbregman]

Adding the flag in the delete command is problematic. The way the gateway update works we can't tell which flags were passed to the delete command in case the delete was a result of an update triggered by an OMAP change. We could add such information but this will complicate the code. A much simpler approach is to pass the flag when creating the namespace. The question is do we want two separate flags? One to create the image and another one trash it on delete? We could just use one flag and automatically trash any image which was created by the gateway. We could add a flag to the configuration which will either enable or disable this behavior.

[caroav]

@gbregman in case we go with your suggestion. In Ceph, when deleting data, the user must type something like "yes I'm sure" (need to find the exact phrase being used). We need to do the same.

@paulrobe is it ok for your use case, that images that were created by the GW will always be deleted when calling the delete ns?

[gbregman]

@caroav we are not interactive so we can't ask the user's approval. The closest thing we have is the "--force" parameter.

[caroav]

No need to be interactive. Just add a flag which takes a string, and this string must be "yes-I'm sure" or something like that.

[paulrobe]

For us, AFAIK, the only image created by the gateway is during a namespace creation and so if we're deleting that namespace we're happy for the related image to be deleted. @caroav Is that what you mean? Only delete the image that is tied to that namespace? Or am I missing some other possibilities?

All the other images we manipulate are done via the RBD APIs not the nvmeof ones

[caroav]

Yes that's what I mean.

[gbregman]

See ISCE-1742