Open baodongli opened 4 years ago
I don't think there was a particular reason for not doing it other than we haven't seen a huge need for it... One challenge is that, as far as I know, there's no way to know whatever we'd be deleting is something we created. How do you envision this kind of thing working?
Also, just so I can better understand your needs, what is the use case? FWIW, the --dry
option was added to help avoid situations like creating users in the wrong zone, without the cluster name appended, etc. I realize that probably isn't much help after the fact, though.
With cloud onefs, we have a concept called fileshare. A fileshare is identified by an ID, and associated with a directory, capacity and protocols. We currently support NFS and SMB protocols, and are planning to add HDFS. A fileshare can be deleted and the associated directory removed. That means all the resources associated with the fileshare will be cleaned up after it's deleted.
We're planning to use this tool to create users/groups/directories for HDFS. Ideally, a fileshare with HDFS enabled should be completely cleaned up after it's deleted by the user. On the other hand, we're not sure that a user would ever need to delete it.
As you can see, given that the cluster is fully managed by Cloud OneFS (Or IMS), we're not concerned about deleting something not created by the tool.
I'm trying to use this code to support HDFS in Cloud OneFS. Is there any particular reason that deletes are not supported?