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.
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: futures. thread. ThreadPoolExecu tor directly, avoiding the side-effect of importing concurrent. futures. process. ProcessPoolExec utor.
- 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.
- 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.