Restore failed: error fetching address

[Curtis Hovey]

Restore can fail when bootstrapping a new server and the provider is slow to provide public addresses, as seen in
    http://reports.vapour.ws/releases/3102/job/functional-ha-backup-restore/attempt/2512

    http://reports.vapour.ws/releases/issue/5604a1a7749a561f57c47dc4

This looks like a timing related issue. Retrying or waiting longer might fix this.

[Michael Foord (mfoord)]

These failures are definitely related (as in - at least hitting the code) to the recent changes around determining the public (and private) address of a machine. "no address" is a new error, for when no preferred address has been set.

However, the restore code does set machine / provider addresses using the standard machine.Set*Addresses methods - which ought to be setting the preferred addresses. (In state/backups/restore.go:updateMachineAddresses )

I'll dig in a bit further and see if I can find anything more.

[Michael Foord (mfoord)]

Ok, I think I have it. When a new machine is created (in this case the bootstrap machine) a new record is created using State.machineDocForTemplates. This *does not* set any preferred addresses - so PreferredPublicAddress (and Private) will return "no address" error until the first time SetMachineAddresses or SetProviderAddresses is called. I can update the creation of new machines to also set the preferred addresses.

[Canonical Juju QA Bot (juju-qa-bot)]

Juju-CI verified that this issue is Fix Released in juju-core 1.24:
    http://reports.vapour.ws/releases/3144

[Canonical Juju QA Bot (juju-qa-bot)]

Juju-CI verified that this issue is Fix Released in juju-core 1.25:
    http://reports.vapour.ws/releases/3145

[Martin Packman (gz)]

This is an intermittent failure, the blesses on 1.24 and 1.25 do not mean it's been fixed. The regression is due to bug 1435283 which is present on all three branches.

[Michael Foord (mfoord)]

It *may* have been intermittent because as soon as SetMachineAddresses or SetProviderAddresses was called on the bootstrap machine the PublicAddress and PrivateAddress would become available. With the fix already landed they should be available immediately.

Have they failed since my fix landed?

[Martin Packman (gz)]

I had not realised these fixes had landed:

<https://github.com/juju/juju/pull/3446>
<https://github.com/juju/juju/pull/3447>

And this forward port is ready to go for master:

<https://github.com/juju/juju/pull/3448>

[Michael Foord (mfoord)]

A misunderstanding. mgz didn't see that I'd landed a fix and thought the transition to "fix released" was spurious.

[Curtis Hovey (sinzui)]

The commits to 1.24 and 1.25 match the tested and blessed revisions in CI, these branches are fix committed.

http://reports.vapour.ws/releases/issue/5604a1a7749a561f57c47dc4 shows that master did not have this issue at the time of the bug report, but on Friday Oct 2, it appears and is a cause of failure for 3 builds, so the bad behaviour was eventually merged into master and no needs fixing.