One other option and maybe the better so far.... remove the ability to specify types on clone and create-from-snap altogether. This is getting redundant between migrate, replicate and retype.
The use case is what really matters here, so I think we could just always use the parent volume type for clone and create-from-snap, that way we're always getting the efficient process and it removes all of this confusion.
Then if a user wants to assign a different type to the child volume, they use the retype and have more control over whether a potentially slow and painful migration is done.
I'm a bit uncomfortable with having all of this overlap in the various API commands. It creates quite a bit of confusion and the docs for these types of features looks like code with "if "you did this"; elif "this"; elif "that"".... It's now way to create an API IMO.
One other option and maybe the better so far.... remove the ability to specify types on clone and create-from-snap altogether. This is getting redundant between migrate, replicate and retype.
The use case is what really matters here, so I think we could just always use the parent volume type for clone and create-from-snap, that way we're always getting the efficient process and it removes all of this confusion.
Then if a user wants to assign a different type to the child volume, they use the retype and have more control over whether a potentially slow and painful migration is done.
I'm a bit uncomfortable with having all of this overlap in the various API commands. It creates quite a bit of confusion and the docs for these types of features looks like code with "if "you did this"; elif "this"; elif "that"".... It's now way to create an API IMO.