_build_instance does not have a recoverable network_api.allocate_for_instance

[Joshua Harlow]

It appears that if the allocate of a instances network fails due to a race condition at the network_api layer that the instance will be set in the error state instead of trying to recover from said failure in a graceful manner (retrying could be one solution for example). Looking at the NetworkManager code it if a race happens at the code level, then an exception will be passed back which will stop the instance from continuing to build.

[jichenjc (jichenjc)]

commit f0cf1c0fc14ba44ae6af5aad93ccd2fe010094a5
may already fix this bug

[jichenjc (jichenjc)]

Allow retrying network allocations separately

    Introduce a new config option, 'network_allocate_retries', that allows
    one to retry network allocations. The default is 0 for no retries to
    match the current behavior.

    The network allocations currently get retried by a full retry of a build
    via the scheduler, if those are enabled. This patch reduces the need to
    re-schedule for simple network allocation issues.

    The retrying happens in the network alloc async greenthread, so for virt
    drivers that support the new NetworkModel, the retrying potentially
    happens in the background while the image is being downloaded, etc.