Open Stack

Hi Preston,
No need to apologize. They are aspect of the same problem.
However, VMs backup is one of the many aspects that we are approaching
here, such as:

- VM backups
- Volumes backups
- Specific applications consistent data backup (i.e. MySQL, Mongo, file
system, etc)
- Provide capabilities to restore data even if keystone and swift are not
available
- Upload data during backup to multiple media storage in parallel
- Web Interface
- Provide capability to synchronize backups for sharded data on multiple
nodes
- Encryption
- File based incremental
- Block based incremental
- Tenant related data backup and restore
- Multi platform OS support (i.e. Linux, BSD, OSX, Windows, iOS, Android,
etc)
- Everything is upstreamed.

This looks like a list of features... and actually it is.

Block based and some multi platform OS aside, all the mentioned features
are provided to the date. Most of them are available since Kilo.

I agree with the multi API, room for vendors and to provide different
approaches, but please let me say something (*not referring specifically to
you or Sam or anyone*)

All the time people say you have to do this and that, but the facts are
that at the end of the day, always the same 6 engineers (not even full
time) are working on it since 2 years, investing professional and personal
time on it.

We try to be open, to accept everybody (even the most arrogant), to
implement features for whoever needs it, but the facts are that the only
Companies that invested on it are HP, a bit Ericsson and Orange (apologize
if I forgot anyone). We never said no to anyone about anything, never
focused only to a single Company influence, never blocked a thing... and
never will.

Wouldn't be better to join efforts if companies need a backup solution and
have their own requirements implemented by a common public Team, rather
then start creating many tools to solve the same set of problems? How can
ever competition benefit this? How can ever fragmenting projects help to
provide a better solution?

I'm sorry, but unless the TC or many people from the Community, tell us to
do something different (in that case we'll do it straight away), we'll keep
doing what we are doing, focusing on delivering what we think is the most
advanced solution, according the resources and time we have.

We need to understand that here the most important thing is to work in
Team, to provide great tools to the Community, rather then thinking to be
PTL or maintain independence just for the sake of it or focusing only on
what's the best for a single Company. If this vision is not shared, then,
unfortunately, good luck competing, while if the vision is shared... let's
do together unprecedented things.

Many thanks,
Fausto


On Sun, Jan 31, 2016 at 1:01 AM, Preston L. Bannister <preston at bannister.us>
wrote:

> Seems to me there are three threads here.
>
> The Freezer folk were given a task, and did the best possible to support
> backup given what OpenStack allowed. To date, OpenStack is simply not very
> good at supporting backup as a service. (Apologies to the Freezer folk if I
> misinterpreted.)
>
> The patches (finally) landing in QEMU in support of incremental backup
> could be the basis for efficient backup services in OpenStack. This is all
> fairly high risk, in the short term. The bits that landed in QEMU 2.4 may
> not be sufficient (there are more QEMU patches trying to land). When put
> into production, we may find faults. For use in OpenStack, we may need
> changes in libvirt, and/or in Nova. (Or *maybe* not if usage for backup
> proves orthogonal.)  The only way to work out the prior is to start. The
> timeline could be months or years.
>
> There is a need for a common API for backup as a service in the cloud.
> Something more than imitating AWS. Allow some room for vendors with
> differing approach.
>
> I see the above as not competing, but aspects of the same problem.
>
>
> ​
>
> __________________________________________________________________________
> 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/20160131/0b0248cb/attachment.html>