Hi Peter, > Right. So just one more question now - seeing as the plan is to > deprecate non-libvirt-pool drivers in Kilo and then drop them entirely > in L, would it still make sense for me to submit a spec today for a > driver that would keep the images in our own proprietary distributed > storage format? It would certainly seem to make sense for us and for > our customers right now and in the upcoming months - a bird in the > hand and so on; and we would certainly prefer it to be upstreamed in > OpenStack, since subclassing imagebackend.Backend is a bit difficult > right now without modifying the installed imagebackend.py (and of > course I meant Backend when I spoke about subclassing DiskImage in my > previous message). So is there any chance that such a spec would be > accepted for Kilo?
It doesn't hurt to try submitting a spec. On the one hand, the driver would "come into life" (so to speak) as deprecated, which seems kind of silly (if there's no libvirt support at all for your driver, you couldn't just subclass the libvirt storage pool backend). On the other hand, it's preferable to have code be upstream, and since you don't have a libvirt storage driver yet, the only way to have support is to use a legacy-style driver. Personally, I wouldn't mind having a new legacy driver as long as you're committed to getting your storage driver into libvirt, so that we don't have to do extra work when the time comes to remove the legacy drivers. If you do end up submitting a spec, keep in mind is that, for ease of migration to the libvirt storage pool driver, you should have volume names of '{instance_uuid}_{disk_name}' (similarly to the way that LVM does it). If you have a spec or some code, I'd be happy to give some feedback, if you'd like (post it on Gerrit as WIP, or something like that). Best Regards, Solly Ross _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev