Comment 21 for bug 1727358

This looks like a chain of decisions that are all locally reasonable but when put together may not give a sensible result. cloud-init uses jinja2 as a sensible templating engine. jinja2 has async handling, which relies on asyncio. asyncio uses the multiprocessing module, which has both thread and process models; and the process model sets up a secure (true random) key to use for IPC.

Possible options for eliminating this use of urandom() include:
 - making jinja2 configurable to avoid asyncio and changing cloud-init to select this.
 - adjusting asyncio to only lazily import concurrent.futures.
 - adjusting asyncio to import concurrent.futures.thread.ThreadPoolExecutor directly, avoiding the side-effect of importing concurrent.futures.process.ProcessPoolExecutor.
 - make multiprocessing configurable to knowingly preseed an insecure auth key, and have cloud-init initialize multiprocessing directly before importing jinja2.

It may or may not be worth making any changes to at all, if the problem only manifests with current linux-kvm kernel config and can be fixed there by enabling in-kernel entropy sources. This should be measured on other clouds to see if there's any benefit to boot speed at large.