Hi cinder members, Eharney recently add a comment about 'resource-reset-status' command here [1] on Dec 22, and I'd like to paste his comment here to get more attention and discussion before the patch can go on.
*I'd like to discuss the general design here and get input from others before landing more reset-state commands.* * I get the feeling that we are just copying existing things because they are already there, but I think we can come up with something better.* * (Note: I asked for more details about the CLI in the spec review, but the only thing that showed up there was a command example that doesn't say anything about defaults and mirrors what existed already. So I think we can get further into details now that there's code here.)* * We also need to stop defaulting these commands to "available". It's dangerous and almost guaranteed to produce an undesirable result for someone who runs this without studying --help first, which is not good design.(I know we do this in other commands. It's wrong there, too.)* * We could at least require input of "--state <x>" rather than having a default here.* I try to figure out the his concerns there: 1. We should consider redesign the 'resource-rest-status' in the cinderclient as we could have too many reset commands here: - reset-state - snapshot-reset-state - backup-reset-state - group-reset-state with this patch - group-snapshot-reset-state with this patch Additionly, he add a new patch [2] and try to have them covered with a single reset command: (draft)cinder reset-state --type snapshot abcd-1234 --status error 2. Stop using default value 'available' for reset-status command. 3. The codes there just mirror what existed already (If the main point here is about reduce duplication, I think this could be easily fixed by another patch, and could be ignored). Please leave comments here or in the patches if you are interested in. Merry Christmas TommyLike [1] https://review.openstack.org/#/c/390169/ [2] https://review.openstack.org/#/c/413156/
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev