Open Stack

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...
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/f5b9014f/attachment.html>