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
