Open Stack

On Sat, Feb 6, 2016 at 5:12 PM, Duncan Thomas <duncan.thomas at gmail.com>
wrote:

> Actually, keeping track of changed blocks on cinder volumes would make the
> cinder incremental backup substantially more efficient... Something could
> push them into cinder at detach time, and an api call for cinder to pull
> them at live backup time, and cinder backup can do the rest... Not sure of
> the none-cinder bits of the architecture, but certainly an interesting
> idea. In the event something goes wrong, cinder can assume the while device
> has changed or fall back to the current mechanism, so it is back compatible
> from a tenant point of view...
>
The mechanism that nova could call right now has no libvirt counterpart. So
with Ekko I am talking to the qemu process through the monitor socket to
initiate these commands. QEMU spits out the data I need to backup, I am as
of now unsure if the changed block bitmap itself can be extracted or if it
is all an internal tracking (I haven't looked into this).

I can see a future where, though nova-api's, both Cinder and Ekko can
perform backups without the raw data having to traverse through nova
itself, just the metadata such as changed-blocks and what not. This would
be my preferred solution rather than have Nova itself run the backup and
transfer of data to the backing storage (not to mention scheduling and
retention). Additionally it would mean that neither Ekko nor Cinder would
need to talk to the hypervisors directly and can still utilize that
low-level info.


> On 6 Feb 2016 17:56, "Sam Yaple" <samuel at yaple.net> wrote:
>
>> On Sat, Feb 6, 2016 at 3:00 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
>>
>>> On 2016-02-05 16:38:19 +0000 (+0000), Sam Yaple wrote:
>>> > I always forget to qualify that statement don't I? Nova does not
>>> > have a mechanism for _incremental_ backups. Nor does Nova have
>>> > compression or encryption because AFAIK that api only creates a
>>> > snapshot. I would also point out again that snapshots != backups,
>>> > at least not for those who care about backups.
>>>
>>> And just to be clear, you assert that the Nova team would reject
>>> extending their existing backup implementation to support this, so
>>> the only real solution is to make another project.
>>>
>>
>> I don't know if Nova would reject it or not, but as discussed it could be
>> extended to Cinder. Should Nova ever backup Cinder volumes? Additionally,
>> why don't we combine networking into Nova? Or images? Or volumes? What I do
>> assert is that we have done alot of work to strip out components from Nova,
>> backups don't seem like a good candidate to shove into Nova.
>>
>> Luckily since Ekko and Nova (just like Ekko and Freezer) don't have any
>> conflicting operations should Ekko be built separate and merged into Nova
>> it would be fairly painless process since there are no overlapping services.
>>
>> Integration with Nova where Nova controls the hypervisor and Ekko
>> requests operations through the Nova api before doing the backup is another
>> question, and that is reasonable in my opinion. This is likely an issue
>> that can be addressed down the road rather than at this moment, though.
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160206/3f8a00a8/attachment.html>