There are separate driver API calls for create_volume() and create_export()
The Solidfire driver effectively does a create_export inside the create_volume call. Compare the last 10 or so lines of _get_model_info with _do_export in solidfire.py and you'll see. The create_export method appears redundant (duplicated code).
In the Nexenta driver create_volume() and create_export() do exactly what they say. You must call them both before you can attach.
At the very least the API contract/expectations for these driver calls needs to be explicitly defined somewhere before you can say which is wrong. Should create_volume implicitly export the volume as well. If so, then what is the purpose of create_export() ?
Logically, Nexenta looks correct here.
It still looks like the _create_from_image flow is broken. It tries to connect to a volume that has not yet been exported. That it works with Solidfire is a side effect of the Solidfire choosing to make create_export() unnecessary and redundant.
There are separate driver API calls for create_volume() and create_export()
The Solidfire driver effectively does a create_export inside the create_volume call. Compare the last 10 or so lines of _get_model_info with _do_export in solidfire.py and you'll see. The create_export method appears redundant (duplicated code).
In the Nexenta driver create_volume() and create_export() do exactly what they say. You must call them both before you can attach.
At the very least the API contract/ expectations for these driver calls needs to be explicitly defined somewhere before you can say which is wrong. Should create_volume implicitly export the volume as well. If so, then what is the purpose of create_export() ?
Logically, Nexenta looks correct here.
It still looks like the _create_from_image flow is broken. It tries to connect to a volume that has not yet been exported. That it works with Solidfire is a side effect of the Solidfire choosing to make create_export() unnecessary and redundant.