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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1727358 Title: cloud-init is slow to complete init on minimized images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1727358/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
