Hi, A couple of years ago I created a Nova spec for the StorPool image backend: https://review.openstack.org/#/c/137830/ There was some discussion, but then our company could not immediately allocate the resources to write the driver itself, so the spec languished and was eventually abandoned.
Now that StorPool has a fully maintained Cinder driver and also a fully maintained Nova volume attachment driver, both included in the Queens release, and a Cinder third-party CI that runs all the tests tagged with "volume", including some simple Nova tests, we'd like to resurrect this spec and implement a Nova image backend, too. Actually, it looks like due to customer demand we will write the driver anyway and possibly maintain it outside the tree, but it would be preferable (and, obviously, easier to catch up with wide-ranging changes) to have it in. Would there be any major opposition to adding a StorPool shared storage image backend, so that our customers are not limited to volume-backed instances? Right now, creating a StorPool volume and snapshot from a Glance image and then booting instances from that snapshot works great, but in some cases, including some provisioning and accounting systems on top of OpenStack, it would be preferable to go the Nova way and let the hypervisor think that it has a local(ish) image to work with, even though it's on shared storage anyway. This will go hand-in-hand with our planned Glance image driver, so that creating a new instance from a Glance image would happen instantaneously (create a StorPool volume from the StorPool snapshot corresponding to the Glance image). If this will help the decision, we do have plans for adding a full-blown Nova third-party CI in the near future, so that both our volume attachment driver, this driver, and our upcoming Glance image driver will see some more testing. Thanks in advance, and keep up the great work! Best regards, Peter __________________________________________________________________________ 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
