Open Stack

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