Fixing backup and restore

[Nate Finch]

My preference would be to convert the scripts into Go executables that do
the exact same thing (to start), which can then start to be refactored to
leverage all the rest of the knowledge embedded in our codebase to do
things like figure out the path to the correct mongo executable, for
example.  This would also ensure that it doesn't lag behind the codebase,
because it would get compiled and have its tests run along with the rest of
our code.  It would also prevent us from duplicating logic between go code
and bash scripts.

The conversion should only take a day or two for someone who understands
what the scripts are doing, since the logic has already been written.


On Thu, Apr 17, 2014 at 1:03 AM, John Meinel <john at arbash-meinel.com> wrote:

> So backup and restore in its original incarnation was just writing down in
> a set of scripts what we were performing at the time to make backup/restore
> work at a given site. They were a bit hackish to start with.
>
> What we really want is to integrate them into the system, and make it
> aware of those operations. "juju restore" sort of has to operate on its
> own, since the assumption is that the state server has gone away.
> But "juju backup" should actually be a request to the API Server to backup
> the state server, rather than trying to do it behind its back.
>
> The question is whether it is worth scheduling the time to do it properly,
> vs trying to continue patching up the existing work.
>
> I do know that Horacio is working on at least getting the existing one
> into a functional state. He is off until next week, and was waiting on some
> feedback from William as to how to proceed.
>
> John
> =:->
>
>
>
> On Wed, Apr 16, 2014 at 6:27 PM, Curtis Hovey-Canonical <
> curtis at canonical.com> wrote:
>
>> The backup and restore test has passed 1 out of a 500 runs. I have
>> never succeeded in using backup and restore. This feature is broken,
>> and because it is always broken, new bugs have been introduced.
>>
>> The initial bug caused by a race condition when restore is fixed. I
>> think there are now 3 other bugs represented in these two bug reports:
>>
>>     * juju-backup command fails against trusty bootstrap node
>>       https://bugs.launchpad.net/juju-core/+bug/1305780
>>     * backup restore timeout restarting agent
>>       https://bugs.launchpad.net/juju-core/+bug/1304116
>>
>> I see these issue testing on my own machines and in CI:
>>
>> * backup assumes mongodb-client is installed. This isn't the case for
>> trusty because it using juju-mongodb. The client is installed, but the
>> bash script that is backup assumes mongodump is in the path. on
>> trusty, we guarantee /usr/lib/juju/bin/mongodump.
>>
>> * backup can kill the state-server. Well done. If I had gotten the
>> tarball back from the backup, I could have immediately restored it.
>> When backup cripples the state server, it is then impossible to juju
>> scp the file to my local machine. Maybe the issue is simply that the
>> backup portion of the script exits before juju and mongodb are backup?
>> Maybe backup needs to be aware of HA changes to make a safe backup?
>>
>> * I sometimes get a backup file. I cannot restore though. Sometimes
>> restore states is succeeded, but juju status never works afterwards.
>> Restore doesn't succeed most of the time, it reports it cannot get the
>> public address. HA may be  a factor in this since this error appeared
>> about the time HA was being added to the code.
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140418/a5d0fdb5/attachment.html>